Official statement
Other statements from this video 1 ▾
Google processes JSON-LD whether it's inserted in the <head> or the <body> of the page. This technical flexibility allows the implementation to adapt to each CMS or framework's constraints. However, some validation tools and server configurations might interpret these two locations differently — the devil is in the details of execution.
What you need to understand
Why was this clarification from Mueller necessary?
For years, the official documentation from Schema.org and Google's guidelines recommended inserting JSON-LD in the of the page. This habit created a persistent confusion: many SEOs thought that placing JSON-LD elsewhere would invalidate its processing by Googlebot.
The technical reality is more flexible. The Google parser scans the entire rendered DOM — whether it’s in the
or the . As long as the JSON-LD is syntactically valid and accessible at crawl time, Google utilizes it regardless of the positioning.In what cases do we favor one location over the other?
Inserting in the remains the dominant practice for consistency: metadata (title, meta description, Open Graph) is already found there. Grouping structured data in one place facilitates auditing and code maintenance.
On the contrary, some CMS or JavaScript frameworks dynamically inject content into the
— think of React, Vue, or Angular pages generating the DOM on the client side. In these architectures, placing JSON-LD in the may turn out to be simpler to implement, or even unavoidable if the is locked by a global template.Does Google treat these two locations with the same priority?
Officially, yes. Googlebot parses the complete DOM once the JavaScript is executed (on pages that contain it). The positioning of JSON-LD does not affect its reading, as long as the script is present in the final rendered HTML.
However, caution: if JSON-LD is injected late by an asynchronous script or if the server returns an incomplete DOM during the crawl, Google may not see it — but this problem affects both the
and the . The real risk lies in rendering latency, not in the location.- Confirmed flexibility: Google processes JSON-LD whether it’s in the or
- Editorial consistency: grouping metadata in the simplifies auditing
- Technical constraints: some frameworks require injection into the
- Third-party validation: external tools may require the — to be tested on a case-by-case basis
- Critical rendering: JSON-LD must be present in the final DOM, regardless of its position
SEO Expert opinion
Is this statement consistent with real-world observations?
Yes, massively. Tests conducted on thousands of pages show that Google extracts and indexes JSON-LD placed in the with no observable difference compared to placement in the
. Rich results (FAQ, Product, Article, etc.) normally appear in SERPs in both configurations.That said, some validation tools — including WordPress plugins or third-party validators — generate warnings if JSON-LD is found outside the
. These alerts are often false positives that reflect a rigid interpretation of old specifications, not a real Google compliance issue.What nuances should be added to this stated flexibility?
Mueller talks about Google's processing, not the crawl performance or timing of execution. If your JSON-LD is injected at the end of the
via a defer or async script that triggers after 3 seconds, Googlebot might crawl the page before the DOM is complete.The crawl budget and rendering latency then become decisive. On sites with a high volume of pages or with long loading times, JSON-LD placed too low in the
risks never being seen during certain quick crawls. [To be checked] with Google Search Console: monitor structured data errors, as they often reveal this type of problem.In what cases might this rule not apply?
Some proprietary CMS or certain server cache configurations (Varnish, Cloudflare, etc.) might serve partial HTML to bots if the DOM is not fully rendered server-side. In these architectures, placing JSON-LD in the
offers an extra guarantee: it will be present in the very first HTML response, before any JavaScript execution.Similarly, if you need to comply with regulatory constraints or third-party audits (some e-commerce certifications require strict placement), it's better to stick with the
to avoid unnecessary debates with meticulous auditors.Practical impact and recommendations
What should you do on an existing site?
If your JSON-LD is already in the and functioning correctly (no errors in Search Console, rich results in SERPs), don’t change anything. Migrating to the
will bring no measurable SEO gain — it’s wasted time.On the other hand, if your CMS or framework forces you to place JSON-LD in the
, go ahead without guilt. Just check that the script is indeed present in the source HTML (View Page Source, not the DOM inspector showing the final render) and that Google detects it via the rich results testing tool.What mistakes should you avoid during implementation?
Never inject JSON-LD via an async or defer script that triggers after a user event (scroll, click, consent). Googlebot does not simulate these interactions — it crawls the DOM as it is rendered at the initial page load.
Another trap: duplicating JSON-LD in both the
AND . This can create structured data duplicates that Google interprets as contradictory, leading to errors in Search Console or the disabling of rich results. One location is sufficient.How can you verify that the implementation is correct?
First, use Google's rich results testing tool by pasting your page URL. If the tool detects and validates your JSON-LD, you’re good — regardless of whether it’s in the
or .Next, monitor the Enhancements section of Google Search Console for 2-3 weeks. If no structured data errors appear and your eligible pages receive their rich snippets in SERPs, the implementation is working. In case of doubt, test with the URL inspection tool to see exactly what Googlebot crawled.
- Verify that JSON-LD is present in the source HTML (View Page Source), not just in the rendered DOM
- Test each type of page (article, product, FAQ) with Google’s Rich Results Test
- Monitor structured data errors in Search Console for 3 weeks after deployment
- Avoid asynchronous or conditional injections (after cookie consent, scroll, etc.)
- Never duplicate JSON-LD in and simultaneously
- Document the chosen location in your technical guide to avoid regressions during updates
❓ Frequently Asked Questions
Google traite-t-il différemment le JSON-LD placé en fin de <body> ?
Peut-on placer plusieurs blocs JSON-LD dans la même page, certains dans <head> et d'autres dans <body> ?
Les outils de validation tiers (Schema.org Validator, autres) acceptent-ils le JSON-LD dans le <body> ?
Le placement dans <head> ou <body> affecte-t-il la vitesse d'indexation des données structurées ?
Faut-il migrer un JSON-LD déjà fonctionnel du <head> vers le <body> ?
🎥 From the same video 1
Other SEO insights extracted from this same Google Search Central video · duration 1 min · published on 11/09/2019
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.