Comment Googlebot gère-t-il vraiment les changements d'adresse IP de vos serveurs ?

Pourquoi Googlebot vérifie-t-il les adresses IP de manière autonome ?

Lorsqu'un moteur de recherche comme Google crawle le web, il doit traduire chaque nom de domaine en adresse IP pour établir la connexion au serveur. Cette résolution DNS classique s'appuie normalement sur le TTL (Time To Live), un paramètre qui indique combien de temps l'information peut être mise en cache.

Problème : si le TTL est réglé sur 86 400 secondes (24 heures), un changement d'IP ne serait théoriquement détecté qu'après cette période. Google a donc mis en place une vérification périodique active des adresses IP, au moins quotidienne, pour ne pas dépendre uniquement des TTL déclarés par les webmasters.

Que signifie concrètement « au moins une fois par jour » ?

Google affirme ici que Googlebot interroge les serveurs DNS au minimum une fois toutes les 24 heures pour chaque domaine suivi. Cela signifie que même avec un TTL élevé, Google force un rafraîchissement de sa propre base d'adresses IP régulièrement.

En pratique, cette fréquence minimale permet de détecter rapidement les migrations d'infrastructure, les changements de CDN, ou les bascules entre serveurs. Le délai maximal théorique avant que Googlebot découvre la nouvelle IP devient donc 24 heures, plutôt que le TTL configuré.

Quelle est l'implication pour les migrations de serveurs ?

Traditionnellement, on recommandait de réduire le TTL DNS à 300 secondes (5 minutes) plusieurs jours avant une migration, pour que les caches DNS se vident rapidement lors du basculement. Cette déclaration de Google suggère que cette précaution n'est plus strictement nécessaire pour le bot de Google lui-même.

Googlebot découvrira la nouvelle adresse dans les 24 heures maximum, quel que soit le TTL. Attention cependant : cette logique ne s'applique pas aux autres crawlers (Bing, Yandex, etc.) ni aux utilisateurs finaux dont les navigateurs respectent strictement les TTL. La recommandation de réduire temporairement le TTL reste donc valable pour l'accessibilité globale du site.

• Googlebot vérifie activement les IP au minimum quotidiennement, indépendamment du TTL déclaré
• Le délai maximal de détection d'un changement d'IP par Google est donc d'environ 24 heures
• Les autres crawlers et utilisateurs restent dépendants du TTL configuré dans vos zones DNS
• La réduction temporaire du TTL reste pertinente pour minimiser l'impact côté utilisateurs lors d'une migration
• Googlebot continuera d'indexer le contenu même si votre TTL était élevé au moment du changement

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

Oui, cette affirmation correspond à ce qu'on observe lors des migrations d'infrastructure. Les sites qui ont basculé de serveur avec un TTL élevé (plusieurs heures) ont généralement constaté que Googlebot suivait rapidement, souvent dans la journée. [Vérifié] Les logs serveurs confirment que Google ne semble pas « coincé » sur une ancienne IP pendant plusieurs jours comme d'autres crawlers peuvent l'être.

Cela dit, la formulation « au moins une fois par jour » reste volontairement floue. Google ne précise pas si cette vérification est exactement toutes les 24 heures ou si la fréquence varie selon l'importance du domaine. Les sites à forte autorité ou fort trafic bénéficient probablement de vérifications plus fréquentes, mais Google ne le dit pas explicitement. [A vérifier] sur des sites de tailles différentes.

Quelles nuances faut-il apporter à cette affirmation ?

