Site ouvert aux humains, fermé aux IA

La panne la plus coûteuse de septembre ne ressemble pas à une panne. Le site s'ouvre, le design est en place, le responsable se connecte depuis son téléphone et voit tout. Mais les positions chutent, Google Ads affiche "Destination not accessible", et le site a disparu des réponses IA. Dans l'analyse publiée le 7 septembre 2026, la situation est décrite littéralement: un prestataire a activé en juillet 2026 le blocage de tous les bots dans Cloudflare, Googlebot est passé dessous, et la publicité est tombée avec l'organique. Voici qui doit être explicitement autorisé à revenir, et pourquoi le second canal de pertes, les scripts à la place des liens, reste totalement invisible dans les rapports.

D'où vient cette vague de 403

Le 1 juillet 2026, Cloudflare a supprimé l'interrupteur unique "bloquer les bots IA" et réparti les bots en trois catégories: Search, Agent, Training. Les options sont accessibles à tous, y compris sur l'offre gratuite. Cela ressemble à une amélioration, et c'en est une, avec une réserve que peu de gens ont lue jusqu'au bout.

La réserve: Cloudflare considère qu'une partie des crawlers ont un usage mixte, à la fois recherche et entraînement. Sont classés comme mixtes Googlebot, Bingbot et Applebot. Toute configuration qui bloque l'entraînement, y compris l'ancienne option "Block AI bots", les bloque aussi. L'avertissement a été publié le 5 août 2026, mais les réglages, les gens les ont cochés en juin et juillet.

Le 4 août 2026, Search Engine Journal a relayé un message de r/SEO: avec AI Training = Block et Bot Fight Mode activé, Googlebot et Bingbot recevaient un HTTP 403 en tentant de récupérer le sitemap, et dans la section AI Crawlers du panneau Cloudflare les deux apparaissaient comme bloqués. Dans un fil du Cloudflare Community, un propriétaire de site écrit que dès début juillet 2026 des requêtes Googlebot vérifiées recevaient un 403 avec la mention dans Security Events: "Blocked by 'Block AI training crawlers'".

Et voici la date importante. À partir du 15 septembre 2026, les valeurs par défaut de Cloudflare changent: pour les nouveaux domaines, les bots des catégories Training et Agent sont bloqués sur les pages qui affichent de la publicité, Search reste autorisé. Autrement dit, un nouveau domaine arrive désormais avec le blocage activé par défaut, et il faudra s'en occuper avant le lancement, pas après une réclamation.

1. 1 juillet 2026Cloudflare répartit les bots en Search, Agent, Training
2. 4 août 2026signalement de 403 pour Googlebot et Bingbot sur le sitemap
3. 5 août 2026avertissement: Googlebot, Bingbot, Applebot sont considérés comme mixtes
4. 31 août 2026rapports sur les surfaces IA dans toutes les Search Console
5. 15 septembre 2026nouveaux réglages de blocage par défaut pour les nouveaux domaines

Pourquoi ce n'est plus une histoire rare

Il y a un an, le blocage des crawlers concernait une dizaine de gros éditeurs. Aujourd'hui c'est le décor. Selon Cloudflare, la part de réponses 4xx pour l'ensemble des crawlers sur leur réseau a atteint 35,79% en juillet 2026 contre 14,04% en juillet 2025, soit 21,75 points de hausse. Les séries hebdomadaires le confirment: de 11,70% à 16,77% en 2025 et de 34,85% à 37,10% en 2026.

La raison est claire. Selon les statistiques Cloudflare de juin 2026, les crawlers d'entraînement ont généré 50,6% du trafic des bots de modèles, les crawlers de recherche seulement 10,7%, et plus de la moitié des passages ont porté sur des pages inchangées depuis la visite précédente. En juin 2026, le patron de Cloudflare, Matthew Prince, a déclaré que le trafic des bots dépassait pour la première fois le trafic humain. Quand les logs montrent que la moitié de la charge consiste à recopier des pages inchangées dans le dataset de quelqu'un, le bouton "interdire" se presse tout seul. La seule question, c'est ce qui passe dessous au passage.

