Addon Domain Showing the Wrong Site in cPanel? The Fix

You added an addon domain in cPanel, uploaded your files, and pointed the domain — but when you visit it, you get your primary site instead, a blank 404, or a browser SSL warning. This is one of the most common support tickets we see, and it's almost always one of four things: DNS, document root, a stray .htaccess rule, or AutoSSL still catching up. Here's how to tell which one you've got and fix it.

Symptom: What You're Actually Seeing

Before you start changing settings, pin down exactly what's happening, because the fix is different for each:

• Addon domain shows your primary site's homepage — usually a document root or DNS problem.
• Addon domain shows "Index of /" (a directory listing) — no index file at that path, or wrong path entirely.
• Addon domain shows a 404 or "This site can't be reached" — DNS hasn't resolved to your server yet.
• Browser shows "Not Secure" or a certificate name mismatch — AutoSSL hasn't issued a certificate for that specific domain yet.

Cause 1: DNS Isn't Actually Pointing at Getwebup Yet

Adding an addon domain in cPanel only tells your hosting account to expect that domain. It does nothing to the domain's DNS unless its nameservers already point at Getwebup. If you registered the domain elsewhere and haven't updated its A record or nameservers, visitors are still landing on whatever server used to host it — or getting a generic "can't be reached" if it was never hosted before.

Check it from your terminal or cPanel Terminal:

dig +short yourdomain.com A

Compare that IP against your server's IP, shown in cPanel's home screen under "Shared IP Address" (or your VPS dashboard if you're on a dedicated IP). If they don't match, you have two options:

• Point the domain's nameservers to Getwebup's, and let cPanel manage the zone automatically, or
• Keep the domain's current nameservers and just add/edit an A record there, pointing the root and www to your server's IP.

Give it 15 minutes to a few hours to propagate, depending on the old record's TTL. Don't restart the addon domain setup while you wait — DNS is the only thing missing.

A Quick Trick to Test Before DNS Propagates

You can confirm the server side is configured correctly even before DNS catches up, by forcing your own request to hit the right server:

curl -I -H "Host: yourdomain.com" http://your.server.ip

If that returns a 200 with the right content, your server config is fine and you're purely waiting on DNS. If it returns the wrong site or an error, the problem is on the server — move to Cause 2 or 3.

Cause 2: Wrong or Shared Document Root

When you created the addon domain, cPanel offered a document root like /home/username/yourdomain.com. Two mistakes happen constantly here:

• "Share document root" got checked — this deliberately makes the addon domain serve the same folder as another domain. If you didn't mean to do that, it explains exactly why you're seeing your primary site.
• Files got uploaded to the wrong folder — people often upload straight to public_html out of habit, instead of the addon domain's actual subfolder.

Verify the real document root two ways:

1. In cPanel, open Domains and check the "Document Root" column next to the addon domain.
2. Or via SSH, look at the account's userdata file: cat /var/cpanel/userdata/username/yourdomain.com and check the documentroot line.

If it's shared with another domain and shouldn't be, edit the addon domain in cPanel, uncheck sharing, and set a dedicated folder. Then move your site's files into that folder — File Manager's move function or an SFTP client both work.

Cause 3: No Index File, or a Stray .htaccess Rule

If the document root is correct but you're seeing a blank directory listing, there's simply no index.html or index.php in that folder yet. Upload one (even a placeholder) to confirm the path is right before deploying the full site.

If instead you're being redirected somewhere unexpected, check for host-based rewrite rules bleeding in from the parent public_html/.htaccess. A common culprit:

RewriteCond %{HTTP_HOST} ^yourprimarydomain\.com$ [NC]
RewriteRule ^(.*)$ /some-folder/$1 [L]

Rules like this are meant to scope redirects to the primary domain only, but a missing NC flag, a typo in the host pattern, or Apache's mod_userdir settings can cause it to apply more broadly than intended. Comment the block out, reload the addon domain, and re-add the rule with a tighter host condition if the redirect is genuinely needed.

Cause 4: AutoSSL Hasn't Covered the New Domain Yet

AutoSSL validates domain ownership over HTTP before it issues a certificate — which means it can't run successfully until DNS is pointed correctly (Cause 1). Until then, the browser either shows a certificate for your primary domain (a mismatch warning) or refuses the connection outright as "Not Secure."

Once DNS is confirmed pointing at your server:

1. Go to cPanel > Security > SSL/TLS Status.
2. Find the addon domain in the list, check the box, and click Run AutoSSL.
3. Give it a few minutes — it re-validates and issues a fresh certificate automatically.

If it keeps failing, check that nothing is blocking http://yourdomain.com/.well-known/acme-challenge/ — a security plugin, a blanket HTTPS-redirect rule, or Cloudflare in "orange cloud" mode in front of the domain can all break the validation request.

Quick Reference Table

Prevention: Save Yourself the Next Ticket

• Point DNS (or nameservers) at Getwebup before you finish adding the addon domain, not after — it shaves hours off the whole process.
• Leave "Share document root" unchecked unless you deliberately want two domains serving identical content.
• Drop a placeholder index.html into the new folder immediately, so you can confirm routing before the real site goes up.
• Keep host-based rewrite rules scoped tightly with proper regex anchors and the NC flag where needed — multi-domain accounts are exactly where sloppy .htaccess rules cause cross-domain leakage.