The Subdomains tool in cPanel creates a name under your domain and gives it a directory. That is the whole job on the panel side, and it works only for domains whose DNS this server answers.
If the domain's DNS is elsewhere, or you need a wildcard, that is a DNS record in place of a panel setting. How to Set Up a Subdomain with DNS deals with that side.
Creating one
Open Subdomains, type the prefix, and choose the domain it belongs to.
cPanel proposes a document root automatically: usually a folder of the same name inside public_html. That default is fine, and it is worth reading before accepting.
Placing it inside public_html means the same files are also reachable at example.com/shop/, which is a second address serving the same content. Placing the directory outside public_html avoids that entirely. For why it matters, see Addon Domains, Subdomains and Duplicate Content.
The document root is the setting that matters
Everything else about a subdomain follows from where it points.
Two subdomains sharing a document root serve the same site under two names. A subdomain pointed at public_html itself serves your main site rather than anything separate, which is occasionally intended and usually a mistake.
Check the path after creating it. The panel lists each subdomain with its root, and reading that list is faster than working out why a subdomain shows the wrong site.
Installing something on it
A subdomain behaves like any other site on the account: it has a directory, and whatever is in that directory is served.
An application installer will offer the subdomain as a destination once it exists. Leave the installer's directory field empty for the site to live at the subdomain root rather than a folder beneath it; the same trap as installing on a main domain. How to Install Applications with Softaculous goes into the fields.
Redirecting one instead
The Subdomains screen offers a redirect option, which sends visitors elsewhere rather than serving the directory.
Useful for a name you own but do not want to maintain separately. Note that a redirected subdomain still needs certificate coverage, because the browser checks the certificate before following the redirect.
Removing one properly
Removing the subdomain in the panel deletes the name and the DNS record. It does not delete the directory or its contents.
So the files remain, using disk, and remain reachable at whatever path they occupy under public_html. Delete the directory separately once you are sure, and take a copy first, because this is the point at which people discover something else was living in there.
Common problems in the panel
"Subdomain already exists" when it plainly does not: usually a leftover DNS record from a previous one, or the name existing on another account on the same server.
The subdomain shows the main site. Its document root is public_html. Change the root rather than adding rules to work around it.
A browser warning on the subdomain. The certificate does not cover it. Run AutoSSL after creating any subdomain instead of assuming coverage extends automatically. Managing AutoSSL in WHM explains why failures appear only in a log.
How many is reasonable
Subdomains are free and they are not free of consequence.
Each one is a hostname that needs certificate coverage, a directory that needs maintaining, and a potential source of duplicate content if it serves the same files as something else.
A handful with a purpose is normal. Twenty accumulated over years, most of which nobody can account for, is a cleanup job waiting, and each abandoned one is a name still answering for content nobody is watching.
Check it after creating
Load the subdomain over HTTPS, confirm it shows what you intended in place of the main site, and confirm the path in the panel matches the directory you meant.
Those three take a minute and they catch every problem in this article except the certificate, which needs AutoSSL to have run first.
For the shorter walkthrough aimed at a first subdomain, How to Set Up a Subdomain goes into the same job in fewer steps.
Confirm it resolves before assuming the panel is wrong
A subdomain that returns nothing is usually a name that does not yet exist rather than a document root that is misconfigured.
dig sub.example.com A +short dig sub.example.com A @8.8.8.8 +short curl -sI http://sub.example.com/ | head -1
If your own resolver answers and a public one does not, the record exists and has not propagated. That is a matter of waiting, and changing settings during the wait creates a second problem to untangle later.
If neither answers, the record was not created, which happens when the domain's DNS is hosted elsewhere. Creating a subdomain in the panel sets up the site; it does not create the record at an external provider. Moving DNS to a third party provider deals with where the record then belongs.
The certificate has to include it
A new subdomain is not covered by the existing certificate, so the first secure request produces a warning even though everything else is correct.
echo | openssl s_client -connect sub.example.com:443 -servername sub.example.com 2>/dev/null \ | openssl x509 -noout -subject -ext subjectAltName
Read the alternative names list and check the new name appears. Automatic issuance usually picks it up within a day, and that day is when the site is newest and most likely to be shown to somebody.
Where the subdomain is meant to be public immediately, request the certificate deliberately rather than waiting for the routine run. Managing AutoSSL covers triggering it.
Rules from the parent apply, and sometimes should not
A subdomain created inside the main document root inherits the rules above it, which produces behaviour nobody configured.
ls -la ~/public_html/.htaccess ~/public_html/sub/.htaccess 2>/dev/null grep -nE 'RewriteRule|Redirect|Header' ~/public_html/.htaccess | head
A rewrite that sends everything to the main application will do the same for the subdomain, so the new site is unreachable while its files sit exactly where they should be.
The clean arrangement is a document root outside the parent, so nothing is inherited. Where that is not possible, the subdomain needs its own rules that stop the inherited ones applying, and that is more fragile than moving the directory.
