A reseller adds domains to accounts they do not log into. WHM has its own screens for that, and they behave slightly differently from the cPanel versions a client would use.
Three domain types, one conversion, and the reasons each one is chosen.
The three types, decided by what the domain is for
An addon domain is a different domain serving a different website, with its own directory. It shares the account's disk, bandwidth and limits, and nothing else.
A subdomain is a name in front of an existing domain, also with its own directory. It inherits part of the parent domain's standing and is the usual home for a blog, a shop or a staging copy.
A parked domain is a second name pointing at an existing site. No directory, no separate content, no separate website. The usual case is the .net version of a .com, or a former name that people still type.
Choosing the wrong one is the ordinary cause of two addresses unexpectedly serving the same site.
Why adding an addon domain creates a subdomain too
When an addon domain is added, a subdomain of the account's main domain is created alongside it, pointing at the same directory. That is how the panel wires it up internally, and it means the site is now reachable at two different addresses with identical content.
Nothing warns about it. From a search engine's point of view it is duplicate content, and which of the two addresses gets treated as the real one is not your decision unless you make it.
The fix is a canonical tag naming the address you want to be authoritative, and a redirect from the other. The check is to request the subdomain address directly and see what happens: if it serves the site rather than redirecting, the work is not done. There is more on the pattern in addon domains, subdomains and duplicate content.
Doing it from WHM rather than from cPanel
The practical difference is scope. In cPanel you are working inside one account, and the account is implied. In WHM you pick the account first, which means you can add a domain to a client's account without their password and without asking them to do it.
The second difference is the limits. An account can only hold as many addon domains as its package allows, and WHM shows you that ceiling while cPanel simply refuses at the point of creation. If the client's package has no addon domains available, the screen will not let you add one, and the answer is the package rather than the domain.
This is a case worth knowing about: a reseller whose own allocation permits nothing cannot grant a package that permits something. The limit is checked at both levels.
Converting an addon domain into an account
Sooner or later an addon domain outgrows being a folder inside somebody else's account. A client wants their own login, or the site is being sold, or it simply needs limits of its own.
The conversion turns that addon domain into a full cPanel account. It moves the files, creates the account with its own username and home directory, and takes the associated databases and email with it.
Two things are worth knowing before running it.
The database prefix changes. Databases carry the account username as a prefix, so a new account means new database names. Anything with a configuration file pointing at the old name has to be updated, and the application will show a database connection error until it is.
It counts against your account allocation. One addon domain becomes one account, so the number of accounts you are permitted goes down by one. On a full allocation the conversion is refused.
Take a backup first. This moves data between accounts, and it is not the kind of operation to run on a Friday afternoon.
Parking a domain, and when not to
Parking is right when a second name should show the same site: a common misspelling you own, a country variant, an old brand name.
Parking is wrong when the second name should be its own site later. Once people link to a parked name and it serves identical content, separating the two is a redirect job rather than a setting change, and any standing the name has built belongs to the site it was pointing at.
There is one more case worth naming. If a domain is bought for later and simply parked with no thought, it is still a domain that can be used to send mail claiming to come from you. That is a separate problem covered in how to park or hold a domain before you use it, and it is worth two minutes.
Subdomains created from WHM
The screen creates the DNS record and the document root together, exactly as the cPanel version does, and the same rule applies: the document root decides where the files go, and it is easier to set correctly now than to move later.
One thing that catches people out is removal. Deleting a subdomain does not delete its directory. The files stay on disk, still counting against the quota, and still served if anything else points at that path. If the point of the removal was to reclaim space, the directory has to go separately.
Certificates follow the hostname, not the account
Every domain and subdomain added here is a separate hostname needing its own certificate coverage. Automatic issuance usually handles it within a run or two, provided the name resolves to this server.
The exception is a name pointed at an external service. Whoever serves the name issues its certificate, which is not you, and no amount of running AutoSSL on this server changes that.
A short order of operations
Decide which of the three types the domain actually is, from what it is for rather than from what is quickest. Check the account's package allows it. Add it from WHM against the right account. For an addon domain, handle the duplicate address it creates. Confirm the certificate appears within a day. And if you are converting one into an account, back up first and expect to update a database name.
