Why does Google slow down crawling after a server or CDN migration?

What actually happens technically during a server change?

When you migrate to a new server or activate a CDN, Google detects a change in the server responses. Googlebot doesn't immediately know if this new infrastructure can support the volume of requests it was sending previously. It therefore adopts a cautious approach: temporarily reducing the load to avoid bringing the site down.

This testing phase is not documented in terms of exact duration. It can last from a few days to several weeks depending on the server's responsiveness, the observed response times, and its capacity to handle traffic spikes. Google gradually increases crawling based on the observed performance.

How does this slowdown affect indexing?

A reduced crawl means fewer pages discovered or updated in the index. If you publish fresh content during this period, it will take longer to appear in search results. Changes to existing content will also be reflected with a delay.

The issue is particularly concerning for sites with a limited crawl budget — typically large e-commerce catalogs, news sites, or platforms generating numerous pages. A small corporate site with 50 pages will hardly notice any perceptible difference.

Does this measure apply to all types of changes?

Yes, whenever the IP address or delivery infrastructure changes. This includes server migrations, switching to a CDN, changing hosts, as well as domain migrations with redirection. Google treats every new entry point as an unknown infrastructure that needs to be validated.

The severity of the slowdown depends on the context. A site migrating to a high-performance CDN will return to its normal pace faster than a site switching from a premium host to a low-end shared hosting with degraded response times.

• Crawling systematically slows down after an infrastructure change. It's a preventive measure by Google.
• The duration of the slowdown depends on the actual performance of the new server and its ability to absorb Googlebot's traffic.
• Sites with a tight crawl budget are the most affected; smaller sites hardly notice.
• A well-configured CDN allows a faster return to normal than an undersized server.
• Google increases crawling gradually, not all at once, to avoid any overload.

Is this statement consistent with field observations?

Absolutely. SEOs managing technical migrations regularly observe a crawl dip in the days following an infrastructure change. Server logs show a clear decrease in Googlebot requests, usually between 30% and 60% for a few days.

What is less documented is the actual duration of this phase. [To be verified] Google provides no specific timeline. In practice, recoveries are seen in 48-72 hours for well-optimized sites, but sometimes take 2-3 weeks for more fragile infrastructures. There is no transparency regarding the performance thresholds that Googlebot expects.

What factors speed up or prolong this slowdown?

Three main levers: server response times, ability to handle load spikes, and stability of HTTP responses. A server that returns 503 errors or timeouts under load will remain throttled longer. Google will take no risks.

Premium CDNs with global distribution and aggressive caching often limit the slowdown to just a few days. An undersized origin server behind a poorly configured CDN will prolong the testing phase. Post-migration monitoring is essential to identify bottlenecks.

Are there cases where this mechanism does not apply?

Purely DNS migrations without actual infrastructure changes—such as pointing a domain to another IP within the same datacenter—trigger less caution. Google quickly detects that performances remain the same and adjusts less drastically.

Sites with a history of stable crawling and excellent performance recover their pace faster. Google remembers: a site that has always managed Googlebot traffic well benefits from a shorter testing period. This is empirical, not officially documented.

What can you do before a migration to limit the impact?

Prepare the infrastructure by intentionally overloading the new server before the DNS switch. Use load testing tools to simulate normal crawl volume and identify limits. Google will test anyway, so it’s better to know the weaknesses beforehand.

Properly configure the CDN cache and cache-control rules. A CDN that serves static pages from cache reduces the load on the origin and speeds up the return to normal crawling. Check that prioritized URLs are cached before the switch.

How to monitor crawler activity post-migration?

Monitor the server logs in real-time to track the number of hits from Googlebot each day. A sharp drop confirms the slowdown. Compare it with the 15 days prior to migration to quantify the gap. Search Console also provides signals in the coverage report.

Keep track of the average response times for Googlebot requests specifically. If you notice degradations or timeouts, the infrastructure is not coping. Google will not resume crawling until performance remains stable.

Should you force a resumption of crawling or let it happen naturally?

There is no direct lever to force Google to resume a normal rate. Indexing requests via Search Console do not change the overall crawl budget allocated to the site. They prioritize individual URLs, that’s all.

The only effective action: optimize server performance so Google notices an improvement. Reduce response times, eliminate 5xx errors, stabilize the load. Crawling will naturally increase when the infrastructure proves its reliability.

• Load test the new server before the DNS switch with a volume equal to or greater than the usual crawl.
• Configure the CDN cache to serve priority pages without constantly hitting the origin.
• Monitor server logs daily for 3 weeks post-migration to detect anomalies.
• Track response times in Search Console and compare with pre-migration periods.
• Avoid planning critical publications within 10 days of an infrastructure migration.
• Check for the absence of 5xx errors or timeouts under Googlebot's load.