Crawlers IA : protéger son hébergement sans bloquer Google

Les robots d’exploration ne sont pas nouveaux sur le Web : Googlebot, Bingbot et les outils de surveillance visitent les sites depuis longtemps. Mais la multiplication des crawlers associés aux services d’intelligence artificielle a changé l’équilibre pour certains petits sites. Lorsqu’un robot parcourt de nombreuses pages, archives, images ou paramètres d’URL en peu de temps, il peut consommer de la bande passante, des ressources CPU et des connexions PHP ou base de données.

Sur un hébergement mutualisé, ces ressources sont partagées et encadrées. Un pic de requêtes automatisées peut donc ralentir un site WordPress, provoquer des erreurs temporaires ou faire atteindre des limites définies par l’hébergeur. L’objectif n’est pas de bloquer tous les robots : Google reste essentiel à la visibilité naturelle. Il s’agit plutôt d’identifier les explorateurs qui n’apportent pas de trafic utile, puis de les encadrer avec des règles simples et réversibles.

Ce guide explique comment protéger un petit site contre les crawlers IA, sans sacrifier votre référencement sur Google ni transformer l’administration de votre hébergement en projet technique complexe.

Pourquoi les crawlers IA peuvent ralentir un petit site

Un crawler télécharge des pages pour les analyser. Cela semble anodin lorsqu’il consulte quelques URL par jour. Le problème apparaît lorsqu’un robot explore un catalogue complet, des milliers d’articles, des pages de recherche interne ou des URL qui contiennent des paramètres.

Chaque visite peut déclencher plusieurs opérations côté serveur :

la requête HTTP arrive sur le serveur web ;
WordPress, Drupal, PrestaShop ou un autre CMS génère éventuellement la page ;
PHP exécute du code et interroge souvent une base de données ;
le serveur transmet le HTML, les images et les autres fichiers demandés.

Si le cache de page est actif, une partie du travail est évitée. Mais le robot peut toujours utiliser de la bande passante et multiplier les connexions. S’il accède à des pages non mises en cache, à des filtres e-commerce, aux résultats de recherche interne ou à des URL dynamiques, son impact augmente.

Les sites récents, les blogs personnels et les boutiques modestes sont plus exposés aux effets visibles d’un trafic automatisé, car ils disposent rarement de la marge de ressources d’une grande plateforme. Cela ne signifie pas qu’un crawler IA est forcément malveillant. Certains éditeurs de robots annoncent clairement leur agent utilisateur et respectent les directives publiques. En revanche, les règles de robots.txt restent des consignes : un robot sérieux les applique volontairement, un bot agressif peut les ignorer.

Il faut aussi distinguer les véritables robots de moteurs de recherche des imitations. N’importe quel visiteur automatisé peut envoyer un en-tête User-Agent contenant le mot « Googlebot ». Bloquer ou autoriser une simple chaîne de caractères sans vérification peut mener à de mauvaises décisions.

Le bon réflexe consiste à commencer par observer : un blocage général et immédiat peut perturber un service légitime, tandis qu’une analyse des journaux permet d’agir sur des signaux concrets.

Les signaux qui doivent vous alerter sur votre hébergement

Un crawler ne provoque pas systématiquement une panne. Il laisse souvent des indices progressifs. Vous pouvez les repérer dans le tableau de bord de votre hébergeur, dans un outil d’analytics ou dans les fichiers de logs.

Voici les symptômes les plus courants :

une hausse inhabituelle de la bande passante, sans hausse équivalente dans Google Analytics ou Matomo ;
des pointes de CPU, de processus ou d’entrées simultanées signalées dans le panneau d’hébergement ;
des pages qui deviennent lentes à certains moments de la journée ;
des erreurs HTTP 429, 500, 502, 503 ou 504 dans les logs ;
un grand nombre de requêtes répétées sur les mêmes archives, catégories, pages de tags ou URL avec paramètres ;
des alertes de dépassement de ressources envoyées par votre hébergeur.

Une forte activité n’est toutefois pas nécessairement un problème de robots IA. Une campagne e-mail, un article partagé sur un réseau social, une sauvegarde, une extension WordPress défaillante ou une attaque par force brute peuvent produire des symptômes comparables. Comparez donc la période concernée avec vos actions marketing et avec les visiteurs réels visibles dans vos statistiques.

Si votre site est propulsé par WordPress, un cache de page correctement configuré constitue une première protection utile. Des extensions comme WP Super Cache, W3 Total Cache ou LiteSpeed Cache, lorsque l’environnement est compatible, peuvent réduire le travail nécessaire pour servir les pages publiques. Cette optimisation ne remplace pas la limitation d’un robot excessif, mais elle diminue sa capacité à saturer PHP et MySQL.

Avant de changer d’offre, vérifiez aussi les fondamentaux de votre formule. Un hébergement adapté à un blog débutant ne répond pas aux mêmes besoins qu’une boutique avec de nombreuses pages dynamiques. Notre guide sur l’hébergement d’un blog pour débuter aide à replacer cette question dans son contexte.

Reconnaître les robots IA dans les logs et les statistiques

