Why a Restored cPanel Account Shows the Default Page Instead of the Site

You restore a cPanel account or finish a migration. The files are there, the database imported cleanly, and WHM lists the account as active. But when you open the domain in a browser, you get the server's default page instead of the website. The usual first guess is that the restore failed. Usually it didn't. The web server just couldn't connect the request to the account. Once you know how Apache decides which site to serve, this symptom makes sense. It also points to a short list of things to check.

What the default page is telling you

Think of a shared building with one reception desk on each floor. A courier arrives at a floor, which is the IP address, and gives the receptionist a name, which is the domain. The receptionist checks the list for that floor only. If the name is on it, the parcel goes to the right office. If it isn't, the parcel goes to whoever is listed first on that floor, the default. Apache works the same way with name-based virtual hosts. A virtual host, or vhost, is a block of configuration that says "for this domain, on this IP and port, serve files from this directory." When a request arrives, Apache first narrows the candidates to the vhosts bound to the IP and port the connection came in on. Then it compares the Host header the browser sent with each vhost's ServerName and ServerAlias. If one matches, that site is served. If none match, Apache uses the first vhost defined for that IP and port. On a cPanel server, that first vhost is the server's default host. It serves the default page, which an administrator may have customized. So the default page is not an error page in the usual sense. It means: "A request reached this IP, but no account on this IP claims this domain." That clue narrows the problem a lot. Either the request reached a different IP than the one the account's vhost uses, or the vhost for that domain doesn't exist in the live configuration. The same matching logic explains a related symptom, where a site presents another domain's certificate. That case is covered in Why Your Site Serves Another Domain's SSL Certificate.

IP mismatch between DNS and the vhost

This is the most common cause after a restore. During a restore or transfer, cPanel assigns the account an IP on the new server. That's usually the main shared IP, or a dedicated IP if one was requested or kept. The Apache vhost is built on that IP. The DNS zone, meanwhile, may still say something else. There are a few typical ways this happens. In the first, the zone was restored with the old server's IP in its A records. If the domain uses nameservers somewhere else, such as a registrar, an external DNS provider, or a CDN, nobody updated the records there. Visitors either never reach the new server, or they reach a different machine. In the second, the account came back on a dedicated IP, but DNS points to the server's shared IP, or the other way around. Both IPs belong to the same server, so traffic does arrive. But it lands on the floor where this domain isn't on the list, and Apache serves the default host. This catches people out because pinging the domain shows the right server, and everything looks correct at a glance. In the third, the account was moved to a different IP after the restore, for example through WHM's option to change a site's IP address. But a DNS zone hosted somewhere else still has the previous value. To check, compare two things: what DNS actually returns, and which IP the account's vhost is bound to. On cPanel, /etc/userdatadomains lists each domain with its owner, document root, and IP:port. That gives you the server's side of the story in one line. You can then skip DNS entirely and ask the server directly for the domain on a specific IP with curl --resolve. This tells you whether the vhost works on that IP, regardless of what any resolver or browser cache says.

BASH

# What public DNS returns (check both IPv4 and IPv6)
dig +short A example.com
dig +short AAAA example.com

# Which IP cPanel bound the account's vhost to (read-only)
grep 'example.com' /etc/userdatadomains

# Ask the server for the site on a specific IP, bypassing DNS
curl -sI --resolve example.com:80:192.0.2.10 http://example.com/

Replace example.com and 192.0.2.10 with the real domain and the IP from userdatadomains. Suppose curl against the vhost IP returns the site's own headers, such as a redirect to its canonical URL or the WordPress-style headers you expect. Then the server is fine and DNS is pointing somewhere else. Now suppose curl against the IP DNS returns gives you the default page. That confirms the mismatch. The fix depends on which side is wrong. Either update the A record to the IP the account uses, or move the account to the IP DNS points to. Whichever you choose, make it a deliberate decision, especially if the dedicated IP exists for a reason such as an older SSL setup or a mail reputation the customer cares about.

The AAAA record nobody remembered

