Détection des bots

MetriXs utilise plusieurs couches pour filtrer le trafic de bots de vos statistiques.

Vérifications côté serveur

• Filtrage user-agent, la bibliothèque isbot couvre 1500+ bots connus
• Modèles d’automatisation, bloque Puppeteer, Playwright, Selenium, python-requests, curl, Scrapy et plus
• Limitation de débit, max 120 événements par IP par minute, plus une limite par sous-réseau /24 (200 événements / 5 min) pour capturer les botnets distribués (basé sur Redis)
• Vérification de domaine, l’en-tête Origin doit correspondre au domaine enregistré
• Vérification Accept-Language, les requêtes sans en-tête Accept-Language valide sont rejetées
• Jeton d’empreinte de navigateur, le tracker code des signaux de navigateur réels (taille d’écran, fuseau horaire, concurrence matérielle, etc.) dans un jeton que les bots HTTP bruts ne peuvent pas produire

Vérifications côté client

Le script du tracker détecte aussi les bots avant l’envoi des événements :

• navigator.webdriver === true, Selenium/CDP
• window._phantom, window.__nightmare, PhantomJS, Nightmare.js
• window.Cypress, runners de test Cypress
• screen.width === 0, Chrome sans tête
• navigator.languages.length === 0, nombreux environnements sans tête

Détection d’IP de datacenter / cloud

MetriXs utilise la base de données ASN de MaxMind pour identifier le trafic depuis des fournisseurs de cloud et de datacenter connus. Les événements de ces réseaux sont automatiquement rejetés, car ils sont presque toujours automatisés :

• AWS, Google Cloud, Azure, DigitalOcean, Hetzner, OVH, Linode
• Alibaba Cloud, Tencent Cloud, Huawei Cloud, ByteDance, Cloudflare Workers
• Et bien d’autres

Auto-exclusion

Ajoutez localStorage.setItem('metrixs_ignore', 'true') dans la console de votre navigateur pour exclure vos propres visites.

Carte des bots bloqués

L’onglet Sécurité du tableau de bord affiche une carte Bots bloqués : le nombre de requêtes de bots rejetées sur la période sélectionnée, avec une répartition par raison, pays et page. Les requêtes bloquées ne comptent jamais dans vos statistiques — la carte montre simplement que le filtrage est actif.

Liens morts et bruit de crawl

Le tracker enregistre une page vue sur chaque page qui le charge, y compris les pages d’erreur. Quand un site passe hors ligne ou est restructuré, les crawlers continuent de revérifier les anciennes URL pendant des mois. Ces vérifications apparaissent comme des pages vues sur des chemins qui n’existent plus, avec un schéma reconnaissable : exactement une page vue par visiteur, aucun référent, aucun défilement et aucun temps passé sur la page, et une répartition geographique qui suit le réseau de proxys du crawler plutôt que de vrais lecteurs. Ce trafic exécute du vrai JavaScript, il n’est donc pas bloqué.

Si vous reconnaissez ce schéma, trois options, par ordre d’impact :

1. Retirez le snippet du modèle de page d’erreur. La correction la plus ciblée quand le trafic 404 est du bruit pur : les crawlers et les visiteurs égarés ne sont plus comptés, tandis que les vraies pages restent entièrement suivies.
2. Suivez explicitement les 404. Ajoutez la balise meta 404 au modèle de page d’erreur : chaque 404 enregistre alors aussi un événement 404 avec le chemin demandé dans la carte Événements auto-suivis, afin que les URL mortes avec de vrais visiteurs (par exemple des liens internes cassés) deviennent visibles. Les pages vues elles-mêmes comptent toujours.
3. Servez du 410 Gone pour les chemins définitivement supprimés. Les crawlers et moteurs de recherche désindexent les réponses 410 plus vite que les 404, donc le trafic de revérification s’estompe avec le temps.