Les logs d’accès sont la source la plus directe. Selon votre hébergeur, vous pouvez les trouver sous les noms « Logs », « Access logs », « Journaux bruts », « Statistiques » ou via cPanel et Plesk. Des outils tels qu’AWStats peuvent également présenter les agents utilisateurs les plus actifs.

Une ligne de log contient généralement l’adresse IP, la date, l’URL demandée, le code de réponse HTTP, le volume transféré, le référent et l’agent utilisateur. Ce dernier est souvent le premier élément à examiner.

Parmi les agents utilisateurs publiquement connus, on peut notamment rencontrer :

GPTBot, associé à OpenAI ;
ChatGPT-User, utilisé lorsque ChatGPT récupère une page à la demande d’un utilisateur ;
ClaudeBot, associé à Anthropic ;
PerplexityBot, associé à Perplexity ;
Google-Extended, jeton distinct de Googlebot pour gérer certains usages liés aux produits Gemini ;
Bytespider, associé à ByteDance.

Cette liste ne suffit pas à attribuer une requête avec certitude. Les agents utilisateurs peuvent être modifiés ou usurpés. Utilisez-les comme un indicateur, puis regardez le comportement : nombre de requêtes, vitesse de passage, URL visitées, adresses IP et codes de réponse.

Ne confondez pas Googlebot et Google-Extended

Pour préserver le SEO, cette distinction est essentielle. Googlebot est le crawler utilisé pour Google Search. Le bloquer dans robots.txt revient à empêcher l’exploration des pages concernées par Google, avec un risque évident pour leur indexation.

Google-Extended est un jeton séparé. Les indications de Google précisent qu’il ne modifie pas le fonctionnement de Google Search. Vous pouvez donc choisir une directive visant Google-Extended sans bloquer Googlebot. Consultez la documentation Google sur ses crawlers avant toute modification durable, car les règles et les agents déclarés peuvent évoluer.

Vérifier un vrai Googlebot avant de l’autoriser

Un agent utilisateur « Googlebot » n’est pas une preuve. Google explique comment vérifier ses crawlers par résolution DNS inverse, puis résolution DNS directe de l’hôte obtenu. Le nom d’hôte validé doit appartenir aux domaines googlebot.com ou google.com. Cette vérification est surtout utile si vous mettez en place des règles de pare-feu avancées ou si vous constatez un trafic suspect prétendant être Google.

Pour la majorité des débutants, il est plus prudent de ne pas créer une règle de blocage large sur le mot « bot ». Les visiteurs et robots légitimes doivent continuer à accéder au site.

Utiliser robots.txt pour demander aux crawlers IA de ne pas explorer

Le fichier robots.txt se place à la racine du domaine, par exemple à l’adresse https://www.votre-domaine.fr/robots.txt. Il indique aux robots coopératifs les zones qu’ils ne doivent pas explorer.

Pour demander à plusieurs crawlers IA identifiés de ne pas parcourir votre site, vous pouvez ajouter des groupes distincts :

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Chaque bloc cible un agent précis. La directive Disallow: / signifie que l’exploration de l’ensemble du site est demandée à cet agent. Elle ne concerne pas Googlebot, Bingbot ou les navigateurs humains.

Évitez absolument une règle comme celle-ci si vous voulez rester visible dans les moteurs :

User-agent: *
Disallow: /

Elle demande à tous les robots respectueux de ne plus explorer aucune page, y compris les robots de recherche. De même, ne créez pas un bloc destiné à Googlebot sauf si vous savez précisément pourquoi vous souhaitez retirer une partie du site de l’exploration.

Robots.txt n’est pas une barrière de sécurité. Il ne bloque pas techniquement une requête HTTP et ne protège pas les contenus confidentiels. Une page privée doit être protégée par authentification, un contrôle d’accès serveur ou une autre mesure adaptée. Pour les crawlers qui ignorent les consignes, il faut intervenir au niveau du CDN, du pare-feu applicatif ou de l’hébergeur.

Après modification, ouvrez votre fichier dans un navigateur pour vérifier qu’il est bien accessible et qu’il n’a pas été remplacé par une page d’erreur. Si vous utilisez WordPress avec une extension SEO, vérifiez aussi si elle génère un robots.txt virtuel.

Bloquer ou limiter les bots avec un CDN et un pare-feu

Un réseau de diffusion de contenu, ou CDN, se place entre le visiteur et votre serveur. Au-delà de l’accélération des contenus statiques, il peut filtrer certaines requêtes avant qu’elles n’atteignent votre hébergement. Cloudflare, par exemple, propose des outils de pare-feu applicatif, des règles personnalisées et des mécanismes de limitation selon l’offre choisie.

Le principe le plus simple consiste à créer une règle ciblant un agent utilisateur précis, par exemple GPTBot, puis à choisir une action de blocage ou de défi. L’interface, les fonctions disponibles et les limites dépendent de votre abonnement : consultez la documentation du service avant de reproduire une règle trouvée dans un tutoriel.

