Why is my website not showing after I changed DNS?

The two-minute check

Everything below turns on one question: what do the domain’s own nameservers say right now? That answer isn’t cached and it isn’t what your computer remembers; it’s the configuration as it stands. If it’s right, you’re waiting. If it’s wrong, no amount of waiting will help.

1. Look the domain up at lookup.icann.org and note the nameservers listed. That’s where the authoritative records live.
2. Query those nameservers directly. This needs a command, because browser tools such as Google’s Dig show you a resolver’s (possibly cached) answer and can’t be pointed at a specific nameserver. On a Mac or Windows computer, a developer or coding agent runs dig example.com A @ns1.yourprovider.com or nslookup example.com ns1.yourprovider.com, naming one of the nameservers from step 1; Vercel’s DNS documentation shows the same form. Query A and AAAA for the bare domain and CNAME for www.
3. Compare each answer with the record the host shows on its domain screen, character by character.
4. Open the host’s domain screen and read what it reports: an alert such as Vercel’s “Invalid Configuration” or Netlify’s “Pending DNS verification”, nothing wrong, or a certificate still being issued.

Then go to the section that matches:

Waiting or broken: what “propagation” actually is

DNS changes don’t spread across the internet. Every record carries a time-to-live, or TTL, and any resolver that looked the record up may keep its copy for that long before asking again. Your change is visible to a given resolver as soon as its old copy expires. So the longest you should ever wait for a record change is the TTL the old record had when you changed it, plus a little. A record with a five-minute TTL is done in minutes for nearly everyone; a one-day TTL means some visitors see the old answer for up to a day.

Two things are slower. A brand-new name that didn’t exist before can be held back by negative caching, where resolvers remember that the name had no record for as long as the zone’s settings allow, commonly one to three hours. And a nameserver change goes through the registry, whose own records for your domain carry a long TTL (two days for .com, as a direct query of the registry’s servers shows): Cloudflare says to allow up to 24 hours and Vercel up to 48 for that specific change. Those are the only cases where a day or two is a real estimate.

So the test is simple. If the authoritative answer from step 2 is correct and the host reports nothing wrong, you are waiting, and you know the ceiling. If the authoritative answer is wrong, nothing is propagating; the configuration itself needs fixing. Don’t let anyone, including a support chatbot, tell you to wait 48 hours before doing step 2.

The record is wrong

The most common cause, and the least glamorous. Compare the authoritative answer with the host’s domain card: the type (A versus CNAME), the exact value, and the name it’s on. Frequent mistakes: a CNAME value with a typo or a missing character; the record added at www.www or example.com.example.com because the panel appends the domain automatically; an A record where the host wanted a CNAME; a value copied from a different project. Vercel reports these as an “Invalid Configuration” alert and Netlify as pending DNS verification. Fix the record, save, and the host’s check clears within the TTL.

The change was made at the wrong DNS provider

If the nameservers from step 1 belong to a different company from the panel you edited, your edit went to a zone nobody is asking. This happens when a domain is registered at one company but its DNS is at Cloudflare, or when a builder set up its own nameservers long ago. The registrar’s DNS panel will happily accept records that the world never sees. Sign in to the provider the nameservers actually name and make the change there. The diagnostic guide has a table for recognising whose nameservers they are.

The nameservers delegate somewhere else

Two variants. The domain’s nameservers may still point at a previous provider or builder because someone changed records but not nameservers, or changed nameservers but the registry hasn’t updated yet; step 1 shows which nameservers the registry has. Or a subdomain such as app may have its own NS records that delegate it to another service, so records you add for it at the main provider are ignored. In either case, the fix is at the registrar for the domain’s nameservers, or at the delegated provider for the subdomain, and the DNS guide covers moving a whole zone safely if that’s what you’re really doing.

The apex and www are configured differently

example.com and www.example.com are two names with two records, and hosts need both added. If one works and the other doesn’t, the missing piece is at the DNS, the host, or the certificate for the failing name. That’s its own guide: why www works but the bare domain doesn’t.

Old records are still present

Adding a new record without removing the old one leaves two answers, and resolvers use whichever they get. Two A records at the apex, one old and one new, send some visitors to the old host. A CNAME added at a name that still has an A record is rejected by many panels, or worse, silently ignored. Vercel’s troubleshooting page says explicitly to remove outdated records to prevent conflicts. Query the name with Dig and look at the whole answer, not just the first line; then delete what shouldn’t be there.

A stale AAAA record

AAAA records are IPv6 addresses. Devices on IPv6-capable networks, which includes most phones on mobile data, prefer the AAAA record when one exists. If your old host had one and the new host doesn’t (Vercel, for instance, doesn’t support IPv6), the leftover AAAA record sends those devices to the old host while everyone else sees the new site. Query AAAA for both names and remove any the new host didn’t ask for.

Proxied DNS or a CDN is in the way

If the answer shows Cloudflare’s addresses rather than your host’s, the record is proxied: Cloudflare answers for the domain and fetches from the host. That’s intended when Cloudflare is your host or you chose it, but it has two effects here. Outside hosts may not be able to verify the domain or issue a certificate while proxied; Netlify says the proxying must be turned off before it can issue one. And Cloudflare’s cache can keep serving the old host’s pages after the record changed. Set the website records to DNS only (the grey cloud) while the host validates, and purge Cloudflare’s cache or turn on Development Mode to see the origin directly.

The host hasn’t finished verifying the domain

With the records right, the host still has to notice. Vercel clears its “Invalid Configuration” alert once it sees the records; if the domain is in use by another Vercel account, it wants a TXT record too, and the alert stays until it sees it. Netlify shows “Pending DNS verification” until the A or CNAME resolve to it. On Cloudflare, a domain whose nameserver change hasn’t been confirmed sits in “Pending Nameserver Update”; Cloudflare says activation takes minutes to hours, and that a change not fully published at the registrar, or stale DNSSEC records there, keeps it pending. Until the zone is active it can’t be attached to a Worker at all. Read the exact status on the host’s screen; each names what it’s waiting for.

The certificate is still pending

If the site answers over plain http but the browser shows a privacy error over https, DNS is done and the certificate isn’t. Hosts issue certificates automatically only once they can see the DNS records pointing at them; Cloudflare quotes 15 minutes to 24 hours after activation, Vercel and Netlify give no figure. A CAA record in your DNS that doesn’t allow the host’s certificate authority blocks issuance indefinitely. The HTTPS guide covers this branch.

It’s your own cache

When the authoritative answer is right, the host says valid, and a phone on mobile data shows the new site while your laptop shows the old one, the laptop is the problem. Your computer, your browser and your home router each cache DNS. Try a private window, then a different network, then clearing the operating system’s DNS cache. If the browser insists on the old site over https even after DNS is right, it may have cached a redirect; a private window rules that out too. None of this needs fixing at the DNS provider.

Sources

The rules and product behaviour described above were checked against these pages when the guide was last updated. If something here has changed, these are the places to look.

• Record TTL · Cloudflare
• Full DNS setup: change your nameservers · Cloudflare
• Proxy status · Cloudflare
• Purge cache · Cloudflare
• Development Mode · Cloudflare
• Domains troubleshooting · Vercel
• Managing DNS records · Vercel
• Pending nameservers · Cloudflare
• Domain status · Cloudflare
• Clarifications to the DNS specification, RFC 2181 §8 · IETF
• Negative caching of DNS queries, RFC 2308 · IETF
• Working with DNS · Vercel
• Configure external DNS for a custom domain · Netlify
• Domain troubleshooting tips · Netlify
• ICANN Lookup · ICANN
• Dig (DNS lookup) · Google Admin Toolbox