Le JSON d'hydratation en bas de page nuit-il au SEO ?

Qu'est-ce que le JSON d'hydratation et pourquoi certains sites le masquent aux bots ?

L'hydratation est le processus par lequel un framework JavaScript (React, Vue, Next.js) transforme du HTML statique en application interactive côté client. Pour fonctionner, le framework injecte souvent un objet JSON volumineux en bas de page, contenant l'état initial de l'application — parfois plusieurs centaines de kilooctets.

Certains développeurs craignent que ce JSON alourdisse le DOM, dilue la densité sémantique perçue par Google, ou constitue du contenu dupliqué si le JSON reprend des données déjà présentes dans le HTML. Résultat : ils créent une logique serveur qui détecte Googlebot et désactive l'injection du JSON pour ce client uniquement.

Pourquoi Google déconseille-t-il cette pratique ?

Martin Splitt coupe court : ce JSON n'est pas un problème pour le moteur. Google parse le HTML rendu final, et le JSON d'hydratation — souvent placé dans un <script type="application/json"> — n'est pas interprété comme du contenu textuel indexable. Il ne dilue rien, ne crée pas de duplication pénalisante.

En revanche, créer une branche de code spécifique pour les bots introduit de la fragilité : risque de divergence entre ce que voit l'utilisateur et ce que voit Google (cloaking involontaire), bugs de déploiement si la détection User-Agent échoue, maintenance accrue. Tout cela pour un bénéfice nul.

Cette déclaration s'applique-t-elle à tous les types de JSON en bas de page ?

Splitt parle explicitement du JSON d'hydratation — celui généré par les frameworks modernes pour réhydrater l'interface. Il ne parle pas des autres usages de JSON : structured data (JSON-LD), données de tracking analytics, ou configurations tierces.

La déclaration ne couvre pas non plus les cas où le JSON contient du contenu éditorial brut (articles complets, descriptions produit) sans équivalent HTML visible. Dans ce dernier cas, la question de l'indexation se pose différemment — mais ce n'est pas le sujet ici.

• Le JSON d'hydratation (état initial des frameworks JS) ne nuit pas à l'indexation.
• Créer un code différent pour Googlebot ajoute de la complexité sans gain SEO.
• Google lit le HTML rendu final — le JSON dans un <script> n'est pas considéré comme contenu textuel.
• Cette règle ne concerne pas les structured data JSON-LD ni les autres usages de JSON en page.

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et elle confirme ce que les tests empiriques montrent depuis plusieurs années. Les sites en SSR (Server-Side Rendering) avec hydratation — Next.js, Nuxt, SvelteKit — s'indexent correctement même avec des payloads JSON conséquents en bas de page. Google a suffisamment progressé dans le rendu JavaScript pour ignorer ce qui relève de la plomberie technique.

Ce qui pose réellement problème, c'est le rendu asynchrone critique : du contenu chargé après l'exécution JS côté client, sans équivalent HTML initial. Le JSON d'hydratation, lui, suppose que le HTML est déjà présent — donc indexable.

Quelles nuances faut-il apporter ?

La déclaration de Splitt repose sur un présupposé implicite : votre HTML initial contient déjà le contenu sémantique complet. Si votre framework génère un shell vide côté serveur et que tout le contenu s'affiche via JavaScript après hydratation, vous êtes hors périmètre — et en difficulté SEO. [A verifier] : Google n'a jamais précisé de seuil de taille au-delà duquel un JSON d'hydratation deviendrait problématique. On suppose qu'il n'y en a pas, mais les tests publics sur des payloads de plusieurs Mo restent rares.

Autre point : si votre JSON contient des données structurées lisibles (prix, avis, descriptions) mais que le HTML équivalent est absent ou caché, Google pourrait théoriquement les ignorer — mais ce n'est plus un problème d'hydratation, c'est un problème d'architecture.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si vous faites du cloaking délibéré — servir un HTML différent à Google pour masquer du contenu sensible ou manipuler le ranking — la présence ou l'absence de JSON devient le cadet de vos soucis. Google pénalise le comportement, pas le JSON.

Si votre site utilise un CSR pur (Client-Side Rendering) sans pré-rendu serveur, vous n'avez probablement pas de JSON d'hydratation au sens strict — vous avez un bundle JS qui génère tout à la volée. Là, le problème n'est pas le JSON, c'est l'absence de HTML initial indexable.

Que faut-il faire concrètement avec le JSON d'hydratation ?

Ne rien faire. Laissez votre framework injecter son JSON d'hydratation normalement, pour tous les clients sans distinction. Si vous utilisez Next.js, Nuxt, ou un équivalent en SSR/SSG, le JSON généré automatiquement (souvent dans __NEXT_DATA__) ne nécessite aucune intervention.

Assurez-vous que le HTML rendu côté serveur contient déjà le contenu textuel complet — titres, paragraphes, données produit. Le JSON ne doit servir qu'à réhydrater l'interface interactive, pas à remplacer du contenu manquant.

Quelles erreurs éviter ?

Ne créez pas de logique de détection User-Agent pour masquer le JSON aux bots. Cela introduit une divergence entre l'expérience utilisateur et l'expérience bot, ce qui peut être interprété comme du cloaking — même involontaire. Google valorise la cohérence du code source.

Ne confondez pas optimisation du payload et suppression du JSON. Si votre JSON d'hydratation pèse 500 Ko, le problème n'est pas qu'il existe, c'est qu'il est trop gros. Optimisez la taille des données côté serveur (pagination, lazy loading des états non critiques), mais ne le supprimez pas pour Googlebot.

Comment vérifier que mon implémentation est conforme ?

Utilisez Google Search Console et l'outil d'inspection d'URL. Comparez le HTML brut (View Source) avec le HTML rendu (onglet "Rendered HTML"). Si le contenu textuel est identique dans les deux cas, votre hydratation fonctionne correctement — le JSON est transparent pour Google.

Testez également la vitesse de rendu avec Lighthouse. Un JSON très volumineux peut ralentir le Time to Interactive (TTI) et le Total Blocking Time (TBT), ce qui dégrade indirectement le SEO via les Core Web Vitals. Si vos scores chutent, réduisez la taille du JSON, mais ne le supprimez pas.

• Laisser le JSON d'hydratation visible pour tous les clients, bots inclus.
• Vérifier que le HTML initial contient tout le contenu sémantique essentiel.
• Ne pas créer de branche de code spécifique pour Googlebot.
• Optimiser la taille du JSON si elle dépasse 100-200 Ko (chunking, lazy loading).
• Tester le rendu avec l'outil d'inspection d'URL de Google Search Console.
• Surveiller les Core Web Vitals pour détecter un impact performance du JSON volumineux.