Introduction

After a cPanel account transfer, an addon domain can start loading the main account site or a default placeholder instead of its own content. That usually means the website files are present, but the addon domain was not rebound cleanly to the right document root or the new server is still serving a fallback virtual host for that hostname.

Treat this as a binding and document-root problem before assuming the website files are missing. Start by proving which directory the addon domain should serve, then confirm the new server actually maps that hostname to the expected path.

Symptoms

  • The addon domain loads the main site instead of its own site after transfer
  • Visiting the addon domain shows a default cPanel page or placeholder site
  • The files for the addon domain exist, but the wrong content is served
  • Only the primary domain works correctly while addon domains are wrong
  • The issue starts immediately after cPanel migration or restore
  • DNS points at the new server, but the addon domain still resolves to the wrong document root

Common Causes

  • The addon domain was not restored cleanly in the destination cPanel account
  • The new server mapped the hostname to the wrong document root
  • A default or fallback virtual host is handling the addon domain request
  • The addon domain’s DNS now points to the new server before the binding is fully rebuilt
  • A parked-domain, alias, or older binding survived the migration and overrides the intended site
  • The website files were restored, but the hostname-to-directory relationship was not

Step-by-Step Fix

  1. Confirm which document root the addon domain is supposed to use on the destination server, because you need the intended path before you can tell whether the server binding is wrong.
  2. Check the addon domain entry inside the destination cPanel account and verify that the domain still exists there, because a transfer can move the files without fully rebuilding the addon-domain definition.
  3. Compare the configured document root for the addon domain with the actual location of the site files, because a wrong path will make the server fall back to the main site or another default response.
  4. Verify that the addon domain’s DNS points only to the destination server you are testing, because mixed DNS can make a correct cPanel binding look wrong when requests still hit another host.
  5. Review the web-server or virtual-host state for that hostname if the cPanel entry looks correct, because a stale or default vhost can keep serving the wrong site even when the account panel shows the expected mapping.
  6. Check for alias, parked-domain, or old domain associations that survived the migration, because one leftover binding can intercept the hostname before the intended addon-domain path is used.
  7. Test the addon domain with a known file in the expected document root after each correction, because a direct content check proves whether the hostname is finally serving the right directory.
  8. Compare one working domain binding and one broken addon-domain binding in the same account, because differences in root path or hostname registration usually reveal what the restore missed.
  9. Document every addon domain and its final document root after recovery, because cPanel transfers often restore files first while leaving secondary domain bindings to be fixed later.