Préparation à la recherche par IA : les problèmes de SEO technique qui empêchent un site d’être découvert

D’où viennent les chiffres

Le 29 septembre 2026, SitequiryBot a exploré 106 sites connus (surtout slovènes et allemands, plus des sites en anglais et dans d’autres langues ; boutiques, médias, services publics, entreprises, tourisme, associations). L’exploration a abouti pour 90 d’entre eux ; 13 ont répondu à notre robot par un code 403 ou 429 ou par une page de vérification anti-bots, et 3 ont redirigé vers un autre domaine. Pour chaque site exploré, nous avons analysé jusqu’à 20 pages et contrôlé les 12 381 liens internes qu’elles contenaient, avec les mêmes vérifications que le Rapport de site payant.

Chaque chiffre ci-dessous compte des sites, pas des pages : un site compte une seule fois pour un problème, qu’une URL ou cinquante soient touchées. Il s’agit d’un échantillon de commodité composé de sites connus, pas d’une image du Web entier, et 20 pages ne font pas une exploration complète : un site qui « passe » peut très bien avoir le problème ailleurs. Les chiffres sur robots.txt, les sitemaps, llms.txt et le balisage sont publiés avec leur méthode dans notre étude sur la préparation à la recherche par IA (en anglais) ; les chiffres techniques de cette page viennent de la même exploration et sont disponibles en CSV et en JSON sous licence CC BY 4.0 (jeu de données en anglais). Aucun résultat par site n’est publié.

SEO classique et visibilité dans l’IA : même socle, dernière étape différente

Google le dit clairement : ses fonctionnalités d’IA n’exigent rien de plus. Sa page Fonctionnalités d’IA et votre site Web indique qu’une page doit être indexée et pouvoir s’afficher avec un extrait, et que les bonnes pratiques SEO habituelles s’appliquent. Aucun balisage particulier ni aucun fichier spécial ne rend une page éligible aux Aperçus IA ou au Mode IA.

Les autres outils de recherche par IA envoient leurs propres robots. OpenAI utilise OAI-SearchBot pour faire apparaître des sites dans ChatGPT search, indépendamment de GPTBot, qui collecte des données d’entraînement. Anthropic décrit Claude-SearchBot, Claude-User et ClaudeBot et indique qu’ils respectent robots.txt ; Perplexity utilise PerplexityBot pour ses résultats de recherche. Quoi que ces systèmes fassent ensuite, ils commencent comme un moteur de recherche : récupérer l’URL, suivre les liens, lire le HTML.

C’est la dernière étape qui change. Un moteur de recherche classe une liste de pages ; une réponse d’IA retient quelques passages et peut les citer. Aucune de ces entreprises ne publie la façon dont elle choisit les sources d’une citation, et aucune exploration, la nôtre comprise, ne permet de le mesurer. La couche technique tranche une question plus étroite et plus facile à vérifier : la page peut-elle seulement faire partie des candidates ?

1. Des robots refoulés avant d’avoir vu une page

Premier filtre : robots.txt. Dans notre étude, 14 des 90 sites (16 %) bloquaient au moins un des quatre robots de recherche IA que nous testons, et 18 (20 %) au moins un des 15 robots d’IA de toute nature. Vu de l’extérieur, impossible de savoir si un blocage est voulu : vérifiez donc qu’une règle écrite pour empêcher l’entraînement des IA ne vise pas aussi un robot de recherche. Le vérificateur de robots d’IA classe chaque agent utilisateur selon son rôle : recherche, action déclenchée par l’utilisateur ou entraînement.

Deuxième filtre : le pare-feu ou le CDN, dont robots.txt ne dit rien. Sur les 106 sites de notre échantillon, 13 n’ont pas laissé entrer notre robot du tout et ont répondu par 403, 429 ou une page de vérification. Nous avons constaté la même chose chez nous : le 13 octobre 2026, le robots.txt de sitequiry.com autorisait tous les robots, mais le pare-feu de l’hébergeur renvoyait une erreur 403 à l’agent utilisateur Bytespider. Une protection anti-bots qui ne distingue pas un robot de recherche d’un aspirateur de contenu peut bloquer OAI-SearchBot ou PerplexityBot comme n’importe quel autre visiteur, et le propriétaire du site n’en voit aucune trace dans robots.txt.

Troisième filtre, plus discret : le noindex. Google rappelle qu’une page bloquée par robots.txt ne peut pas montrer sa balise noindex, puisque le robot ne la récupère jamais (Google : bloquer l’indexation). Dans notre exploration, une page d’accueil portait un noindex : un seul site, mais c’est toute sa porte d’entrée qui demandait à rester hors de l’index.