Autre détail qui change les habitudes: la gestion des bots a quitté le niveau du robots.txt pour celui de l'infrastructure. Les catégories Cloudflare, les Content Signals avec le champ use (immediate, reference, full), l'identification cryptographique Web Bot Auth. Depuis le 7 mai 2026, Shopify applique des limites plus strictes aux bots qui ne signent pas leurs requêtes via Web Bot Auth. Les modifications du robots.txt ne disparaissent pas pour autant, elles ne sont simplement plus le seul endroit où votre site dit "non" à un bot.

Qui garder en liste blanche en permanence

La liste est courte, et elle ne parle pas d'IA. Ce sont les bots sans lesquels la recherche, la publicité et les flux produits cassent.

• Googlebot
• Google InspectionTool
• AdsBot-Google
• AdsBot-Google-Mobile
• Storebot-Google

Sur AdsBot, il existe une position officielle, et elle clôt le débat. L'aide Google Ads sur "Destination not accessible" cite explicitement comme causes les codes 404 et 403 lors du passage d'AdsBot, l'interdiction d'AdsBot dans le robots.txt et les configurations serveur qui bloquent l'accès. La recommandation, au même endroit: ajouter en liste blanche les user agents AdsBot-Google et AdsBot-Google-Mobile, et rendre le site accessible depuis tous les pays. Ce dernier point fait particulièrement mal à ceux qui ferment la moitié du monde par géofiltre au niveau du CDN: le bot n'arrive pas d'où vous l'attendez.

Google InspectionTool, c'est ce qui fait tourner l'inspection d'URL dans la Search Console. Storebot-Google parcourt les pages produits. Si vous ne les laissez pas passer, vous n'obtenez pas une chute de positions mais une bizarrerie: les rapports sont vides, et le support vous dit "chez nous tout va bien".

Pourquoi la coche verte dans la Search Console ne prouve rien

Dans cette même analyse du 7 septembre 2026, il y a une phrase qui justifiait la lecture: une inspection d'URL réussie confirme l'accès du bot de recherche, mais ne prouve pas l'accès d'AdsBot. Ce sont des user agents différents, et une règle dans le CDN peut laisser passer l'un et couper l'autre.

L'ordre de vérification est donc le suivant: d'abord les logs par user agent sur les 30 derniers jours, ensuite les événements de sécurité dans le panneau du CDN, et seulement après les outils Google. Dans les logs, vous ne voyez pas une opinion mais des codes de réponse. Si Googlebot arrive et reçoit un 403, il y aura un 403, et aucune coche dans l'interface ne le couvrira. Chez moi, je fais passer ce contrôle une fois par mois et après chaque intervention sur l'infrastructure, par des mains extérieures ou les miennes [chiffre à ajouter: combien de fois dans l'année j'ai trouvé une règle en trop].

Ce qu'a montré une expérience sur 41 jours

La seconde moitié des pertes est technique, mais d'une tout autre nature. Vinicius Stanula, Associate Director SEO chez LOCOMOTIVE, a mené une expérience sur 41 jours et l'a décrite sur Search Engine Land. Le site comportait 11 sections dont les liens étaient en HTML pur, et 10 sections dont les liens étaient injectés en JavaScript. Le sitemap renvoyait un 404, le fil d'Ariane et les panneaux de hiérarchie avaient été retirés: il ne restait au bot que les liens.

Résultat: Googlebot a atteint 2% des pages accessibles via des liens JS. Quant à GPTBot, ClaudeBot, Bingbot, aux crawlers de Meta et à Amazonbot, ils n'ont trouvé pratiquement aucune de ces pages.

Cela rejoint une mesure plus ancienne de Vercel et MERJ, de décembre 2024: aucune exécution de JavaScript n'a été constatée chez le moindre grand crawler IA. Les crawlers de ChatGPT téléchargeaient des fichiers JS dans 11,50% des requêtes, ceux de Claude dans 23,84%, mais ne les exécutaient pas. Télécharger et exécuter, ce n'est pas la même chose, et c'est exactement sur cet écart que disparaissent les catalogues, les filtres, les blocs chargés au clic et les flux infinis.

