Blocage de robots par absence de chargement, la technique à double tranchant

Un visiteur qui vient lire votre page web mais ne charge PAS vos images, votre CSS ou votre JS... n'est pas un humain, mais plus généralement un robot crawler ! La détection et le blocage de ces robots parasites sur le log de non-chargement des ressources part de ce constat tout simple.

Et là, sans que vous n'y pensiez, cette super idée de configuration de firewall web peut tout à fait bloquer Google, ChatGPT ou le partage LinkedIn de votre dernier article. Avouez que ce serait dommage. Le pépin se situe ici. Un scraper malveillant et un moteur de réponses IA se comportent parfois de façon identique. Ok, alors on fait quoi ? et bien, ceci :

Le blocage de robots par absence de chargement, comment ça marche

Un navigateur humain, ou un robot qui rend vraiment la page comme Googlebot moderne, télécharge systématiquement le document HTML puis va chercher les feuilles de style, les scripts et les images qui vont avec.

Un simple robot crawler, lui, se contente souvent d'aspirer le HTML brut et repart. Le blocage de robots basé sur ce signal consiste à surveiller vos logs serveur, à repérer les couples IP ou user-agent qui demandent la page mais jamais ses ressources, et à les traiter comme suspects.

Cette approche est redoutablement efficace contre le spam de site web classique, les scrapers de contenu et les robots d'IA d'entraînement les moins soignés. Elle coûte quasiment rien en performance serveur, contrairement à un pare-feu WAF qui analyse chaque requête en profondeur.

C'est souvent la première ligne de blocage de robots avant même d'investir dans un Cloudflare ou un Sucuri.

Le test du log, en pratique

Vous croisez deux colonnes, le nombre de requêtes vers la page HTML et le nombre de requêtes vers ses ressources associées, pour un même user-agent ou une même IP sur une fenêtre de quelques minutes.

Un ratio proche de zéro pour les CSS, JS et images signale un robot crawler qui ne rend rien. Un ratio proche de un correspond à un vrai navigateur, humain ou automatisé, comme un test Core Web Vitals ou un outil de performance serveur légitime.

Comment détecter un robot crawler sur son serveur web

La majorité des robots d'IA fonctionnent en HTTP simple. Ils envoient une requête, récupèrent le HTML, en extraient le texte utile pour l'entraînement ou pour répondre à une question, et referment la connexion.

Charger le CSS ne sert à rien pour un LLM qui traite du texte, charger le JS encore moins puisque ces robots n'exécutent quasiment jamais de JavaScript. Le résultat est identique à celui d'un scraper malveillant du point de vue de vos logs, alors que l'intention n'a rien à voir.

"Nous détectons une augmentation des visites issues des robots crawlers jusque x5 sur les serveurs de nos clients depuis le 6 aout 2026."

Un robot crawler généraliste applique exactement la même logique, qu'il travaille pour un moteur de réponses ou pour un aspirateur de contenu. Le sujet rejoint notre page sur le rendu JavaScript et le référencement, où la même mécanique explique pourquoi un site mal rendu reste invisible.

C'est précisément ce qui rend le blocage de robots par cette seule méthode dangereux si vous ne complétez pas avec une liste blanche. GPTBot, ClaudeBot, PerplexityBot ou CCBot ne chargeront jamais vos images, exactement comme un spam de site web venu aspirer votre contenu.

Sans distinction, vous coupez au même moment votre trafic GEO et votre exposition dans les moteurs de réponses.

Le danger caché du blocage de robots automatique

Un robot crawler bloqué par erreur ne prévient personne. Pas d'alerte, pas d'email, juste une citation qui disparaît dans ChatGPT ou Perplexity, ou un partage LinkedIn qui n'affiche plus ni titre ni image parce que LinkedInBot n'a jamais pu lire la page.

Notre analyse de la disparition des citations Reddit montre à quel point ce genre de trou de visibilité peut passer inaperçu pendant des semaines. Notre suivi des citations dans les moteurs de réponses aide justement à repérer quand un robot crawler stratégique a été bloqué par erreur, avant que le trou ne dure des mois.

La distinction n'est jamais automatique, elle se construit robot par robot. Construire une vraie stratégie intelligence artificielle sur son site commence par savoir quel robot on choisit de nourrir et lequel on écarte.

Quels crawlers IA faut-il systématiquement épargner ?

Voici la liste des user-agent à exclure de tout blocage de robots basé sur l'absence de chargement des ressources, classée par famille.

Et les bots de réseaux sociaux, pourquoi les épargner aussi ?

facebookexternalhit ou LinkedInBot ne visitent votre page qu'une fraction de seconde, uniquement pour extraire le titre, la description et l'image de partage. Ils ne chargeront jamais votre CSS ni vos scripts, ce n'est pas leur travail.

Les bloquer avec cette méthode ne relève pas du spam de site web, ça revient à couper l'aperçu de vos propres articles partagés par vos propres clients. Les exclure d'un blocage de robots automatique est plus simple que de les réintégrer après coup.

Reverse DNS et user-agent, la vérification qui sauve votre GEO

Le user-agent seul ne prouve rien. N'importe quel scraper peut se présenter comme Googlebot ou GPTBot en changeant une simple chaîne de caractères dans sa requête.

