Passer au contenu
SilktideAide

Contenu lisible sans JavaScript

Le contenu principal de votre page — les paragraphes, titres, tableaux et prix que le visiteur vient chercher — doit être présent dans le HTML que votre serveur renvoie dès la première requête. L’amélioration par est très bien. Un contenu qui n’apparaît qu’après l’exécution de JavaScript est invisible pour la plupart des robots d’IA, et donc pour les assistants qui s’y réfèrent.

Dans toute cette page, supposons que Fernwood a reconstruit son site marketing en application monopage. Dans un navigateur, tout semble complet. L’affichage du code source montre un <div id="root"></div> presque vide. Cette coquille vide est ce que GPTBot, ClaudeBot, PerplexityBot et des robots similaires reçoivent.

Pourquoi cela fonctionne

Les moteurs de recherche traditionnels ont en grande partie résolu ce point : Google rend JavaScript avant l’indexation. Les moteurs de réponses ne l’ont pas fait. Les robots qui alimentent ChatGPT, Claude, Perplexity et des systèmes similaires récupèrent en général la réponse HTML brute et s’arrêtent — ils n’attendent pas l’hydratation de votre framework, n’exécutent pas votre bundle et ne suivent pas les routes côté client. La comparaison de crawl de Silktide (page rendue vs. HTML brut) repose exactement sur ce comportement; voir Contenu sans JavaScript.

Le mode de défaillance est silencieux et total :

  • Une page bien classée sur Google peut être totalement absente des réponses d’IA, parce que les assistants n’ont jamais reçu le texte.
  • Tout autre investissement AEO sur cette page — données structurées, dates lisibles par machine, rédaction orientée réponse — est inutile si le robot ne voit jamais le contenu que ces signaux décrivent.
  • Les visiteurs humains, lorsque les scripts échouent ou sont bloqués, voient la même coquille vide, et le premier affichage de contenu en pâtit même lorsque les scripts finissent par réussir.

Il s’agit d’un problème d’architecture du site, pas d’édition de page. Corriger une URL à la main ne répare pas le gabarit qui produit les cent suivantes.

Comment vérifier ce que voit un robot d’exploration

Avant de changer quoi que ce soit, confirmez le problème. Trois méthodes, de la plus probante à la moins :

  1. Le contrôle de Silktide. Contenu sans JavaScript compare le texte significatif du corps de la page rendue avec le HTML brut capturé au moment du crawl. Il signale les pages où le texte brut est à la fois inférieur à ~10 % du texte rendu et minuscule en valeur absolue — une véritable coquille vide, pas une page qui se contente de s’enrichir.
  2. Afficher le code source, pas Éléments de DevTools. Dans le navigateur, "View Page Source" affiche ce que le serveur a envoyé. Le panneau Éléments montre le DOM après l’exécution de JavaScript. Si le texte de votre article apparaît dans Éléments mais est absent d’Afficher le code source, les robots qui ignorent JS ne le verront pas.
  3. Récupérer sans navigateur. Depuis un terminal : curl -sL https:\/\/fernwood.example\/pricing | head. Ou utilisez un navigateur en mode texte. Si le tableau des tarifs est absent de cette sortie, il est absent pour le robot aussi.

Confirmez aussi que le robot est autorisé à entrer — une réponse HTML parfaite est inutile si robots.txt bloque le robot d’IA, ou si un pare-feu le bloque en pratique (Robots d’IA bloqués en pratique).

Comment le corriger

Choisissez l’approche adaptée à votre pile technologique. Les trois aboutissent au même résultat : la première réponse HTML contient le contenu.

1. Rendu côté serveur (SSR)

Le serveur rend chaque page en HTML à la demande; JavaScript procède ensuite à l’hydratation pour l’interactivité. C’est la voie par défaut des frameworks qui la prennent en charge :

  • Next.js - utilisez l’App Router avec des Server Components, ou getServerSideProps / getStaticProps dans le Pages Router. N’expédiez pas une racine uniquement côté client qui récupère le contenu après montage.
  • Nuxt - mode universel / SSR (le défaut), pas ssr: false.
  • Remix, SvelteKit, Astro (mode SSR) et équivalents - même idée : la réponse du document inclut le corps de la page.

Règle générale : si c’est une récupération dans useEffect / onMounted qui place l’article sur la page, déplacez cette récupération de données vers le serveur.

2. Génération de site statique (SSG)

Préconstruisez les pages en HTML simple au moment de la publication. Idéal pour du contenu qui ne varie pas selon le visiteur — articles de blogue, documentation, pages marketing, tarification. Astro, Eleventy, Hugo, Next.js output: 'export' et Nuxt generate produisent tous des fichiers qu’un robot peut lire sans aucun JavaScript.

Le SSG est généralement le gain le plus économique pour les sites marketing et de contenu : aucun coût de rendu par requête, et le HTML sur le disque est exactement ce que reçoit le robot.

3. Pré-rendu comme solution transitoire

Si vous ne pouvez pas encore changer de framework, un service ou une étape de build de pré-rendu peut servir un instantané HTML rendu aux robots (et souvent aux visiteurs en première visite) pendant que la SPA continue de fonctionner pour les sessions interactives. Considérez ceci comme un pont, pas une destination : la fraîcheur des instantanés, l’invalidation du cache et les routes authentifiées deviennent autant de charges de maintenance. Préférez corriger le mode de rendu quand c’est possible.

Les conseils de Google sur le SEO JavaScript et l’article de web.dev Rendu sur le Web couvrent le même spectre — SSR, SSG et amélioration progressive — du point de vue des moteurs de recherche.

Ce que doit contenir le premier HTML

Pas chaque pixel. Le contenu qu’une citation reprendrait :

  • Le corps de l’article ou de la page — titres, paragraphes, listes, tableaux.
  • Les prix, limites et autres faits que vous voulez que les assistants reprennent.
  • Données structurées dans un bloc <script type="application\/ld+json"> du HTML initial — du JSON-LD injecté seulement après l’hydratation est aussi invisible que le texte.
  • URL canonique, titre et méta-description dans <head>.

JavaScript peut toujours gérer les menus, la personnalisation, des graphiques qui enrichissent un tableau déjà présent et des fonctionnalités progressives. Le contrôle de Silktide est volontairement indulgent concernant l’enrichissement : les pages qui servent leur contenu principal en HTML et superposent le comportement au-dessus réussissent.

Schémas d’échec courants

  • SPA uniquement côté client — Create React App, SPA Vite et configurations similaires qui livrent une coquille vide et récupèrent les routes dans le navigateur. La solution est SSR/SSG, pas plus de code côté client.
  • Contenu derrière "Load more" ou des onglets qui n’apparaissent jamais dans le HTML. Si le seul moyen d’atteindre la section trois est un clic qui la récupère, les robots n’atteindront jamais la section trois. Privilégiez de vraies URL ou incluez le contenu dans la réponse initiale.
  • « Ça marche dans Google, donc c’est bon. » Le rendu par Googlebot ne remplace pas la lisibilité par les robots d’IA. Réussir pour Google et échouer pour GPTBot est une divergence courante et invisible.
  • Bloquer le robot et accuser JavaScript. Vérifiez toujours l’accès des robots d’IA et l’accessibilité effective en parallèle de cette technique.

Comment Silktide aide

Si Silktide ne peut pas lire votre contenu sans JavaScript, les assistants que vous voulez voir vous citer ne le peuvent pas non plus.

Connexes

Dernière mise à jour

Cette page vous a-t-elle été utile?

Contenu lisible sans JavaScript | Aide de Silktide