Le JSON sérialisé dans vos apps JavaScript compte-t-il comme du contenu dupliqué ?

Pourquoi cette question se pose-t-elle en premier lieu ?

Quand tu fais du Server-Side Rendering (SSR) avec un framework moderne, ton serveur génère une page HTML complète avec le contenu déjà rendu. Jusque-là, rien de sorcier.

Sauf que pour que ton app puisse reprendre la main côté client sans tout re-fetcher, tu sérialises l'état applicatif (les données ayant servi au rendu) dans une balise <script type="application/json">. Résultat : le même contenu apparaît deux fois dans le HTML source — une fois dans le DOM visible, une fois dans le JSON.

Et naturellement, les praticiens SEO se sont demandé si Google allait considérer ça comme du contenu dupliqué interne, avec toutes les conséquences que ça implique : dilution sémantique, cannibalisation potentielle, voire signal de spam dans les cas extrêmes.

Que dit exactement Google sur ce point ?

Martin Splitt coupe court : Google n'indexe que le DOM rendu, pas le JSON sérialisé. Même si techniquement le crawleur voit les deux, seul le contenu visible dans l'arbre DOM après parsing compte pour l'indexation.

Concrètement, si ton SSR injecte un bloc JSON de 50 Ko avec toutes tes props React, Google l'ignore totalement pour le classement sémantique. Il regarde ce qui s'affiche dans le navigateur après hydratation, point final.

C'est une clarification bienvenue parce que ça lève une incertitude qui poussait certains à bidouiller des solutions sous-optimales — genre charger l'état via un endpoint séparé, ce qui casse l'expérience utilisateur et rallonge le Time to Interactive.

Quelles implications techniques pour un site en production ?

Si tu bosses sur un site Next.js, Nuxt ou SvelteKit avec SSR, tu peux continuer à utiliser __NEXT_DATA__, __NUXT__ ou équivalent sans te poser de questions. Ces mécanismes sont conçus exactement pour ça : transférer l'état serveur au client.

Par contre, ça ne veut pas dire que tout est permis. Si ton JSON sérialisé contient des données sensibles (tokens, infos utilisateur privées), elles restent visibles dans le source HTML. C'est un problème de sécurité, pas de SEO, mais c'est bon à rappeler.

Autre nuance : Google ne voit pas le JSON pour l'indexation, mais il peut quand même le crawler et le stocker. Si tu balances 200 Ko de JSON sur chaque page, ça bouffe du crawl budget pour rien. Optimise la taille de ton payload même si ça n'impacte pas directement le ranking.

• Google indexe uniquement le DOM rendu, jamais le JSON sérialisé dans les balises script.
• Les frameworks modernes (Next, Nuxt, Gatsby, etc.) peuvent continuer à hydrater l'état sans crainte de duplication pénalisante.
• Attention aux données sensibles dans le JSON : elles restent exposées dans le HTML source.
• Un payload JSON surdimensionné peut impacter le crawl budget même s'il n'impacte pas l'indexation sémantique.
• Cette règle s'applique aux balises <script type="application/json"> ou similaires, pas aux scripts exécutables qui pourraient modifier le DOM.

Cette déclaration colle-t-elle avec ce qu'on observe sur le terrain ?

Honnêtement ? Oui, et c'est cohérent avec ce qu'on sait du rendering pipeline de Google depuis des années. Googlebot parse le HTML, construit le DOM, exécute le JS si nécessaire, et indexe le résultat final. Les balises script non exécutables (comme type="application/json") sont ignorées.

Ce qui est nouveau, c'est que Martin Splitt le formalise clairement. Avant, on devait déduire ce comportement à partir de tests empiriques et de bribes d'infos éparpillées. Maintenant, on a une position officielle — et ça change tout pour les projets en SPA/SSR qui hésitaient encore.

Par contre, j'ai vu des cas où des devs sérialisaient du JSON dans des balises visibles (genre un <div style="display:none"> avec du JSON dedans). Là, Google peut effectivement le voir comme du contenu caché, et ça peut poser problème. La clé, c'est que le JSON soit dans un contexte non-DOM (balise script).

Quelles limites faut-il garder à l'esprit ?

Déjà, cette règle ne s'applique qu'au contenu sérialisé dans des balises script. Si tu dupliques ton contenu ailleurs — genre dans des attributs data-* surdimensionnés, dans des commentaires HTML, ou dans des iframes cachées — c'est une autre histoire.

Ensuite, attention à ne pas confondre "pas un problème pour l'indexation" avec "sans impact sur les performances". Un JSON de 300 Ko ralentit le Time to First Byte, gonfle la taille de la page, et peut dégrader les Core Web Vitals. C'est pas pénalisé comme du duplicate content, mais ça peut te plomber sur d'autres critères.