La vérification qui compte s'appelle le reverse DNS, suivie d'une résolution inverse pour confirmer que l'adresse IP appartient réellement au domaine annoncé. Google documente précisément cette méthode pour authentifier Googlebot et ses autres robots.

En pratique, avant tout blocage de robots définitif sur un user-agent sensible, croisez le reverse DNS avec les plages IP publiées par Google, Bing, OpenAI ou Anthropic. Un faux Googlebot venu d'un hébergeur quelconque tombe immédiatement.

Un vrai Bingbot ou un vrai Perplexity résiste au test et mérite de continuer à circuler librement sur votre site.

Trois configurations de firewall qui bloquent les robots sans aveugler votre SEO

Trois approches, de la plus déléguée à la plus artisanale. Toutes partagent la même règle d'or, ne jamais bloquer sur le user-agent seul. On bloque sur l'absence de preuve d'identité, sur le comportement ou sur la violation d'une règle explicite, et on garde en amont une liste blanche des robots crawler utiles.

Option 1 : le WAF cloud avec liste des bots vérifiés

La méthode la plus simple si le site passe déjà par Cloudflare, AWS WAF ou Akamai. Le WAF maintient lui-même la liste des bots vérifiés par reverse DNS et plages IP publiées. Googlebot, Bingbot, GPTBot, ClaudeBot ou PerplexityBot y figurent, un faux Googlebot venu d'un VPS n'y figure pas.

Chez Cloudflare, le champ cf.client.bot est disponible sur tous les plans, gratuit compris. La première règle laisse passer les vérifiés, la seconde traite ce qui ressemble à un robot sans l'être officiellement.

Règle 1 : action Skip sur toutes les règles suivantes :

Règle 2 : action Managed Challenge plutôt que Block :

Le Managed Challenge évite d'éliminer un humain avec un navigateur exotique. Un vrai visiteur passe sans rien voir, un script Python sans moteur JavaScript échoue. Avec le module Bot Management payant, remplacez la liste de user-agent par cf.bot_management.score lt 30, qui s'appuie sur l'empreinte TLS et le rythme de navigation plutôt que sur une chaîne falsifiable.

Option 2 : reverse DNS et plages IP publiées sur votre propre serveur

Sans WAF cloud, sur un VPS ou un dédié avec Nginx, Apache ou HAProxy, la vérification se fait maison. Google, Bing et OpenAI publient chacun un fichier JSON de leurs plages IP officielles. Un cron les récupère chaque nuit et régénère un fichier d'inclusion. La règle devient alors simple, un user-agent de robot dont l'IP n'est dans aucune plage connue reçoit un 403.

Le rate limiting complète le dispositif pour tout ce qui n'a pas prouvé son identité, robots déguisés en navigateur compris. Un vrai crawler respecte les 429, un scraper agressif se fait couper.

Puis dans le bloc server :

La clé vide de $limit_key exempte les IP vérifiées du rate limiting, Googlebot n'est jamais ralenti. En complément, le filtrage par ASN simplifie la maintenance des listes, AS15169 pour Google et AS8075 pour Microsoft, à condition d'accepter que tout le cloud de ces éditeurs passe avec.

Cette option demande un vrai suivi. Les plages changent, les bots réseaux sociaux ne publient pas tous les leurs, et le reverse DNS pur, vérifié en forward-confirmed comme le documente Google, reste la référence pour trancher un cas douteux dans vos logs serveur.

Option 3 : le honeypot qui piège seulement les robots qui trichent

Cette approche ne décide pas qui est légitime, elle laisse les robots se dénoncer eux-mêmes. Les bons crawlers lisent le robots.txt et le respectent. Les scrapers et scanners de vulnérabilités l'ignorent et suivent tous les liens présents dans le code source, même invisibles.

Un lien caché dans le HTML pointe vers une URL piège, interdite dans le robots.txt :

Toute IP qui touche /piege/ a violé la règle en connaissance de cause. Fail2ban ou CrowdSec lit le log et bannit au niveau du firewall, tous ports confondus.

Le risque de faux positif est quasi nul puisque seul un robot qui a ignoré le robots.txt peut tomber dedans. Un humain ne voit pas le lien, Googlebot ne le suivra jamais. Vérifiez seulement que votre CDN ou votre cache ne réécrit pas le lien et que le préfetch du navigateur ne le déclenche pas, d'où le tabindex et le aria-hidden.

Laquelle choisir pour votre blocage de robots ?

Sur un hébergement mutualisé sans accès serveur, l'option 1 suffit. Sur un serveur administré qui subit du scraping ciblé, l'option 2 en base et l'option 3 par-dessus forment le duo le plus solide. Dans tous les cas, la liste blanche des crawlers IA et des bots sociaux vue plus haut reste posée avant la moindre règle de blocage.

Besoin d'un regard extérieur sur vos logs ?

Se faire accompagner sur ce point précis, c'est éviter de découvrir six mois plus tard que votre citation GEO a disparu à cause d'une règle posée un peu vite. Notre agence GEO à Metz traite ce type d'audit chaque semaine, avec la liste blanche à jour et le reverse DNS qui va avec.

Et si on regardait ensemble vos logs serveur, pour voir lesquels de vos robots méritent vraiment la porte, et lesquels vous font vivre en silence ?