Website Not Working After DNS Change: How to Fix It Fast

by

Website not working after DNS change usually means the new DNS records are incomplete, incorrect, not fully propagated, or pointing to a server that is not ready yet. In many cases, the website itself is fine. The problem is that the domain is no longer reaching the right place consistently.

This is one of the most common website outages after migrations, hosting moves, Cloudflare setup, nameserver changes, or A record edits. The good news is that most DNS problems follow a predictable pattern and can be fixed methodically.

Quick Fix

  • Check whether you changed nameservers, A records, CNAME records, or Cloudflare proxy settings.
  • Confirm the domain points to the correct server IP.
  • Make sure the new hosting or origin server is actually ready to serve the domain.
  • Wait for propagation if the change was recent, but do not assume propagation is the only issue.
  • Clear local DNS cache and test from another network.
  • Check for old AAAA records that may point to the wrong IPv6 address.
  • Verify that SSL is installed on the new destination if the site uses HTTPS.
  • Check whether email, subdomains, or CDN records were broken during the change.
  • If using Cloudflare, confirm the correct DNS record type and proxy status.
  • Test the site by hostname and by server IP separately.

What Does “Website Not Working After DNS Change” Mean?

This usually means you changed the DNS for a domain, and now the site does not load correctly for you, for some users, or for everyone.

That failure can appear in different ways:

  • the site does not open at all,
  • the domain opens the wrong website,
  • one device works while another does not,
  • HTTP works but HTTPS fails,
  • the homepage loads but other parts are broken,
  • Cloudflare or browser errors appear after the change.

DNS changes do not only affect one thing. They can affect:

  • the main website,
  • subdomains,
  • email routing,
  • CDN or proxy behavior,
  • SSL routing,
  • server validation and hostname matching.

This is why a DNS change can break a site even when the web files themselves never changed.

Why a Website Stops Working After a DNS Change

Most cases come from a short list of real causes.

1. The Domain Points to the Wrong IP Address

This is one of the most common causes.

The A record may point to:

  • an old server,
  • the wrong hosting account,
  • a staging server,
  • a decommissioned machine,
  • a server that does not host the domain.

If the IP is wrong, the browser may reach a real server, but not the right website.

2. Nameservers Were Changed, but the Zone Was Not Recreated Correctly

This is a major cause after moving DNS between registrars, Cloudflare, hosting panels, or DNS providers.

The nameserver change may succeed, but the new DNS zone may be missing:

  • A records,
  • CNAME records,
  • MX records,
  • TXT records,
  • subdomain records.

People often think they “moved DNS,” but they really moved only the nameservers and forgot to rebuild the full zone properly.

3. DNS Propagation Is Incomplete

Propagation is real, but it is also overused as an excuse.

Yes, DNS changes can take time to appear everywhere. But if the records are wrong, waiting longer will not fix anything.

Propagation is most likely when:

  • some users see the new site,
  • some users still see the old site,
  • mobile data works but home Wi-Fi does not,
  • one DNS resolver shows the new IP and another still shows the old one.

Propagation can delay recovery, but it is not the root cause if the new records are misconfigured.

4. The New Server Is Not Ready for the Domain

Sometimes the DNS is correct, but the destination server is not ready yet.

Typical examples:

  • the virtual host was not added,
  • the domain was not attached in hosting,
  • the site files are missing,
  • the web server does not listen for that hostname,
  • the origin server firewall blocks requests.

In that case, DNS points correctly, but the website still fails.

5. HTTPS Is Broken on the New Destination

This is very common after DNS changes.

The domain may now point to the new server, but:

  • the SSL certificate is missing,
  • the certificate does not match the hostname,
  • the certificate chain is incomplete,
  • Cloudflare SSL mode no longer matches the new origin,
  • HTTPS redirects are configured before SSL is ready.

That can make the website look down when the real issue is just HTTPS on the new target.

6. Old AAAA Records Still Point to the Wrong IPv6 Address

This is a hidden but very common cause.

You may fix the A record for IPv4, but leave an old AAAA record in place. Then:

  • some devices use IPv4 and work,
  • some devices prefer IPv6 and fail,
  • the site looks random and inconsistent.

If the website works for some users but not others after a DNS change, check IPv6 early.

7. Cloudflare or CDN Proxy Records Were Set Incorrectly

