Pourquoi Google ralentit-il son crawl après un changement d'hébergement ?

Pourquoi cette réduction automatique du crawl ?

Quand vous changez d'hébergement ou de CDN, Google détecte le changement d'adresse IP associée à votre domaine. À ce moment-là, le moteur ne connaît pas les capacités réelles de votre nouvelle infrastructure.

Le risque ? Saturer un serveur qui ne supporterait pas le même volume de requêtes que l'ancien. Google préfère donc revenir à un taux de crawl conservateur, histoire de ne pas planter votre nouveau setup dès les premières heures.

Combien de temps dure cette phase de ralentissement ?

Mueller parle de "plusieurs semaines". Concrètement, on observe sur le terrain des périodes allant de 2 à 6 semaines selon la taille du site et son historique de crawl.

Le retour à la normale n'est pas linéaire — c'est une courbe progressive où Google teste par paliers la capacité de votre infrastructure à encaisser plus de charge.

Ce ralentissement affecte-t-il tous les types de sites de la même façon ?

Non. Les sites avec un crawl budget élevé (gros médias, e-commerce massifs) sont plus impactés que les petits sites qui se font crawler 2-3 fois par jour de toute façon.

Sur un petit blog WordPress, vous ne remarquerez peut-être même pas la différence. Sur un site de 500 000 pages avec des mises à jour quotidiennes, c'est une autre histoire.

• Ralentissement automatique : Google ne vous demande pas votre avis, c'est un comportement par défaut
• Durée variable : de 2 à 6 semaines selon le site et son historique
• Impact proportionnel : plus votre crawl budget est élevé, plus vous le sentirez passer
• Déclencheur : changement d'IP détecté lors d'une migration d'hébergement ou de CDN

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

Oui, et c'est même documenté depuis des années dans les logs de crawl. On observe effectivement une baisse brutale du nombre de hits Googlebot juste après un changement d'IP.

Le problème, c'est que Mueller reste vague sur le délai exact. "Plusieurs semaines", ça peut vouloir dire 3 comme 8 — et pour un e-commerce en pleine saison, cette incertitude est problématique.

Quelles nuances faut-il apporter ?

Première nuance : ce ralentissement peut être partiellement compensé si vous avez un fichier sitemap.xml bien maintenu et des pages qui changent régulièrement. Google priorise quand même le contenu frais, même en mode prudent.

Deuxième nuance : [À vérifier] — on manque de données sur l'impact réel d'une demande manuelle de crawl via Search Console pendant cette période. Certains observent une réactivité normale, d'autres non.

Troisième point : si votre nouveau serveur est nettement plus performant que l'ancien et que vous avez configuré un temps de réponse serveur impeccable, Google pourrait réajuster plus vite. Mais aucune garantie officielle là-dessus.

Dans quels cas cette règle pourrait-elle ne pas s'appliquer ?

Si vous utilisez un CDN comme Cloudflare en mode proxy depuis le début et que vous changez juste l'hébergeur derrière, l'IP publique vue par Google ne change pas. Donc pas de ralentissement.

Autre cas : les sites avec un taux de crawl déjà très faible (quelques pages par jour) ne verront probablement aucune différence — on ne peut pas ralentir ce qui est déjà au ralenti.

Que faut-il faire concrètement avant et après la migration ?

Avant : planifiez votre migration d'hébergement en dehors des périodes critiques (lancements produits, pics saisonniers). Si vous avez le choix, migrez pendant une période creuse.

Pendant : surveillez vos logs de crawl comme le lait sur le feu. Installez un monitoring sur les hits Googlebot pour voir la baisse en temps réel et anticiper la remontée.

Après : ne paniquez pas si vous constatez une baisse immédiate. C'est normal. En revanche, si après 6 semaines le crawl n'est toujours pas remonté, creusez — il y a peut-être un souci technique (temps de réponse, erreurs 500, etc.).

Quelles erreurs éviter absolument ?

Ne tentez pas de "forcer" le crawl en soumettant massivement des URLs via Search Console. Google va quand même respecter son taux de crawl prudent, et vous allez juste polluer votre interface pour rien.

Autre erreur classique : modifier le fichier robots.txt ou le sitemap.xml pendant la période de migration "pour aider Google". Résultat : vous introduisez de nouvelles variables et vous ne savez plus si la baisse de crawl est normale ou liée à vos modifs.

Comment vérifier que tout se passe bien ?

Trois indicateurs à surveiller : les logs serveur (volume de hits Googlebot), le rapport de couverture dans Search Console (pas de nouvelles erreurs ?), et les temps de réponse serveur (si c'est lent, Google ralentira encore plus).

Si votre infrastructure tient la charge et que les performances sont bonnes, Google remontera le crawl progressivement. Patience.

• Planifier la migration en période creuse (hors pics business)
• Mettre en place un monitoring des logs de crawl avant la migration
• Vérifier que le nouveau serveur répond rapidement (TTFB < 200ms idéalement)
• Ne pas modifier robots.txt ou sitemap.xml pendant la transition
• Surveiller le rapport de couverture Search Console pendant 6 semaines
• Accepter la baisse temporaire comme normale, ne pas sur-réagir
• Si le crawl ne remonte pas après 6 semaines, auditer les performances serveur