Dernier point : Google dit qu'il n'indexe pas le JSON, mais qu'en est-il des autres moteurs ? Bing, Yandex, Baidu ont-ils la même logique ? [A vérifier] — on n'a pas de déclaration officielle équivalente chez eux. Si tu optimises pour un marché multilingue ou des moteurs alternatifs, garde une marge de prudence.

Y a-t-il des cas où cette règle ne tient plus ?

Oui. Si ton JSON sérialisé contient du contenu structuré différent de ce qui s'affiche dans le DOM, ça peut créer des incohérences. Par exemple, si ton JSON liste 50 produits mais que ton DOM n'en affiche que 10, Google va indexer les 10, pas les 50.

Autre cas limite : les sites qui utilisent du JSON-LD pour le balisage Schema.org. Là, c'est voulu — Google lit ce JSON pour extraire les données structurées. Mais si tu mélanges du JSON-LD valide avec du JSON applicatif sérialisé, assure-toi que les deux restent dans des balises séparées et correctement typées.

Que faut-il vérifier concrètement sur ton site ?

Première étape : ouvre le HTML source (Ctrl+U ou afficher le code source) de tes pages SSR et repère les balises <script> qui contiennent ton état sérialisé. Vérifie qu'elles ont bien un attribut type="application/json" ou équivalent — jamais type="text/javascript" si c'est juste du JSON passif.

Ensuite, utilise l'outil d'inspection d'URL de la Search Console et compare le DOM rendu (onglet "Plus d'infos" > "Page rendue") avec ton HTML source. Si tu vois des différences majeures entre les deux, c'est que ton hydratation modifie le contenu — et ça, c'est un problème potentiel.

Vérifie aussi la taille de ton payload JSON. Si une page pèse 150 Ko dont 100 Ko de JSON sérialisé, tu as un problème d'architecture. Optimise en ne sérialisant que les données strictement nécessaires à l'hydratation, pas l'intégralité de ton state Redux ou Vuex.

Quelles erreurs éviter absolument ?

Ne sérialise jamais ton JSON dans un élément DOM visible (même caché en CSS). Ça inclut les <div style="display:none">, les <template> mal utilisés, ou les attributs data-* surdimensionnés. Google peut interpréter ça comme du cloaking ou du contenu caché, avec les pénalités qui vont avec.

Évite aussi de sérialiser des données redondantes. Si ton JSON contient exactement le même texte que ton DOM, mot pour mot, tu gaspilles de la bande passante et du crawl budget. L'idée, c'est de sérialiser l'état applicatif (IDs, flags, petites props), pas de re-dupliquer tout le contenu textuel.

Dernier piège classique : les scripts inline mal encodés. Si ton JSON contient des caractères spéciaux (guillemets, chevrons, slashes) et que tu l'injectes sans échapper correctement, tu risques de casser le HTML ou d'ouvrir des failles XSS. Utilise les fonctions d'échappement de ton framework (serialize-javascript, JSON.stringify + escape, etc.).

Comment s'assurer que tout fonctionne correctement ?

Lance un audit avec Screaming Frog ou Sitebulb en mode JavaScript activé. Vérifie que le contenu indexable (titres, textes, structured data) est identique entre le HTML source et le DOM rendu. Si tu vois des différences, creuse : c'est soit un problème d'hydratation, soit un bug de SSR.

Utilise aussi Lighthouse ou WebPageTest pour mesurer l'impact du JSON sérialisé sur les performances. Si ton Time to Interactive explose à cause d'un payload JSON massif, il faut optimiser — soit en lazy-loadant certaines données, soit en déplaçant l'état côté serveur (sessions, cookies).

Enfin, teste avec des User-Agents variés. Google dit qu'il ignore le JSON, mais qu'en est-il de Googlebot-Mobile vs Desktop ? Des bots tiers ? Un test rapide avec curl -A "Googlebot" te montrera exactement ce que le crawleur reçoit.

• Vérifie que ton JSON sérialisé est dans des balises <script type="application/json">, jamais dans du DOM visible.
• Compare le HTML source et le DOM rendu dans la Search Console pour détecter les différences post-hydratation.
• Optimise la taille du JSON : sérialise uniquement l'état minimal nécessaire, pas l'intégralité du store applicatif.
• Échappe correctement les caractères spéciaux dans le JSON pour éviter les failles XSS et les erreurs de parsing.
• Audite les performances (Lighthouse, WebPageTest) pour t'assurer que le payload JSON n'explose pas le Time to Interactive.
• Teste avec différents User-Agents (Googlebot, Googlebot-Mobile, crawlers tiers) pour vérifier la cohérence du rendu.