Une règle ciblée est préférable à une règle vague. Bloquer toutes les requêtes contenant « AI », « bot » ou « crawler » peut toucher des services utiles : outils de disponibilité, aperçus de liens, robots de moteurs ou intégrations externes.

La limitation de débit est parfois plus souple qu’un blocage

Si vous hésitez à exclure complètement un robot, la limitation de débit (rate limiting) est une alternative. Elle consiste à restreindre le nombre de requêtes autorisées sur une durée donnée, souvent par adresse IP ou par chemin. C’est particulièrement pertinent pour des zones coûteuses à générer :

la recherche interne d’un CMS ;
les filtres produits d’une boutique ;
les pages avec de nombreux paramètres dans l’URL ;
les points d’entrée d’API qui ne devraient pas être publics.

Le paramétrage doit rester prudent. Une limite trop basse peut gêner un utilisateur réel qui navigue rapidement ou un crawler de recherche légitime. Commencez par une règle restreinte à une URL problématique, observez les résultats dans les journaux, puis ajustez.

Certains hébergeurs proposent également ModSecurity, Imunify360 ou leur propre pare-feu. Ces outils peuvent aider contre des requêtes manifestement abusives, mais les réglages proposés dans le panneau varient beaucoup d’un fournisseur à l’autre. Si vous êtes sur une offre mutualisée, le support peut aussi confirmer si un pic est lié à un bot identifiable ou à une autre limite de compte.

Préserver Google et le référencement naturel pendant le filtrage

Le référencement ne dépend pas seulement du fait que Googlebot puisse accéder à la page d’accueil. Les articles, catégories importantes, images et ressources nécessaires au rendu doivent rester disponibles. Après chaque changement, contrôlez que vos pages stratégiques répondent normalement pour un visiteur classique et qu’aucune règle ne vise accidentellement Googlebot.

Google Search Console est l’outil de référence pour suivre l’exploration et l’indexation de votre site dans Google. Le rapport sur l’indexation des pages peut aider à détecter des erreurs d’exploration ou des exclusions inattendues. Ce n’est pas un outil de mesure de tous les bots, mais il permet de vérifier que vos actions défensives ne créent pas un problème SEO.

Gardez également en tête ces principes :

ne bloquez pas les adresses IP ou les agents utilisateurs à l’aveugle ;
n’appliquez pas de règle générale à tous les crawlers ;
ne bloquez pas les fichiers CSS et JavaScript nécessaires au rendu des pages ;
conservez une copie de votre précédent robots.txt et de chaque règle de pare-feu ;
testez une modification à la fois afin de pouvoir identifier son effet.

Le cache et un bon hébergement restent des compléments importants. Un CDN intégré peut être utile, mais son intérêt dépend du trafic, du type de contenu et de la localisation de votre audience. Retrouvez les critères à examiner dans notre article CDN intégré : est-ce utile pour un petit site ?.

Checklist simple pour protéger son site sans nuire au SEO

Vous n’avez pas besoin de mettre en place toutes les protections le même jour. Suivez plutôt cette méthode progressive.

1. Relevez les symptômes. Notez les périodes de lenteur, alertes d’hébergement, volumes de bande passante et erreurs serveur.
2. Consultez les logs. Identifiez les agents utilisateurs et les URL les plus demandées. Cherchez des répétitions anormales plutôt qu’un nom de bot isolé.
3. Vérifiez le trafic humain. Comparez les données des logs avec Google Analytics, Matomo ou votre outil de mesure habituel.
4. Mettez à jour robots.txt. Ajoutez uniquement les agents IA que vous avez décidé d’exclure. Ne bloquez pas Googlebot.
5. Activez le cache. Servez les pages publiques depuis un cache lorsque cela est compatible avec votre CMS et votre site.
6. Ajoutez une règle ciblée. Dans Cloudflare ou votre pare-feu, bloquez ou limitez l’agent qui pose réellement problème.
7. Contrôlez Search Console. Vérifiez dans les jours qui suivent que l’indexation et l’exploration Google ne montrent pas de nouvelle anomalie.
8. Documentez vos changements. Conservez la date, la règle appliquée et son motif. Cela facilite un retour arrière si nécessaire.

Cette approche convient aussi à un site qui n’a pas encore de problème visible. Installer un cache, garder des logs accessibles et connaître son fichier robots.txt permet d’agir sereinement le jour où une hausse de trafic automatisé survient.

Conclusion : protéger les ressources, sans fermer la porte aux visiteurs utiles

Les crawlers IA font désormais partie du trafic que doit gérer un site web. Ils ne justifient pas une réaction excessive : Googlebot, les utilisateurs réels et certains services automatisés légitimes doivent conserver un accès normal à vos contenus. En revanche, un robot qui consomme des ressources sans bénéfice concret peut être limité de manière ciblée.

Commencez par les logs, utilisez robots.txt comme signal public, puis ajoutez un filtre CDN ou pare-feu seulement lorsque les données le justifient. Cette méthode protège votre hébergement tout en préservant les fondations de votre SEO. Si les lenteurs persistent malgré ces mesures, il peut être utile de revoir les ressources de votre formule avec notre comparatif des critères pour choisir un hébergeur de petit site.