Skip to content
Rescue 404
Rescue

DNS and Domain Problems

Domain points to wrong website

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

When a domain resolves but shows the wrong site, parking page, or hoster default, DNS (or the vhost behind it) is aimed at the incorrect target—fix A/AAAA/CNAME (and proxy mode) to the intended server, then confirm the host’s document root for that hostname. This is not NXDOMAIN; the name already resolves.

Wrong-website symptoms mean DNS found an IP—just not the one that serves your content—or the correct IP still hosts a default/parked vhost. Migrations, leftover CDN proxies, and mixed www/apex records are the usual culprits. This guide walks from public dig answers to hosting document roots without assuming WordPress itself is broken.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • Cloudflare documents that incorrect or conflicting DNS records cause hostnames to resolve to unexpected targets or fail to reach the intended origin. (Cloudflare DNS troubleshooting)
  • Cloudflare’s manage-DNS-records guide covers creating and updating A/AAAA and CNAME records that control where a hostname points. (Cloudflare manage DNS records)
  • MDN defines DNS as the system that maps hostnames to network addresses clients use to reach a site. (MDN DNS glossary)

What the error means

Browsers load whatever content answers at the IP (or CDN edge) that DNS returns. If A/AAAA still point at an old server, a parking host, or another client’s account, visitors see that site even though your new WordPress copy is healthy elsewhere. Proxied CDN setups add another layer: orange-cloud records show CDN anycast IPs in dig, while the origin A record behind the proxy must still target the right machine. Wrong document root or missing server-name/vhost on the correct IP produces hoster default pages that look identical to “DNS points at the wrong place.” Distinguish this from ERR_NAME_NOT_RESOLVED: here dig returns an address; the problem is which address and what that host serves for your Host header.

Common symptoms

  • Domain loads a different company’s site, an old redesign, or a “coming soon” from a previous host
  • Browser shows a registrar parking page or ads instead of your WordPress site
  • Hoster default welcome page appears though files were uploaded elsewhere
  • dig returns an IP that is not your current server or expected CDN pattern
  • www shows the new site while apex still shows the old one (or the reverse)
  • Temporary host URL is correct, but the custom domain is not
  • SSL certificate names another brand or the wrong hostname on that IP

Most likely causes

  1. 01 A/AAAA still point at the previous host after migration
  2. 02 CNAME for www aimed at an outdated target or parking hostname
  3. 03 CDN proxy enabled while origin IP behind it is wrong or offline
  4. 04 Correct IP, but the web server vhost/document root is not mapped to this domain
  5. 05 Multiple A records left behind—some clients hit the old address
  6. 06 Nameservers correct but someone edited the wrong zone file / wrong domain
  7. 07 Load balancer or reverse proxy upstream still targets a stale backend

What changed before the problem started

  • Hosting migration completed for files but DNS was never updated
  • CDN or reverse proxy enabled with an incorrect origin
  • Staging domain or addon domain accidentally received the live A record
  • Old host recycled the IP onto a parking or default site
  • www CNAME changed without updating apex A/AAAA
  • Agency pointed the domain at a holding page during a redesign and never restored it

Troubleshooting steps

  1. 01

    Confirm the name resolves and capture the public IP

    Use dig/nslookup (or an online checker) for apex and www against 1.1.1.1. Note every A/AAAA answer. Success signal: you know whether DNS returns your intended target, an old IP, parking, or mixed answers.

  2. 02

    Compare that IP to your current host’s documented address

    In the hosting panel, find the shared IP, dedicated IP, or “point domain here” instructions. For proxied CDN setups, compare the origin record inside the CDN, not only the public anycast IP. Success signal: mismatch is proven (wrong IP) or ruled out (IP correct → vhost problem).

  3. 03

    Correct A/AAAA/CNAME at the authoritative DNS host

    Edit records only where dig NS says you should. Point apex and www at the intended targets; remove duplicate A records that still list the old server. Success signal: public dig matches the new intended answers after TTL.

  4. 04

    If the IP is already correct, fix the vhost / document root

    In cPanel/Plesk/server config, ensure this hostname’s document root is the WordPress directory with your `wp-config.php`. Addon/parked domain mistakes commonly serve `/public_html` defaults instead. Success signal: the temporary URL and custom domain show the same site.

  5. 05

    Align www and apex deliberately

    Decide which host is canonical. Make both DNS records and any host redirects consistent so one variant cannot keep serving the old target. Success signal: both hostnames land on the same intended content (with one redirect if you choose).

  6. 06

    Purge CDN cache after origin is right

    If a CDN sat in front during the wrong-origin period, purge cache or briefly use development mode so visitors are not stuck on a cached parking/default page. Success signal: edge and origin both show the correct site.

When to stop troubleshooting

Escalate when you cannot tell which account controls live DNS, the IP is shared and vhost mapping needs root/host support, CDN origin settings are locked to another team, or the “wrong site” may be an active compromise/parking dispute. Bring dig output, intended IP, and screenshots of both the wrong page and the correct temporary URL.

Information to collect before requesting help

  • 01 Exact hostname(s) showing the wrong site
  • 02 Public dig A/AAAA (and CNAME) for apex and www
  • 03 Intended hosting IP or CDN origin IP
  • 04 Where NS point and which panel you edit
  • 05 Whether a temporary host URL shows the correct WordPress site
  • 06 CDN/proxy on or off for each hostname
  • 07 Recent migration, DNS, or redesign cutover dates

How a professional repairs the problem

We verify public DNS targets, correct A/AAAA/CNAME (and CDN origin) to the intended host, then confirm the server vhost/document root serves your WordPress files for that Host header. After content matches, we align www/apex, purge edge caches, and tidy SSL so browsers stop trusting leftovers from the wrong server.

Frequently asked questions

Is this the same as ERR_NAME_NOT_RESOLVED? +
No. That error means DNS never returned an IP. Wrong-website means DNS succeeded but aimed at the wrong place—or the right IP still serves a default/parked vhost.
Why does the temporary URL work but my domain does not? +
Files are on the new host, but the domain’s A/AAAA (or CDN origin) still point elsewhere—or the domain is not assigned to that account’s document root yet.
Can Cloudflare show the wrong site if DNS looks “updated”? +
Yes. Proxied records hide the origin IP in public dig. If the origin behind the proxy is still the old server, visitors see that content until origin is corrected and cache purged.
Will changing WordPress Site URL fix a parking page? +
Not if DNS or the vhost never reaches your WordPress install. Fix the target first; then update Site URL if links still point at an old domain.
Why do only some visitors see the old site? +
Resolver cache and multiple A records. Wait out TTL, remove obsolete A/AAAA, and have holdouts flush local DNS or try a public resolver.
Could malware cause “wrong website”? +
Sometimes—malicious redirects or hacked DNS can send people elsewhere. If DNS and vhost look correct but content is foreign, treat it as a security incident as well as a DNS check.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.