If you use Cloudflare or another proxy, DNS is not just about the destination IP. The proxy status matters too.

Common mistakes:

  • proxied record points to the wrong origin,
  • DNS-only should have been used but proxy was enabled,
  • Cloudflare SSL mode does not match the new server,
  • wrong record type was chosen,
  • origin firewall blocks CDN traffic after the change.

8. Subdomains or Related Records Were Forgotten

The main website may be fixed while other parts stay broken.

This often affects:

  • www,
  • mail,
  • blog,
  • shop,
  • api,
  • staging subdomains.

One missing subdomain record can make the whole migration look like a broader outage.

9. Local DNS Cache Still Uses the Old Records

Even when public DNS is correct, your device or router may still be using old cached data.

This is more likely if:

  • the site works on mobile data but not Wi-Fi,
  • another device on another network sees the new site,
  • you changed DNS very recently,
  • the router keeps stale cache longer than expected.

How to Fix a Website That Is Not Working After a DNS Change

Start by identifying exactly what changed, then verify the current records before changing anything else.

1. Confirm What You Changed

This sounds obvious, but it matters.

Did you change:

  • nameservers,
  • A records,
  • AAAA records,
  • CNAME records,
  • Cloudflare proxy status,
  • MX records too,
  • the hosting destination?

Do not troubleshoot “DNS” broadly if the real change was only one specific record.

2. Check Which IP the Domain Points To Right Now

Before assuming propagation, verify the current live answer.

You need to know:

  • what IP the domain returns now,
  • whether that IP is correct,
  • whether the same answer appears across different resolvers.

If the answer is wrong, propagation is not the main issue. The DNS record itself is.

3. Test the Site by Server IP

If possible, test the new server directly.

This helps answer a key question:

  • Is the server itself ready, or is DNS only exposing a server-side problem?

If the site does not work even when you reach the correct server directly, DNS is not the only issue.

4. Check Whether the Domain Is Attached Correctly on the New Hosting

DNS can point correctly to the server, but the hosting may still not know which site to serve.

Check:

  • the domain is added in hosting,
  • the virtual host exists,
  • the document root is correct,
  • the right site files are in place,
  • the server responds to the correct hostname.

5. Check HTTP and HTTPS Separately

Try both versions:

  • http://example.com
  • https://example.com

If HTTP works and HTTPS fails, the real issue is likely SSL, not DNS.

Check for:

  • missing certificate,
  • wrong certificate,
  • Cloudflare SSL mode mismatch,
  • forced HTTPS before the new SSL is ready.

6. Check for Leftover AAAA Records

If the site works for some users but not others, inspect IPv6 records right away.

Common pattern:

  • IPv4 A record is updated correctly,
  • old AAAA record remains,
  • IPv6-capable users reach the wrong host.

This is one of the most common “it works for some people only” causes after DNS changes.

7. Verify Cloudflare or CDN Record Settings

If you use Cloudflare, inspect:

  • record type,
  • proxy status,
  • origin IP,
  • SSL mode,
  • edge redirects,
  • origin firewall behavior.

Make sure the record points to the correct server and that the new origin is ready to work behind the proxy.

8. Flush Local DNS Cache

If the public DNS is correct but your device still sees the old route, flush the local DNS cache and test again.

This matters most when:

  • the site works elsewhere already,
  • your device still sees the old destination,
  • the DNS change was recent.

9. Restart the Router

Routers sometimes keep stale DNS or bad network state longer than expected.

If the website works on mobile data but not home Wi-Fi, restart the router before doing more complex changes.

This often fixes “still seeing the old site” cases faster than people expect.

10. Try Another DNS Resolver

If one resolver still serves old or wrong data, test a public DNS provider temporarily.

This helps determine whether the issue is:

  • your device cache,
  • your ISP resolver,
  • actual public DNS records,
  • or incomplete propagation.

11. Check Subdomains One by One

If the main site works but other services do not, audit the zone record by record.

Check:

  • www,
  • mail,
  • cpanel,
  • api,
  • shop,
  • other custom subdomains.

Do not assume one correct record means the whole zone is healthy.

12. Check Whether Email Broke Too

Some DNS changes break the website and email at the same time.

