CrawlCheck

Outils gratuits

Sept contrôles gratuits, sans inscription

En une phrase

La page des outils gratuits répond à deux questions en quelques secondes, sans compte : une requête de vos journaux d’accès qui se présente comme GPTBot, ClaudeBot, Googlebot ou un autre robot nommé vient-elle vraiment de cet opérateur (vérifié par rapport aux plages IP qu’il publie — vérifiée, usurpée ou invérifiable, jamais deux résultats seulement), et une machine peut-elle lire votre robots.txt, votre sitemap et votre llms.txt avec le bon type de contenu, ou un cache sert-il quelque chose que votre serveur ne produit plus.

Saisissez un domaine. Sans inscription, rien à installer. Une machine peut-elle lire vos fichiers, ce robot dans vos journaux est-il réel, que permet réellement votre robots.txt à chaque agent d’IA, un premier brouillon de votre llms.txt à partir des pages que vous publiez déjà, votre position face à un concurrent, ce à quoi Google peut s’accrocher dans une vidéo YouTube, et si une requête de robot signée vient vraiment du robot qu’elle nomme.

Les constats les plus fréquents, sur toutes les analyses
Aucun llms.txtNO_LLMS_TXT24.5%La page est surtout du codePAGE_IS_MOSTLY_CODE22.4%Un cache sert une copie périméeSTALE_CACHE_SERVED17%Les fichiers machine pèsent plus que la pageMACHINE_CHAIN_HEAVY10.3%Pas d’en-tête HSTSHSTS_MISSING7.4%Les groupes d’IA nommés perdent les règles *ROBOTS_RULES_SHADOWED6.8%Aucun sitemap XML trouvéNO_SITEMAP_FOUND6.6%Un refus IA est déjà définiAI_OPTOUT_SET6.5%Part des 2,400 analyses du jeu de données public qui présentaient ce constat. En direct ; les mêmes chiffres que sur /data.

Votre site en fait-il partie ? Vérifiez gratuitement → Les 52 taux →

Une machine peut-elle lire vos fichiers ?

Quatre requêtes au domaine indiqué : robots.txt, sitemap, llms.txt et la page d’accueil, lus selon le type de contenu et l’âge du cache.

Quatre requêtes au site indiqué. Résultats mis en cache dix minutes.

Ce robot dans vos journaux est-il réel ?

Collez des lignes brutes de journal d’accès. Chacune qui nomme un robot connu est vérifiée par rapport aux plages d’adresses que cet opérateur publie réellement.

C’est le contrôle que presque personne ne fait, et il renverse les conclusions. Un journal plein de GPTBot en 403 donne l’impression que votre hébergeur bloque OpenAI — jusqu’à ce que vous découvriez qu’ils venaient tous d’une seule adresse portant sept noms de robots différents. Nous l’avons mesuré exactement ainsi sur de vrais sites. Regroupez par adresse avant de conclure quoi que ce soit.

Rien n’est stocké. Les lignes sont examinées en mémoire et la réponse n’est pas journalisée.

Que permet votre robots.txt à chaque robot d’IA ?

Une seule récupération du fichier, puis chaque moteur de réponse, index de recherche et robot d’entraînement nommé est résolu comme le fait un robot : uniquement son propre groupe, correspondance la plus longue, allow l’emporte en cas d’égalité.

La règle que tout le monde comprend mal : un Disallow sous User-agent: * ne s’applique jamais à un agent qui a son propre groupe. Nommez GPTBot une seule fois n’importe où dans le fichier et chaque règle * cesse de s’appliquer à lui. Ceci montre ce qui s’applique réellement, agent par agent, au chemin choisi.

Une requête au site indiqué. Les robots d’entraînement sont listés, pas jugés.

Rédiger un brouillon de llms.txt à partir de ce que vous publiez déjà

Lit votre page d’accueil et jusqu’à 25 pages déclarées avec leurs propres titres et descriptions, et rédige un premier brouillon dans la forme habituelle.

C’est volontairement un brouillon. Un fichier généré n’est qu’une liste de liens avec les titres pour descriptions ; la valeur du fichier, c’est le choix. Réduisez-le aux pages sur lesquelles on interrogerait un assistant, rédigez vous-même les descriptions, puis servez-le en text/plain et vérifiez l’URL nue — le contrôle ci-dessus vous dira s’il est bien arrivé.

