Should you really lower the DNS TTL before migrating your hosting?

What is DNS TTL and why does it matter for SEO?

The TTL (Time to Live) defines how long a DNS resolver caches the IP address associated with a domain name. When the TTL is set to 3600 seconds (1 hour), DNS servers worldwide hold onto this information for an hour before requesting the value again.

For a site migrating hosts, a high TTL presents a straightforward problem: Google bots continue to crawl the old IP for hours, even if the new server is already active. As a result, 404 errors, timeouts, or even temporary loss of indexing can occur if content becomes inaccessible on the old server.

Why does Google emphasize exactly 5 minutes?

The value of 5 minutes (300 seconds) is not arbitrary. It’s a compromise between responsiveness and server load. A TTL that is too short (for example, 30 seconds) multiplies DNS queries and can degrade performance, especially on high-traffic sites.

With 5 minutes, the DNS cache refreshes quickly enough for the transition to be nearly seamless without overwhelming the resolvers. Google crawlers typically visit a site several times a day: if the TTL is low at the time of the switch, they fetch the new IP during their next visit.

What happens if we forget this step?

A TTL left at 86400 seconds (24 hours) means that for an entire day, some of the traffic and bots will continue to point to the old IP. If the old host cuts off service immediately, the site becomes inaccessible for these visitors.

From an SEO perspective, Google may encounter 5xx HTTP errors or timeouts, triggering alerts in Search Console and potentially slowing down the crawl. In the worst-case scenario, if the downtime lasts for several days, some pages may be temporarily de-indexed.

• Reduce the TTL to 5 minutes at least 24-48 hours before the DNS migration
• Ensure that the old IP remains accessible for a few hours after the switch
• Monitor Search Console to detect crawl errors during the transition
• Restore a normal TTL (3600-86400s) once the migration stabilizes
• Plan the migration outside peak traffic times to limit user impact

Is this recommendation sufficient in all cases?

Google's guideline is correct for a simple migration: same host, same tech stack, just a change of IP. However, it is silent on complex migrations (changing CMS, overhauling architecture, transitioning from HTTP to HTTPS simultaneously).

In these contexts, DNS TTL is just one parameter among many. If the new infrastructure has degraded response times or configuration errors, lowering the TTL won’t solve anything. Bots will crawl the new IP faster, sure, but they might encounter a poorly configured site.

Why doesn’t Google discuss the other technical layers?

This statement focuses on DNS but intentionally ignores other critical levers: 301/302 redirects, server configuration, CDN caching management. A low TTL is useless if redirects are not in place or if the CDN continues to serve old pages.

Let’s be honest: Google simplifies for a general audience. An SEO professional knows that a hosting migration requires a complete audit [To be verified] before and after, not just a DNS adjustment. Google’s silence on these points does not imply they are optional.

Are the 5 minutes always applicable?

For a standard corporate site, yes. For a high-traffic media or e-commerce site during peak season, that’s debatable. A TTL that is too short can create a surge in DNS resolver requests and degrade the latency perceived by end users.

Some hosts also impose minimum TTLs (600 seconds in the case of certain registrars). If your registrar does not allow you to go below 10 minutes, Google’s recommendation becomes impractical. Check the technical limitations of your DNS provider before planning.

What should you concretely do before a migration?

First step: identify the current TTL of your DNS records. Use `dig` or `nslookup` to check the active value. If it's higher than 3600 seconds, reduce it to at least 300 seconds 48 hours before the big day.

Why 48 hours in advance? Because the old TTLs must expire before the new value takes effect globally. If your TTL is at 86400 seconds and you lower it to 300 seconds the day before, some resolvers will hold onto the old value for an additional 24 hours.

How can you verify that the switch went smoothly?

After pointing your DNS to the new IP, monitor three indicators: HTTP errors in Search Console, server response times (using GTmetrix or Pingdom), and Googlebot crawl logs. If you see a spike in 5xx errors or timeouts in the hours following the migration, the transition is not going smoothly.

Also, test manually from various geographical locations (VPN, multi-region tools). DNS propagation is not uniform: a user in Asia might still see the old IP while everything works in Europe. Keep the old server online for 24-48 hours after the switch to avoid abrupt cutting off.

What mistakes must be absolutely avoided?

Don't raise the TTL too soon. Some SEOs, stressed by potential DNS overload, raise the TTL to 3600 seconds as soon as the site seems stable. The problem is: if a bug appears 12 hours later and requires a rollback, you are stuck with a long TTL that slows down the reverse process.

Another trap: forgetting about subdomains. If your site uses `blog.example.com` or `shop.example.com`, each subdomain has its own DNS record and TTL. Forgetting a subdomain can break part of the site without affecting the main domain.

• Reduce the TTL to 300 seconds at least 48 hours before the migration
• Ensure that all DNS records (A, AAAA, CNAME) are included
• Keep the old server accessible for 24-48 hours after the switch
• Purge the CDN cache simultaneously with the DNS change
• Monitor Search Console and server logs for 72 hours post-migration
• Gradually raise the TTL back to 3600 seconds once stability is confirmed