Blocage User-Agent
Filtrer les robots au niveau du serveur, du WAF ou du CDN sans rendre le site invisible pour Googlebot.
Le blocage User-Agent, ou filtrage par UA, refuse l’accès à un site selon l’identité déclarée du client. La règle s’applique au niveau du serveur, du pare-feu applicatif (WAF) ou du CDN. En SEO, un blocage mal ciblé rend un site invisible pour Googlebot ou les crawlers IA, sans alerte dans le CMS.
Comment fonctionne le blocage User-Agent ?
Le blocage User-Agent repose sur l’en-tête HTTP User-Agent, envoyé à chaque requête. Un navigateur, Googlebot ou GPTBot se présentent chacun avec une signature distincte. Une règle de filtrage compare cette signature à une liste de motifs. Les requêtes correspondantes sont rejetées, le plus souvent avec un code 403. Le blocage User-Agent se pose à quatre niveaux : fichier .htaccess (mod_rewrite sur Apache ou LiteSpeed), module serveur type mod_security, plugin de sécurité WordPress, ou edge d’un CDN comme Cloudflare. Le blocage à l’edge est le plus traître : la requête n’atteint jamais le serveur d’origine, donc les logs du site ne gardent aucune trace du refus. La pression à filtrer explose : le trafic de GPTBot a bondi de 305 % entre mai 2024 et mai 2025, sa part passant de 2,2 % à 7,7 % du crawl observé (Cloudflare, juillet 2025). Le blocage User-Agent reste contournable par usurpation, un robot pouvant se déclarer sous une fausse identité.
Pourquoi le blocage User-Agent est important pour le SEO ?
Le blocage User-Agent est devenu un enjeu SEO majeur avec l’essor des moteurs génératifs. Un filtre trop large, hérité d’une configuration anti-scraping ou activé par défaut par un hébergeur ou un CDN, coupe silencieusement l’accès aux robots dont dépend la visibilité. Le cas extrême touche Googlebot : ce robot crawle à la fois pour l’indexation Search et pour l’entraînement IA de Google, donc le bloquer revient à disparaître des SERP (Cloudflare Radar, décembre 2025). Le cas fréquent touche GPTBot, ClaudeBot ou PerplexityBot. Un site bloqué à ce niveau disparaît des réponses de ChatGPT Search, de Perplexity et des AI Overviews, sans aucun signal dans la Search Console. Le diagnostic tient en une commande : curl -I -A "GPTBot" https://www.votresite.com/. Un 403 avec un User-Agent de robot et un 200 avec un User-Agent de navigateur signent un blocage User-Agent au niveau serveur ou CDN.
| Critère | Blocage robots.txt | Blocage User-Agent serveur |
|---|---|---|
| Nature | Directive indicative, respect volontaire | Verrou technique, refus avant tout contenu |
| Code HTTP renvoyé | 200, le robot lit la consigne et s’abstient | 403 immédiat, la page n’est jamais servie |
| Robots non coopératifs | Peuvent ignorer la directive | Bloqués, sauf usurpation de User-Agent |
| Visibilité du blocage | Fichier public, lisible par tous | Invisible sans test actif ou analyse de logs |
Comment savoir si un site bloque les robots IA ?
Testez chaque robot avec curl : curl -I -A "GPTBot" https://www.votresite.com/. Répétez avec ClaudeBot, PerplexityBot et OAI-SearchBot. Un 403 signale un blocage serveur ou CDN. Un 200 signale un accès normal. Complétez par la lecture du robots.txt et des logs serveur. Attention : un blocage à l’edge d’un CDN n’apparaît pas dans les logs d’origine.
Bloquer les bots IA nuit-il au référencement Google ?
Non, tant que le blocage User-Agent cible uniquement les robots IA et épargne Googlebot et Bingbot. Bloquer Google-Extended, le robot d’entraînement de Gemini, n’a aucun impact sur le classement dans Google Search. Le risque vient des règles trop larges : un motif comme « bot » ou « crawl » attrape aussi Googlebot. En revanche, bloquer les fetchers de recherche IA supprime toute visibilité dans ChatGPT Search, Perplexity et les réponses génératives.
Exemple concret de blocage User-Agent
Un blocage User-Agent se détecte en comparant la réponse serveur selon l’identité envoyée. Exemple : une page répond normalement à un navigateur, mais refuse l’accès à GPTBot ou PerplexityBot. Le contenu existe, le robots.txt peut sembler correct, WordPress ne signale rien, mais le crawler IA ne reçoit jamais la page. Pour le SEO, le problème est critique : le contenu reste visible pour l’utilisateur, mais invisible pour le moteur qui doit le récupérer, l’indexer ou le citer.
curl -I -A "Mozilla/5.0" https://www.exemple.com/curl -I -A "GPTBot" https://www.exemple.com/curl -I -A "OAI-SearchBot" https://www.exemple.com/curl -I -A "PerplexityBot" https://www.exemple.com/Si le navigateur reçoit un 200 et le robot un refus, la cause est en amont de WordPress. Les suspects : règle serveur, WAF, CDN, plugin de sécurité ou configuration d’hébergement. Point clé : une règle WAF ou serveur s’évalue avant toute lecture du robots.txt. Un blocage User-Agent prime donc sur n’importe quelle directive Allow du robots.txt. Le robots.txt ne suffit pas au diagnostic, car la requête est rejetée avant que le robot puisse lire la page.
Erreur fréquente observée en audit
Cas réel. En audit GEO, l’erreur classique consiste à vérifier le robots.txt et à conclure que les crawlers IA sont autorisés. Sur un hébergement mutualisé ou derrière un CDN, une règle de sécurité peut pourtant bloquer certains User-Agents avant même WordPress. La correction : tester les principaux robots avec curl, comparer les codes HTTP avec ceux d’un navigateur, puis remonter la chaîne. Logs serveur, WAF, CDN, règles .htaccess et plugins de sécurité, dans cet ordre.
Questions fréquentes
Un blocage User-Agent remplace-t-il le robots.txt ?−
Non, les deux agissent à des niveaux différents. Le robots.txt formule une demande que le robot applique ou ignore. Le blocage User-Agent refuse la connexion au niveau du serveur, du WAF ou du CDN, sans laisser le choix au robot.
Comment tester un blocage User-Agent depuis son poste ?+
Une requête curl avec l’option -A rejoue le User-Agent d’un robot. La réponse attendue est un code HTTP, pas une connexion coupée. Un blocage placé en amont du serveur web refuse même la lecture du fichier robots.txt.
Un pare-feu WordPress peut-il bloquer un crawler à mon insu ?+
Oui, Wordfence et les WAF d’hébergeur embarquent des listes de robots. La règle s’applique avant WordPress et ne laisse aucune trace dans l’administration. Le diagnostic passe par les logs serveur ou un test en ligne de commande.
Sources
- 1Cloudflare Radar, « 2025 Year in Review » · décembre 2025 consulter la source
- 2Cloudflare, « From Googlebot to GPTBot: Who’s crawling your site in 2025 » · août 2025 consulter la source
- 3Ahrefs, « The AI Bots That ~140 Million Websites Block the Most » · août 2025 consulter la source
Faire expliquer ce terme par une IA
Ouvre le moteur de ton choix avec un prompt pré-rempli sur ce terme.