• Ouvrez votre robots.txt et lisez chaque groupe User-agent qui nomme un robot d’IA ; le vérificateur de robots d’IA le fait pour 15 d’entre eux.
• Demandez à votre hébergeur ou à votre CDN quels robots leur pare-feu soumet à une vérification. Cloudflare, par exemple, propose un réglage qui bloque les robots d’IA quel que soit le contenu du robots.txt.
• Vérifiez que les pages que vous voulez voir trouvées ne portent pas de noindex, ni dans le HTML ni dans un en-tête X-Robots-Tag.

2. Des liens internes qui ne mènent nulle part, ou par un détour

Les robots découvrent la plupart des pages en suivant des liens. Sur les 12 381 liens internes contrôlés, 64 menaient à une page d’erreur (dont 60 erreurs 404). C’est peu en apparence, mais ils se répartissaient sur 18 des 90 sites (20 %) et, sur 10 de ces 18 sites, la même cible cassée était liée depuis au moins trois des pages analysées, ce qui désigne en général un lien de menu, de pied de page ou de modèle.

Les redirections étaient bien plus fréquentes : 67 sites (74 %) contenaient au moins un lien interne vers une URL redirigée, le plus souvent de http:// vers https:// ou vers une version avec ou sans barre oblique finale. Une redirection unique ne pose pas de problème. Les chaînes, si : 23 sites (26 %) avaient au moins une URL qui exigeait deux redirections ou plus. Les robots de Google suivent jusqu’à 10 sauts (Google : codes d’état HTTP), et ses recommandations pour les changements d’adresse demandent une redirection directe vers l’URL finale, ou à défaut une chaîne de moins de cinq sauts, idéalement trois au plus (Google : déplacer un site). Les autres robots d’IA ne documentent pas leurs limites : partez du principe que chaque saut supplémentaire est une requête qui risque de ne pas être faite.

Les deux problèmes se corrigent de la même façon : remplacez le lien lui-même par l’URL finale, dans le modèle qui l’affiche, au lieu d’ajouter une redirection de plus. Pour voir quelles adresses Google a lui-même classées comme redirigées ou introuvables, le guide Pourquoi mon site n’apparaît-il pas sur Google ? passe en revue les motifs du rapport sur l’indexation des pages dans la Search Console.

3. Des sitemaps qui contredisent les pages qu’ils listent

Un sitemap est la liste des URL que vous demandez aux moteurs de recherche d’explorer et d’indexer. Sur les 90 sites, 75 en avaient un. Parmi eux, 15 (20 %) listaient au moins une URL redirigée ou en erreur, et 6 (8 %) une page en noindex. Chaque fois, c’est une contradiction : le sitemap dit « indexez cette page » alors que la page répond « j’ai déménagé », « je n’existe pas » ou « ne m’indexez pas ».

Google demande d’y placer les URL canoniques que vous voulez voir dans les résultats, et n’utilise lastmod que si cette date est exacte de façon constante (Google : créer un sitemap). Bing fait la même remarque en pensant à la recherche par IA : dans un article de juillet 2025, il recommande un sitemap complet avec un lastmod fidèle, plus IndexNow pour les pages modifiées, afin que les résultats alimentés par l’IA restent à jour.

• Générez le sitemap à partir des mêmes données que celles qui fixent la canonical et le noindex : une page redirigée ou exclue en sortira alors automatiquement.
• Donnez à lastmod la date de la dernière modification du contenu, pas celle de la génération du fichier.
• Déclarez le sitemap dans robots.txt. Sur les 84 sites dont le robots.txt était lisible, 70 le faisaient ; les autres comptent sur les moteurs pour le trouver à l’adresse par défaut.

4. Canonical, doublons et langues : des signaux qui se contredisent

Une balise canonical indique aux moteurs laquelle de plusieurs URL similaires est la principale. Google la range parmi les signaux forts, avec les redirections, alors que la présence d’une URL dans le sitemap n’est qu’un signal faible (Google : URL canoniques). Une canonical qui pointe vers une page redirigée, en erreur ou en noindex envoie les robots dans une impasse. Nous ne l’avons trouvé que sur un site. Les erreurs de canonical étaient rares dans cet échantillon, mais une canonical fausse dans un modèle touche toutes les pages construites à partir de lui.

Les titres en double étaient plus fréquents : 16 sites (18 %) avaient au moins deux pages indexables portant le même titre. Quand deux pages se présentent de façon identique, le moteur doit deviner seul laquelle répond à une requête ; les consignes de Google sur les liens de titre demandent un titre distinct et descriptif pour chaque page.

