Fin août, irs.gov, le site de l'administration fiscale américaine, a perdu sa visibilité sur Google sur des requêtes majeures comme « tax brackets » ou « free tax filing », en même temps que d'autres sites fédéraux. Les résultats restants affichaient des favicons cassés et des extraits sans description, et les PDF de l'IRS avaient disparu de l'index. Barry Schwartz a documenté le cas ; sa lecture, partagée par la communauté, est qu'une protection anti-bot renforcée côté gouvernement a bloqué Googlebot au passage. Le site se rétablissait progressivement le 28 août.
- Les symptômes forment une signature : chute sur les requêtes fortes, favicons cassés, extraits vides, PDF disparus, alors que le site répond aux humains ; c'est un Google qui reçoit une réponse valide mais pas le contenu
- John Mueller l'a expliqué en juillet : une page « Êtes-vous un robot ? » servie en 200 à Googlebot est indexée comme contenu, peut être désindexée ou perdre sa canonicité au profit d'un autre site ; les contrôles classiques ne la détectent pas
- Rien n'indique une pénalité ni un algorithme ; c'est une erreur de configuration de sécurité, la cause de chute la plus sous-diagnostiquée parce qu'elle ne laisse aucune erreur dans les outils habituels
Pourquoi une page en 200 peut faire disparaître un site
Une protection anti-bot mal calibrée ne renvoie pas une erreur : elle renvoie une page d'interstitiel (défi JavaScript, captcha, « vérification de votre navigateur ») avec un code 200. Pour Googlebot, la requête réussit. Ce qu'il indexe, c'est l'interstitiel. Les conséquences en cascade sont exactement celles observées sur irs.gov : plus de description (l'extrait est généré depuis le contenu reçu, qui n'en a pas), favicon cassé (le fichier lui-même est bloqué), PDF qui disparaissent (les documents sont servis derrière la même protection), et chute de positions parce que les pages ne contiennent plus les mots recherchés. Mueller a décrit un cas voisin, l'erreur « Page indexée sans contenu », où un service de sécurité bloquait silencieusement Googlebot tout en laissant passer les visiteurs.
Le piège est que tout semble marcher. Le site s'ouvre dans un navigateur, la supervision ne remonte rien, aucune erreur 5xx. Le seul endroit où le problème est visible, c'est ce que Google voit : l'outil d'inspection d'URL avec la capture de la page rendue, ou un crawl qui s'identifie comme Googlebot depuis une adresse que le pare-feu traite comme lui. Un test depuis son propre poste ne prouve rien, puisque le poste est autorisé.
Le contexte de 2026 rend le cas plus fréquent, pas moins. Les sites renforcent leurs défenses contre les crawlers d'IA, avec des règles de blocage par comportement plutôt que par user-agent, et ces règles attrapent Googlebot si personne n'a explicitement vérifié ses plages d'adresses. Google publie ses plages IP officielles ; la vérification par DNS inverse est documentée depuis dix ans. Ce qui manque, c'est la coordination entre l'équipe qui règle le pare-feu et celle qui suit le SEO.
Mon avis : ce n'est pas une news IRS, c'est une checklist. Chaque durcissement de sécurité (nouveau CDN, nouvelle règle WAF, activation d'un mode « sous attaque », protection anti-IA) doit être suivi dans l'heure d'une inspection d'URL sur trois pages. Le coût d'oublier se mesure en jours de visibilité, et pour un site qui sert des formulaires fiscaux à la rentrée, en bien plus.
Ce que ça change pour vous
Si vous gérez un site derrière Cloudflare, Akamai, un WAF ou un service anti-bot, vous êtes exposé au même scénario, et probablement plus qu'un site gouvernemental : les équipes sont plus petites et les changements de règles plus fréquents. Si vous bloquez les crawlers d'IA (et c'est légitime), vérifiez que la règle ne prend pas Googlebot dans le filet par ricochet.
Le rapport de statistiques d'exploration de Search Console est votre alarme : une hausse soudaine de réponses « autre » ou une chute de la taille moyenne des réponses, sans changement côté site, signe un interstitiel servi à Googlebot. L'analyse de vos logs serveur le montre encore plus vite : des hits Googlebot en 200 avec une taille de réponse anormalement uniforme et petite.
- Après tout changement de règle de sécurité, passe trois URL clés (accueil, une page profonde, un PDF) dans l'outil d'inspection d'URL et regarde la capture de la page rendue : si tu vois un défi ou un interstitiel, c'est ce que Google indexe
- Dans ton WAF ou CDN, ajoute une règle d'autorisation explicite pour Googlebot vérifiée par DNS inverse ou par les plages IP publiées par Google, placée avant toute règle de blocage comportemental
- Mets une alerte sur le rapport de statistiques d'exploration : baisse de la taille moyenne des réponses ou hausse des codes « autre » sur 48 heures, et rapproche-la du journal de changements de ton équipe sécurité
Sources
- Search Engine Roundtable - IRS Website Drops In Google Search (27 août 2026)
- Search Engine Journal - « Are you a bot » screens can get your pages dropped by Google (John Mueller, juillet 2026)
- Google Search Central - Vérifier Googlebot et ses plages d'adresses IP
Source : Seroundtable.com
Cet article a été rédigé avec l’assistance d’un modèle de langage (LLM).
