You changed the server address, pressed save, opened the site, and found it unchanged. Or worse: broken for some visitors while fine for others. This is not a hosting fault; it is how DNS works. The system is distributed and caches answers at many layers, and each layer waits until its copy expires before asking again.

What happens between save and visible

When you request a page, your browser does not ask your server directly. It asks the operating system, which may ask the router, which asks the internet provider, which asks a caching resolver. If none holds a valid answer, the question finally reaches the nameservers authoritative for your domain. Every layer keeps the answer for a while, so some visitors read the new record while others still use the old one.

What TTL really means

TTL stands for Time To Live: the number of seconds a record may be cached. A value of 3600 means the world may keep using the old address for a full hour. A value of 300 means five minutes. TTL is therefore not a speed button but a promise made in advance: you tell everyone how long to wait before asking you again.

Before migrating: lower TTL first

  • 24 to 48 hours before the move, lower the TTL on A, AAAA and CNAME records to 300. Nothing changes yet, but the later wait becomes shorter.
  • Move files and the database first, and test the site on the new address where possible.
  • When you are satisfied, point the record at the new server. Do not touch mail records in this step.
  • Keep the old hosting active for at least 48 hours; some networks update slowly, and you may need a rollback.
  • Once stable, raise TTL again to reduce load on the nameservers.

Why two visitors differ at the same minute

Say you change the record at noon with a one-hour TTL. A visitor who opened the site a minute earlier still holds the old address until their copy expires. A visitor who has never been to the site asks again and reaches the new server immediately. A third uses a provider that keeps answers longer than the published TTL and sees the change later still. That is why "the site is down" means nothing until you know who sees what, and when.

The practical rule: instead of asking "has the change appeared?", ask "how long ago did I change it, and what TTL was active at that moment?". If less time has passed than the TTL, waiting is the correct action, not editing the record again. Re-editing under pressure creates conflicting copies and lengthens stabilisation instead of shortening it.

How to verify the change properly

Do not judge from your own browser; you are the most likely to hold a stale copy. Use an external DNS lookup that queries several servers, try a mobile network, or flush the local cache. The tool on this site shows records as the world sees them: the DNS records checker. If the new record appears on some servers only, you are mid-propagation and that is expected.

Common problems that look like outages

First: updating the apex record and forgetting www, so one works and the other fails. Second: putting a CNAME on the apex itself, which the standard disallows and which causes confusing behaviour. Third: a typo in the IP address, producing an unreachable server indefinitely. Fourth: a negative cache at some providers that insists the name does not exist for hours. Fifth: forgetting that the certificate covers a different name, so a security warning replaces the page, as explained in the free SSL guide.

Read the records before editing

Best habit: read every current record and save a copy before any change. One forgotten MX record means mail stops for hours, and a forgotten verification TXT record breaks a working service. The full explanation of each record type is in DNS records explained.

Bottom line

Propagation is not a fault but a cache expiring. Handle it in order: lower TTL early, move data before the address, wait, verify from outside your own machine, then raise TTL once stable. Understanding the chain stops the panic at every change and reduces site and mail downtime from hours to minutes.