You changed the nameservers, or transferred the domain, or moved to a new host — and now the site is gone. The reflex is to wait, because everyone says DNS takes 24 to 48 hours. Waiting is right for exactly one of the causes below and wrong for the other five, and each hour spent waiting on the wrong one is an hour of avoidable downtime.
First: is it actually broken, or actually propagating?
These look identical from your desk and are trivial to tell apart with a resolver you have never used.
Run the domain through the DNS Checker, which queries several public resolvers at once, and read the pattern rather than any single answer:
- Some resolvers return the new value, others the old one. This is propagation. Nothing is broken. Wait it out — the TTL on the old record tells you how long is left, and it is a specific number, not 48 hours.
- Every resolver returns the old value, well past the TTL. The change did not take effect. Something is wrong at the provider.
- Every resolver returns nothing at all. The domain does not resolve for anyone. This is the most urgent case and it is not propagation.
- Every resolver returns the new value and the site still fails. DNS is finished and correct. The problem is at the destination, and no amount of waiting helps.
That last case is the one that costs people days. DNS is not your problem — go to the connection error you are seeing or the down checklist instead.
Cause 1: the zone was never rebuilt at the new provider
Comfortably the most common way a nameserver change takes a site down, and the reason it is so common is that the failure is invisible until it is total.
Changing nameservers does not move your records. It changes who is asked for them. The new provider answers with whatever is in its zone, and for a freshly created zone that is often a default set that points nowhere near your site — or nothing at all.
The old provider still holds a perfect copy of your records, and it is still serving them to every resolver that has not expired its cache. That is why the site works for an hour and then stops: nothing broke at the moment of the change, the correct answers simply aged out.
The fix is to rebuild the zone at the new provider, completely, from the record of what you had. If you did not export it first, the old provider's control panel almost certainly still shows the zone. Pull it before you cancel anything there.
Do not miss the mail records. Sites come back and mail stays broken for days, because nobody tests mail after a DNS change. The MX records, the SPF TXT record, the DKIM selector records and the DMARC record all live in the same zone and all vanish with it — see SPF, DKIM and DMARC for what each one has to contain.
Cause 2: the registrar still points at the old nameservers
The zone is right, the records are right, and the domain's delegation was never actually updated — or the update was rejected and the confirmation was missed.
Check what the registrar publishes with the WHOIS Lookup. The nameserver lines there are authoritative for where the internet is told to ask. If they still name the old provider, nothing you do at the new provider can have any effect, because nobody is asking it.
Cause 3: the transfer moved the domain but not the DNS
Specific to website down after domain transfer, and it catches people who did everything else right.
Transferring a domain moves the registration between registrars. It does not move DNS hosting, and it does not copy your zone. Some registrars set their own nameservers on a domain as it arrives, which silently replaces a working delegation with an empty one.
Two things to check, in this order: does WHOIS still list the nameservers you expect, and if it does, does the provider behind them still have your zone? A transfer can also end a bundled DNS service you were relying on without appearing to change anything.
Cause 4: the records point at the right host and the wrong site
DNS is complete and correct, and it resolves to a server that does not know what to do with the request.
On shared hosting and any server hosting more than one site, the IP address is not enough — the web server decides which site to serve by reading the Host header. If the new host has no virtual host configured for your domain, you get its default: a parking page, an unrelated site, or a 404 that looks like a broken site.
The tell is that you are getting a real HTTP response rather than a connection failure. Something is answering. It is simply answering as the wrong site, which is a hosting configuration issue and not DNS at all.
Cause 5: HTTPS was never set up at the new host
The site loads on http:// and fails on https://, and since browsers now default to HTTPS, that reads as completely down.
Certificates are issued per server, not attached to the domain, so a new host needs its own. Most issuance requires the domain to already resolve to that server, which produces a genuine ordering problem: DNS has to be live before the certificate can be issued, so there is a window where the site resolves and cannot be served securely.
Confirm with the SSL Checker. If it reports no certificate or one for the wrong hostname, that is the whole problem, and it is usually one command on the new server.
Cause 6: the old server was switched off too early
The change was made correctly and the site broke anyway, for a while, for some people.
Resolvers hold the old answer until its TTL expires. Every one of them that has not expired is still being sent to the old server. If that server is off, those visitors get nothing — and that is the entire population of anyone who visited recently, which is to say your regular visitors.
Leave the old server running and serving until the old TTL has fully elapsed. Then leave it another day. This costs one month of hosting and removes the most avoidable form of migration downtime there is.
The order to check, when it is already broken
- Public resolvers — DNS Checker. Establishes whether this is propagation, a wrong record, or no record.
- The registrar's delegation — WHOIS Lookup. Confirms the internet is being told to ask the provider you think it is.
- The zone at the provider. Does the A record exist and name the right IP?
- The server itself — Website Down Checker. If DNS is right, the answer is here.
- The certificate — SSL Checker, if HTTP works and HTTPS does not.
- The
wwwvariant, and the bare domain. One having a record and the other not is common and is a two-minute fix.
Steps 1 and 2 take about a minute together and between them eliminate most of the possibilities.
What "my website disappeared from the internet" usually means
Two very different situations get described in the same words, and the distinction decides everything you do next.
It does not resolve — the domain returns nothing anywhere. Check the registration before anything else, because an expired domain looks exactly like this, and a DNS change made near a renewal date is a coincidence people misread constantly. The expiry timeline covers what recovery involves at each stage.
It resolves and does not load — DNS finished, and the destination is the problem. Nothing in this article applies. Go to the connection error the browser is showing you.
A third case, which is not downtime at all: the site loads perfectly and has vanished from Google. That is indexing, not reachability, and none of these checks measure it.
Doing it right the next time
The full sequence is in how to change nameservers without downtime. Three points do most of the work:
- Export the zone before touching anything, and keep it until the migration is finished.
- Lower the TTL a day ahead, so that if something is wrong the blast radius is minutes rather than a day.
- Build the new zone before switching the delegation, so the change is the last step rather than the first.
Start by finding out what the resolvers actually return with the DNS Checker.