Aller au contenu
SilktideAide

Contenu lisible sans JavaScript

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

Dans toute cette page, supposons que Fernwood ait reconstruit son site marketing en application monopage. Dans un navigateur, il paraît complet. L'affichage du code source montre un <div id="root"></div> presque vide. C'est cette coquille vide que reçoivent GPTBot, ClaudeBot, PerplexityBot et autres crawlers similaires.

Pourquoi cela fonctionne

Les moteurs de recherche traditionnels ont largement résolu ce point : Google rend le JavaScript avant indexation. Les moteurs de réponse, non. Les crawlers qui alimentent ChatGPT, Claude, Perplexity et systèmes similaires récupèrent généralement la réponse HTML brute et s'arrêtent là — 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 propre comparaison d'exploration 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, car 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 crawler ne voit jamais le contenu décrit par ces signaux.
  • Les visiteurs humains en cas d'échec ou de blocage des scripts voient la même coquille vide, et le premier rendu de contenu souffre même si les scripts finissent par réussir.

C'est un problème d'architecture du site, pas un problème d'édition de page. Corriger une URL à la main ne corrige pas le gabarit qui en produit cent autres.

Comment vérifier ce que voit un crawler

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 au HTML brut capturé au moment de l'exploration. Il signale les pages où le texte brut représente à la fois moins d'environ 10 % du texte rendu et est minuscule en valeur absolue — une vraie coquille vide, pas une page qui se contente de s'enrichir.
  2. Affichez le code source, pas l'onglet Éléments des DevTools. Dans le navigateur, "Afficher le code source de la page" montre ce que le serveur a envoyé. Le panneau Éléments montre le DOM après exécution de JavaScript. Si le texte de votre article est dans Éléments mais absent du code source, les crawlers qui ignorent le JS ne le verront pas.
  3. Récupérez sans navigateur. Depuis un terminal : curl -sL https://fernwood.example/pricing | head. Ou utilisez un navigateur en mode texte. Si le tableau des tarifs manque dans cette sortie, il manque aussi pour le crawler.

Vérifiez également que le crawler est autorisé à entrer — une réponse HTML parfaite est inutile si robots.txt bloque le crawler d'IA, ou si un pare-feu le bloque en pratique (Crawlers d'IA bloqués en pratique).

Comment corriger

Choisissez l'approche adaptée à votre pile. 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 hydrate ensuite pour l'interactivité. C'est la voie par défaut des frameworks qui le prennent déjà en charge :

  • Next.js — utilisez l'App Router avec les 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 le montage.
  • Nuxt — mode universel / SSR (par défaut), pas ssr: false.
  • Remix, SvelteKit, Astro (mode SSR) et équivalents — même idée : la réponse du document inclut le texte du corps.

Règle empirique : si c'est un fetch dans useEffect / onMounted qui place l'article sur la page, déplacez cette récupération de données côté serveur.

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

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

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

3. Pré-rendu comme solution transitoire

Si vous ne pouvez pas encore changer de framework, un service de pré-rendu ou une étape de build peut servir un instantané HTML déjà rendu aux crawlers (et souvent aux nouveaux visiteurs) tandis que le SPA continue de fonctionner pour les sessions interactives. Considérez cela comme un pont, pas une destination : l'actualité 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 dès que possible.

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

Ce qui doit figurer dans 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 voir répétés par les assistants.
  • Les données structurées dans un bloc <script type="application/ld+json"> du HTML initial — du JSON-LD injecté uniquement après l'hydratation est aussi invisible que le texte.
  • L'URL canonique, le title et la meta description dans <head>.

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

Erreurs fréquentes

  • SPA uniquement côté client — Create React App, Vite SPAs et configurations similaires qui livrent une coquille vide et récupèrent les routes dans le navigateur. La correction est SSR/SSG, pas plus de code client.
  • Contenu derrière "Charger plus" ou des onglets qui n'apparaissent jamais dans le HTML. Si la seule façon d'atteindre la section trois est un clic qui la récupère, les crawlers n'atteignent jamais la section trois. Préférez de vraies URL ou incluez le contenu dans la réponse initiale.
  • "Ça marche dans Google, donc tout va bien." Le rendu par Googlebot n'est pas un substitut à la lisibilité par les crawlers d'IA. Réussir avec Google et échouer avec GPTBot est une divergence courante et invisible.
  • Bloquer le crawler et accuser JavaScript. Vérifiez toujours l'accès des crawlers d'IA et la joignabilité effective en parallèle de cette technique.

Comment Silktide aide

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

Liens associés

Dernière mise à jour

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

Contenu lisible sans JavaScript | Centre d’aide Silktide