Subdomain vs Addon Domain: Plan a Second cPanel Site

Web Hosting & Domains / cPanel / Website setup

Choose a subdomain such as blog.example.com when the second site belongs under your existing domain. Choose an addon domain such as example.net when it needs its own registered name on the same cPanel account. For either option, give an independent site its own document root, configure the authoritative DNS, and verify HTTPS before launch.

The name you choose does not automatically create an application, publish its files, or establish a separate hosting account. A reliable setup plan keeps those decisions visible instead of treating “add domain” as the whole job.

01 / Choose the address visitors should remember

A subdomain is a name beneath an existing domain: blog.example.com or help.example.com. An addon domain is an additional registered domain hosted through the same cPanel account. The cPanel glossary describes addon domains as separately configurable directories that let one account manage multiple domains, and notes that the domain must be registered.

These choices describe organization and ownership. Do not select one because someone promises an automatic search-ranking improvement. Choose a stable address, a clear purpose, and a maintenance arrangement you can support.

A different domain also brings a separate registration and renewal commitment. Record who controls the registrar account and who will renew it, even when the website sits beside another site in the same hosting dashboard.

02 / Confirm what the hosting plan actually permits

Check the plan’s domain allowance, storage, database allowance, and any application requirements before starting. The ability to add another name does not establish that the plan meets the second site’s needs.

cPanel account settings include limits for addon domains, subdomains, databases, disk space, and bandwidth. The provider determines what your account receives. If a control is missing or a limit is reached, ask the host about the supported options.

Write down who will administer each site. If another business needs its own cPanel login, ownership, or resource management, discuss a separate account with the host. cPanel’s addon-to-account conversion documentation explains that a standalone account gives more control over resources such as databases, FTP accounts, and SSH access.

Do not treat different folders as evidence of independent account administration or guaranteed security isolation. Define the access and maintenance requirements before choosing the account arrangement.

Also plan backups and recovery. Record which files, databases, uploads, and other services belong to the new application so that a later move does not depend on someone remembering the setup.

03 / Keep an independent site’s content in the intended directory

The document root is the directory from which the server serves a domain’s public files. It is a filesystem location, not a public-domain registration or a DNS record.

cPanel’s creation guide explains that selecting Share document root makes the new domain serve the existing domain’s content. For a separate site, review that checkbox and specify a separate root where the interface permits it.

For example, your main site might use public_html, while the second uses public_html/blog-site or another host-approved location. Those paths illustrate the decision; use the actual path shown in your account rather than copying an example blindly.

Allowed locations vary. cPanel documents a host-controlled restriction on document roots outside public_html. If the interface rejects a path, use a permitted location or ask the provider. You do not need to change server-wide settings to follow this guide.

If you want two addresses to show one existing site, sharing content may be intentional. Decide the preferred public address and redirect behavior separately, instead of accidentally creating two independently accessible copies.

04 / Create the hosting entry and record the result

In current cPanel interfaces, start in Domains → Create a New Domain. Older host instructions may use “Addon Domains” or “Subdomains.” Follow the controls available in your account.

1. Enter the exact intended hostname, such as blog.example.com, or the additional registered domain.
2. Review the shared-document-root choice.
3. Confirm the separate site’s document root and any automatically populated fields.
4. Submit the entry, then inspect the result in Domains.

The Domains list shows the domain, document root, and redirect information. Record those values before deploying content. Check the spelling of the hostname and ensure that its root is not the directory of an unrelated live site.

An addon setup can also create an associated subdomain. Namecheap explains this cPanel architecture. Seeing that associated name does not mean visitors must use it as the site’s primary address.

Host ownership checks can affect creation. For example, Namecheap’s addon-domain instructions allow a domain-control validation process when retaining third-party nameservers. Follow the provider’s documented process rather than changing nameservers simply to dismiss an error.

05 / Update the authoritative DNS, not merely a local zone

The server needs a hosting entry, and visitors need DNS that directs the hostname to the intended service. Neither task substitutes for the other.

First identify which provider’s nameservers are authoritative for the domain. If the domain uses Cloudflare’s usual full setup, Cloudflare is the authoritative DNS provider and you manage its public records there. Adding a record only inside cPanel does not update that separate Cloudflare zone.

Use the host’s required record type and destination. A hostname might use an address record or an appropriate CNAME, depending on the service. Our A vs CNAME guide covers that specific choice.

Preserve unrelated records. Namecheap notes that changing nameservers does not automatically transfer existing DNS records to cPanel and can disrupt website or email service. Before any intentional nameserver migration, inventory the records and prepare the destination zone.

For a second site, keep a small record of the hostname, DNS provider, record type, destination, and date changed. If DNS and hosting disagree, that record helps you identify which layer needs correction.

Do not use an exact “propagation time” as a substitute for checking the answer being returned. If the hostname still points elsewhere, inspect the authoritative records and any cached answers before editing the site’s files.

06 / Verify HTTPS for the exact hostname

After DNS and hosting are aligned, check the certificate for the address visitors will use. A successful domain entry is not proof that HTTPS is ready.

cPanel’s SSL/TLS Status interface reports certificate details, unsecured or expiring names, and AutoSSL problems. On some installations it appears within a unified SSL/TLS Certificates interface.

Inspect the relevant hostname and read any validation error. Ask the host how certificates are issued and renewed for your plan. Do not bypass a browser certificate warning as a launch workaround.

Test each intended public address, including a www variant if you will use one. Confirm that redirects end at the chosen HTTPS address and that the expected site loads there.

If a proxy or CDN is involved, verify that the complete supported HTTPS configuration is in place with that provider and the host. Avoid changing encryption settings by trial and error to make a warning disappear.

07 / Check the site, then document later changes

Check more than the home page. Open an internal page, load an image, and try the site’s ordinary login or enquiry workflow using appropriate test data. Record what you observed and any unresolved issue before announcing the address.

Be deliberate about later document-root changes. cPanel states that changing the root does not move the files; it changes where the server looks. Plan the files and application configuration alongside that change.

The same documentation explains that removing a domain entry retains its directory and content. Removal is not a complete site deletion or a domain-registration cancellation. Preserve a backup and understand related email and DNS consequences before retiring an entry.

Frequently asked questions