You want to add a blog, a shop, a staging copy or a second business to your hosting. cPanel offers three ways, and they are not interchangeable.
The decision is cheap now and expensive later, because reversing it means every published address has to be redirected.
Subfolder
example.com/blog/; a directory inside the existing site.
Nothing to create. It uses the site's existing certificate, and it is part of the same site in every sense that matters: the same application, the same configuration, and the same accumulated standing in search results.
That last point is the reason this is the default answer for content. A new section under an established site starts with the site's reputation behind it. The same content on a new hostname starts from nothing.
The cost is coupling. It runs inside the same application, so it shares its PHP version, its plugins and its faults.
Subdomain
blog.example.com. A separate hostname on the same account.
Technically independent: its own directory, its own application, its own configuration. You can run a completely different system there without touching the main site.
Two consequences people meet later. It needs to be covered by a certificate, and a subdomain created after the certificate was issued is not covered until issuance runs again. For that, see SSL for subdomains and addon domains.
And search engines treat it as largely separate from the main site. Whether that is good or bad depends entirely on what you are putting there.
Right for: staging sites, applications, documentation, anything technically distinct. Creating and managing subdomains walks through the panel side, and setting up a subdomain with DNS explains the case where it points somewhere else entirely.
Addon domain
otherbusiness.com. A different domain served from the same account.
Completely independent. Its own name, its own registration to pay for, its own certificate, its own everything. Visitors have no way to tell the two sites share hosting.
Right for a genuinely separate business or brand. Wrong as a way of splitting up one business, where it fragments effort across names that each have to be established separately.
Creating and managing addon domains deals with setting one up.
The decision, stated simply
Content that belongs to this site and should benefit from it: subfolder. Blog, guides, support articles, a section of the same business.
Something technically separate: subdomain. Staging, an application, a tool, anything needing its own software.
A different business: addon domain.
The most common regret is the first one: putting the blog on a subdomain because it was tidier, then wanting its accumulated standing to help the main site and finding it does not transfer without redirecting everything.
Staging deserves one extra rule
A staging subdomain is the right choice, and it must not be indexed, otherwise your unfinished copy competes with your real site in search results, and visitors occasionally land on it.
Add a noindex instruction, and password-protect it if it is not meant to be public at all. Note that blocking it in robots.txt alone can leave it listed without a description, which is worse. Writing a robots.txt goes into it.
What all three share
They live in the same hosting account, so they share its disk, its bandwidth and its processing allowance. Three busy sites on one shared plan compete with each other. There is more on noticing before customers do in monitoring your hosting resources.
They also share a compromise. A vulnerability in one application can reach files belonging to the others, which is the argument for keeping genuinely unrelated sites on separate accounts rather than saving a few pounds by consolidating. Addon domains, subdomains and duplicate content explains the other shared-account trap.
If you chose wrongly
Move the content, then redirect every old address to its new match, permanently, and to the equivalent page rather than to a homepage.
It works, it is a day of careful mapping, and it is entirely avoidable by spending five minutes on the decision first. Planning redirects goes into doing it without losing the traffic.
Confirm what was actually created
All three arrangements are made through similar screens and produce different things on disk, and the difference matters later.
ls -la ~/public_html/ | head -12 grep -E 'example.com|sub.example.com' /etc/userdatadomains 2>/dev/null curl -sI https://sub.example.com/ | head -1
Read where the document root actually points. A subdomain created inside the main site's directory inherits everything above it, including rewrite rules that can make it unreachable.
The entry in the domain list states the type and the owner, which resolves the common confusion where nobody remembers whether something was set up as a subdomain or as a separate domain.
Each one needs its own certificate coverage
A new name is not covered by the existing certificate, and the first secure request produces a warning.
echo | openssl s_client -connect sub.example.com:443 -servername sub.example.com 2>/dev/null \ | openssl x509 -noout -ext subjectAltName | head -3
Automatic issuance usually adds it within a day, and that day is when the site is newest and most likely to be shown to somebody.
Where it needs to be public immediately, request the certificate deliberately rather than waiting for the routine run. Managing AutoSSL covers triggering it.
Moving between them later is a redirect problem
Changing the arrangement changes every address, and the content is the easy half.
Moving a section from a subfolder to a subdomain, or the reverse, means every existing link, bookmark and search result points at the old form. Without redirects those become errors rather than a move.
curl -s https://example.com/sitemap.xml | grep -c 'loc'
Capture the address list before making the change, since it is the source for building the mapping and cannot be reconstructed afterwards. That is the main argument for choosing deliberately at the start rather than expecting to adjust later. Redirecting a domain or page covers writing them.