First, identify what “the old server” means
After a DNS change, an old website appearing in a browser does not necessarily mean DNS is still returning the old address. DNS helps a browser find a destination, but the server at that destination decides what content to serve. A redirect, hosting configuration or page cache can also make a move look incomplete. Separating these possibilities saves time.
Start with the exact hostname that behaves unexpectedly. example.com and www.example.com can have different DNS records and different web settings. Note whether the browser shows the old page while staying on the same address, or whether its address bar changes to another hostname. If possible, compare results from another device or network, but treat that comparison as a clue rather than proof of the cause.
Check the authoritative DNS setup
A record change only helps if it was made where the domain’s active DNS is hosted. The nameservers assigned at the domain registrar determine which DNS provider is authoritative. If you edited records in a different provider’s dashboard, the public answer may remain unchanged. Check the domain’s assigned nameservers, then inspect the records at that provider.
Verify every hostname visitors use. An apex name such as example.com may have A and AAAA records, while www.example.com may use a CNAME. An A record points to an IPv4 address; an AAAA record points to an IPv6 address. If the A record was updated but an AAAA record still points to the old server, some visitors may continue reaching it over IPv6. Likewise, updating the apex does not automatically update www.
If the hostname uses a CNAME, follow its target rather than assuming the visible hostname has a direct address record. Also check for duplicate or unintended address records: if both old and new addresses are published for the same name, visitors may reach either destination. A DNS lookup tool such as dig or nslookup can help you compare the answers for the apex, www, A and AAAA records with what is shown in the active DNS dashboard.
Allow for cached DNS answers
Even when authoritative DNS has the new answer, a recursive resolver may temporarily return an older one from its cache. DNS records have a time to live, or TTL, that tells resolvers how long they may keep an answer. Lowering the TTL after a resolver has already cached a record does not shorten that existing cache entry. This is why a change can appear on one network before another.
Compare an answer from an authoritative nameserver with answers from the resolvers your device or network uses. If the authoritative answer is new but a resolver still returns the old address, waiting for that cached answer to expire is usually the appropriate next step. Restarting a browser or clearing a device’s DNS cache might remove a local cached answer, but it cannot clear a cache held by an upstream resolver. Avoid making repeated record changes solely because different networks update at different times; that can make the result harder to interpret.
Look beyond DNS if the address is already correct
If DNS returns the new server address but you still see the old site, check what the new server is serving for that hostname. A hosting account may not yet be configured to recognize the domain, or a copied site may still contain old content. Web server rules and application settings can also redirect visitors back to an old hostname. Watching the browser’s address bar during a visit can reveal a redirect, though it will not explain every server-side issue.
If the site uses a CDN or proxy, the public DNS answer may correctly point to that service rather than directly to either hosting server. In that case, check the service’s configured origin—the server from which it fetches the site—and its content cache. Browser caches can also retain pages or redirects. Testing in a private browsing window can help distinguish some local browser behavior, but it is not a substitute for checking DNS and server settings.
Use a steady troubleshooting order
Work from the domain outward: confirm the active nameservers; check authoritative records for each hostname and address type; compare resolver answers; then inspect redirects, CDN settings and hosting configuration. Record the answers you see and where you saw them, without sharing account credentials or private dashboard access. If you need to ask a provider for help, the affected hostname, expected destination and observed DNS answers are more useful than a statement that the change “has not propagated.”
Once both authoritative and resolver answers show the intended destination, continued old content is a strong reason to investigate the website’s delivery path rather than change DNS again. Keeping DNS records and hosting settings aligned—and checking both www and the apex—makes the next move easier to verify.