Jusqu’à 27 requêtes au site indiqué. Résultats mis en cache dix minutes.

Comment vous situez-vous face à un concurrent ?

Deux pages d’accueil, la même analyse sur les deux : chaque section dont un moteur de réponse a besoin, côte à côte, avec les constats propres à l’un de vous deux.

Deux analyses, ~20 secondes chacune si l’un des sites est nouveau pour nous. Rien n’est stocké en dehors des rapports eux-mêmes. Besoin de tout le marché ? Un site face à jusqu’à cinq concurrents.

Cette requête de robot signée est-elle réelle ?

Web Bot Auth permet à un robot de signer chaque requête avec une clé qu’il publie. Saisissez l’hôte du robot, ou collez les en-têtes d’une requête signée, et chaque étape du contrôle s’affiche : le répertoire de clés, les signatures qu’il porte, l’empreinte de chaque clé, les composants couverts et la fenêtre de temps.

N’importe qui peut taper un user-agent ; une signature sur votre propre nom d’hôte, non. Une clé ne compte que si elle a signé le répertoire où elle figure, si bien qu’une liste de clés copiée ou modifiée ne prouve rien. Cela fonctionne pour tout agent signataire, pas seulement le nôtre.

Une requête vers le répertoire de clés de l’agent. Les en-têtes collés sont vérifiés en mémoire et ne sont pas stockés ; un nonce vérifié n’est conservé que jusqu’à son expiration, pour repérer un rejeu.

À quoi Google peut-il s’accrocher dans votre vidéo ?

Collez une URL YouTube : chapitres, type de sous-titres, description, langue et thèmes, chaque ligne comparée à ce à quoi un résultat de recherche peut s’accrocher. Les chaînes entières et le lien avec le site sont dans Watch.

Trois résultats, jamais deux

Vérifiée

L’adresse est dans la plage publiée par l’opérateur. La requête est bien ce qu’elle prétend être.

Usurpée

L’opérateur publie des plages et cette adresse est en dehors de toutes. Quelqu’un d’autre porte ce nom.

Invérifiable

L’opérateur ne publie aucun flux, donc l’identité ne peut être ni confirmée ni mise en cause. Amazonbot et Meta-ExternalAgent sont ici en permanence.

Compter les invérifiables comme usurpés gonflerait le taux ; les compter comme authentiques le sous-estimerait. Le taux d’usurpation se divise donc uniquement par vérifiées plus usurpées, et la réponse indique ce dénominateur au lieu de vous laisser le supposer.

Ce que détectent les deux contrôles

Le contrôle des fichiers machine récupère votre robots.txt, llms.txt et votre sitemap comme le fait un robot et lit le type de contenu et le corps, pas seulement le statut. La défaillance qu’il vise : un bouclier anti-robots ou une page de vérification qui répond HTTP 200 avec du HTML là où devrait se trouver un fichier texte. Tous les moniteurs de disponibilité jugent cela sain. Un validateur l’interprète comme « aucune directive », ce qui équivaut à tout est autorisé — l’exact contraire de ce que dit votre fichier. Nous avons vu une page de vérification servie ainsi comme robots.txt à tous les robots, Googlebot compris, mise en cache à l’edge pendant des heures. Le contrôle fait une requête par fichier et indique ce qu’une machine analyserait réellement.

Le contrôle de purge répond à une question que votre tableau de bord CDN laisse sans réponse : la purge que vous venez de lancer a-t-elle vraiment évincé quelque chose ? Il récupère l’URL avant et après sans contournement du cache, compare les octets et lit les en-têtes age et d’état du cache. La défaillance qu’il vise : une API de purge qui renvoie 200 sur une couche de cache pendant qu’une autre — Varnish devant une origine, ou une règle d’edge qui fige un TTL — continue de servir les anciens octets. Un 200 d’un point d’accès de purge concerne l’appel d’API, pas le cache. Nous avons publié une modification, purgé, reçu un 200, et l’URL anonyme a servi l’ancien fichier pendant encore une heure ; c’est cette heure qui explique ce script.

