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 renommant googlebot.json en common-crawlers.json
• Ajouter une validation de schéma (par exemple avec Zod en TypeScript) sur les réponses pour transformer les...