Crawlers IA et crawlabilité

Avant qu'un assistant IA puisse mentionner une marque, son crawler doit pouvoir lire le site. CrunchJunkie vous propose deux outils complémentaires sous Visibilité IA → un client → le groupe « Site web et robots » : • Crawlabilité : vérifie le robots.txt d'un site pour montrer quels crawlers IA (GPTBot, ClaudeBot, Google-Extended, PerplexityBot et environ 20 autres) sont autorisés, partiellement bloqués ou entièrement bloqués. C'est le moyen le plus rapide de repérer l'autogoal classique : bloquer par erreur les bots mêmes qui alimentent les réponses IA. • Insights de crawl : montre quels bots IA ont réellement visité le site, à quelle fréquence et quelles pages ils ont demandées, en lisant les logs d'accès de votre serveur ou de votre CDN. L'crawlabilité vous dit ce qui est autorisé ; les Insights de crawl vous disent ce qui se passe vraiment.

L'crawlabilité n'a besoin de rien d'autre que de l'adresse du site. 1. Vérifiez que le client a un site web enregistré : Clients → ouvrez le client → renseignez l'URL de son site (par ex. example.com). Elle est alors préremplie dans l'analyseur. 2. Ouvrez Visibilité IA → le client → Crawlabilité. 3. Le domaine est prérempli (ou saisissez n'importe quel domaine). Cliquez sur Analyser. CrunchJunkie récupère le robots.txt du domaine et affiche un tableau des bots IA connus avec un statut (Autorisé, Partiel ou Bloqué) ainsi que, pour chacun, la raison de ce classement et la façon de le modifier. Chaque vérification est enregistrée dans un historique chronologique : vous pouvez la relancer plus tard et voir exactement ce qui a changé depuis la dernière. Aucune configuration, aucun tag : l'outil lit directement le robots.txt public.

Les Insights de crawl ont besoin des logs d'accès de votre serveur ou de votre CDN, car c'est le seul endroit où les visites des bots IA sont enregistrées. 1. Ouvrez Visibilité IA → le client → Insights de crawl. À la première visite, vous voyez une URL d'ingestion unique (…/api/crawl-logs/<key>) et un bouton d'envoi. La clé appartient au projet : si vous supprimez un projet dont le drain a livré des logs au cours des 14 derniers jours, CrunchJunkie vous demande d'abord de déplacer la clé vers un autre projet du client (le drain continue de fonctionner sans changement) ou de confirmer ; un drain qui poste encore vers l'URL d'un projet supprimé reçoit une réponse 410 Gone avec la date, jamais un 401 sans fin. 2. Faites arriver les données, de l'une des deux façons : • Ponctuel : téléchargez un export de logs d'accès depuis votre serveur ou votre CDN (format combined de Nginx/Apache, ou export de logs Cloudflare/Vercel en .log/.csv) et envoyez le fichier sur la page. • Continu : pointez un drain de logs vers l'URL d'ingestion pour que les nouvelles requêtes arrivent automatiquement : un drain de logs Vercel, un forwarder Nginx/Apache, un Cloudflare Worker (la voie gratuit/Pro ; extrait prêt à coller sur la page Insights de crawl) ou Cloudflare Logpush (Enterprise uniquement). Un piège avec un drain de logs Vercel : ses règles d'échantillonnage forment une liste blanche. Vercel les exécute de haut en bas, et une requête qui ne correspond à aucune règle est écartée. Un drain dont l'unique règle est, par exemple, « /api/crawl-logs à 0 % » (pour que la route d'ingestion ne se journalise pas elle-même) ne transmet donc rien du tout, et Vercel l'affiche pourtant comme activé, car aucune livraison n'échoue jamais. Si vous ajoutez une règle de ce type, placez en dessous une règle fourre-tout : chemin vide, production, 100 %. Sans aucune règle, le drain transmet tout. 3. CrunchJunkie analyse les lignes, ne garde que les requêtes des bots IA (tout le reste est ignoré) et construit le tableau de bord : total des visites, bots actifs, répartitions par plateforme / bot / finalité (entraînement, recherche, requête utilisateur), chemins les plus explorés, codes de statut HTTP et une tendance des visites dans le temps, consultable sur 7/14/30/90 jours. Le tableau des pages principales montre ce que lisent les vrais crawlers : les sondes de scanners (chemins de type /.env sous n'importe quel nom) et les requêtes d'imposteurs (IP usurpées, noms n'apparaissant que dans robots.txt, IP qui tournent entre les noms de crawlers de plusieurs opérateurs) sont écartées et signalées par un seul compteur, et un nom qu'un scanner a emprunté est marqué comme tel sur la carte de son fournisseur et dans la liste par bot. Sous Codes de statut, les réponses 5xx sont réparties entre celles qu'un crawler réel ou invérifiable a reçues sur une page de contenu, soit une panne qui a compté, et celles qui n'ont croisé que des sondes de scanners. Seuls les user-agents des bots IA sont stockés : le trafic humain ordinaire des logs est écarté, il n'y a donc aucune donnée personnelle de visiteurs à gérer. Une carte, « Markdown demandé », dépend de ce que votre source de logs fournit. Depuis le printemps 2026, les agents qui récupèrent les pages pour les réponses IA envoient Accept: text/markdown sur des URL de pages ordinaires, et la carte montre par crawler combien de requêtes ont demandé du Markdown parmi les requêtes dont l'en-tête Accept a été enregistré (la taille de l'échantillon est toujours affichée). L'extrait Cloudflare Worker transmet l'en-tête ; un drain de logs Vercel, Cloudflare Logpush et les logs d'accès combined ne le font pas : avec ces sources, la carte indique que l'en-tête est inconnu au lieu d'afficher 0 %. Un forwarder personnalisé peut inclure l'en-tête dans un champ « accept » à chaque visite.

Les données de crawl ne servent pas qu'à votre propre diagnostic : elles vont directement dans un rapport client. Ajoutez un widget Tableau, choisissez la source Visibilité IA et réglez sa dimension sur « Crawler visits ». Vous obtenez une ligne par crawler IA qui a réellement demandé des pages au site dans la plage de dates du rapport (GPTBot, PerplexityBot, ClaudeBot et les autres), sur cinq colonnes : Bot, Plateforme, Type (entraînement, recherche ou requête utilisateur), Visites et Part, c'est-à-dire le pourcentage de ce bot parmi toutes les visites de bots de la période. Il vaut la peine d'expliquer à un client ce qui distingue ce tableau de tout le reste de la page. Tous les autres chiffres de visibilité IA sont des estimations échantillonnées : nous interrogeons les modèles de nombreuses fois et comptons ce qui revient, ce qui est la manière honnête de mesurer quelque chose de non déterministe, mais cela reste un échantillon avec une marge d'erreur. Celui-ci n'en est pas un. Chaque visite est une ligne d'un log serveur qui consigne qu'un bot nommé a récupéré une URL à un instant donné. C'est un fait établi, et c'est la preuve la plus solide que vous puissiez présenter à un client que les systèmes d'IA lisent son site. Il y a un prérequis à respecter. Le tableau n'a de données que si l'ingestion des logs de crawl est configurée pour ce projet (voir « Configurer les Insights de crawl » ci-dessus). Sans elle, le widget est simplement vide, et vide signifie « pas encore connecté », pas « aucun crawler IA ne s'intéresse à ce site ». Mettez l'ingestion en place avant que le tableau n'approche un rapport client, sinon il raconte exactement la mauvaise histoire.

La carte « Par section du site » regroupe les mêmes récupérations de pages que le tableau des pages principales selon la partie du site qu'elles touchent, pour que vous voyiez si les crawlers passent leur temps sur /blog, /products ou /docs, et où ils sont refusés. Les sondes de scanners, les requêtes d'imposteurs, les appels d'API ou d'outils, ainsi que les récupérations de robots.txt, de sitemaps et de ressources sont exclus et comptés sous la carte. Un chemin trouve sa section dans cet ordre. Vos propres règles de section passent en premier. Viennent ensuite la page d'accueil, puis la première partie du chemin quand au moins une page récupérée se trouve en dessous : /blog/a et /blog/b forment la section /blog, et /blog elle-même s'y rattache. Un dossier de langue tel que /de/ ou /en-gb/ est conservé comme préfixe : /de/blog et /blog sont donc deux sections. Une page au premier niveau sans rien de récupéré en dessous (/about, /pricing) va dans « Pages de premier niveau ». Les douze sections les plus actives sont affichées et les autres sont additionnées dans « Autres sections », qui indique leur nombre ; une section issue de vos propres règles est toujours affichée. Chaque section affiche ses requêtes et leur part de toutes les récupérations de pages, les requêtes par opérateur de crawler (OpenAI, Anthropic, Google et les autres), combien proviennent des plages d'IP publiées d'un opérateur, le nombre de pages distinctes, ainsi que la part des réponses 2xx, refusées par un pare-feu ou un CDN (403/406), ou en échec (404, 410, autres 4xx, 5xx). Ces parts sont calculées sur les récupérations dont la ligne de log portait un statut, et la carte indique ce nombre. Tous les chiffres sont des comptes ou des parts divisés une seule fois sur l'ensemble de la fenêtre, jamais des moyennes. Vos propres sections : ouvrez « Modifier les sections » sur la carte et saisissez une règle par ligne, un préfixe de chemin et, en option, un nom après un signe égal, par exemple /de/blog = Blog (DE). Le préfixe correspondant le plus long l'emporte : /de/blog prend donc ses pages avant /de. Jusqu'à 20 règles ; elles s'appliquent en même temps à la page, au tableau de rapport « Crawl sections » et au connecteur MCP, pour toutes les périodes, car elles ne changent que la façon dont les récupérations stockées sont regroupées. Une section très explorée n'est pas forcément une section que les réponses IA citent. Les crawlers récupèrent des pages pour les indexer ou pour répondre à une question ; les réponses sont généralement construites à partir d'un index ou d'un cache. Lisez cette carte pour l'accès et pour des problèmes comme un pare-feu qui refuse une section, et les pages Visibilité IA pour les citations.

Si l'crawlabilité montre qu'un bot IA que vous voulez est Bloqué, modifiez le robots.txt du site pour l'autoriser (la note « Comment le modifier » de chaque ligne vous donne la directive exacte), déployez, puis cliquez de nouveau sur Analyser pour confirmer le changement : l'historique chronologique enregistrera l'amélioration. Partiel signifie que seuls certains chemins sont interdits : des règles pour /api, /admin ou une zone de connexion sont normales et n'exigent aucun changement ; vérifiez les chemins listés et ne les modifiez que s'ils couvrent des pages que vous voulez voir utilisées dans les réponses. Si les Insights de crawl montrent un bot qui reçoit beaucoup de 404 ou qui n'atteint jamais vos pages clés, c'est le signal de corriger les liens internes, les sitemaps ou les erreurs serveur, pour que le crawler puisse réellement indexer le contenu que vous voulez voir apparaître dans les réponses IA.