Bons et mauvais robots : classer avant de bloquer
Une IP demande 600 pages en 10 minutes. Si c'est un collecteur de prix, vous voulez l'arrêter. Si c'est Googlebot découvrant un sitemap, le bloquer peut retarder des milliers de produits. Même rapidité apparente, décisions opérationnelles opposées.
On ne distingue pas bons et mauvais robots par le seul user-agent, la vitesse ou JavaScript. Répondez à trois questions : qui est-ce, que fait-il et quel impact produit-il ?
Bons, mauvais et inconnus
Bons robots
Un bon robot sert un objectif accepté ou bénéfique au site :
- Robots des moteurs de recherche ;
- Surveillance de liens, disponibilité ou sécurité configurée par vous ;
- Récupération des aperçus de partage social ;
- Services d'accessibilité ou archivage autorisés ;
- Clients API partenaires sous accord.
Bon ne signifie pas sans restriction. Googlebot respecte robots.txt pour l'exploration automatique ; votre surveillance nécessite aussi des limites de points d'accès et de débit.
Mauvais robots
L'automatisation nuisible cause des dommages ou détourne l'usage du site :
- Clics publicitaires frauduleux ;
- Collecte de prix, contenu ou données clients ;
- Bourrage d'identifiants et attaques de mots de passe ;
- Création de comptes, spam de formulaires ou rétention des stocks ;
- Recherche de vulnérabilités ;
- Faux trafic polluant les analyses.
Robots inconnus
Souvent le plus grand groupe : outils SEO, applications mobiles, navigateurs sans interface, proxy de test ou nouveaux services IA. Bloquer immédiatement peut casser une intégration ; autoriser sans limite crée du risque.
Limitation et observation sont souvent préférables à une décision binaire pour ce groupe.
Un user-agent n'est pas une identité
Une requête disant :
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
n'a pas prouvé son origine Google. Tout script peut copier ce texte.
Google recommande :
- Le DNS inverse doit renvoyer un nom d'hôte Google valide, et le DNS direct revenir à la même IP ;
- Comparer l'IP source aux plages de robots publiées par Google.
Autoriser sur le seul user-agent favorise l'usurpation. Bloquer sur ce seul critère manque les robots imitant les navigateurs.
Matrice de signaux de classement
Aucun signal n'est parfait. Combinez-en plusieurs :
| Signal | Question |
|---|---|
| Identité réseau | Résidentiel, centre de données, VPN, Tor ou plage de robot vérifiée ? |
| User-agent | Cohérent avec l'empreinte TLS et le comportement ? |
| Fréquence | Requêtes par minute, cinq minutes et heure ? |
| Navigation | Charge HTML, CSS, images et chemins habituels ? |
| Comportement | Défilement, clics, focus, lecture et transitions naturels ? |
| Cible | Contenu public ou connexion, paiement et formulaires ? |
| Impact | Ressources, analyses faussées ou pertes publicitaires ? |
Un robot légitime peut être rapide, vérifié, respectueux de robots.txt et centré sur le public. Un collecteur peut annoncer Chrome en ignorant les ressources, changeant d'IP et ne récoltant que les produits.
Six comportements suspects
1. Haute fréquence sans rythme humain
Des centaines de clics espacés exactement de 200ms sont peu humains. Les robots légitimes sont aussi rapides : combinez fréquence, identité et URL visées.
2. Requêtes limitées aux points d'accès commerciaux
Les robots de stocks appellent la fonction d?ajout au panier, les robots d?attaque des identifiants ciblent la connexion et la fraude au clic frappe ? r?p?tition les pages de destination publicitaires ; le fait de sauter la navigation normale est un indice fort pour d?tecter la fraude au clic.
3. Empreinte et user-agent incohérents
Le user-agent annonce Safari sur iPhone mais TLS, ordre des en-têtes ou fenêtre ressemblent à Chromium sans interface sur ordinateur. L'incohérence est plus utile que le texte seul.
4. IP tournantes, traces d'appareil stables
Les proxy résidentiels permettent de changer d'adresse. Si cookies, empreintes, comportements et cibles se répètent, bloquer chaque IP devient sans fin.
5. Ressources secondaires jamais chargées
Les navigateurs récupèrent normalement CSS, JavaScript, polices et images nécessaires. Un collecteur simple demande seulement HTML ou API. Cache et confidentialité en font un indice complémentaire, pas une preuve.
6. Échecs progressant dans une liste
Des identifiants, coupons, cartes ou chemins d'administration séquentiels révèlent l'automatisation. Les limites IP échouent face aux robots distribués ; ajoutez compte, empreinte et action.
Éviter les règles brutales bloquant les bons robots
Bloquer tous les centres de données
Beaucoup de mauvais robots les utilisent, mais aussi surveillance, webhooks, recherche et services professionnels. Cela peut convenir à une action sensible de coupon, pas à tout le site public.
Bloquer chaque client rapide
Robots de recherche et moniteurs envoient des rafales valides. Les limites doivent refléter sensibilité des points d'accès et identité vérifiée.
Imposer des défis JavaScript partout
Les robots de recherche rendent certains JavaScript, mais défis antibot, cookies obligatoires et CAPTCHA peuvent bloquer la découverte. Le public important nécessite un accès propre aux robots vérifiés.
Garder confiance dans une ancienne liste autorisée
IP, services et besoins changent. Chaque entrée nécessite source, responsable, date de révision et journal d'utilisation.
Politique de réponse selon le risque
Niveau 1 : autoriser et journaliser
Pour robots vérifiés, surveillance interne et partenaires connus. Le privé exige toujours une authentification ; « bon robot » n'est pas une autorisation.
Niveau 2 : limitation souple
Pour l'automatisation inconnue lisant le public. Renvoyez 429 avec Retry-After au-delà du seuil plutôt que bloquer définitivement un court pic.
Niveau 3 : défi ou capacités réduites
Pour risque modéré : recherche rapide, paniers ou formulaires répétés. Introduisez contrôle JavaScript, CAPTCHA après seuil ou données réduites.
Niveau 4 : bloquer
Pour bourrage d'identifiants, exploitation, spam confirmé, fraude au clic étayée ou correspondance avec une liste de refus fiable.
Niveau 5 : enquêter et préserver les preuves
Pour fraude ou attaques durables, gardez identifiant de requête, horodatage, IP hachée, user-agent, empreinte, campagne et action. Limitez les données personnelles au nécessaire ; visez des décisions reproductibles.
Protéger différemment chaque surface
Pages de contenu et SEO
Autorisez les robots vérifiés, utilisez fortement le cache, limitez les inconnus et surveillez la collecte. Pas de CAPTCHA devant les articles et catégories à indexer.
Connexion et réinitialisation
Limitez par compte et IP, détectez les listes d'identifiants, utilisez MFA et alertez sur les échecs. Les actions révèlent aussi les robots résidentiels.
Formulaires de prospects
Honeypots, temps minimal, validation serveur et limites réduisent le spam. Le CAPTCHA seul ne suffit pas contre les fermes assistées par des humains.
Paiement et coupons
Suivez la fréquence par compte, appareil, carte et coupon. Bloquer les centres de données peut aider avec des exceptions pour les clients professionnels.
Pages publicitaires
Enregistrez campagne, identifiant de clic, horodatage et score. Comparez clics publicitaires, sessions, journaux et conversions. L'exclusion financière exige plus qu'une requête suspecte.
Enquêter sur une IP ou empreinte
- Classez l'adresse avec IP Checker.
- Vérifiez le DNS inverse si elle prétend être un grand robot.
- Récupérez les actions sur 5–30 minutes.
- Comparez user-agent, en-têtes, empreinte et ressources.
- Examinez campagne, page d'arrivée et valeur de l'action.
- Attribuez une confiance plutôt qu'une étiquette vrai/faux absolue.
- Choisissez autorisation, limitation, défi ou blocage.
- Donnez une expiration aux règles temporaires.
Un score 0–100 préserve la zone grise :
- 80–100 : signaux humains forts ;
- 50–79 : surveillance ou limites légères ;
- Sous 50 : plusieurs signaux d'automatisation ou de risque.
Les seuils dépendent du produit. Blogs, banques et jeux ont des tolérances différentes.
Traiter les faux positifs comme un indicateur produit
Arrêter 99% des robots en perdant 5% des vrais clients peut être pire qu'une approche moins agressive. Surveillez :
- Défis réussis ;
- Visiteurs bloqués contactant l'assistance ;
- Conversion avant et après règle ;
- Robots revenant par de nouvelles IP ;
- Points d'accès avec beaucoup de faux positifs.
Chaque règle nécessite raison, responsable et retour arrière. « Cette IP paraît étrange » n'est pas une politique opérationnelle.
Gérer les règles antibot comme le code de production
Les contrôles s'accumulent. Un blocage IP d'urgence peut rester des années après le changement de propriétaire de l'adresse. Traitez les règles comme une logique de production versionnée.
Chaque règle devrait enregistrer :
- Comportement ou incident justifiant la règle ;
- Signaux et niveau de confiance ;
- Points d'accès et utilisateurs concernés ;
- Responsable et date d'approbation ;
- Expiration ou révision ;
- Instructions de retour arrière ;
- Indicateurs de faux positifs à surveiller.
Testez en mode rapport seul lorsque le risque le permet. Journalisez les requêtes qui auraient été limitées ou bloquées, puis comparez aux connexions et achats réussis, robots vérifiés et plaintes. Cette observation révèle regex trop larges et règles réseau avant leur impact client.
Déployez par surface plutôt que globalement. Une règle stricte peut convenir aux coupons mais nuire à la documentation. Les politiques par point d'accès produisent aussi des indicateurs plus clairs.
Gardez un contournement d'urgence pour les opérations vérifiées et un retour arrière rapide. Pendant un faux positif, attendre un déploiement complet peut coûter plus que l'automatisation visée.
Révisez enfin les listes autorisées aussi soigneusement que les refus. Un jeton partenaire compromis ou une ancienne exception peut devenir une faille durable. La confiance doit être limitée, observable et régulièrement revérifiée.
Robots.txt est-il une défense antibot ?
Robots.txt est une convention pour robots coopératifs ; les malveillants peuvent l'ignorer. Il reste essentiel à Googlebot et aux robots légitimes mais ne remplace pas WAF, authentification, limitation ou analyse comportementale.
Utilisez Robots.txt Checker pour vérifier qu'une modification contre la collecte n'a pas bloqué la recherche.
Vue d'ensemble : découvrez le Quality Score du trafic et lancez un audit SEO gratuit avant un blocage global.
Conclusion
Vérifiez l’identité du robot avec la méthode officielle du fournisseur et examinez ses actions. Les en-têtes de sécurité ne prouvent ni son identité ni son autorisation par le WAF.
Références : Google Search Central – Googlebot et présentation des robots Google.
Foire aux questions
Le user-agent seul peut-il vérifier Googlebot ?
Faut-il bloquer toute IP de centre de données ?
Robots.txt peut-il bloquer les robots malveillants ?
Vérifiez votre site web gratuitement
Effectuez un audit SEO ou vérifiez la qualité de votre trafic dès maintenant — aucune inscription requise.