CF GaragePourquoi des règles de sécurité finissent par bloquer les moteurs de recherche
Les moteurs d'indexation comme Googlebot et Bingbot se comportent d'un point de vue réseau comme des automates : fréquence de requêtes soutenue, exploration depuis des datacenters distants et absence d'exécution de CAPTCHAs interactifs. Lorsque la configuration Cloudflare est trop rigide, ces robots légitimes sont refoulés :
- Règles de géoblocage (Country Blocking) trop larges : Googlebot explore l'immense majorité des sites depuis des adresses IP situées aux États-Unis. Si vous restreignez l'accès à l'Europe ou à la France sans exception, Googlebot est systématiquement bloqué en erreur 403.
- Rate Limiting global non contextualisé : Les passages d'indexation profonde génèrent des pics de requêtes légitimes qui dépassent rapidement les seuils de Rate Limiting appliqués aveuglément à l'IP.
- CAPTCHAs JavaScript (Managed Challenge) imposés aux bots : Googlebot ne résout pas les CAPTCHAs interactifs ni les boucles Turnstile. Présenter un Managed Challenge empêche définitivement l'indexation de vos pages par Googlebot.
- Mauvaise distinction entre vrais et faux bots : Bloquer un User-Agent usurpé avec des expressions approximatives finit par rejeter les véritables serveurs d'indexation de Google et de Bing.
La configuration de règles de sécurité saine pour préserver votre SEO
Pour sécuriser votre site web tout en garantissant un accès prioritaire et fluide à tous les robots d'indexation légitimes :
- Utilisation impérative de
cf.client.bot: Ce champ managé par Cloudflare authentifie de manière fiable les crawlers officiels (Googlebot, Bingbot, Applebot, DuckDuckGo) via reverse DNS vérifié et listes d'adresses IP officielles. - Création d'une règle d'exemption prioritaire (Skip Rule) : Placer en tête de vos règles de sécurité une directive autorisant sans restriction les requêtes où
cf.client.bot == true, en contournant le géoblocage et les CAPTCHAs de sécurité. Notre bibliothèque de guides Cloudflare détaille la configuration complète produit par produit. - Gestion des outils d'inspection Google Search Console : Identifier les requêtes de test en direct (qui partagent l'ASN Google AS15169) pour ne pas fausser les audits d'indexation.
- Surveillance des rapports de crawl et des logs de sécurité : Corréler les journaux d'événements de sécurité avec le rapport de statistiques d'exploration de Search Console pour éliminer tout point de friction.
Débloquer Googlebot pas à pas
Si les positions ont déjà chuté, suivez cette séquence avant de modifier la moindre règle. Chaque étape est vérifiable : vous savez toujours ce qui a changé et avec quel effet.
Étape 1 : confirmer que le blocage est bien côté Cloudflare. Dans Google Search Console, ouvrez l'inspection d'URL et lancez un test en direct sur quelques URL concernées. Récupérez ensuite une page par vous-même et examinez la réponse :
curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://exemple.fr/page
Un 403 ou une page de CAPTCHA pointe vers une règle de sécurité ou de Rate Limiting de votre zone. Un 5xx renvoie plutôt à votre serveur d'origine, un problème différent traité dans notre guide sur les erreurs 521, 522 et 524 intermittentes.
Étape 2 : identifier la règle exacte dans les événements de sécurité. Dans le tableau de bord Cloudflare, ouvrez Sécurité > Événements, filtrez sur l'IP de service ou le user agent observés dans Search Console, et notez la colonne Service de l'événement bloquant : règles personnalisées, Rate Limiting, Bot Fight Mode ou règles d'accès IP. Un bloc qu'on ne voit pas est un bloc qu'on ne corrige pas.
Étape 3 : exempter les crawlers vérifiés par une règle Skip en tête de liste. Dans Sécurité > WAF > Règles personnalisées, créez une règle tout en haut de la liste avec une action Skip désactivant les produits de sécurité restants, sur une expression de bots vérifiés :
(cf.client.bot)
Le champ cf.client.bot n'est vrai que pour les crawlers validés par Cloudflare via reverse DNS : les user agents usurpés qui se prétendent Googlebot restent donc exposés à vos autres règles. Si vous souhaitez aussi autoriser les requêtes d'inspection en direct de Google, étendez l'expression avec ip.src.asnum eq 15169.
Étape 4 : revérifier avec l'inspection d'URL en direct. Relancez le test en direct de Search Console sur les URL affectées. Un « URL disponible pour Google » confirme la correction du point de vue de Google lui-même, pas seulement du vôtre.
Étape 5 : surveiller les statistiques d'exploration pendant une semaine. Les requêtes d'exploration et le nombre de pages indexées remontent progressivement. Comparez le rapport de statistiques d'exploration avant et après ; une reprise saine apparaît généralement en quelques jours une fois les 403 et les pages de CAPTCHA disparus.
Les erreurs fréquentes qui fragilisent le trafic de recherche
- Se fier au seul user agent. Une expression comme
http.user_agent contains "Googlebot"s'usurpe trivialement et laisse passer les attaquants. Associez toujours la chaîne à une vérification, ou utilisez simplementcf.client.bot. - Exempter « tous les bots » aveuglément. Certaines configurations autorisent toute requête signalée automatisée, y compris les scrapers abusifs déjà classés par Cloudflare. Calez l'exemption sur les moteurs de recherche vérifiés.
- Oublier Bingbot et les moteurs secondaires. Bing alimente plusieurs expériences de recherche et son crawler mérite la même exemption ;
cf.client.botle couvre avec Applebot, DuckDuckGo et d'autres. - Supprimer toute protection le temps du débogage. Désactiver toutes les règles de sécurité pour « tester » vous expose exactement au trafic d'attaque visé par vos règles. Une règle Skip ciblée permet le test sans l'exposition.
- Ne jamais corréler avec Search Console. Les journaux firewall seuls ne montrent pas l'impact sur le budget de crawl. Une vérification hebdomadaire des statistiques d'exploration détecte les frictions avant que les positions ne bougent.
Questions fréquentes
En combien de temps les positions reviennent-elles après le déblocage de Googlebot ?
Les pages momentanément inaccessibles sont généralement ré-explorées en quelques jours et les positions suivent l'exploration. Comptez une récupération significative en une à trois semaines selon la durée du blocage et la taille du site. Soumettre des sitemaps à jour dans Search Console accélère la redécouverte.
Le Bot Fight Mode bloque-t-il Googlebot ?
Le Googlebot vérifié est normalement détecté et autorisé, mais le Bot Fight Mode ne propose aucune option de configuration : les cas limites et les crawlers usurpés peuvent encore produire des blocages ou des CAPTCHAs. Si Search Console montre des 403 ou des pages de CAPTCHA, remplacez le bouton global par des règles personnalisées autorisant explicitement cf.client.bot, comme décrit dans notre guide sur les faux positifs du Bot Fight Mode.
Faut-il bloquer les crawlers IA dans le même temps ?
C'est possible, et le même flux de règles personnalisées s'applique. La distinction clé : les crawlers de recherche vérifiés (cf.client.bot) doivent être exemptés tandis que les scrapers IA indésirables comme GPTBot ou ClaudeBot sont bloqués par leur signature. Notre guide sur le blocage des crawlers IA en conservant Googlebot détaille les expressions exactes.
Puis-je me contenter d'autoriser les plages IP de Google ?
Cela fonctionne mais vieillit mal : Google publie des plages qui évoluent sans préavis et une liste statique se dégrade en silence. Les champs vérifiés par reverse DNS comme cf.client.bot restent exacts automatiquement, d'où leur statut de signal recommandé.