Le 31 mars 2026, Google annonçait le déplacement des fichiers JSON listant les plages d’adresses IP de ses crawlers, de /search/apis/ipranges/ vers /crawling/ipranges/ sur developers.google.com.
Officiellement, une simple réorganisation de l’URL, motivée par le fait que ces IP couvrent aussi Shopping, AdSense ou Gemini, au-delà de la Search. Et ce changement était annoncé pour … dans six mois.
Mais l’agence londonienne Merj a remarqué que le changement a été beaucoup plus brutal que prévu.
Avec un effet de bord susceptible de casser silencieusement de nombreuses infrastructures SEO et sécurité.
Un 200 OK qui ne dit pas son nom
Google avait promis une période de transition de six mois avec des redirections.
Le 7 avril à 09h42 UTC, soit huit jours après l’annonce, les anciennes URL ont cessé de retourner les données d’IP. Pas de 301, pas de 308, pas de 404 non plus : les endpoints obsolètes renvoient désormais un code 200 OK accompagné d’un JSON inattendu du type {"Action needed": "update the location..."}.
C’est un comportement assez pernicieux.
Une redirection HTTP (code 3xx) aurait été suivie automatiquement par la plupart des clients. Un code 404 ou 410 aurait déclenché des alertes. Un 200 OK avec un JSON valide mais vide de préfixes IP passe sous les radars des systèmes de validation laxistes : le script parse la réponse sans erreur, ne trouve aucun préfixe, et continue avec une allowlist vide en production.
Google a partiellement fait machine arrière le 8 avril à 09h45 UTC, les anciennes URL servant à nouveau les bonnes données. Mais la fenêtre de dysfonctionnement a duré près de 24 heures, et le correctif ne lève pas toutes les ambiguïtés.
Un fichier renommé, une anomalie résiduelle
Premier point que le billet officiel de Google passe sous silence : googlebot.json a été renommé common-crawlers.json. Mettre à jour le chemin du répertoire ne suffit donc pas, il faut aussi changer le nom du fichier. Les autres fichiers (special-crawlers.json, user-triggered-fetchers.json, user-triggered-fetchers-google.json, user-triggered-agents.json) conservent leur nom.
Seconde anomalie repérée par Merj : le fichier user-triggered-agents.json, qui couvre le nouveau crawler Google-Agent (associé à Project Mariner, l’agent d’IA de Google), se comporte différemment. L’ancienne URL continue de servir de vraies données IP, mais obsolètes de plus de cinq semaines : 4 préfixes datés du 3 mars, contre 18 préfixes à jour sur la nouvelle URL, incluant des allocations IPv4 et IPv6 inédites.
Le piège est ici inversé : pas d’erreur de schéma, pas d’allowlist vide, mais des données silencieusement périmées, ce qui est potentiellement pire pour un système de bot verification.
Les systèmes concernés
Toute infrastructure qui récupère automatiquement les plages d’IP de Google est exposée :
- Les allowlists de pare-feu autorisant les IP de Googlebot
- Les règles de WAF (Web Application Firewall) utilisées pour la classification des bots
- Les scripts de bot verification qui comparent les requêtes entrantes aux IP publiées
- Les configurations CDN avec protection d’origine
- Les pipelines d’analyse de logs qui taggent le trafic par type de crawler
Le mode de défaillance dépend du langage. Un code strictement typé (Go, Java) crashera en tentant de désérialiser le JSON inattendu, ce qui est paradoxalement la bonne nouvelle : l’alerte remonte. Un parsing souple continuera son exécution avec une liste vide, sans erreur ni avertissement, jusqu’à ce que les taux de crawl baissent ou que les rapports de classification de bots deviennent incohérents.
Ce qu’il faut faire
La migration elle-même est triviale. Trois actions à mener :
- Mettre à jour toutes les références vers
/crawling/ipranges/, en renommantgooglebot.jsonencommon-crawlers.json - Ajouter une validation de schéma (par exemple avec Zod en TypeScript) sur les réponses pour transformer les défaillances silencieuses en échecs explicites
- Rafraîchir une fois les données pour couvrir la fenêtre du 7 au 8 avril pendant laquelle des données vides ou périmées ont pu être ingérées
Merj, qui avait migré dès l’annonce du 31 mars, n’a subi aucune rupture de service et a partagé ses constats avec Vercel et Akamai.
Ce que cet épisode dit des pratiques Google
Au-delà du correctif technique, l’épisode illustre un écart récurrent entre les communications officielles de Google et la réalité opérationnelle du déploiement.
Une période de transition annoncée à six mois a duré huit jours. Un renommage de fichier non mentionné dans le billet de blog. Un mode de défaillance choisi qui privilégie un 200 OK trompeur plutôt qu’une redirection standard ou un code d’erreur explicite.
Pour les équipes SEO et infrastructure, cela confirme la nécessité de ne jamais faire confiance aveuglément aux flux Google, même lorsqu’ils sont servis depuis developers.google.com, et d’instrumenter chaque ingestion automatisée avec des contrôles de cohérence.
Bibliographie
- Update Your Google Crawler IP Range Endpoints, Merj, 8 avril 2026
- New Location for the Google Crawlers’ IP Range Files, Google Search Central Blog, 31 mars 2026
- Crawling infrastructure changelog, Google Search Central
- Documentation common-crawlers, Google Search Central
- Documentation Google-Agent et Project Mariner
- Verifying Googlebot and other Google crawlers