Kinsta a analysé plus de 10 milliards de requêtes HTTP sur l’ensemble de son infrastructure d’hébergement et a constaté que des robots avaient accédé aux URL « Ajouter au panier » des sites WordPress à 7,67 millions de reprises au cours d’une seule période de 24 heures. Un seul robot d’indexation a généré à lui seul 550 millions de requêtes en 30 jours avant qu’une règle ne le bloque.
Aucune de ces requêtes n’a abouti à une conversion. Aucune n’a renvoyé de visiteur vers le site. Elles n’ont cessé d’affluer en ciblant les pages de panier, les URL de produits filtrés, les requêtes de recherche et les points de terminaison AJAX, chacune forçant le serveur à exécuter du code PHP, à lancer une requête de base de données et à gérer une session pour un trafic qui ne se transformerait jamais en client.
Les sites absorbant cette charge n’étaient pas hors service. Les pages se chargeaient. Le processus de paiement fonctionnait. À tous les égards, ils semblaient en bonne santé. C’est précisément le problème abordé dans cet article.
Le trafic généré par les robots n’est plus un simple bruit de fond
En 2025, les robots représentaient 53 % de l’ensemble du trafic web, marquant ainsi la première fois où le trafic automatisé dépassait le trafic humain au cours d’une année civile. En juin 2026, Cloudflare Radar estimait ce chiffre à 57,5 %, un renversement de tendance qui, selon le PDG de Cloudflare lui-même, s’est produit plusieurs années avant ses prévisions.
Pour les exploitants de sites WordPress, ce changement concret va au-delà d’un simple pourcentage. Le trafic généré par les robots d’aujourd’hui ne se limite pas aux robots d’indexation effectuant leur travail habituel. Il inclut des robots d’entraînement à l’IA, des outils de scraping, des robots d’audit SEO, des outils de surveillance de la disponibilité, de faux agents utilisateurs, ainsi que des outils d’IA agentique qui suivent les liens de manière bien plus intensive que ne le ferait jamais un robot d’indexation traditionnel.
Certains indexent le contenu. D’autres le « scrapent ». D’autres encore testent les points de terminaison. D’autres enfin traitent chaque combinaison de paramètres d’URL comme une page distincte et les explorent toutes.
Ce dernier comportement est particulièrement coûteux pour WordPress. Une page produit comportant des filtres de couleur, de taille, de tri, de pagination et de stock apparaît comme une seule et même page pour un visiteur humain. Un robot peut y voir des centaines d’URL uniques et les explorer toutes.
Le trafic généré par les robots basés sur l’IA a bondi de 300 % en un an. À la fin de l’année 2025, les robots IA représentaient 1 visite sur 31 sur le réseau de TollBit, contre 1 sur 200 au début de l’année. La tendance est claire. Ce qui reste encore sous-estimé, c’est le coût réel de ce trafic.
La bande passante est le coût évident
La bande passante correspond aux données que votre site transfère lorsqu’un utilisateur demande une page, une image, un script, un fichier ou tout autre élément. Les visiteurs humains l’utilisent. Les robots aussi, et ils n’achètent rien par la suite.
Un robot d’indexation qui consulte un article de blog une seule fois ne pose pas de problème. En revanche, un robot qui explore de manière répétée les archives, les pages d’étiquettes, les ressources image, les flux, les scripts et les URL filtrées peut consommer de la bande passante réelle sans générer la moindre valeur commerciale.
Selon les données de Cloudflare pour 2025, citées dans le rapport de Kinsta sur le trafic généré par l’IA et les robots, 80 % de l’activité d’exploration par l’IA est destinée à l’entraînement de modèles plutôt qu’à la recherche ou à des requêtes déclenchées par les utilisateurs, et elle ne génère aucun trafic de référence vers le site. Pour les sites WordPress riches en contenu, cette dynamique transforme des pages à forte valeur ajoutée en ressources très coûteuses.
Le plus insidieux, c’est que le gaspillage de bande passante s’accumule souvent sans entraîner de problème de performance visible. Le site continue de se charger. Le serveur continue de répondre. Mais la consommation ne cesse d’augmenter, car le trafic automatisé continue de solliciter des pages et des ressources dont aucun visiteur humain n’a besoin.
Au moment où le coût de la bande passante devient évident, le site a peut-être déjà passé des jours, voire des semaines, à traiter un trafic qui n’a jamais apporté la moindre valeur ajoutée à l’entreprise.
La charge du backend est le coût le plus difficile à évaluer
Toutes les requêtes n’ont pas le même coût de traitement. Un article de blog mis en cache est relativement peu coûteux, car le serveur renvoie une version stockée et passe à autre chose. Les requêtes dynamiques fonctionnent différemment.
Lorsqu’un bot accède à une action du panier WooCommerce, à une page de produit filtrée, à une URL de requête de recherche, à une page de connexion ou à un point de terminaison AJAX, le serveur ne peut pas puiser dans le cache. Il doit effectuer à chaque fois :
- Exécution PHP — un thread est réservé pour toute la durée de la requête
- Requêtes à la base de données — la page interroge la base de données à chaque chargement, sans cache pour absorber cette charge
- Gestion des sessions — les pages de panier et de commande créent ou valident une session à chaque requête, même pour les robots qui ne finaliseront jamais d’achat
- Logique des plugins — toute extension qui s’accroche à ces requêtes exécute son code à chaque accès
- Contournement du cache — la requête n’entre jamais dans le cache, de sorte que les futures requêtes identiques entraîneront à nouveau le même coût
C’est là que le trafic généré par les robots s’avère plus coûteux qu’il n’y paraît. Le problème ne réside pas uniquement dans la quantité de données téléchargées par un robot. Il réside dans la charge de travail que l’infrastructure doit supporter avant de renvoyer ces données.
Les données d’infrastructure de Kinsta permettent de quantifier concrètement l’ampleur du phénomène : les robots ont accédé aux URL « Ajouter au panier » 7,67 millions de fois en l’espace de 24 heures, dont 3,75 millions de requêtes provenant du seul ClaudeBot. Chacune a été traitée comme une nouvelle requête côté serveur. Chacune a déclenché l’exécution de code PHP et une requête de base de données. Aucune ne répondait à un client.
Comme l’a expliqué Daniel Pataki, directeur technique de Kinsta, lors du lancement : « La plupart des conseils en matière de gestion des bots se résument à “tout bloquer” ou “ne rien faire”. Aucune de ces deux approches ne fonctionne à grande échelle. »
Pourquoi l’argument « nous n’avons pas connu d’interruption de service » passe à côté de l’essentiel
La disponibilité signifie que le site reste en ligne. Cela ne signifie pas pour autant que le site fonctionne efficacement.
Un site WordPress peut absorber un volume important de trafic inutile avant que les visiteurs ne remarquent un dysfonctionnement. Les pages continuent de se charger. Le processus de commande fonctionne toujours. Les écrans d’administration restent réactifs. Mais l’infrastructure continue de traiter chaque requête de bot qui atteint un point de terminaison dynamique, et ce traitement a un coût réel, même lorsque le site semble stable.
Ce coût se manifeste de manière plus subtile qu’une panne :
- Une utilisation accrue de la bande passante qui se rapproche progressivement des limites de votre plan
- Une pression accrue sur les workers PHP et les connexions à la base de données
- Une marge de manœuvre réduite lorsque de véritables pics de trafic sollicitent ces mêmes ressources
- Des analyses faussées qui confondent les sessions de robots avec l’engagement humain
- Des résultats de tests A/B et des taux de conversion faussés par un trafic qui n’avait jamais l’intention de se convertir
- Des décisions relatives à l’infrastructure prises sur la base de données qui ne reflètent pas le comportement réel de l’audience
- Un dépannage plus difficile lorsque le bruit généré par l’activité des bots masque le signal des véritables problèmes de performance
C’est pourquoi l’absence de « temps d’arrêt » peut donner aux équipes un faux sentiment de sécurité. Le site semble stable car l’infrastructure absorbe la charge supplémentaire. Absorber ce gaspillage a tout de même un coût ; il ne se manifeste simplement pas de manière visible.
Pourquoi les agences devraient-elles remédier à ce problème avant que les clients ne s’en aperçoivent ?
Les agences sont généralement informées du trafic généré par les robots après que celui-ci a déjà causé un problème visible. Un client constate une augmentation de la consommation de ressources d’hébergement, un ralentissement des écrans d’administration, des ralentissements lors du paiement, des schémas de trafic inhabituels ou des données analytiques qui ne correspondent plus à ses résultats commerciaux. À ce stade, la discussion est réactive. L’agence doit expliquer ce qui s’est passé, en quoi cela est important et quels changements doivent être mis en œuvre.
Le trafic généré par les robots permet au contraire aux agences d’adopter une approche proactive.
Il n’est pas nécessaire d’adopter un ton alarmiste. On peut rester pragmatique :
- « Votre site fonctionne peut-être bien, mais une partie de ce trafic ne provient peut-être pas de véritables visiteurs. »
- « Certaines activités des robots sont utiles, comme les robots d’indexation ou les outils de surveillance, mais d’autres ne font que consommer des ressources. »
- « Nous pouvons réduire le gaspillage sans affecter le trafic qui compte réellement. »
- « Une bonne gestion de ce phénomène préserve la marge de performance et contribue à maintenir une utilisation prévisible. »
Cela relie la gestion des robots à des préoccupations que les clients comprennent déjà : coût, efficacité, fiabilité. Cela permet également à l’agence de passer du statut de dépanneur réactif à celui de conseiller proactif en matière d’infrastructure, ce qui favorise une relation plus durable.
L’objectif n’est pas de bloquer tous les robots
Il est important de noter que tout le trafic généré par les robots n’est pas nuisible. Les robots d’indexation aident les pages à apparaître dans les résultats de recherche. Les outils de surveillance vérifient la disponibilité du site. Les plateformes de référencement (SEO) effectuent des audits des pages. Les prestataires de paiement, les intégrations, les API et les automatisations WordPress peuvent également avoir besoin d’accéder au site pour effectuer des tâches légitimes.
Les robots d’IA sont plus complexes. Certains propriétaires de sites peuvent souhaiter bénéficier d’une visibilité dans les expériences basées sur l’IA. D’autres peuvent estimer que l’exploration par l’IA engendre plus de coûts qu’elle n’apporte de valeur, en particulier lorsqu’elle extrait de vastes bibliothèques de contenu sans générer en retour de trafic de référence significatif.
C’est pourquoi l’objectif n’est pas de bloquer toutes les requêtes automatisées. Un blocage excessif peut entraîner des problèmes de référencement, perturber les intégrations, interrompre la surveillance ou interférer avec les flux de travail WordPress normaux.
Une meilleure approche consiste à exercer un contrôle sélectif :
- Autoriser le trafic utile
- Bloquez les automatisations manifestement inutiles
- Vérifier le trafic suspect
- Protéger les chemins à fort coût
- Surveiller les résultats
Cela permet aux équipes d’exercer un meilleur contrôle sans traiter tous les robots de la même manière. L’objectif est de réduire le gaspillage tout en préservant le trafic, les outils et les flux de travail qui continuent de soutenir l’activité.
Comment la protection contre les robots de Kinsta gère cela dans la pratique
Dès que le trafic généré par les robots devient un problème d’infrastructure, la réponse doit être adaptée à la situation réelle du site.
La protection contre les robots dans MyKinsta est conçue pour s’adapter à cette variabilité. Elle est incluse dans tous les plans sans frais supplémentaires, fonctionne au niveau de l’environnement et prend effet immédiatement dès que les réglages sont modifiés.
Niveaux de protection
Accédez à Sites > nom du site > Protection contre les robots > Modifier pour choisir parmi quatre niveaux prédéfinis, chacun s’appliquant indépendamment par environnement, ce qui permet aux environnements de préproduction, de développement et de production d’utiliser des paramètres différents.
- Bloquer le trafic malveillant — le réglage par défaut sur tous les sites. Gère l’atténuation des attaques DDoS et bloque les adresses IP et les points d’accès associés à des schémas d’attaque connus. Cette fonctionnalité est déjà activée sur tous les sites Kinsta.
- Bloquer les automatisations — le point de départ recommandé pour la plupart des sites confrontés à une charge de robots. Bloque le trafic automatisé et malveillant confirmé tout en laissant passer les robots vérifiés et les visiteurs réels. Efficace pour les sites subissant des accès répétitifs sur des URL dynamiques sans vouloir interdire l’accès au trafic humain.
- Défier les robots — ajoute une étape de vérification pour les robots potentiels et le trafic non classé. Un visiteur qui réussit la vérification ne sera plus sollicité pendant dix jours sur le même navigateur et la même adresse IP. Utile lors des pics de trafic, des évènements promotionnels ou des périodes de scraping intensif, où l’équilibre entre blocage et friction nécessite davantage de précision.
- Défier tout le monde — le réglage le plus strict, conçu pour une utilisation à court terme lors d’une attaque en cours ou d’abus prolongés. Tout le trafic non vérifié est soumis à un test, y compris les visiteurs probablement humains. Il ne s’agit pas d’une configuration permanente.
Avant de passer à un niveau supérieur à Bloquer le trafic malveillant, vérifiez que vos intégrations critiques pour votre activité figurent dans le répertoire des robots vérifiés de Cloudflare. À partir du niveau Défier les robots ou supérieur, tout outil se connectant à votre site de manière programmatique et non vérifié sera soumis à un test ou bloqué.
Bloquer les robots d’indexation IA
Le bouton Bloquer les robots d’indexation IA est un contrôle distinct du niveau de protection. Il cible spécifiquement les robots d’indexation IA, y compris ceux qui sont vérifiés comme GPTBot, tout en laissant Googlebot et Bingbot inchangés. L’indexation de votre site par les moteurs de recherche se poursuit normalement.
Pour les sites riches en contenu, les éditeurs, les bibliothèques de documentation et les plateformes de contenu premium où les robots d’indexation IA accèdent de manière répétée et en grand nombre aux pages d’articles, aux pages d’archives et aux ressources non mises en cache, ce bouton supprime cette charge sans affecter la visibilité dans les résultats de recherche.
Le compromis est réel et mérite d’être souligné : le blocage des robots d’exploration IA réduit la fréquence à laquelle votre contenu apparaît dans les réponses et les résumés générés par l’IA. Pour les sites où la visibilité dans l’IA est une priorité stratégique, il peut être plus judicieux de conserver les automatisations de blocage ou de Défier les robots, car elles filtrent les comportements les plus nuisibles tout en permettant l’indexation. Pour les sites où le coût des ressources serveur et l’utilisation du forfait priment sur la visibilité dans l’IA, le blocage est la solution la plus simple.
Autoriser les automatisations WordPress courantes
Lorsque vous augmentez le niveau de protection au-delà de la valeur par défaut, activez simultanément l’option Autoriser les automatisations WordPress courantes.
Cela active une liste blanche gérée des chemins d’accès et services WordPress courants, tels que les requêtes API REST, les routes WooCommerce, les tâches en arrière-plan, les tâches planifiées et les intégrations d’extensions, afin qu’un filtrage plus strict des robots ne perturbe pas discrètement les flux de travail dont dépend le site.
Activez cette option dès que vous passez au niveau Bloquer les automatisations ou à un niveau supérieur. L’objectif est de réduire le trafic inutile, et non d’interrompre les opérations légitimes.
Toujours autoriser
Certains services ne doivent jamais faire l’objet d’une vérification, quel que soit le niveau de protection. La section « Toujours autoriser » vous permet d’ajouter jusqu’à 50 exceptions personnalisées par adresse IP, chemin d’URL ou agent utilisateur.
Utilisez-la pour :
- Webhooks des prestataires de paiement (Stripe, PayPal)
- Services de surveillance de confiance (UptimeRobot, Pingdom)
- Intégrations de partenaires connues ou utilisateurs d’API
- Plages d’adresses IP des développeurs ou du bureau
- Chemins d’accès WordPress spécifiques tels que /wp-json/* ou /wp-admin/admin-ajax.php s’ils ne sont pas déjà couverts par la liste des automatisations WordPress
Répartition des requêtes et résultats de la protection contre les robots
Il est difficile d’optimiser le trafic des bots lorsque les équipes ne peuvent pas voir comment les requêtes sont classées ou traitées.
Avant de modifier tout réglage, consultez d’abord l’écran « Protection contre les robots ». Le graphique de répartition des requêtes affiche toutes les requêtes effectuées sur votre site au cours des dernières 24 heures, classées en sept catégories : « Probablement des utilisateurs humains », « Robots vérifiés », « Probablement des robots », « Robots d’indexation IA », « Robots d’indexation IA à fréquence excessive », « Trafic non classé » et « Trafic automatisé ».
La question a changé
L’hébergement a toujours été évalué à l’aune d’une courte liste de résultats visibles : le site est-il en ligne ? Se charge-t-il rapidement ? Les visiteurs peuvent-ils accomplir ce pour quoi ils sont venus ?
Ces questions restent importantes. Mais elles ne reflètent plus toute la réalité.
Un site peut rester en ligne tout en gaspillant de la bande passante. Il peut se charger rapidement tandis que des robots consomment les threads PHP et les connexions à la base de données dont les véritables visiteurs ont besoin. Il peut réussir un test de vitesse un mardi après-midi, puis peiner sous la charge du lancement d’une campagne le jeudi, car la marge de manœuvre qui aurait dû être disponible avait déjà été utilisée pour traiter un trafic qui n’a jamais profité à l’entreprise.
La question n’est plus simplement « Le site peut-il supporter la charge ? », mais « Quelle part de cette charge le site devrait-il réellement supporter ? »
Le trafic généré par les robots n’a pas besoin de mettre un site hors ligne pour avoir un coût. Il lui suffit de continuer à solliciter les chemins qui nécessitent un véritable traitement, et de le faire à un volume qui, sur tous les tableaux de bord, ressemble à une activité normale.
C’est en obtenant une visibilité sur ce trafic et en disposant des contrôles permettant d’agir en fonction de ce que vous observez que vous pouvez changer la donne. Vous ne pouvez pas gérer ce que vous ne voyez pas, et vous ne pouvez pas agir sur ce que vous voyez si vos seules options consistent à tout bloquer ou à ne rien faire.
Pour les équipes WordPress gérant des sites riches en contenu, des boutiques WooCommerce ou d’importants portefeuilles de clients, l’hébergement WordPress infogéré de Kinsta met ces contrôles à votre disposition dans MyKinsta, sans frais supplémentaires, et réglables par environnement sans avoir à ouvrir de ticket de support. Commencez par consulter le rapport sur le trafic généré par l’IA et les robots pour obtenir une vue d’ensemble complète de ce qui sollicite l’infrastructure WordPress et de ce que cela coûte.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