Quand les lancer : après toute modification d’un fichier machine, après tout changement de configuration du cache ou du CDN, et chaque fois qu’une correction destinée aux robots « devrait » être en ligne. La seule habitude qui compte : vérifiez l’URL nue en dehors de votre propre session, car votre navigateur connecté est le client le moins représentatif de votre site.

Récupérez les scripts

Les deux mêmes contrôles, pour un terminal. Ce sont ceux que nous utilisons.

Aucun n’est un produit. Ce sont les contrôles qui ont détecté de vraies défaillances sur ce projet, publiés parce qu’un article décrivant un outil inaccessible n’est qu’une publicité.

cachecheck.sh

Vérifie si un cache sert un document que votre origine ne produit plus. Il ignore totalement les codes de statut : un PURGE qui renvoie 200 prouve que quelque chose a répondu, pas que quoi que ce soit a été évincé. Il récupère l’URL nue et une version sans cache, les compare, et refuse de juger si l’une des deux lectures est une page de vérification.

Voir ou télécharger → · curl -sO https://crawlcheck.io/tools/cachecheck.sh

verify.sh

Vérifie si une modification que vous avez déployée figure vraiment sur la page que reçoit un inconnu. Il compte votre balisage hors des balises style et script, pour qu’un nom de classe présent dans une feuille de style ne passe pas pour un élément de la page ; il récupère trois fois pour faire apparaître tout ce qui est conditionnel ; et il précise qu’il mesure la vue anonyme.

Voir ou télécharger → · curl -sO https://crawlcheck.io/tools/verify.sh

Utilisez-les, modifiez-les, sans attribution. Ils ne font aucune requête réseau ailleurs qu’à l’URL que vous leur donnez.

Vous voulez que le contrôle tourne pour vous, deux fois par jour ?

Ces deux-là tournent quand vous y pensez. Les mêmes contrôles planifiés, avec un message dès qu’un résultat change, c’est de la surveillance. Laissez une adresse et nous vous préviendrons quand ce sera prêt — sans compte, et rien d’envoyé d’ici là.

Une adresse, un seul usage. Les scripts ci-dessus restent gratuits et n’en ont pas besoin.

Partez de ce que vous vérifiez

Questions sur cette page

QComment vérifier qu’une requête de robot signée est réelle ?
Utilisez le vérificateur de signature de cette page. Donnez-lui l’hôte d’un robot : il récupère le répertoire de clés à /.well-known/http-message-signatures-directory sans suivre de redirection, vérifie le type de contenu, calcule l’empreinte RFC 7638 de chaque clé et vérifie les signatures du répertoire lui-même, de sorte qu’une clé ne compte que si elle a signé le répertoire où elle figure. Collez les en-têtes d’une requête signée et il vérifie ensuite la signature de cette requête avec une clé prouvée de cette façon, en montrant les composants couverts et la fenêtre de temps. Cela fonctionne pour tout agent Web Bot Auth, pas seulement le nôtre.
QComment le vérificateur de journaux décide-t-il qu’une requête est réelle ?
Chaque ligne qui nomme un robot connu est vérifiée par rapport aux plages IP publiées par cet opérateur (OpenAI, Anthropic, Perplexity, Google, Bing, Apple). Dans une plage publiée : vérifiée ; hors de toutes les plages : usurpée ; un opérateur sans flux publié (Amazonbot, Meta-ExternalAgent) est invérifiable et n’est compté ni dans un cas ni dans l’autre.
QCe que je colle est-il stocké ?
Non. Jusqu’à 200 lignes sont examinées en mémoire et la réponse n’est pas journalisée.
QQue vérifie le contrôle de domaine ?
Quatre requêtes : robots.txt, sitemap.xml, llms.txt et la page d’accueil. Il indique si chaque fichier est servi avec le bon type de contenu (un robots.txt qui renvoie du HTML est illisible pour un robot, même avec un 200) et si la copie servie est plus ancienne que ce que produit l’origine.
QPourquoi une purge qui a renvoyé 200 sert-elle encore d’anciens octets ?
Un 200 d’un point d’accès de purge concerne l’appel d’API, pas le cache. Le contrôle lit les en-têtes d’âge de la copie servie au lieu de se fier à la réponse de purge.

Pour aller plus loin