How does Googlebot really handle changes to your server's IP addresses?

Why does Googlebot autonomously check IP addresses?

When a search engine like Google crawls the web, it needs to translate each domain name into a IP address to establish the connection to the server. This classic DNS resolution usually relies on the TTL (Time To Live), a parameter that indicates how long the information can be cached.

Problem: if the TTL is set to 86,400 seconds (24 hours), a change in IP would theoretically only be detected after that period. Google has therefore implemented active periodic checks of IP addresses, at least daily, to avoid relying solely on the TTL declared by webmasters.

What does “at least once a day” really mean?

Google states here that Googlebot queries DNS servers at least once every 24 hours for each tracked domain. This means that even with a high TTL, Google enforces a refresh of its own IP address database regularly.

In practice, this minimum frequency allows for quick detection of infrastructure migrations, changes of CDN, or switches between servers. The maximum theoretical delay before Googlebot discovers the new IP thus becomes 24 hours, rather than the configured TTL.

What are the implications for server migrations?

Traditionally, it was recommended to reduce the DNS TTL to 300 seconds (5 minutes) several days before a migration so that DNS caches would empty quickly during the switch. This statement from Google suggests that this precaution is no longer strictly necessary for Googlebot itself.

Googlebot will discover the new address within 24 hours at most, regardless of the TTL. However, this logic does not apply to other crawlers (Bing, Yandex, etc.) or to end users whose browsers strictly adhere to the TTL. Therefore, the recommendation to temporarily reduce the TTL remains valid for the overall accessibility of the site.

• Googlebot actively checks IP addresses at least daily, regardless of the declared TTL
• The maximum detection delay for an IP address change by Google is therefore about 24 hours
• Other crawlers and users remain dependent on the TTL configured in your DNS zones
• Temporary TTL reduction remains relevant to minimize the impact on users during a migration
• Googlebot will continue to index content even if your TTL was high at the time of the change

Is this statement consistent with field observations?

Yes, this claim aligns with what is observed during infrastructure migrations. Sites that have switched servers with a high TTL (several hours) have generally found that Googlebot tracks quickly, often within the day. [Verified] Server logs confirm that Google does not seem to be 'stuck' on an old IP for several days as other crawlers might be.

That said, the phrasing “at least once a day” remains deliberately vague. Google does not specify whether this check is exactly every 24 hours or if the frequency varies based on the domain's importance. High authority or high traffic sites likely benefit from more frequent checks, but Google does not explicitly state this. [To be verified] on varying site sizes.

What nuances should be added to this claim?

First point: this logic only applies to Googlebot. Real users, Bingbot, other crawlers, and even some Google services (like Google Ads or Google Analytics that operate through different infrastructures) strictly observe the DNS TTL. Reducing the TTL before a migration remains essential to limit 404 errors or timeouts for users.

Second nuance: Google speaks of a “reasonable delay” without precisely defining this term. In practice, 24 hours might seem long if your old server is immediately shut down after migration. It remains advisable to keep the old server accessible for at least 48 hours, with a 301 redirect to the new IP or a temporary reverse proxy.

In what situations could this rule pose a problem?

If you migrate to a new infrastructure and the old server becomes immediately inaccessible, Googlebot may continue trying to crawl the old IP for a few hours. Result: temporary server errors, pages unavailable in the SERPs, and potentially a transient drop in visibility.

Another case: sites with multiple subdomains or complex DNS configurations (CDN, load balancers, multiple A/AAAA). Google does not clarify whether the daily check covers all DNS records simultaneously or if some subdomains might be checked less frequently. [To be verified] under real conditions on distributed architectures.

What should you concretely do during a server migration?

Continue to temporarily reduce the DNS TTL to 300 seconds (5 minutes) at least 48 hours before the migration. Even if Googlebot no longer strictly depends on this parameter, end users and other crawlers need it to switch quickly. This precaution drastically reduces temporary accessibility errors.

During the actual switch, make sure the old server remains accessible for at least 48 to 72 hours. Set up a 301 redirect at the server level pointing to the new address, or keep the same content on both infrastructures in parallel. This covers Googlebot's 24-hour window and provides a safety margin.

How to check that Googlebot is correctly following the change?

Monitor your server logs on the new infrastructure in the hours following the migration. You should see User-Agent Googlebot appear relatively quickly, often within 6 to 12 hours after the DNS change. If after 24 hours you see no crawling activity, check that your new IP is not blocked by a firewall or WAF.

Also check the Search Console: go to Settings > Crawling > Crawl Stats. A sharp increase in server errors (5xx) or timeouts indicates that Googlebot is still trying to access the old address. Use the URL Inspection tool to force an immediate crawl of some strategic pages and speed up detection.

What errors should you absolutely avoid?

Never shut down the old server immediately after changing the DNS record. Even if Google detects the change quickly, intermediate DNS caches (ISPs, enterprises, CDNs) can take several hours to synchronize. Result: thousands of users and bots face a dead server, creating massive negative signals.

Avoid neglecting subdomains and secondary records. If you migrate example.com but forget www.example.com or blog.example.com, Googlebot will continue to crawl these subdomains on the old IP. Result: partial errors, fragmented indexing, and conflicting quality signals sent to Google.

• Reduce the DNS TTL to 300 seconds at least 48 hours before the migration
• Keep the old server accessible for 48-72 hours after the switch
• Set up 301 redirects on the old server to the new infrastructure
• Check that all subdomains and DNS records are properly migrated
• Monitor server logs and Search Console in the 24 hours following migration
• Use the URL Inspection tool to force crawl of strategic pages