Le 17 décembre 2024, Vercel et le cabinet SEO MERJ ont publié une étude de trafic qui répond à une question que la plupart des propriétaires de sites WordPress ne s’étaient jamais posée : quand un crawler IA arrive sur une page, voit-il vraiment ce que voit un visiteur humain ? wp-premiums vous a déjà montré ce que l’AI Client change sur un site WordPress, et ce qu’il ne change pas, toujours sous l’angle d’un agent qui agit sur votre site une fois arrivé dessus. L’étude Vercel/MERJ pose une question qui vient avant tout ça. Ces crawlers savent-ils seulement lire la page ? Leurs données répondent non, pour la plupart des crawlers IA qui visitent aujourd’hui les sites WordPress. Allons voir ensemble ce qu’elles montrent vraiment, et qui, sur WordPress, doit s’en inquiéter.
Les crawlers IA voient-ils vraiment votre page comme vous ?
Aucun des grands crawlers IA de l’étude Vercel/MERJ n’exécute le JavaScript. GPTBot et ses cousins OpenAI OAI-SearchBot et ChatGPT-User, ClaudeBot chez Anthropic, PerplexityBot, le crawler de Meta, Bytespider chez ByteDance, et CCBot chez Common Crawl récupèrent tous le HTML brut de la page, puis s’arrêtent là. Deux crawlers échappent à ce constat. Google Gemini hérite du moteur de rendu de Googlebot lui-même, et AppleBot rend les pages via ce que l’étude décrit comme un crawler fondé sur un vrai navigateur, à la manière de Googlebot. La documentation officielle de Google sur le JavaScript et le SEO pose le principe général sans détour : le rendu côté serveur reste une bonne idée, parce que tous les robots ne savent pas exécuter de JavaScript.
Cela ne veut pas dire que GPTBot et ClaudeBot ignorent totalement les fichiers JavaScript. GPTBot télécharge un fichier JavaScript dans 11,5 % de ses requêtes, et ClaudeBot dans 23,84 % des siennes, mais Vercel et MERJ n’ont trouvé aucune preuve que l’un ou l’autre exécute ensuite ce code. Télécharger un script et l’exécuter sont deux choses différentes, et seule l’exécution permet à un crawler de voir un contenu que la page construit dans le navigateur. Sur le réseau propre de Vercel, le mois précédant la publication de l’étude, GPTBot a généré 569 millions de requêtes et le crawler de Claude 370 millions, un volume cumulé que Vercel situe à environ 20 % de ce que Googlebot a envoyé sur ce même réseau durant la même période. Des chiffres qui viennent d’un seul réseau d’hébergement, pas du web entier, mais qui donnent une idée utile de la fréquence réelle de passage de ces crawlers.
Un site WordPress classique est-il concerné ?
Voici ce que la plupart des articles sur cette étude oublient de dire, et c’est justement le point qui compte si vous tenez un site WordPress ordinaire. WordPress génère son HTML côté serveur par défaut, exactement ce dont un crawler IA a besoin pour lire une page sans exécuter la moindre ligne de JavaScript. La documentation officielle des développeurs WordPress décrit l’éditeur de blocs de la même façon : le serveur traite le PHP, interroge la base de données, et envoie un HTML déjà complet au navigateur, la même approche que WordPress utilise depuis bien avant l’existence de React ou de Vue.
L’Interactivity API, rendue publique avec WordPress 6.5, ne change rien à ce calcul. Elle ajoute de petits attributs de données à un HTML déjà rendu côté serveur, pour que les clics et interactions d’un visiteur puissent mettre à jour la page sans rechargement complet. La documentation de WordPress est explicite : le HTML rendu côté serveur et sa version hydratée côté client doivent correspondre exactement, l’inverse d’une génération du contenu principal dans le navigateur. Un crawler incapable d’exécuter la moindre ligne de JavaScript reçoit quand même l’article complet ou la fiche produit complète, parce que WordPress l’a déjà écrit dans le HTML avant même que l’Interactivity API n’entre en jeu.
Où le problème commence-t-il vraiment ?
Le risque que décrivent Vercel et MERJ apparaît dès que WordPress cesse d’être ce qui génère la page. Un montage headless, où WordPress ne sert que de backend derrière un frontend JavaScript séparé, confie la construction du HTML à du code qu’un crawler IA ne peut pas exécuter. WP VIP vend exactement ce montage : un backend WordPress couplé à un frontend React ou Next.js qui interroge le contenu via GraphQL, plutôt que de laisser WordPress produire lui-même le HTML. Si ce frontend construit le corps réel de l’article dans le navigateur plutôt que côté serveur ou au moment du build, un crawler IA qui arrive sur la page ne récupère que la coquille HTML chargée avant l’exécution du JavaScript : un titre, un menu de navigation, parfois une icône de chargement, jamais le contenu qu’un humain est venu lire.
Le même risque existe en dehors des montages headless. N’importe quel thème ou constructeur de pages WordPress qui injecte le contenu principal (le texte réel de l’article, la description d’un produit, le détail d’une page de service) via du JavaScript côté client après le chargement initial crée le même angle mort, même sur un site entièrement WordPress. La vraie question n’est pas de savoir si votre site « utilise du JavaScript » (presque tous les sites en utilisent, pour les menus, les carrousels, les formulaires), mais si le contenu que vous voulez vraiment faire lire se trouve dans le HTML envoyé par le serveur, ou s’il est ajouté ensuite par un script.
Un fichier llms.txt règle-t-il le problème ?
Une bonne partie des discussions WordPress sur la visibilité IA se concentre sur llms.txt, un fichier censé indiquer aux systèmes IA le contenu le plus utile d’un site. Ce fichier répond à une question différente de celle-ci. Déclarer son contenu dans une entrée llms.txt dit à un crawler où regarder. Cela ne change rien à sa capacité de lire ce qu’il trouve une fois arrivé là. Un site WordPress qui publie un llms.txt soigneusement rédigé, pointant vers des pages qu’un frontend JavaScript rend côté client, tend quand même une coquille vide à GPTBot ou ClaudeBot quand ils suivent ce lien. La lisibilité vient d’abord. La déclaration ne compte qu’une fois ce point réglé.
Que vérifier concrètement sur votre propre site WordPress ?
Tout ceci se résume à une habitude : regarder vos pages comme le fait un crawler, pas comme le fait votre navigateur.
- Affichez le code source brut de votre page, pas la page telle que rendue dans votre navigateur. Clic droit, afficher le code source de la page (pas « inspecter »), et vérifiez si le texte réel de votre article s’y trouve. Sur un thème WordPress classique ou un thème de blocs, c’est presque toujours le cas.
- Désactivez entièrement le JavaScript dans votre navigateur pour tester, puis rechargez la page. Si le contenu qui vous intéresse disparaît, un crawler IA voit exactement ce que vous voyez à cet instant : rien.
- Si vous tenez un montage WordPress headless ou découplé, demandez-vous si votre frontend rend les pages côté serveur ou au moment du build (les deux gardent le contenu dans le HTML), ou purement dans le navigateur, le schéma qui crée l’angle mort.
- Si vous utilisez un thème ou un constructeur que vous n’avez pas conçu vous-même, vérifiez dans sa documentation comment il charge votre contenu principal : balisage rendu côté serveur, ou application JavaScript côté client montée dans une simple div vide.
LE test qui répond vraiment à cette question est le premier de la liste ci-dessus : affichez le code source brut, et lisez ce qui s’y trouve réellement.
Rien de tout cela ne demande une extension ou une refonte pour être vérifié. Si votre site WordPress se rend de façon normale, blocs Gutenberg ou thème PHP classique, ce point ne vous concerne très probablement pas. Si vous tournez en headless, ou avec un constructeur dont vous n’êtes pas entièrement sûr, cinq minutes de vérification valent le coup avant de vous inquiéter du reste de votre liste de visibilité IA.
Notre avis
La plupart des sites WordPress n’ont pas le problème que décrit cette étude, parce que WordPress rend déjà votre contenu exactement comme un crawler IA a besoin de le recevoir. Les sites concernés sont ceux qui ont délibérément déplacé le rendu vers le navigateur : un frontend headless, un constructeur très chargé en JavaScript, un thème personnalisé qui injecte son contenu principal après le chargement. Si cela décrit votre installation, vérifiez-le avec le test du code source brut ci-dessus avant de vous pencher sur quoi que ce soit de plus élaboré. Si vous êtes curieux de savoir jusqu’où va l’outillage IA de WordPress côté action, une fois qu’un crawler ou un agent peut vraiment lire votre site, notre tour des trois briques qui rendent WordPress agentique est la lecture naturelle qui suit. La lecture vient d’abord, cela dit : un agent qui ne voit pas votre contenu ne peut pas non plus agir dessus.
Photo : Luis Quintero / Pexels.
