MEIKAIAudits de crawlabilité IA : du SEO à la lisibilité machine
Un audit de crawlabilité IA vérifie si des systèmes automatisés peuvent atteindre les pages importantes d’un site, en restituer le contenu et en extraire les faits qu’un visiteur humain peut voir. Il doit produire des preuves de test, et non une note générale de « maturité IA ».
La distinction compte, car plusieurs systèmes peuvent solliciter la même page : index de recherche, crawlers d’entraînement des modèles, fetchers déclenchés par un utilisateur et outils de navigation. L’accès accordé à l’un n’établit pas l’accès des autres, et la crawlabilité ne garantit pas qu’un assistant citera la page.
Partez d’une page et d’une requête
L’unité d’audit doit être une page réelle sur un chemin d’accès réel. Pour chaque template prioritaire, consignez l’URL, l’user agent demandeur, la réponse HTTP, le texte rendu, l’URL canonique et les champs effectivement extraits.
| Test | Condition de réussite | Preuve à conserver |
|---|---|---|
| Accès | Le demandeur visé reçoit le statut et le contenu attendus. | En-têtes de requête, statut de réponse, redirections et entrée de log serveur correspondante. |
| Rendu | Les informations essentielles sont présentes sans interaction non prise en charge. | HTML initial, DOM rendu et capture d’écran lorsque la mise en page influe sur le sens. |
| Extraction | Les champs nommés peuvent être récupérés avec leurs libellés et leurs unités intacts. | Valeurs extraites comparées à la page visible. |
| Identité | La page identifie le produit, l’organisation ou la politique sans ambiguïté. | URL canonique, identifiants d’entité et données structurées. |
| Fraîcheur | Dates, disponibilité et informations de version concordent d’une surface à l’autre. | Contradictions entre le texte de la page, les métadonnées, les flux et les données structurées. |
L’accès ne se limite pas au robots.txt
Les règles robots ne sont qu’un point de contrôle. L’audit doit également suivre les redirections, l’authentification, les défis anti-bots, le routage par locale et le comportement du CDN. Une URL publique peut malgré tout renvoyer une page de vérification ou une coquille applicative vide à un demandeur automatisé.
Les logs serveur constituent la preuve la plus solide qu’un demandeur a bien atteint le site. Un test réussi depuis un navigateur local ne prouve pas que l’edge de production a servi la même réponse à un crawler nommé ou à un fetcher déclenché par un utilisateur.
Testez l’information qui fonde une décision
Une page peut s’afficher correctement tout en dissimulant les faits qui comptent. Noms de produits, identifiants, prix, disponibilité, dimensions, ingrédients, compatibilité, dates d’entrée en vigueur et restrictions géographiques doivent figurer dans le texte visible et être associés à des libellés clairs.
Les cas d’échec les plus courants sont les suivants :
- un contenu chargé uniquement après un clic, un défilement ou une requête côté client ;
- des onglets dont les panneaux inactifs n’existent pas dans le document initial ;
- des valeurs affichées visuellement sans libellé ni unité à proximité ;
- des données structurées en contradiction avec la page visible ;
- des pages régionales partageant une même URL canonique malgré des produits ou des conditions différents ;
- des pages d’erreur qui renvoient un HTTP 200.
Le dernier cas passe facilement inaperçu. Dans notre étude sur la décroissance des citations Alibaba, les articles supprimés renvoyaient une petite page d’erreur générique en HTTP 200. Un monitoring fondé sur le seul statut aurait classé ces URL comme actives.
Choisissez les pages par le risque, pas par le volume
Un échantillon utile couvre des templates et des conséquences business plutôt que les seules URL les plus visitées. Un audit e-commerce pourra inclure un produit en stock, une variante en rupture, un article arrêté, une page de retours et une restriction régionale. Un audit B2B pourra inclure les tarifs, la documentation technique, une page sécurité, une étude de cas et une politique versionnée.
Pour chaque template, définissez les champs qui doivent survivre à l’extraction. « Page rendue » est une condition de réussite trop faible si la référence du modèle ou la date d’application manque.
Faites de l’audit un test de non-régression
La première exécution établit une base de référence. La valeur durable vient de la réexécution des mêmes requêtes après les mises en production du CMS, les changements de navigation, les mises à jour de règles CDN et les modifications de données structurées.
Restez précis sur les échecs : quel demandeur, quelle URL, quel champ et quelle couche a changé. Les équipes techniques disposent alors d’un défaut reproductible plutôt que d’une capture d’écran légendée « l’IA ne peut pas lire le site ».
Ce que l’audit ne prouve pas
Une page conforme est disponible pour la récupération dans les conditions testées. Cela ne prouve pas qu’une plateforme l’a indexée, qu’elle l’a retenue pour un prompt donné, qu’elle la considère comme faisant autorité ou qu’elle continuera de se comporter de la même façon.
La crawlabilité, la visibilité dans les réponses et l’exactitude des citations doivent donc faire l’objet de reportings distincts. L’audit établit si la source est techniquement exploitable ; la mesure au niveau des réponses montre si et comment une plateforme s’en est servie.