You updated the A record or nameservers exactly like the instructions said. A DNS checker confirms the domain resolves to the right IP. And yet, when you open the site, you get cpanel" class="auto-link">wordpress-missing-a-temporary-folder-upload-error" class="auto-link">cPanel's generic "Website Coming Soon" page, an Apache placeholder, or worse — someone else's site. This one trips up more customers than actual DNS mistakes do, because the DNS part is usually already correct. The problem is almost always one step further down the chain: the web server on that IP doesn't know your domain belongs to it yet.

Symptom: What You're Actually Seeing

This issue shows up in a few recognizable ways:

  • A generic "Web Server's Default Page" or "It works!" placeholder instead of your site
  • cPanel/WHM's built-in "Website Coming Soon" screen
  • Someone else's website — usually another customer sharing the same server IP
  • A browser SSL warning showing a certificate for a completely different domain name
  • dig or nslookup shows the correct IP, but the page content is wrong regardless of which network you check from

The giveaway that this isn't a DNS problem: if dig yourdomain.com already returns the right IP consistently from multiple locations, DNS has done its job. The web server is the one dropping the ball.

Cause: Why the Server Doesn't Know Your Domain Yet

On a shared cPanel server, one IP address can host dozens or hundreds of separate accounts and domains. Apache (or LiteSpeed) uses name-based virtual hosting to figure out which account's files to serve — it reads the Host header your browser sends and matches it against a list of domains it's been told about. If your domain isn't on that list, Apache falls back to whatever is configured as the default virtual host, which is where the placeholder page comes from.

The most common reasons a domain ends up missing from that list:

  • The domain was never added to the hosting account. Pointing DNS at an IP and adding the domain in cPanel are two completely separate steps. A lot of people do the first and assume the second happens automatically.
  • It was added as the wrong domain type. If you meant to add it as an addon domain but it's sitting unconfigured, or a subdomain was created without linking it to the right document root, Apache has no matching vhost entry.
  • The account is suspended or not yet fully provisioned. A new account still going through automated setup, or one suspended for a billing issue, will serve the default page even with perfect DNS.
  • Old A records from a previous host are still floating around. If your registrar's DNS panel still has records SkyServer never received the update for, or if a CDN/proxy (like Cloudflare) is caching an outdated origin IP, your browser may be hitting the correct-looking address but landing on the wrong physical server.
  • You're testing before propagation finished, but your local resolver already cached the new IP. Less common, but possible if you tested immediately after a nameserver change — your machine sees the new IP while the server itself was mid-provision.

Fix: Step by Step

Work through these in order — most tickets we see resolve at step 1 or 2.

  1. Confirm the domain is actually attached to your hosting account. Log in to cPanel and check Domains. Your domain (and www alias) should be listed as either the primary domain or an addon domain, with a document root pointing at the folder your site files are in. If it's not there, add it — this alone fixes the majority of "default page" reports.
  2. Verify the IP actually matches the account's IP. Run dig yourdomain.com +short and compare it against the IP shown in cPanel's home page or in your WHM account summary. If they don't match, the DNS record is pointed at the wrong server entirely — go back and fix the A record, not the vhost config.
  3. Check for a suspended or unprovisioned account. In WHM, search for the account under List Accounts. A suspended account shows a different (but similarly generic) holding page. Clear whatever's blocking it — usually a billing or verification hold — and it'll serve normally within a minute or two.
  4. Rebuild Apache's configuration if the domain is listed but still not resolving right. Occasionally a domain is correctly added in cPanel but the underlying Apache vhost config didn't regenerate. From WHM, run Rebuild Apache Configuration (or via SSH: /scripts/rebuildhttpdconf && service httpd restart, adjusting the service name for LiteSpeed if that's your web server).
  5. Clear old DNS records at the source, not just at the destination. If you migrated from another host and DNS is still managed at your registrar or at Cloudflare, double-check there isn't a leftover A record, a proxied orange-cloud entry, or a cached edge node still pointing at the old IP. Set Cloudflare to "DNS only" temporarily while you confirm the origin is correct, then re-enable the proxy.
  6. Bypass DNS entirely to isolate the problem. Edit your local hosts file (/etc/hosts on Mac/Linux, C:\Windows\System32\drivers\etc\hosts on Windows) to map your domain directly to the server IP, then visit the site. If it loads correctly this way, the server side is fine and you're dealing with pure propagation delay — just wait it out. If it still shows the default page even with the hosts file override, the problem is 100% server-side (back to step 1).

Prevention

  • Add the domain in cPanel/WHM before or immediately after updating DNS, not days later. There's no harm in having both done at once — the site simply won't be reachable until DNS catches up either way.
  • When migrating from another host, remove or update DNS records at every place they exist — registrar, old host, and any CDN — rather than assuming the new host's instructions cover all of them.
  • After any domain or account change, test with a hosts file override first. It tells you in seconds whether you're chasing a DNS issue or a server-side one, instead of guessing.
  • If you're on WHM managing multiple accounts, keep a habit of running Rebuild Apache Configuration after bulk domain changes or account restores — it's a cheap step that rules out a whole category of "domain added but not working" tickets.

Frequently Asked Questions

I added the domain in cPanel and it still shows the default page. What now?

Give it a minute for Apache's config to regenerate automatically, then try the hosts-file override test described above. If it loads correctly via hosts file but not normally, you're just waiting on DNS propagation. If it still fails even with the override, rebuild Apache's configuration from WHM and restart the web service.

Why do I see someone else's website instead of a blank placeholder?

This usually means your DNS is pointed at a shared IP where your domain isn't configured, so the web server serves whichever domain happens to be set as that IP's default vhost — which could be another customer's site. Adding your domain to your account (step 1 above) fixes this.

Does this mean my DNS settings are wrong?

Not necessarily. If dig shows the correct IP from multiple networks, your DNS is doing exactly what it's supposed to. The remaining problem lives on the server, not in the DNS zone.

How long should I wait before assuming it's a real problem, not propagation?

If a DNS checker tool shows the new IP consistently across several locations and it's been more than a couple of hours, propagation is not the bottleneck anymore. At that point, move on to checking the domain's status in cPanel/WHM.

Can Cloudflare or another proxy cause this even after I fix the origin server?

Yes. If Cloudflare's proxy (orange cloud) is enabled, visitors hit Cloudflare's edge first, and Cloudflare caches its own view of your origin. Switch the record to "DNS only" while troubleshooting so you're testing the real origin server directly, then re-enable the proxy once you've confirmed the fix worked.