Is dynamic JSON-LD in JavaScript really crawled by Google?

Why does the question of dynamic JSON-LD keep coming up?

Structured JSON-LD markup has become essential for appearing in rich snippets, product carousels, or enhanced FAQs. Many sites deploy this markup via JavaScript, often for convenience: tag managers, marketing scripts, or React or Vue frameworks that generate the DOM on the client side.

The problem? Google must render the page to see this markup. However, rendering is costly in resources: Googlebot does not render all pages instantly, and some may wait several days before being processed in the rendering queue. In the meantime, the structured markup simply does not exist for the engine.

What does it really mean when we say "Google must render the page"?

Googlebot operates in two phases: first, it crawls the raw HTML, then—if necessary—it renders using a headless Chrome browser. The JSON-LD directly present in the HTML source code is read during the first phase. The JSON-LD injected via JavaScript is only visible after the second phase.

This distinction has direct consequences: a page that changes its markup every day via JS can be crawled with outdated markup for weeks. If your site has a limited crawl budget, or if strategic URLs are rarely re-rendered, you lose the opportunity to appear in rich snippets.

What is the real risk with robots.txt?

Mueller emphasizes: JavaScript must not be blocked by robots.txt. Many CMS still block /wp-includes/js/ or /assets/ by reflex, a legacy of old practices. If your JSON-LD script is hosted on a blocked path, Googlebot cannot execute it, even if it wants to render the page.

Worse: some tag managers load JSON-LD from third-party domains (GTM, Segment, etc.). If these resources fail or are blocked, the markup never displays. Testing with the rich results test tool is not enough: this tool uses an unlimited rendering budget, unlike actual Googlebot.

• Dynamic JSON-LD works if Google actually renders your page and JS is not blocked.
• Rendering is not instantaneous: a delay of several days can exist between the initial crawl and the final rendering.
• Robots.txt remains a critical blocking point: check that your scripts and JS resources are allowed.
• Google tools (Search Console, Rich results test) do not accurately replicate the real bot's behavior under conditions of limited crawl budget.
• Prefer static JSON-LD in HTML for strategic pages with high SEO value.

Is this statement consistent with real-world observations?

Yes, but with a major nuance: Google can crawl dynamic JSON-LD, but it does not always do so quickly or systematically. On sites with tight crawl budgets, we regularly observe pages for which rendering takes several weeks. Server logs show frequent HTTP crawls, but Chrome renderings remain spaced out.

Specifically, an e-commerce site with 50,000 products that deploys its prices and availability via JS can see its rich snippets disappear or display outdated data. Google eventually renders the page, but in the meantime, competitors with static JSON-LD gain an advantage in the SERPs. [To be verified]: no official documentation provides a SLA on the delay between crawl and rendering.

What use cases really pose a problem?

JSON-LD injected after user interaction remains invisible to Googlebot. If your script waits for a click, scroll, or late onLoad event, the markup may never appear during rendering. Manual tests may pass, but in production, nothing shows up.

Another common pitfall: Single Page Applications (SPA) using React/Angular that generate the DOM at runtime. If the JSON-LD is injected only after a client-side route change, Googlebot can completely miss the markup. SSR frameworks (Next.js, Nuxt) bypass this issue but are still underused in production.

Should you really rely on Google's testing tools?

Tools like the rich results test tool or Search Console render pages under ideal conditions: no resource limitations, generous timeout, JS executed systematically. In actual production, Googlebot operates with a constrained budget.

Discrepancies between what the test tool shows and what is actually indexed are regularly observed. The best validation remains URL inspection in Search Console, coupled with monitoring crawl + rendering logs through a tool like Oncrawl or Botify. If your strategic pages are never rendered, dynamic JSON-LD is a dead end.

What concrete steps should be taken to secure dynamic JSON-LD?

First step: audit your robots.txt. Many sites still block /js/, /scripts/, or /assets/ out of habit. Use the robots.txt test tool in Search Console to verify that your critical JavaScript files are accessible. If a script containing JSON-LD is blocked, the markup will never be read, even if Googlebot renders the page.

Next, ensure that your JSON-LD is injected before DOMContentLoaded or at the latest, within the first 5 seconds. Asynchronous or deferred scripts that load too late may miss Googlebot's rendering window. Test with slow network throttling (3G) to simulate the bot's real conditions.

How can you ensure that Google is actually rendering your pages?

Set up render monitoring via your server logs. Googlebot identifies its renders with a specific Chrome user-agent. If your strategic URLs are never rendered, or only every 2 months, dynamic JSON-LD is a risky gamble.

Use URL inspection in Search Console on your key pages: the "Crawled version" tab shows the raw HTML, while the "Page view" tab shows the final rendering. If your JSON-LD appears only in the second, you depend on rendering. Compare this frequency with your update rhythm: if you change your prices every 6 hours but Google renders the page every 15 days, the gap is critical.

In what situations should you prefer static JSON-LD?

For all strategic pages with high organic traffic (best-selling product pages, SEO landing pages, pillar articles), static JSON-LD in HTML remains the most reliable solution. Deferred rendering introduces unacceptable latency and uncertainty on these URLs.

Reserve dynamic JSON-LD for cases where you have no choice: fully client-side sites, technical impossibility to modify server templates, or markup generated by third-party tools not integrable on the backend. Even in these cases, consider SSR or static pre-rendering through solutions like Rendertron.

• Check that robots.txt allows all scripts containing JSON-LD
• Test markup injection with a 3G throttling to simulate slow crawling
• Monitor Googlebot renders in server logs (Chrome user-agent)
• Compare rendering frequency with the update rhythm of your content
• Use Search Console URL inspection to validate visible JSON-LD after rendering
• Prefer static JSON-LD for high SEO value pages