D'où une pratique simple. Vous ouvrez la page, vous désactivez JavaScript dans le navigateur, vous regardez ce qu'il reste. S'il reste un cadre vide à la place des produits et du texte, alors pour les bots IA cette page n'existe pas. Les liens doivent être des balises a avec un attribut href, pas un gestionnaire de clic, et les pages principales doivent figurer dans un sitemap qui renvoie 200.

Comment repérer qu'on est sorti des réponses IA

Le problème à part, c'est que cette disparition ne se voit pas dans les rapports habituels. Les positions classiques peuvent rester en place, le trafic organique couler tranquillement, alors que le site a disparu des réponses IA. Dans un rapport mensuel standard, cette colonne n'existe tout simplement pas.

Google en donne déjà une partie. Le 3 juin 2026, les rapports Search Generative AI performance ont été lancés dans la Search Console, et le 31 août 2026 ils ont été déployés sur tous les sites du monde. On y trouve les impressions, les pages, les pays, les appareils et les dates. Pas de clics. Le même 31 août 2026, un interrupteur a été activé globalement pour retirer le contenu de l'affichage dans les surfaces IA de Google, y compris AI Overviews, AI Mode et les fonctions génératives de Discover. Les rapports ont aussi vu apparaître les vues sur les plateformes tierces, dont Instagram, YouTube et TikTok.

Et une limite qu'il vaut mieux connaître d'avance: les données génératives ne vivent que dans l'interface. Une vérification du 11 août 2026 a montré que ni la Search Analytics API ni l'export vers BigQuery ne renvoient ces chiffres. Autrement dit, impossible pour l'instant de monter un tableau de bord automatique sur la visibilité IA: il faudra entrer à la main et faire des captures d'écran chaque semaine. Des impressions sans clics, pas d'export, des trous dans l'historique: les données existent, mais on ne peut pas s'appuyer dessus comme sur un rapport de requêtes classique.

Pourquoi il est trop tôt pour mettre la baisse sur le compte de l'algorithme

Quand les positions chutent, la première hypothèse est toujours la même: une mise à jour. Vérifions le calendrier. La dernière mise à jour de classement confirmée est un spam update: lancé le 18 août 2026 vers 12:30 heure de la côte est des États Unis, terminé le 21 août 2026 à 4:50, un déploiement d'environ 2,5 jours, mondial et pour toutes les langues, troisième spam update de 2026. Tout le reste qui a baissé en septembre relève plutôt de la technique: accès des bots, rendu, landing pages cassées.

Une autre histoire de septembre s'inscrit dans la même logique. Google Data Manager change le schéma de collecte des données sur le site, l'analyse des risques est parue le 8 septembre 2026. Le sens est identique: pendant que tout le monde discute de la qualité des textes, c'est la couche que personne ne regarde qui casse, parce qu'elle a toujours fonctionné.

Quoi faire cette semaine

1. Ouvrir les logs sur 30 jours et retrouver toutes les réponses 403 et 404 par user agent: Googlebot, AdsBot-Google, AdsBot-Google-Mobile, Google InspectionTool, Storebot-Google.
2. Dans le panneau du CDN, vérifier qu'aucun blocage des crawlers d'entraînement ni mode de lutte contre les bots touchant les crawlers mixtes n'est activé. Pour les nouveaux domaines, le faire avant le 15 septembre 2026, pas après.
3. Désactiver JavaScript dans le navigateur et parcourir trois pages types: accueil, catégorie, produit ou article. Ce qui n'est pas visible sans scripts n'existe pas pour les bots IA.
4. S'assurer que le sitemap renvoie 200 et que les liens importants sont des balises a avec href.
5. Aller dans les rapports sur les surfaces IA de la Search Console, relever les impressions actuelles par section et se mettre un rappel pour les relever une fois par semaine. Il n'y a pas d'export, l'historique ne se constituera pas tout seul.

Bloquer les crawlers d'entraînement, au passage, est une décision tout à fait valable. Ce qui ne l'est pas, c'est d'apprendre qui vous avez bloqué par un mail sur une campagne publicitaire arrêtée. Si vous voulez, je regarde votre cas dans les logs et les réglages, écrivez au support.