Ce que l'outil vérifie
Le robots.txt
Ce que votre fichier autorise à CCBot, GPTBot, ClaudeBot, PerplexityBot et Google-Extended. Un groupe qui nomme un robot l'emporte sur la règle générale.
La réponse réelle à CCBot
Votre serveur peut bloquer un robot que le robots.txt autorise. On interroge donc le site avec l'agent CCBot et on regarde ce qui revient vraiment.
Les pages archivées
Le nombre de pages réellement dans l'index, version par version, en séparant les vraies pages du simple robots.txt et des erreurs. La liste des URL est affichée et exportable en CSV.
Les captures Archive.org bonus
L'autre grand index public. Il remonte à 1996 et garde ce qu'il a déjà capturé, même si le site bloque les robots aujourd'hui : un domaine à zéro page chez Common Crawl peut y avoir vingt ans d'archives. On donne la première et la dernière capture, la liste des pages et l'URL Wayback de chacune, à consulter ou à exporter en CSV.
Est-il important d'être archivé dans Common Crawl ?
Oui, dans une stratégie de visibilité IA, mais à sa juste place. Les archives de Common Crawl servent bel et bien à constituer des corpus d'entraînement : FineWeb et FineWeb2, parmi les jeux de données ouverts les plus utilisés, en sont directement issus, après nettoyage, filtrage et déduplication. Encore faut-il distinguer trois choses que l'on confond souvent : être archivé, être retenu pour l'entraînement et être cité dans une réponse.
Être archivé
Vos pages existent dans le corpus public. C'est ce que mesure cet outil et la seule des trois étapes que vous contrôlez directement.
Être retenu
Vos pages survivent aux filtres de qualité et à la déduplication de ceux qui construisent les jeux d'entraînement. Rien ne le garantit.
Être cité
Un assistant vous mentionne dans sa réponse. Cela dépend d'un autre mécanisme et d'autres robots que CCBot.
Être présent ouvre une possibilité, pas un résultat
L'index de Common Crawl recense les captures conservées dans les archives. Avoir des pages réellement présentes les rend disponibles pour tous ceux, nombreux, qui exploitent ce corpus. C'est une porte d'entrée vers des jeux de données d'entraînement, ce n'est pas la preuve qu'un modèle donné les a utilisées. Cette présence n'est pas inutile pour autant : elle est la condition de tout le reste. Son absence, elle, est une certitude d'être hors jeu.
Une page archivée n'est pas une page retenue
Les jeux de données dérivés ne reprennent pas l'ensemble des captures. FineWeb2 documente ses étapes de déduplication et de filtrage : l'essentiel du volume collecté est écarté en chemin. On ne peut donc pas conclure « mon site entraîne les modèles » d'un simple résultat positif.
Pour un audit, la question utile n'est pas « suis-je présent », mais quelles pages sont capturées, à quelles dates, avec quel statut et quel contenu réellement récupérable. C'est exactement ce que liste cet outil, page par page. Une trace qui ne concerne que le robots.txt ne démontre en rien que vos articles ont été archivés.
Être cité par un assistant relève d'un autre mécanisme
L'entraînement et la recherche au moment de répondre sont deux usages distincts que les éditeurs de modèles séparent explicitement. OpenAI le formalise avec deux robots aux rôles différents : GPTBot pour la collecte destinée à l'entraînement, OAI-SearchBot pour la recherche à l'intérieur de ChatGPT. Leur documentation précise que les deux réglages sont indépendants : un site peut autoriser le second pour apparaître dans les réponses tout en refusant le premier.
La conséquence est directe : la présence dans Common Crawl ne dit rien de votre présence dans les réponses de ChatGPT, de Claude ou de Perplexity. C'est pourquoi cet outil vérifie aussi ce que votre robots.txt répond à ces robots-là et non seulement à CCBot.
Ce qu'il faut suivre et dans quel ordre
Traitez l'archivage comme un point de contrôle utile, pas comme un indicateur de performance. Trois mesures à suivre séparément, parce qu'elles ne bougent ni au même rythme ni pour les mêmes raisons : les pages archivées, les citations obtenues dans les assistants et le trafic réellement envoyé. La première est un préalable, les deux autres sont le résultat.
Comprendre les résultats
« Vu, mais rien d'archivé » : qu'est-ce que ça veut dire ?
C'est le cas le plus fréquemment mal lu. Les captures de Common Crawl se rangent en trois familles et une seule prouve qu'une page a été conservée :
- les pages, le contenu réellement archivé ;
- le robots.txt seul, que le robot lit toujours en premier ;
- les diagnostics de crawl, redirections et erreurs rencontrées.
Un domaine peut donc apparaître dans l'index avec son seul robots.txt et zéro page de contenu. La commande en une ligne qui circule sur les réseaux répond « présent » dans ce cas, alors que rien n'a été conservé. Cet outil compte les trois familles séparément.
Mon robots.txt autorise CCBot, mais le site est quand même bloqué
C'est la situation la plus courante et la plus mal diagnostiquée. Votre robots.txt peut être parfaitement permissif pendant que votre hébergeur, votre CDN ou votre plugin de sécurité refuse le robot sur son seul nom d'agent. Beaucoup de configurations contiennent une règle « bloquer les mauvais robots » activée par défaut, qui couvre les robots d'IA sans que personne l'ait décidé.
Quand l'outil détecte ce cas, il l'écrit explicitement : le serveur refuse l'agent CCBot alors qu'il répond à un navigateur. La correction est alors dans votre pare-feu ou votre plugin de sécurité. Modifier le robots.txt n'y changera rien, il autorisait déjà.
Mon site renvoie 403 à CCBot : comment le débloquer ?
Le tableau nomme ce qui a répondu : Cloudflare, LiteSpeed, Akamai, Sucuri ou simplement le serveur. C'est là qu'il faut agir. L'endroit change selon le cas.
Chez Cloudflare. Les robots d'IA y sont classés par comportement plutôt que sous une étiquette unique : Search pour ceux qui indexent afin de répondre plus tard, Agent pour ceux qui agissent en direct pour un utilisateur, Training pour ceux qui collectent afin d'entraîner un modèle. CCBot relève du dernier. Le réglage se trouve dans la section consacrée aux robots d'IA du tableau de bord, où l'on autorise ou refuse chaque comportement. Si une règle de pare-feu bloque en amont, il faut y ajouter une exception pour cet agent. La documentation à jour est sur developers.cloudflare.com.
Chez un hébergeur mutualisé, LiteSpeed ou Apache avec cPanel : le blocage vient presque toujours d'une règle générique du type « bloquer les mauvais robots », activée par défaut et qui balaie les robots d'IA sans distinction. Le support peut la lever pour votre domaine. C'est la demande à leur formuler, plutôt que « débloquez mon site », qui ne leur dit pas quoi chercher.
Sous WordPress, regardez aussi du côté des extensions de sécurité : plusieurs filtrent par nom d'agent, avec des listes toutes faites qui contiennent CCBot.
Les adresses officielles de CCBot
Si votre hébergeur préfère autoriser des adresses plutôt qu'un nom d'agent, Common Crawl les publie et les tient à jour :
3.41.188.32/29
18.97.9.168/29
18.97.14.80/29
18.97.14.88/30
2600:1f28:365:8000::/56 (IPv6)Soit 28 adresses IPv4. La source à transmettre est index.commoncrawl.org/ccbot.json, toujours à jour, plutôt qu'une liste recopiée qui vieillira.
L'argument qui fait accepter la demande. CCBot tourne désormais sur des plages dédiées avec DNS inverse : son identité est vérifiable, contrairement à un simple nom d'agent que n'importe qui peut usurper. L'aller-retour doit boucler sur le même résultat :
$ host 18.97.14.84
84.14.97.18.in-addr.arpa domain name pointer 18-97-14-84.crawl.commoncrawl.org.
$ host 18-97-14-84.crawl.commoncrawl.org
18-97-14-84.crawl.commoncrawl.org has address 18.97.14.84Un service technique acceptera plus volontiers une règle sur
*.crawl.commoncrawl.org qu'une exception sur un nom d'agent. Cette
vérification ne vaut que pour l'IPv4 : la plage IPv6 n'a pas encore de DNS inverse.
Une fois la règle levée, relancez l'analyse : la réponse à CCBot doit passer en 200. Les pages, elles, n'apparaîtront dans l'index qu'à la version suivante, ce qui prend environ un mois.
Chez PlanetHoster : la règle WAF 390509
Cas rencontré et vérifié : chez PlanetHoster, CCBot se fait refuser par le pare-feu applicatif du serveur, le WAF. Le symptôme est reconnaissable. Le robots.txt est parfois servi normalement, les pages répondent 403, le fichier robots.txt lui-même n'interdisant rien. Vous cherchez donc une erreur de configuration là où il n'y en a pas.
La règle en cause porte le numéro 390509. Elle se désactive depuis le panneau N0C :
- Sécurité puis Pare-feu App Web (WAF), pour atteindre la fenêtre des règles du domaine ;
- repérer la règle et basculer son curseur pour la désactiver.
Pour confirmer que c'est bien elle qui bloque avant d'y toucher, Sécurité puis Historique du pare-feu permet de filtrer par domaine et par identifiant de règle. Vous y verrez les requêtes refusées. La procédure complète est dans la documentation N0C.
Trois précisions utiles. Désactivez la règle précise plutôt que le pare-feu entier, que la documentation elle-même présente comme un dernier recours. Le numéro peut différer selon la configuration, mais le principe reste le même, une règle générique de filtrage des robots qui attrape les robots d'IA au passage. Enfin le déblocage n'a aucun effet rétroactif : les pages n'apparaîtront dans l'index qu'à la version suivante, un mois plus tard environ.
Le même symptôme chez un autre hébergeur renvoie généralement à une règle équivalente, souvent nommée « blocage des mauvais robots ». C'est le vocabulaire à employer auprès du support.
Pourquoi interroger plusieurs versions ?
Common Crawl publie une nouvelle version environ chaque mois et chacune est un échantillon du web, pas une copie complète. Un site présent dans une version peut être absent de la suivante sans que rien n'ait changé chez lui.
Un exemple mesuré : un site de premier plan était absent de la version d'août 2026 alors qu'il comptait plusieurs centaines de pages dans celle de juillet. Se fier à une seule version conduit donc à un faux négatif. Trois versions sont interrogées par défaut.
« Coquille JavaScript » : pourquoi compter les mots ?
Common Crawl n'exécute pas le JavaScript. Il enregistre le HTML tel que le serveur l'envoie. Un site qui construit tout son contenu dans le navigateur renvoie donc au robot une page presque vide, même avec un code 200 parfaitement valide.
L'outil compte les mots du texte visible reçu avec l'agent CCBot. En dessous d'environ cent vingt mots sur une page d'accueil, le contenu est probablement rendu côté navigateur et le robot n'a rien à conserver. Le diagnostic n'est affiché que sur une vraie réponse, jamais sur une page d'erreur.
Comment faire entrer mon site dans Common Crawl ?
Il n'existe aucun formulaire de soumission. Le robot découvre les sites par lui-même, en suivant les liens. Ce que vous pouvez faire tient en quelques points :
- autoriser CCBot dans le robots.txt et vérifier qu'aucune règle générale ne le bloque ;
- vérifier que le pare-feu, le CDN ou le plugin de sécurité le laisse passer ;
- servir un contenu lisible sans JavaScript ;
- obtenir des liens entrants, puisque c'est ainsi que le robot arrive.
Ensuite il faut attendre la prochaine version, ce qui prend environ un mois.
Faut-il autoriser tous les robots d'IA ?
C'est un choix éditorial, pas une question technique, mais les deux positions se défendent. Autoriser, c'est accepter que votre contenu serve de matière et, en échange, pouvoir être cité dans les réponses. Bloquer, c'est protéger votre contenu, en sachant qu'un robot bloqué ne vous citera pas.
La distinction utile est entre les robots qui collectent pour l'entraînement et ceux qui vont chercher une page au moment où un utilisateur pose sa question. Bloquer les seconds vous rend invisible dans les réponses en direct, ce qui est rarement l'intention de départ.
Faut-il publier un fichier llms.txt ?
Ça ne sert à rien aujourd'hui, mais ça ne coûte rien non plus. Autant le dire clairement, parce que ce fichier est souvent présenté comme un levier de visibilité IA alors que rien ne l'étaye.
L'idée est séduisante : un fichier à la racine qui résume le site pour les modèles, sur le modèle du robots.txt. Le problème est qu'aucun grand éditeur ne documente qu'il le lit. La documentation des robots de Google n'en parle pas. OpenAI et Anthropic le mentionnent, mais pour leur propre documentation, afin que des agents y naviguent plus facilement. C'est probablement ce qui entretient la confusion : voir un llms.txt chez OpenAI ne veut pas dire qu'OpenAI lit le vôtre.
Donc, en pratique : publiez-en un si vous voulez, il pèse quelques kilooctets et il sera peut-être lu un jour, par des agents de navigation si ce n'est par les robots d'entraînement. Mais ne le comptez pas comme une action de visibilité. Méfiez-vous d'une prestation qui vous le vendrait comme tel. Le temps passé dessus est mieux investi à vérifier que vos pages sont accessibles et lisibles sans JavaScript.
Ce site en publie un, par cohérence avec son sujet. Il ne le présente pas pour autant comme un facteur de visibilité.
L'indice d'autorité, c'est quoi ?
Une note de 0 à 100, calculée à partir du classement que Common Crawl publie à côté de son graphe. Ce classement mesure la place d'un domaine parmi 119,7 millions, d'après les 2,45 milliards de liens relevés.
Quelques repères mesurés : facebook.com 96, google.com 94, wikipedia.org 86, lemonde.fr 71, abondance.com 45. Un site ordinaire se situe entre 10 et 30.
L'échelle est logarithmique. C'est volontaire : entre le premier et le millième il y a un gouffre, entre le millionième et le million-et-unième il n'y a rien. Une échelle proportionnelle collerait 0 à 99 % des sites et n'apprendrait rien.
La mesure retenue est la centralité harmonique, que Common Crawl donne pour plus résistante aux fermes de liens que le PageRank. Elle répond à la question « à quelle distance ce domaine est-il du reste du web », alors que compter les liens entrants se manipule en achetant des liens.
Comme tout le reste ici, ce chiffre est vérifiable : les données sont publiques et vous pouvez refaire le calcul. C'est la différence avec les indices d'autorité du marché, qui reposent sur des explorations privées.
D'où viennent les backlinks affichés ?
Du graphe de liens que Common Crawl publie à côté de ses archives. Il recense les liens entre domaines relevés pendant trois mois d'exploration, soit 2,45 milliards de liens pour la version courante.
Deux choses à savoir avant de comparer ces chiffres à ceux d'un outil payant.
Ces liens sont au niveau domaine. Vous saurez que exemple.fr pointe vers votre site, jamais depuis quelle page, ni avec quel texte de lien, ni s'il est en nofollow. C'est une limite du graphe lui-même, pas de cet outil.
Common Crawl est un échantillon. Un lien qui existe mais dont la page source n'a pas été explorée n'apparaîtra pas. Les chiffres sont donc un plancher, pas un total. En contrepartie, ils sont publics, vérifiables et gratuits, là où les outils du marché reposent sur des explorations privées que personne ne peut auditer.
Les extensions .fr, .net, .org, .com, .de, .io, .app, .pro, .ai, .dev, .vision, .ch, .be, .it, .es, .nl, .ca, .info, .eu, .community, .paris, .bzh, .alsace, .corsica, .quebec, .shop, .online, .site, .store, .blog, .day, .co, .africa, .top, .lol, .ma et .cloud sont précalculées, ce qui rend la réponse immédiate. Pour les autres, le calcul se fait à la demande et le résultat arrive par courriel.
D'où viennent les données ?
De l'index public de Common Crawl, interrogé en direct à chaque analyse, ainsi que de votre propre serveur, interrogé lui aussi en direct. Rien n'est stocké entre deux analyses, à l'exception de la liste des versions disponibles, gardée une journée pour éviter de la redemander à chaque visite.
Les identifiants de version ne sont jamais figés dans le code : ils sont relus à la source, faute de quoi l'outil interrogerait un jour une version périmée sans le signaler.