L'état applicatif en JSON dans le DOM crée-t-il du contenu dupliqué ?

Qu'est-ce que l'hydratation et pourquoi génère-t-elle du JSON dans la page ?

Lorsqu'une application React, Vue ou Next.js effectue du server-side rendering, le serveur envoie un HTML complet au navigateur. Mais pour que l'interface devienne interactive, le framework JavaScript doit prendre le relais côté client.

Ce processus s'appelle l'hydratation. Pour éviter de refaire toutes les requêtes API, le serveur sérialise l'état de l'application dans un bloc <script type="application/json"> ou une variable globale. Le résultat ? Le même contenu apparaît deux fois : une fois rendu en HTML visible, une fois en JSON brut dans le code source.

Pourquoi cette duplication inquiétait certains praticiens SEO ?

La logique paraît sensée : si Google pénalise le contenu dupliqué entre pages différentes, pourquoi ne le ferait-il pas au sein d'une même page ? Certains ont craint que ces gros blobs JSON soient interprétés comme du bourrage de mots-clés ou du texte caché.

Cette crainte s'appuyait sur une compréhension partielle du fonctionnement de Googlebot. Le crawler exécute JavaScript, accède au DOM complet et pourrait techniquement détecter ces doublons structurels. Mais détecter ne signifie pas sanctionner.

Que dit précisément Martin Splitt sur ce sujet ?

La position de Google est sans équivoque : le moteur ne regarde que le DOM rendu. Les données JSON embarquées pour l'hydratation ne sont pas considérées comme du contenu indexable. Googlebot distingue le rendu visuel du code d'initialisation applicatif.

En pratique, cela signifie que vos blocs __NEXT_DATA__, vos window.__STATE__ ou vos balises <script type="application/json"> sont transparents pour l'indexation. Google se fiche de savoir si une donnée existe en mémoire ou dans un script — seul compte ce qui s'affiche dans l'arbre DOM accessible à l'utilisateur.

• Le server-side rendering avec hydratation est totalement safe pour le SEO
• Les frameworks modernes (Next.js, Nuxt, SvelteKit) ne créent pas de risque de duplication interne
• Google différencie clairement le contenu visible du code applicatif technique
• Cette clarification vaut pour tous les types d'état sérialisé : props, store Redux, contexte React, etc.
• Aucune optimisation particulière n'est nécessaire pour "masquer" ce JSON de Google

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

Absolument. Depuis des années, les sites utilisant Next.js ou Gatsby n'ont jamais reporté de pénalités liées à la présence de __NEXT_DATA__ ou équivalent. Si Google sanctionnait réellement cette pratique, les SPA en SSR auraient subi un handicap massif — ce qui n'est pas le cas.

Les tests pratiques confirment : deux versions d'une même page, l'une avec état JSON volumineux, l'autre sans, obtiennent des performances de ranking identiques à contenu HTML égal. Le classement dépend du DOM visible, pas de l'état applicatif sous-jacent.

Quelles nuances faut-il apporter à cette affirmation ?

Soyons honnêtes : cette clarification ne règle pas tous les problèmes SEO des applications JavaScript. Elle se limite strictement à la question de la duplication interne. Si votre contenu critique n'apparaît que côté client après l'hydratation, Google ne le verra pas — mais c'est un autre sujet.

Second point : la taille du payload JSON peut impacter les Core Web Vitals. Un blob de 500 Ko ralentit le parsing, augmente le Largest Contentful Paint et dégrade l'expérience utilisateur. Google ne vous pénalisera pas pour duplication, mais potentiellement pour performance médiocre.

Dans quels cas cette règle ne protège-t-elle pas complètement ?

Si votre framework génère un HTML minimal et charge tout le contenu via JavaScript après l'hydratation, vous sortez du cadre du SSR classique. Google crawl le DOM post-rendering, certes, mais avec des limitations de temps et de ressources. Un site qui prend 8 secondes à afficher son contenu risque une indexation partielle, JSON ou pas.

Autre cas limite : les sites qui sérialisent des données sensibles ou redondantes dans l'état JSON. Même si Google ignore ce contenu pour l'indexation, cela peut poser des problèmes de sécurité ou gonfler inutilement le poids de la page. La règle SEO est claire, mais la bonne pratique technique peut diverger.

Que faut-il faire concrètement sur votre stack technique ?

Rien de particulier si vous utilisez déjà du server-side rendering propre. Continuez à laisser vos frameworks générer leur état d'hydratation comme ils le font nativement. Inutile de chercher à masquer, minifier ou obfusquer le JSON embarqué pour des raisons SEO — c'est du temps perdu.

Concentrez-vous sur ce qui compte réellement : vérifiez que votre contenu critique apparaît dans le HTML initial envoyé par le serveur. Utilisez l'outil d'inspection d'URL de la Search Console ou un curl simple pour voir ce que Googlebot reçoit avant tout JavaScript.

Quelles erreurs éviter avec les frameworks modernes ?

Ne confondez pas SSR et client-side rendering. Si vous utilisez React en mode SPA pur (create-react-app sans SSR), votre contenu charge après hydratation — et là, Google peut avoir du mal à tout indexer. Le problème n'est pas le JSON, c'est l'absence de HTML initial.

Évitez aussi de gonfler artificiellement l'état applicatif avec des données inutiles. Même si Google s'en fiche, chaque Ko compte pour les performances. Un utilisateur sur mobile 3G paiera le prix d'un payload excessif, et indirectement, votre ranking via les Core Web Vitals.

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

Testez votre page avec JavaScript désactivé ou en mode curl. Le contenu essentiel doit être présent dans le HTML brut. Ensuite, vérifiez dans la Search Console que Google voit bien le DOM complet avec l'outil d'inspection d'URL.

Comparez le rendu HTML initial et le rendu après hydratation. Si le contenu change radicalement, c'est un signal d'alerte. L'hydratation doit rendre la page interactive, pas la remplir de contenu absent du HTML serveur. Un site bien architecturé montre le même texte avant et après JavaScript — seuls les événements et interactions s'ajoutent.

• Validez que le contenu prioritaire est présent dans le HTML source (view-source: ou curl)
• Testez avec l'outil d'inspection d'URL de la Search Console pour voir ce que Google indexe réellement
• Mesurez le poids de votre état JSON : au-delà de 100-150 Ko, questionnez sa nécessité
• Comparez le rendu désactivant JavaScript vs avec : le delta doit être minimal sur le contenu éditorial
• Surveillez vos Core Web Vitals, notamment le LCP et le TBT qui peuvent souffrir d'un payload excessif
• Documentez votre architecture SSR pour éviter les régressions lors de refactoring