Cloudflare bloque Googlebot : le réglage qui peut faire chuter votre SEO

Une chute brutale du trafic organique ne vient pas toujours d’une mise à jour Google. Parfois, le coupable se trouve dans un tableau de bord Cloudflare, derrière une option activée en quelques secondes.

Le 13 août 2026, Search Engine Roundtable a rapporté deux cas de sites dont la visibilité s’est effondrée après la mise en place de restrictions anti-bots au niveau du CDN ou du pare-feu. Dans l’un des cas, le trafic a été lourdement touché pendant deux semaines. Google ne pouvait plus explorer le site. Les annonces Shopping ont disparu, le trafic organique s’est écroulé et Google Ads a continué à dépenser le budget.

Ce n’est pas un détail technique. C’est un risque commercial immédiat.

Le faux diagnostic : « Google nous a pénalisés »

Le scénario est classique. Les positions chutent. Des pages sortent de l’index. Le trafic baisse presque verticalement. Comme plusieurs mises à jour Google se succèdent chaque année, l’équipe conclut vite à une Core Update ou à une Spam Update.

Mauvais réflexe.

Avant de réécrire 200 pages ou de désavouer des liens, il faut vérifier une chose beaucoup plus simple : Googlebot reçoit-il encore les pages ?

Cloudflare, les WAF et les outils de contrôle du crawl proposent désormais des réglages destinés à bloquer les robots indésirables et les crawlers d’IA. L’intention est légitime. Le problème apparaît quand une règle « bloquer tous les bots » englobe Googlebot, AdsBot-Google, Google-InspectionTool ou les robots utilisés par Merchant Center.

Une seule règle trop large peut couper plusieurs canaux en même temps.

Robots.txt et pare-feu : deux blocages très différents

Un blocage dans robots.txt indique au moteur qu’il ne doit pas explorer certaines URL. Un blocage Cloudflare intervient plus tôt. Googlebot peut recevoir une erreur 403, une page de challenge, une réponse 429, voire une page HTML différente de celle servie aux utilisateurs.

Dans ce cas, modifier le sitemap ne sert à rien. Demander une indexation dans Search Console non plus. Le serveur refuse encore l’accès.

Le diagnostic doit donc croiser quatre sources :

1. Les logs serveur ou CDN, filtrés sur les plages IP et user-agents Google.
2. L’inspection d’URL dans Search Console, avec le test en direct.
3. Les codes HTTP renvoyés à Googlebot sur plusieurs modèles de pages.
4. L’historique des changements Cloudflare, notamment Bot Fight Mode, WAF, rate limiting et règles personnalisées.

Attention au user-agent. N’importe quel script peut écrire « Googlebot ». Google recommande de confirmer l’identité du robot par DNS inversé ou à partir de ses plages IP publiées. Autoriser aveuglément une chaîne de caractères revient à laisser entrer les imposteurs.

La bonne méthode pour bloquer les bots sans casser le SEO

La sécurité et le SEO ne sont pas adversaires. Ils le deviennent quand personne ne documente les règles.

Commencez par établir une liste explicite des robots nécessaires au business : Googlebot pour la recherche, AdsBot pour les pages de destination, les robots Merchant Center pour les produits, Bingbot si Bing compte dans votre acquisition. Autorisez-les avec une méthode vérifiable, puis bloquez les catégories indésirables.

Ensuite, testez chaque changement sur un petit périmètre. Une règle WAF ne devrait jamais être déployée sur tout le domaine un vendredi soir sans contrôle des logs. Pendant les premières heures, surveillez les réponses 2xx, 3xx, 403 et 429 reçues par les crawlers légitimes.

Je recommande aussi une alerte si le nombre de requêtes Googlebot chute de plus de 50 % par rapport à sa moyenne sur sept jours. Ce seuil n’est pas une règle Google. C’est un garde-fou opérationnel. Il permet de repérer une rupture avant que les pages commencent à sortir de l’index.

Après le déblocage, la récupération n’est pas instantanée

Rétablir l’accès ne remet pas immédiatement toutes les URL à leur ancienne position. Google doit revenir, recrawler les pages, réévaluer les signaux et reconstruire une partie de l’index. Sur un gros site, cela peut prendre plusieurs jours ou davantage.

Il faut soumettre des sitemaps propres, vérifier les pages stratégiques avec l’inspection d’URL et suivre le retour de Googlebot dans les logs. Inutile de modifier massivement le contenu pendant cette phase. Vous ajouteriez du bruit à un incident déjà identifié.

Mon avis est simple : toute modification anti-bot est une modification SEO. Elle doit passer par un ticket, un test et une vérification après déploiement. Un CDN mal configuré peut annuler des années de travail en une case cochée. Ce n’est pas Google qui vous pénalise. C’est votre infrastructure qui lui ferme la porte.