Pourquoi Google ralentit-il le crawl après une migration serveur ou CDN ?

Que se passe-t-il techniquement lors d'un changement de serveur ?

Quand vous migrez vers un nouveau serveur ou activez un CDN, Google détecte un changement dans la réponse des serveurs. Googlebot ne sait pas immédiatement si cette nouvelle infrastructure peut supporter le volume de requêtes qu'il envoyait auparavant. Il applique donc une approche prudente : réduire temporairement la charge pour éviter de faire tomber le site.

Cette phase de test n'est pas documentée en termes de durée exacte. Elle peut durer quelques jours comme plusieurs semaines selon la réactivité du serveur, les temps de réponse observés et la capacité à encaisser les pics. Google augmente progressivement le crawl en fonction des performances constatées.

Pourquoi ce ralentissement impacte-t-il l'indexation ?

Un crawl réduit signifie moins de pages découvertes ou actualisées dans l'index. Si vous publiez du contenu frais pendant cette période, il mettra plus de temps à apparaître dans les résultats. Les modifications de contenus existants seront également répercutées avec retard.

Le problème se pose surtout pour les sites avec un crawl budget limité — typiquement les gros catalogues e-commerce, les sites d'actualités ou les plateformes générant beaucoup de pages. Un petit site corporate de 50 pages ne verra quasiment aucune différence perceptible.

Cette mesure s'applique-t-elle à tous les types de changements ?

Oui, dès que l'adresse IP ou l'infrastructure de diffusion change. Cela couvre les migrations de serveur, les passages à un CDN, les changements d'hébergeur, mais aussi les migrations de domaine avec redirection. Google traite chaque nouveau point d'entrée comme une infrastructure inconnue à valider.

La sévérité du ralentissement dépend du contexte. Un site qui migre vers un CDN performant retrouvera son rythme plus vite qu'un site qui passe d'un hébergement premium à un mutualisé bas de gamme avec des temps de réponse dégradés.

• Le crawl ralentit systématiquement après un changement d'infrastructure, c'est un comportement préventif de Google
• La durée du ralentissement dépend des performances réelles du nouveau serveur et de sa capacité à absorber le trafic Googlebot
• Les sites à crawl budget serré sont les plus impactés, les petits sites le remarquent à peine
• Un CDN bien configuré permet de retrouver un rythme normal plus rapidement qu'un serveur sous-dimensionné
• Google augmente le crawl progressivement, pas d'un coup, pour éviter toute surcharge

Cette déclaration est-elle cohérente avec les observations terrain ?

Absolument. Les SEO qui gèrent des migrations techniques constatent régulièrement un creux de crawl dans les jours qui suivent un changement d'infrastructure. Les logs serveur montrent une baisse nette du nombre de requêtes Googlebot, souvent entre 30% et 60% pendant quelques jours.

Ce qui est moins documenté, c'est la durée réelle de cette phase. [A vérifier] Google ne donne aucun délai précis. Terrain, on observe des reprises en 48-72h pour des sites bien optimisés, mais parfois 2-3 semaines pour des infrastructures plus fragiles. Aucune transparence sur les seuils de performance que Googlebot attend.

Quels facteurs accélèrent ou prolongent ce ralentissement ?

Trois leviers principaux : temps de réponse serveur, capacité à gérer les pics de charge, et stabilité des réponses HTTP. Un serveur qui renvoie des 503 ou des timeouts sous charge restera bridé plus longtemps. Google ne prendra aucun risque.

Les CDN premium avec distribution mondiale et cache agressif permettent souvent de limiter le ralentissement à quelques jours. Un serveur origine sous-dimensionné derrière un CDN mal configuré prolongera la phase de test. Le monitoring post-migration est essentiel pour identifier les goulots.

Y a-t-il des cas où ce mécanisme ne s'applique pas ?

Les migrations purement DNS sans changement d'infrastructure réelle — comme pointer un domaine vers une autre IP du même datacenter — déclenchent moins de prudence. Google détecte rapidement que les performances restent identiques et ajuste moins drastiquement.

Les sites avec un historique de crawl stable et des performances excellentes retrouvent leur rythme plus vite. Google a une mémoire : un site qui a toujours bien géré le trafic Googlebot bénéficie d'une période de test plus courte. C'est empirique, pas documenté officiellement.

Que faire avant une migration pour limiter l'impact ?

Préparez l'infrastructure en surchargeant volontairement le nouveau serveur avant la bascule DNS. Utilisez des outils de load testing pour simuler le volume de crawl habituel et identifier les limites. Google testera de toute façon, autant connaître les faiblesses avant.

Configurez correctement le cache CDN et les règles de cache-control. Un CDN qui sert les pages statiques depuis le cache réduit la charge sur l'origine et accélère la reprise du crawl normal. Vérifiez que les URLs prioritaires sont bien en cache avant la bascule.

Comment surveiller l'évolution du crawl post-migration ?

Monitorer les logs serveur en temps réel pour traquer le nombre de hits Googlebot par jour. Une baisse brutale confirme le ralentissement. Comparez avec les 15 jours précédant la migration pour quantifier l'écart. Search Console donne aussi des signaux dans le rapport de couverture.

Suivez les temps de réponse moyens pour les requêtes Googlebot spécifiquement. Si vous voyez des dégradations ou des timeouts, l'infrastructure ne suit pas. Google ne remontera pas le crawl tant que les performances restent instables.

Faut-il forcer une reprise du crawl ou laisser faire ?

Pas de levier direct pour forcer Google à reprendre un rythme normal. Les demandes d'indexation via Search Console ne modifient pas le crawl budget global alloué au site. Elles priorisent des URLs individuelles, c'est tout.

La seule action efficace : optimiser les performances serveur pour que Google constate une amélioration. Réduire les temps de réponse, éliminer les erreurs 5xx, stabiliser la charge. Le crawl remontera naturellement quand l'infrastructure aura prouvé sa fiabilité.

• Load-tester le nouveau serveur avant la bascule DNS avec un volume égal ou supérieur au crawl habituel
• Configurer le cache CDN pour servir les pages prioritaires sans solliciter l'origine systématiquement
• Monitorer les logs serveur quotidiennement pendant 3 semaines post-migration pour détecter les anomalies
• Tracker les temps de réponse serveur dans Search Console et comparer avec la période pré-migration
• Ne pas planifier de publication critique dans les 10 jours suivant une migration infrastructure
• Vérifier l'absence d'erreurs 5xx ou timeouts sous charge Googlebot