IPv6 deserves its own mention because people miss it often. A zone can carry an AAAA record from the old server, or from a template, that points to an IPv6 address where this account has no vhost. Many browsers and operating systems prefer IPv6 when it's available. So some visitors, often the ones on networks with working IPv6, get the default page. Others, on IPv4 only, see the site normally. That split is a strong hint. Reports like "it works on my phone's mobile data but not on office Wi-Fi," or the reverse, should make you check the AAAA record before anything else. Either remove the stale AAAA record, or make sure the account actually has an IPv6 address assigned and its vhost listens on it. A record that points to an address nothing answers for is worse than no record.

When the server itself is behind NAT

Some servers, especially VPS and cloud instances, only see a private IP on their network interface. The public IP is mapped to it by the provider's network. cPanel handles this with a NAT mapping between local and public addresses. Vhosts get built on the local IP, while DNS zones get the public one. If that mapping is missing or stale after a migration, two things can go wrong. A zone may be written with the private IP, which isn't reachable from the internet. Or vhosts may be built on an address that incoming traffic never arrives on. The result looks like a DNS problem, but the cause is the server's own idea of its IP addresses. If the IPs in userdatadomains and the zone file don't look like anything the provider assigned, check the NAT configuration in WHM before editing records one by one.

The vhost doesn't exist in the live config

Sometimes DNS is correct and the IPs match, but the domain still isn't in the configuration Apache has loaded. cPanel keeps per-domain settings in its userdata files and generates httpd.conf from them. If a restore was interrupted, if httpd.conf was edited by hand outside cPanel's templates, or if the web server wasn't restarted after the rebuild, the userdata can be correct while the running config is missing the domain. You can confirm this by asking the web server to dump its parsed vhosts. On most Apache builds, apachectl -S lists each vhost with its IP, port, and names. If the domain isn't in that list, Apache can't match it, and the default host wins. On cPanel, the usual fix is to rebuild the configuration from userdata with /usr/local/cpanel/scripts/rebuildhttpdconf and then restart the web server. If the rebuild fails with a syntax error, fix that error first. It's often a leftover custom include from the old server. LiteSpeed setups add one more step. Depending on how LiteSpeed is configured, it may read Apache's configuration or use its own. If Apache's config looks correct and LiteSpeed still serves the default page, a graceful restart of LiteSpeed is usually the next step.

Document root problems look different

Document root problems are worth separating from everything above, because they produce different symptoms. The document root is the directory a vhost serves files from, normally public_html for the primary domain, and often a subfolder for addon domains. If the vhost matched but the document root is empty, you usually get a 403 Forbidden or a directory listing, depending on the server's settings. You don't usually get the server's default page. If the document root points to a path that doesn't exist, which happens when an addon domain's folder was renamed or not included in the backup, you typically get a 404 or an error in the domain's error log. A wrong but existing document root shows the wrong content: an old placeholder index.html, a parked page, or another project's files. This distinction saves time. If you're truly seeing the server's default page, start with IPs and vhosts. If you're seeing a 403, a 404, or stale content, go straight to the document root in userdatadomains, then check that the directory exists, contains an index file, and is owned by the account user. An index.html sitting next to index.php is easy to miss. It's also a common reason a restored WordPress site shows an old "coming soon" page, because many servers prefer index.html when both files exist.

Common mistakes while chasing this

The first is trusting the browser. Browsers, local DNS caches, and CDNs all hold on to old answers. Testing with curl --resolve against a known IP removes those variables. It's usually the first thing a support engineer does before touching any configuration. The second is fixing DNS in the wrong place. Editing the zone in cPanel changes nothing if the domain's nameservers point to a registrar or an external DNS provider. Check which nameservers the domain actually delegates to before editing records. The third is assuming a dedicated IP carried over. A restore can bring an account back on the shared IP even if it had a dedicated one on the old server, depending on the options chosen. The reverse can happen too. Look at the IP the account has now, not the one you remember. The fourth is restoring files over a working vhost and then blaming the files. If the vhost was fine and the site broke after you copied content, the cause is in the document root. It isn't Apache. When a restored account shows the default page, read it as a routing message, not a data-loss message. Check what DNS returns for both A and AAAA records, compare that to the IP in userdatadomains, and test the server directly with curl --resolve. If those agree and the domain still isn't matched, rebuild the vhost configuration. Look at the document root only when the symptom is a 403, a 404, or the wrong content.