Le JSON-LD dynamique en JavaScript est-il vraiment crawlé par Google ?

Pourquoi cette question du JSON-LD dynamique revient-elle sans cesse ?

Le balisage structuré JSON-LD est devenu incontournable pour apparaître dans les rich snippets, les carousels produits ou les FAQ enrichies. Beaucoup de sites déploient ce balisage via JavaScript, souvent par commodité : tag managers, scripts marketing, frameworks React ou Vue qui génèrent le DOM côté client.

Le problème ? Google doit rendre la page pour voir ce balisage. Or le rendering coûte cher en ressources : Googlebot ne rend pas toutes les pages instantanément, et certaines peuvent attendre plusieurs jours avant d'être traitées par la file de rendu. Entre-temps, le balisage structuré n'existe tout simplement pas pour le moteur.

Que signifie exactement "Google doit rendre la page" ?

Googlebot fonctionne en deux phases : d'abord le crawl du HTML brut, puis — éventuellement — le rendering via un navigateur headless Chrome. Le JSON-LD présent directement dans le code source HTML est lu lors de la première phase. Le JSON-LD injecté par JavaScript n'est visible qu'après la seconde phase.

Cette distinction a des conséquences directes : une page qui change de balisage tous les jours via JS peut être crawlée avec un markup obsolète pendant des semaines. Si votre site a un crawl budget limité, ou si les URLs stratégiques sont rarement re-rendues, vous perdez l'opportunité d'apparaître en rich snippets.

Quel est le vrai risque avec robots.txt ?

Mueller insiste : le JavaScript ne doit pas être bloqué par robots.txt. Beaucoup de CMS bloquent encore /wp-includes/js/ ou /assets/ par réflexe, héritage d'anciennes pratiques. Si votre script JSON-LD est hébergé sur un chemin bloqué, Googlebot ne peut pas l'exécuter, même s'il veut rendre la page.

Pire : certains tags managers chargent le JSON-LD depuis des domaines tiers (GTM, Segment, etc.). Si ces ressources échouent ou sont bloquées, le balisage ne s'affiche jamais. Tester avec l'outil de test des résultats enrichis ne suffit pas : cet outil utilise un budget de rendu illimité, contrairement au Googlebot réel.

• Le JSON-LD dynamique fonctionne si Google rend effectivement votre page et que le JS n'est pas bloqué.
• Le rendering n'est pas instantané : un délai de plusieurs jours peut exister entre le crawl initial et le rendu final.
• Robots.txt reste un point de blocage critique : vérifiez que vos scripts et ressources JS sont autorisés.
• Les outils Google (Search Console, Test des résultats enrichis) ne reproduisent pas fidèlement le comportement réel du bot en conditions de crawl budget limité.
• Privilégiez le JSON-LD en dur dans le HTML pour les pages stratégiques à forte valeur SEO.

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

Oui, mais avec une nuance majeure : Google peut crawler du JSON-LD dynamique, mais il ne le fait pas toujours rapidement ni systématiquement. Sur des sites à crawl budget serré, on observe régulièrement des pages dont le rendu tarde plusieurs semaines. Les logs serveur montrent des crawls HTTP fréquents, mais les rendus Chrome restent espacés.

Concrètement, un site e-commerce avec 50 000 produits qui déploie ses prix et disponibilités via JS peut voir ses rich snippets disparaître ou afficher des données obsolètes. Google finit par rendre la page, mais entre-temps, la concurrence avec du JSON-LD en dur prend l'avantage dans les SERPs. [A vérifier] : aucune documentation officielle ne donne de SLA sur le délai entre crawl et rendering.

Quels cas d'usage posent vraiment problème ?

Le JSON-LD injecté après interaction utilisateur reste invisible pour Googlebot. Si votre script attend un clic, un scroll ou un événement onLoad tardif, le balisage peut ne jamais s'afficher lors du rendu. Les tests manuels passent, mais en production, rien ne remonte.

Autre piège fréquent : les Single Page Applications (SPA) React/Angular qui génèrent le DOM au runtime. Si le JSON-LD est injecté uniquement après un changement de route côté client, Googlebot peut manquer totalement le balisage. Les frameworks SSR (Next.js, Nuxt) contournent ce problème, mais restent sous-utilisés en production.

Faut-il vraiment se fier aux outils de test Google ?

Les outils comme l'outil de test des résultats enrichis ou la Search Console rendent les pages dans des conditions idéales : pas de limitation de ressources, timeout généreux, JS systématiquement exécuté. En production réelle, Googlebot opère avec un budget contraint.

On constate régulièrement des écarts entre ce que montre l'outil de test et ce qui est effectivement indexé. La meilleure validation reste l'inspection d'URL dans Search Console, couplée à une surveillance des logs crawl + rendering via un outil comme Oncrawl ou Botify. Si vos pages stratégiques ne sont jamais rendues, le JSON-LD dynamique est une impasse.

Que faut-il faire concrètement pour sécuriser son JSON-LD dynamique ?

Première étape : auditez votre robots.txt. Beaucoup de sites bloquent encore /js/, /scripts/ ou /assets/ par habitude. Utilisez l'outil de test robots.txt dans Search Console pour vérifier que vos fichiers JavaScript critiques sont accessibles. Si un script contenant du JSON-LD est bloqué, le balisage ne sera jamais lu, même si Googlebot rend la page.

Ensuite, vérifiez que votre JSON-LD s'injecte avant le DOMContentLoaded ou au plus tard dans les 5 premières secondes. Les scripts asynchrones ou différés qui chargent trop tard peuvent rater la fenêtre de rendu de Googlebot. Testez avec un throttling réseau lent (3G) pour simuler les conditions réelles du bot.

Comment s'assurer que Google rend effectivement vos pages ?

Installez un monitoring des rendus via vos logs serveur. Googlebot identifie ses rendus avec un user-agent Chrome spécifique. Si vos URLs stratégiques ne sont jamais rendues, ou seulement tous les 2 mois, le JSON-LD dynamique est un pari risqué.

Utilisez l'inspection d'URL dans Search Console sur vos pages clés : l'onglet "Version explorée" montre le HTML brut, l'onglet "Affichage de la page" montre le rendu final. Si votre JSON-LD n'apparaît que dans le second, vous dépendez du rendering. Comparez cette fréquence avec votre rythme de mise à jour : si vous changez vos prix toutes les 6 heures mais que Google rend la page tous les 15 jours, le décalage est critique.

Dans quels cas privilégier le JSON-LD statique ?

Pour toutes les pages stratégiques à fort trafic organique (fiches produits best-sellers, landing pages SEO, articles piliers), le JSON-LD en dur dans le HTML reste la solution la plus fiable. Le rendu différé introduit une latence et une incertitude inacceptables sur ces URLs.

Réservez le JSON-LD dynamique aux cas où vous n'avez pas le choix : sites entièrement clients-side, impossibilité technique de modifier les templates serveur, ou balisage généré par des outils tiers non intégrables côté backend. Même dans ces cas, envisagez le SSR ou le pre-rendering statique via des solutions comme Rendertron.

• Vérifier que robots.txt autorise tous les scripts contenant du JSON-LD
• Tester l'injection du balisage avec un throttling 3G pour simuler un crawl lent
• Monitorer les rendus Googlebot dans les logs serveur (user-agent Chrome)
• Comparer la fréquence de rendu avec le rythme de mise à jour de vos contenus
• Utiliser l'inspection d'URL Search Console pour valider le JSON-LD visible après rendu
• Privilégier le JSON-LD statique pour les pages à forte valeur SEO