Vérification SEO par un agent IA : ce que l'agent voit vraiment

Lorsque vous demandez à un agent IA de vérifier le SEO d'une page, il travaille généralement sur la page convertie en texte. Les intertitres et le texte lui parviennent ; le statut HTTP, les en-têtes de réponse, les étapes de redirection, les balises du head et les données structurées, en général non. L'agent peut donc bien analyser votre rédaction, mais il ne peut pas confirmer l'essentiel de ce qui détermine si un moteur de recherche indexe la page.

Les outils de récupération diffèrent d'un assistant à l'autre et évoluent dans le temps : la question utile est donc de savoir ce que l'agent a reçu. En octobre 2026, nous y avons répondu pour l'une de nos propres pages, en enregistrant l'échange HTTP complet à côté de la vue texte sur laquelle travaille un agent. Cet article rapporte précisément ce que nous avons exécuté, ce que contenait chaque vue et comment fournir à un agent les éléments qui lui manquent.

Nous avons récupéré l'une de nos pages des deux façons

Nous avons choisi un article publié, notre guide des chaînes de redirections, et l'avons demandé à l'adresse longue qu'une personne pourrait coller dans un chat : http://www.seoreport.dev/articles/redirect-chains-guide/. Le HTTP simple, l'hôte www et la barre oblique finale sont autant de variantes que le site normalise : la requête allait donc forcément être redirigée.

Nous l'avons lue de 3 façons :

1. L'échange HTTP complet, avec curl, en enregistrant chaque étape, la ligne de statut finale, chaque en-tête de réponse et le HTML brut.
2. Une extraction en texte brut de ce même HTML : scripts, styles et <head> supprimés, texte visible conservé. C'est la conversion qu'effectuent de nombreux outils de récupération avant qu'un assistant ne lise une page.
3. L'outil de récupération intégré à un assistant de programmation IA, à qui nous avons demandé de ne signaler, élément par élément, que ce qui figurait littéralement dans le contenu reçu.

Les vues 2 et 3 concordaient sur chaque élément important ici : le tableau les présente donc ensemble. Seule différence : l'outil de récupération a transmis le titre de la page, tandis que l'extraction simple a conservé le H1, qui contient les mêmes mots.

En volume, la vue texte représentait environ 10 Ko sur une réponse HTML de 71 Ko. L'essentiel de ce qui a été supprimé est du code de script et de style, dont aucune analyse SEO n'a besoin. Le reste, ce sont précisément les éléments qu'une analyse SEO est censée lire.

Deux détails du tableau comptent plus que les chiffres. D'abord, la réponse sur la balise canonique dépendait de la façon dont nous posions la question. Invité à marquer chaque balise « présente ou absente », l'outil de récupération a répondu « absente » pour une balise canonique que la page possède, et n'a ajouté qu'ensuite une réserve sur le <head>. Avec l'option « impossible à déterminer », il a choisi celle-ci. Un agent qui reçoit la première réponse et agit en conséquence recommanderait d'ajouter une balise qui existe déjà. Ensuite, le JSON-LD Article et une balise article:modified_time portent tous deux une date de modification au 3 octobre 2026, alors que la signature visible n'affiche que la date de publication du 28 septembre 2026. La date qu'un moteur de recherche peut lire comme « dernière mise à jour » n'existe que dans la partie de la page que l'agent n'a jamais reçue.

Rien n'était incorrect sur cette page. Deux étapes de redirection restent largement en deçà des 10 que, selon la documentation de Google sur l'exploration, ses robots suivent, et la balise canonique pointe vers la page elle-même. Le constat, c'est que l'agent n'aurait pu le savoir dans un sens comme dans l'autre.

L'outil de récupération ne signalait un statut qu'en cas d'échec

Nous avons répété le test avec une adresse qui n'existe pas sur notre site. Le serveur a répondu 404, et l'outil de récupération l'a signalé : il a indiqué « HTTP 404 Not Found » et n'a renvoyé aucun texte de page. Sur la page qui fonctionnait, le 200 n'a jamais été mentionné.

Ce comportement (les erreurs remontent, les réponses réussies restent muettes) laisse de côté les cas les plus problématiques, justement parce qu'ils répondent 200 :

• Une page qui se lit comme introuvable mais répond 200. Notre page 404 affiche « Article Not Found. The article you are looking for does not exist. » Si un serveur envoyait ce même texte avec un statut 200, la vue texte serait identique. Seule la ligne de statut indique aux moteurs de recherche de quel cas il s'agit, et lorsque Google détecte la version en 200, Search Console la signale comme « Erreur "soft 404" ».
• Une page qui se lit parfaitement mais demande aux moteurs de recherche de ne pas l'indexer. La documentation de Google sur la balise meta robots (consultée en octobre 2026) indique que toute règle utilisable dans une balise meta robots peut aussi être envoyée dans un en-tête HTTP X-Robots-Tag. Un noindex envoyé ainsi ne laisse aucune trace dans le texte. Nous expliquons comment les trouver et trancher dans URL marquée "noindex" dans Search Console.
• Une page dont l'URL canonique est déclarée dans un en-tête. Google documente un en-tête de réponse Link avec rel="canonical" comme alternative à la balise HTML, y compris pour des fichiers non HTML comme les PDF. Une vue texte ne peut pas le voir.