Les sites multilingues ajoutent hreflang, qui ne fonctionne que si chaque version linguistique se cite elle-même et cite toutes les autres, et si chaque lien est réciproque ; sinon, les annotations peuvent être ignorées (Google : versions localisées). Sur les 31 sites utilisant hreflang, 4 (13 %) rompaient cette boucle sur au moins une page. L’outil Vérifier hreflang et canonical contrôle une URL et ses variantes en quelques secondes.

5. Du contenu qui n’existe qu’après l’exécution du JavaScript

Sur 5 des 90 sites (6 %), au moins une page analysée était une coquille rendue côté client : le HTML envoyé par le serveur ne contenait aucun contenu lisible avant l’exécution du JavaScript. Trois autres sites ont été écartés des chiffres par page de l’étude pour la même raison : presque aucune de leurs pages n’avait de contenu dans le HTML.

Google exécute le JavaScript, mais lors d’une étape distincte, après l’exploration, et recommande toujours le rendu côté serveur ou le pré-rendu, notamment parce que tous les robots ne savent pas exécuter de scripts (Google : notions de base du SEO JavaScript). Pour les robots d’IA, la meilleure mesure publique reste l’analyse de Vercel de décembre 2024 : à ce moment-là, aucun des grands robots d’IA n’exécutait le JavaScript ; ceux d’OpenAI et d’Anthropic téléchargeaient les fichiers de script sans les exécuter, tandis que Gemini (via l’infrastructure de Google) et Applebot effectuaient le rendu. Cela peut changer, mais aujourd’hui une page dont le texte n’apparaît que dans le navigateur reste probablement invisible pour une partie des robots de recherche IA.

Le test est simple : affichez le code source de la page (pas l’inspecteur) et cherchez-y une phrase du texte principal. Si elle n’y est pas, interrogez votre développeur sur le rendu côté serveur ou la génération statique pour les pages qui comptent.

6. Des pages difficiles à comprendre une fois lues

Être récupérée ne veut pas dire être comprise. L’étude a montré que 59 % des pages d’accueil comportaient un balisage schema.org, mais que 35 % seulement nommaient l’organisation derrière le site, et que sur 43 % des sites contrôlés, au moins deux pages indexables n’avaient pas de H1. Les données structurées ne valent pas à elles seules une place dans les réponses de l’IA ; Google exige qu’elles décrivent ce qui est visible sur la page (Google : consignes relatives aux données structurées), et ses conseils de mai 2025 sur les expériences d’IA placent un contenu unique et utile en premier, avant tout point technique.

Concrètement : un H1 clair qui nomme le sujet, un titre et une description différents de ceux des autres pages, un bloc Organization qui reprend le nom et l’adresse affichés sur la page, et un texte qui répond en phrases simples à la question traitée par la page. Le guide des données structurées donne un exemple de bloc Organization minimal.

Ce que cette exploration ne peut pas vous dire

• Si un site est cité dans ChatGPT, Perplexity, Claude ou les réponses d’IA de Google. Nous avons mesuré uniquement des signaux de préparation ; aucun chiffre de cette page ne mesure la visibilité ou le classement.
• Si l’un de ces problèmes a provoqué un changement de classement. Ce sont des obstacles documentés à l’exploration et à l’indexation, pas des facteurs de citation par l’IA démontrés.
• Ce qui se passe au-delà de 20 pages par site, ni ce qu’aurait reçu un robot situé ailleurs ou utilisant un autre agent utilisateur.
• La vitesse et les Core Web Vitals, qui n’ont pas été mesurées pour cet échantillon.

Dans quel ordre vérifier votre propre site

• Accès : groupes robots.txt pour les robots de recherche et d’IA, plus les réglages anti-bots du pare-feu ou du CDN. Outil : vérificateur de robots d’IA.
• Indexabilité : aucun noindex involontaire, des canonicals qui pointent vers des pages actives et indexables. Outil : vérificateur de balises meta.
• Liens : aucun lien interne vers une 404, aucune chaîne de redirections ; remplacez les liens par leur URL finale.
• Sitemap : uniquement des URL canoniques et indexables qui répondent 200, avec un lastmod fidèle.
• Rendu : le texte principal figure dans le code source.
• Langues : hreflang liste toutes les versions, page elle-même comprise, et chaque lien est réciproque. Outil : Vérifier hreflang et canonical.
• Compréhension : un seul H1, un titre et une description uniques, des données structurées conformes à la page.

L’analyse gratuite contrôle ces signaux sur une URL, ainsi que la vitesse via Google PageSpeed. Le Rapport de site payant applique les mêmes vérifications que cette exploration sur 20 pages au maximum d’un site et contrôle les liens internes qu’il y trouve. Si les corrections demandent un développeur, l’équipe GE-KO à l’origine de Sitequiry peut prendre en charge leur mise en œuvre.

Questions fréquentes