DNS TTL Explained for Website Migrations
Understand DNS TTL before website migrations, including propagation timing, resolver caching, cutover planning, rollback safety, and common mistakes.
TTL controls how long DNS answers are cached
DNS TTL stands for time to live. It tells resolvers how long they can cache a DNS record before checking again. During normal operation, a longer TTL can reduce repeated DNS lookups and keep resolution efficient. During a website migration, TTL becomes important because it affects how quickly users and crawlers start reaching the new destination after a DNS change.
If a record has a TTL of 24 hours, some resolvers may continue using the old answer for many hours after you update the record. If a record has a TTL of 300 seconds, many resolvers will check again much sooner. This is why teams lower TTL before migrations, not at the moment of migration. Lowering it too late does not clear caches that already stored the old longer value.
Lower TTL before the cutover
A practical migration plan lowers TTL at least one old TTL window before the final switch. If the current TTL is 24 hours, lower it a day or two before the cutover. Then, when the migration happens, resolvers are more likely to refresh quickly. This reduces the period where some users reach the old host while others reach the new one.
Lower TTL is not a magic instant switch. Some resolvers ignore very low TTLs, some networks cache aggressively, and users may have local DNS caches. Still, lowering TTL ahead of time is one of the simplest ways to reduce uncertainty during a migration.
Migration safety depends on both old and new systems
Because DNS propagation is uneven, the old site should remain available during the transition. Do not shut down the old host immediately after changing DNS. Users, crawlers, and third-party services may still reach it for a while. Keep redirects, certificates, and content working until traffic has clearly moved.
Rollback planning also matters. If the new host fails, a low TTL can help you point traffic back faster. But rollback is only useful if the old environment still works. A migration plan should include clear criteria for rollback and the exact DNS records that would change.
- Lower TTL before the migration, not during the emergency.
- Keep the old host alive until traffic has fully moved.
- Test DNS answers from multiple networks and regions.
- Document rollback records before making the cutover.
DNS changes can affect SEO indirectly
Search engines do not penalize a site simply because DNS changes. The risk comes from downtime, certificate failures, wrong redirects, inconsistent content, and crawl errors during the move. If crawlers reach an unavailable host or see broken redirects, indexing signals can suffer. Good DNS planning reduces those risks.
For global websites, test from more than one region. A migration can look complete from your office while users elsewhere still resolve the old address. Use public DNS checkers, command-line tools, CDN analytics, and server logs to confirm behavior across locations.
Raise TTL again after stability
After the migration is stable, teams often raise TTL back to a normal value. Keeping a very low TTL forever can increase DNS query volume and may not provide ongoing value. Wait until the new hosting, redirects, certificates, analytics, and Search Console signals look healthy before changing it back.
DNS TTL is a small number with large operational consequences. Treat it as part of the migration plan, not as a footnote. A careful TTL strategy gives users a smoother transition, gives crawlers fewer errors, and gives the team more control if something goes wrong.