Les éléments se trouvent dans l'échange, pas sur la page

Tout ce que la vue texte a supprimé relève d'une même nature : des éléments qu'échangent un serveur et un robot d'exploration, et qu'un visiteur qui lit la page ne voit jamais. Ils se répartissent en 6 endroits.

Statut et redirections. Chaque étape est une réponse à part entière, avec son propre code de statut. Certains outils de récupération réécrivent http:// en https:// avant d'envoyer la requête : la redirection du HTTP vers le HTTPS n'est alors jamais demandée. Le guide des redirections et de la normalisation des URL indique quelles étapes conserver.

En-têtes de réponse. X-Robots-Tag, Link, Cache-Control, Vary et les en-têtes de sécurité voyagent tous au-dessus du HTML. Aucun d'eux n'est du texte sur la page.

Balises du head. La balise canonique, la balise meta robots, les hreflang, la meta description et les balises Open Graph se trouvent dans le <head>, que les conversions en texte suppriment.

Données structurées. Le JSON-LD se trouve dans un élément <script>. Les conversions en texte suppriment les scripts, et le JSON-LD disparaît avec eux. Le guide des données structurées et des métadonnées sociales explique ce qu'il doit contenir.

HTML brut ou rendu. Certains outils de récupération exécutent JavaScript avant de convertir la page, d'autres non, et le résultat l'indique rarement. Une page dont le contenu n'apparaît qu'après l'exécution de JavaScript peut sembler complète pour un outil et vide pour un autre. Nous avons mesuré la fréquence de cet écart dans ce que voient réellement les robots d'IA.

Fichiers et pages au-delà de l'URL. robots.txt est un fichier distinct que l'agent ne demande jamais si on ne le lui demande pas. La documentation de Google rappelle que lorsque robots.txt bloque une page, Google ne peut pas du tout lire le noindex de cette page : les deux doivent donc être vérifiés ensemble. Le sitemap, les liens internes et les éventuelles URL en double se trouvent entièrement sur d'autres pages.

sequenceDiagram
    participant U as Vous
    participant A as Agent IA
    participant F as Outil de récupération
    participant S as Votre site
    U->>A: Vérifie le SEO de cette page
    A->>F: Récupère l'URL
    F->>S: GET http://www.example.com/page/
    S-->>F: 301 et un en-tête Location
    F->>S: GET https://example.com/page/
    S-->>F: 301 et un en-tête Location
    F->>S: GET https://example.com/page
    S-->>F: 200, en-têtes de réponse, HTML complet
    Note over F: Étapes, statut, en-têtes, balises du head et JSON-LD supprimés
    F-->>A: Texte visible en Markdown
    A-->>U: Conseils fondés sur le seul texte

La plupart des problèmes SEO que nous relevons sont hors du texte de la page

Nos propres données d'audit montrent à quel point une analyse dépend de ce que la vue texte supprime. Sur 45 sites externes audités par SEOReport entre mai et octobre 2026, 94 % des 506 problèmes relevés se trouvaient à un endroit que le lecteur de la page ne voit jamais : en-têtes de réponse, balises du head, données structurées, sitemap XML, robots.txt, redirections ou relations entre pages.

Le graphique ci-dessous répartit ces mêmes 506 problèmes selon l'endroit unique où il faudrait regarder pour en voir la preuve.

Seuls les 5,9 % liés au contenu visible de la page relèvent du type d'éléments qu'une vue texte conserve. Classés selon ce qu'un agent devrait recevoir pour les voir, les autres emplacements forment 3 groupes. Le statut et les en-têtes HTTP, les balises du head et les données structurées représentent ensemble 69 % des 506 problèmes : des éléments qui arrivent dans la réponse même de la page et qu'une conversion en texte jette. Une meilleure extraction de texte ne les récupérerait pas ; lire la réponse elle-même, si. Le sitemap XML, l'ensemble des articles lu comme un tout, les relations entre pages et robots.txt représentent environ 20 % : des éléments qu'aucune réponse de page prise isolément ne contient. Les 5,6 % restants exigent une seconde vue de la page ou de son adresse : la page rendue à côté du HTML brut, la réponse pour smartphone à côté de celle pour ordinateur, ou les étapes de redirection qui précèdent la page.

Le même échantillon montre l'effet site par site : chacun des 45 sites avait au moins un problème relevé hors du texte visible de la page, et pour 24 d'entre eux (53 %), tous les problèmes relevés étaient hors de ce texte. Sur ces 24 sites, une analyse limitée au texte visible n'aurait eu sous les yeux aucun des éléments relevés.

Comment fournir à votre agent les éléments qui lui manquent

Un agent raisonne bien sur les éléments qu'il peut voir. La solution consiste à lui mettre l'échange sous les yeux.