Premier point : cette logique ne s'applique qu'à Googlebot. Les utilisateurs réels, Bingbot, les autres crawlers et même certains services Google (comme Google Ads ou Google Analytics qui passent par d'autres infrastructures) respectent strictement le TTL DNS. Réduire le TTL avant une migration reste donc indispensable pour limiter les erreurs 404 ou timeouts côté utilisateurs.

Deuxième nuance : Google parle de « délai raisonnable » sans définir ce terme précisément. En pratique, 24 heures peuvent sembler longues si votre ancien serveur est immédiatement coupé après la migration. Il reste donc recommandé de maintenir l'ancien serveur accessible pendant au moins 48 heures, avec une redirection 301 vers la nouvelle IP ou un reverse proxy temporaire.

Dans quels cas cette règle pourrait-elle poser problème ?

Si vous migrez vers une nouvelle infrastructure et que l'ancien serveur devient inaccessible immédiatement, Googlebot peut continuer à tenter de crawler l'ancienne IP pendant quelques heures. Résultat : des erreurs serveur temporaires, des pages indisponibles dans les SERPs, et potentiellement une baisse de visibilité transitoire.

Autre cas : les sites avec plusieurs sous-domaines ou configurations DNS complexes (CDN, load balancers, A/AAAA multiples). Google ne précise pas si la vérification quotidienne couvre tous les records DNS simultanément ou si certains sous-domaines peuvent être vérifiés moins fréquemment. [A vérifier] en conditions réelles sur des architectures distribuées.

Que faut-il faire concrètement lors d'une migration serveur ?

Continuez à réduire temporairement le TTL DNS à 300 secondes (5 minutes) au moins 48 heures avant la migration. Même si Googlebot ne dépend plus strictement de ce paramètre, les utilisateurs finaux et les autres crawlers en ont besoin pour basculer rapidement. Cette précaution réduit drastiquement les erreurs d'accessibilité temporaires.

Lors du basculement effectif, assurez-vous que l'ancien serveur reste accessible pendant 48 à 72 heures minimum. Configurez une redirection 301 au niveau serveur pointant vers la nouvelle adresse, ou laissez le contenu identique sur les deux infrastructures en parallèle. Cela couvre la fenêtre de 24 heures de Googlebot et laisse une marge de sécurité.

Comment vérifier que Googlebot suit correctement le changement ?

Surveillez vos logs serveurs sur la nouvelle infrastructure dans les heures suivant la migration. Vous devriez voir apparaître les User-Agent Googlebot relativement rapidement, souvent dans les 6 à 12 heures suivant le changement DNS. Si après 24 heures vous ne voyez aucun crawl, vérifiez que votre nouvelle IP n'est pas bloquée par un firewall ou un WAF.

Consultez également la Search Console : allez dans Paramètres > Exploration > Statistiques sur l'exploration. Une hausse brutale des erreurs serveur (5xx) ou des timeouts indique que Googlebot tente encore d'accéder à l'ancienne adresse. Utilisez l'outil d'inspection d'URL pour forcer un crawl immédiat de quelques pages stratégiques et accélérer la détection.

Quelles erreurs éviter absolument ?

Ne coupez jamais l'ancien serveur immédiatement après avoir changé l'enregistrement DNS. Même si Google détecte le changement rapidement, les caches DNS intermédiaires (FAI, entreprises, CDN) peuvent mettre plusieurs heures à se synchroniser. Résultat : des milliers d'utilisateurs et de bots se retrouvent face à un serveur mort, ce qui génère des signaux négatifs massifs.

Évitez également de négliger les sous-domaines et les enregistrements secondaires. Si vous migrez example.com mais oubliez www.example.com ou blog.example.com, Googlebot continuera à crawler ces sous-domaines sur l'ancienne IP. Résultat : des erreurs partielles, une indexation fragmentée, et des signaux de qualité contradictoires envoyés à Google.

• Réduire le TTL DNS à 300 secondes au moins 48h avant la migration
• Maintenir l'ancien serveur accessible pendant 48-72h après le basculement
• Configurer des redirections 301 sur l'ancien serveur vers la nouvelle infrastructure
• Vérifier que tous les sous-domaines et enregistrements DNS sont bien migrés
• Surveiller les logs serveurs et la Search Console dans les 24h suivant la migration
• Utiliser l'outil d'inspection d'URL pour forcer le crawl des pages stratégiques