If nameservers changed, verify that these still exist correctly:

  • MX records,
  • SPF TXT records,
  • DKIM records,
  • DMARC records.

Even if your current goal is the website, this check prevents a second outage later.

13. Review Recent Changes First

This is often the shortest route to the cause.

Ask:

  • Did we move hosting?
  • Did we change nameservers?
  • Did we enable Cloudflare?
  • Did we force HTTPS before SSL was installed?
  • Did we forget an old IPv6 record?

Most DNS-related website failures start right after one of those changes.

Advanced Troubleshooting

Separate DNS Problems from Server Problems

This is the most important distinction.

  • If the domain points to the wrong place, it is a DNS problem.
  • If the domain points to the correct place but the site still fails, it is likely a server, SSL, or application problem.

Do not keep editing DNS if the DNS already points correctly.

Compare Different Networks and Resolvers

Test the site from:

  • mobile data,
  • home Wi-Fi,
  • another ISP,
  • another DNS provider.

This reveals whether the issue is true propagation, stale local cache, or a broader misconfiguration.

Watch for Mixed A and CNAME Logic

Some site failures come from using the wrong record type in the wrong place.

Examples:

  • root domain should use A record but was set another way,
  • www should point to the root but points elsewhere,
  • a proxy expects one type of record but another was used incorrectly.

Bad record design can make DNS changes look random.

Check Canonical Redirect Behavior After DNS Changes

Sometimes DNS is correct, but the site still appears broken because the application or web server redirects visitors to the old domain, wrong host, or wrong protocol.

This is common after:

  • domain migration,
  • HTTPS changes,
  • WordPress URL mismatch,
  • reverse proxy setup.

If the page loads the wrong hostname after DNS changes, check redirects too.

Check TTL Expectations Realistically

Low TTL can help reduce propagation delay, but it does not fix wrong records.

Do not rely on “just wait” if:

  • the IP is wrong,
  • the zone is incomplete,
  • SSL is broken on the new target,
  • the server is not configured for the domain.

Waiting helps only when the new configuration is already correct.

Prevention Tips

  • Lower TTL before planned migrations, not after.
  • Document the full DNS zone before changing nameservers.
  • Check A, AAAA, CNAME, MX, and TXT records together.
  • Prepare SSL on the new server before switching traffic.
  • Verify Cloudflare or CDN settings before enabling the proxy.
  • Test the new server by hostname and by IP before go-live.
  • Keep staging, production, and old hosts file overrides under control.
  • Change one layer at a time when possible.

The best prevention is simple: treat DNS changes like infrastructure changes, not like a small setting flip.

When to Contact Support

Contact your hosting provider if:

  • the domain points correctly but the server does not respond properly,
  • HTTPS is broken on the new destination,
  • the domain is not attached correctly on the server,
  • you need server logs or virtual host changes you cannot access.

Contact your DNS or CDN provider if:

  • nameserver changes are involved,
  • records do not resolve as expected,
  • proxy behavior may be wrong,
  • edge configuration is part of the problem.

Focus on local troubleshooting if:

  • the site works on mobile data but not your Wi-Fi,
  • another device already sees the new site,
  • your router or local DNS cache may be stale.

FAQ

Why is my website not working after a DNS change?

Usually because the new records are wrong, incomplete, not fully propagated, or pointing to a server that is not ready yet.

How long does a website take to work after a DNS change?

It depends on TTL, resolver cache, and the type of change. But if the records are wrong, waiting longer will not fix the problem.

Why does my website work for some users but not others after DNS changes?

Usually because of partial propagation, stale local DNS cache, old router cache, or a bad AAAA record affecting only some networks.

Can SSL break a website after a DNS change?

Yes. If the domain points to a new server without the correct certificate or with the wrong proxy SSL mode, the website can fail even though DNS is technically correct.

What is the first thing to check after a DNS change breaks a site?

Check what IP the domain points to right now and confirm that the destination server is the correct one and is ready to serve the domain.

Final Thoughts

Website not working after DNS change usually comes down to one simple truth: the domain is not reaching the right destination cleanly and consistently yet.

Start by checking the current DNS answer, then confirm the new server is actually ready, then test HTTPS, IPv6, Cloudflare, and local cache in that order. That approach solves most post-DNS-change outages much faster than just waiting and hoping propagation fixes everything by itself.

Leave a Comment