Si votre agent dispose d'un terminal, demandez-lui d'exécuter ces commandes et de vous montrer la sortie brute avant de tirer la moindre conclusion. Sinon, exécutez-les vous-même et collez la sortie dans le chat.

# 1. Every hop, every status, the headers that matter (GET, following redirects)
curl -sL -D - -o /dev/null http://www.example.com/page/ \
  | grep -iE '^(HTTP/|location|x-robots-tag|link|content-type|cache-control|vary)'

# 2. Canonical, hreflang and meta robots tags from the raw HTML
curl -s https://example.com/page \
  | grep -oiE '<link[^>]*rel="(canonical|alternate)"[^>]*>|<meta[^>]*name="robots"[^>]*>'

# 3. How many JSON-LD blocks the raw HTML contains
curl -s https://example.com/page | grep -o 'application/ld+json' | wc -l

# 4. The crawl rules that apply to the page
curl -s https://example.com/robots.txt

Trois habitudes rendent les réponses fiables :

• Utilisez GET, pas HEAD. Certains serveurs ne répondent pas de la même façon aux deux. Le nôtre, par exemple : la première étape de notre test a répondu 301 à une requête GET et 308 à une requête HEAD.
• Demandez ce qu'il a reçu avant de demander ce qui ne va pas. « Liste le code de statut, les en-têtes et les balises du head que tu vois » transforme un angle mort en manque visible, et vous montre quelles réponses « absent » signifient en réalité « jamais reçu ».
• Demandez si le HTML a été rendu. Si l'outil de l'agent a exécuté JavaScript, sa vue peut différer de ce qu'envoie le serveur. Comparez-la avec le HTML brut de la commande 2, comme le décrit le guide sur le rendu JavaScript.

Une vérification complète d'une page reste la vérification d'une seule page

Avec l'échange complet sous les yeux, un agent peut analyser correctement une page. Ce que la réponse ne peut pas contenir, c'est le reste du site : si votre sitemap liste la page, si d'autres pages renvoient vers elle, si une autre URL la duplique, si robots.txt bloque des pages que votre sitemap annonce. Dans l'échantillon ci-dessus, environ un problème relevé sur cinq se trouvait là où aucune réponse de page prise isolément ne pouvait le montrer. Pour les couvrir, il faut répéter le travail sur de nombreuses pages, dans de nombreuses sessions, avec une méthode identique à chaque fois : c'est le sujet de pourquoi une seule session d'IA ne peut pas auditer tout un site.

Un diagnostic SEOReport complet effectue une grande partie de ce travail à l'échelle du site en un seul rapport. Il demande les pages listées dans votre sitemap, suit l'adresse que vous soumettez à travers chaque étape de redirection, lit votre robots.txt et compare le HTML brut de votre page d'accueil à la page rendue. Chaque constat est accompagné de sa preuve (codes de statut, valeurs d'en-têtes, URL concernées), et chaque constat tiré d'un échantillon de pages indique combien de pages ont été examinées. Un agent peut créer et lire ce rapport via le serveur MCP et l'API REST : il part ainsi des éléments du site, et non du texte.

Questions fréquentes

ChatGPT peut-il vérifier le SEO de mon site ?

Il peut analyser tout contenu qui lui parvient : les intertitres, le texte, et le titre si l'outil le transmet. Qu'il voie aussi le code de statut, les en-têtes, les balises du head ou les données structurées dépend de l'outil de récupération qu'il utilise à ce moment-là, ce qui varie et est rarement précisé. Demandez-lui d'abord de lister ce qu'il a reçu, ou collez la sortie des commandes ci-dessus.

Un vérificateur SEO par IA équivaut-il à un audit SEO ?

Un vérificateur SEO par IA analyse généralement une page à partir du contenu que renvoie son outil. Un audit lit l'échange HTTP, robots.txt, le sitemap et les relations entre les pages, et consigne la preuve de chaque constat pour que le résultat puisse être vérifié et reproduit. Les deux répondent à des questions différentes : l'un analyse la rédaction d'une page, l'autre établit ce que le site sert aux robots d'exploration.

Pourquoi mon agent affirme-t-il que ma page n'a pas de balise canonique alors qu'elle en a une ?

La balise canonique se trouve dans le <head>, que les conversions en texte suppriment. Lors de notre test, l'outil de récupération a répondu « absente » pour une balise canonique bien présente. Vérifiez avec la commande 2 ci-dessus, ou en affichant le code source de la page dans un navigateur, avant d'appliquer ce genre de conseil.

Importe-t-il que l'outil de récupération de mon agent exécute JavaScript ?

Oui, lorsque votre contenu ou vos balises dépendent de JavaScript. Un outil qui effectue le rendu de la page peut signaler un titre ou un H1 absent du HTML brut, et un outil qui ne le fait pas peut signaler une page quasi vide que les navigateurs affichent en entier. Comparer le HTML brut à la page rendue permet de savoir laquelle des deux versions les moteurs de recherche et les autres robots reçoivent en premier.