What does Google say about SEO? /

Official statement

When structured data appears in the raw HTML and is then modified by JavaScript transformations in the rendered DOM, this generates conflicting signals for search engines during rendering.
🎥 Source video

Extracted from a Google Search Central video

💬 EN 📅 15/04/2021 ✂ 22 statements
Watch on YouTube →
Other statements from this video 21
  1. Is it true that Google really indexes all JavaScript content, or do we still need traditional HTML?
  2. Why do JavaScript and meta robots tags create an indexing nightmare?
  3. What causes conflicts between your canonical tags in raw HTML and rendered output?
  4. Is it true that publishing more content leads to better rankings?
  5. Are your internal links secretly sabotaging your crawl budget?
  6. Should you really use rel='ugc' and rel='sponsored' if they don’t add any value to PageRank?
  7. Why is JSON-LD dominating all other structured data formats?
  8. Do rich snippets really enhance the adoption of structured data?
  9. Is HTTPS really essential for leveraging HTTP/2 and boosting performance?
  10. Is it true that mobile-first indexing is really completed and what risks do you still face?
  11. Why are Core Web Vitals a disaster on mobile despite the mobile-first approach?
  12. Does Google really index all client-side rendered content through JavaScript?
  13. Can JavaScript really change a noindex meta robots tag after the fact?
  14. What happens when conflicting canonical tags in raw and rendered HTML block your page indexing?
  15. Is it really necessary to produce more content to rank higher?
  16. Why does Google recommend using rel='ugc' and rel='sponsored' if they offer no direct benefits to publishers?
  17. How does JavaScript manipulation of your structured data impact your SERP visibility?
  18. Should you really remove aggregate ratings from your homepage?
  19. How does Google's visibility enhance the adoption of structured data?
  20. Why has HTTPS become essential for speeding up your web pages?
  21. Why has mobile-desktop parity become a critical issue for your organic visibility?
📅
Official statement from (5 years ago)
TL;DR

Google states that modifying structured data after the initial load via JavaScript generates conflicting signals during rendering. Specifically, if your rich snippets appear differently in the raw HTML and after JS execution, crawlers receive two inconsistent versions. The direct impact: a risk of rich results not displaying, or even penalties for structured spam if Google detects intentional manipulation.

What you need to understand

What is the difference between raw HTML and rendered DOM?<\/h3>

Raw HTML<\/strong> refers to the initial source code sent by the server — the one you see in 'View Page Source'. The rendered DOM<\/strong>, on the other hand, reflects the final state of the page after the complete JavaScript execution, dynamic transformations, and asynchronous loading.<\/p>

For structured data<\/strong>, this distinction is critical. If you inject a JSON-LD script using React, Next.js, or any client-side framework, the schema.org does not exist in the raw HTML — it only appears after rendering. Google must then perform two crawls: a quick one (raw HTML) and a complete render (resource-intensive).<\/p>

Why do 'conflicting' signals pose a problem?<\/h3>

Imagine a Product<\/strong> markup with a price of €99 in the initial HTML, then JavaScript replacing it with €79 in the DOM. Google sees two incompatible versions of the same object. Which is reliable? Which one to display in the rich snippets?<\/p>

Crawlers then apply a priority logic<\/strong>: generally, the raw HTML takes precedence for critical signals (indexing, ranking), while the rendered DOM is used to validate enriched results. But if the two diverge too much, Google may simply ignore the structured data — or worse, suspect a cloaking attempt.<\/p>

Under what circumstances does this JavaScript modification occur?<\/h3>

Modern frameworks (React, Vue, Angular, Next) often generate markup on the client side. You publish an article with a minimal schema.org Article, then JavaScript enriches the author<\/strong>, dateModified<\/strong>, aggregateRating<\/strong> fields after loading.<\/p>

Another common case is e-commerce sites that load prices, stock, or customer reviews via asynchronous API. The initial schema.org Product includes placeholders, which are dynamically replaced. For Google, it’s a mixed signal — even if the intention is not malicious.<\/p>

  • Raw HTML<\/strong> = data sent by the server before JS<\/li>
  • Rendered DOM<\/strong> = final state after complete JavaScript execution<\/li>
  • Mixed signals<\/strong> = inconsistency between the two versions for the same structured object<\/li>
  • Main risk<\/strong> = non-displaying of rich snippets or suspicion of cloaking<\/li>
  • Modern frameworks<\/strong> = the most common source of structured modifications post-loading<\/li><\/ul>

SEO Expert opinion

Is this statement consistent with real-world observations?<\/h3>

Yes, largely. For years, SEOs have observed that rich snippets disappear<\/strong> on full-JS sites without SSR (Server-Side Rendering). Google Search Console shows 'Structured data not found' errors when the schema.org is present… only in the rendered DOM.<\/p>

But here’s the catch: Google simultaneously claims 'we render JavaScript like Chrome'. So why this inconsistency? Because the crawl budget<\/strong> limits full rendering to a fraction of the pages. For millions of URLs, Googlebot first reads the raw HTML, queues the JS rendering, and makes immediate decisions on the first version. [To be confirmed]<\/strong>: Google has never released clear metrics on the time delay between raw crawl and rendering — observed gaps range from a few hours to several weeks.<\/p>

What nuances should be added to this rule?<\/h3>

First, not all types of modifications are equal. Dynamically adding a dateModified<\/strong> field does not create the same risk as reversing a price from €100 to €10. Google likely tolerates non-critical enrichments<\/strong> — but no official documentation defines this boundary.<\/p>

Next, SSR and hydration techniques (Next.js, Nuxt) solve the issue: the initial HTML already contains the complete structured data, and JavaScript merely activates interactivity. Technically, no mixed signal — the rendered DOM confirms the raw HTML instead of contradicting it.<\/p>

In what cases does this rule not apply?<\/h3>

On sites with a high crawl budget<\/strong> and a history of trust (major media, large e-commerce brands), Google likely renders JavaScript systematically. Mixed signals are then detected and resolved quickly — even if this is not an excuse to neglect the issue.<\/p>

Another exception: non-visual structured data<\/strong> added later (technical breadcrumbs, SameAs, Organization). Google may ignore them during the first crawl without impacting critical rich snippets (Product, Recipe, FAQ). But it’s a risky bet — better to serve everything server-side.<\/p>

Warning<\/strong>: If your JS transformations systematically modify fields displayed in the SERPs (price, reviews, availability), you’re playing with fire. Google may interpret this as unintentional cloaking and degrade your visibility on enriched results.<\/div>

Practical impact and recommendations

What concrete steps can be taken to avoid mixed signals?<\/h3>

The golden rule: serve your complete structured data in the initial HTML<\/strong>. If you’re using a traditional CMS (WordPress, Drupal), SEO plugins (Yoast, Rank Math, Schema Pro) already inject JSON-LD server-side — no issues.<\/p>

For modern sites (React, Next, Gatsby), enable SSR or static generation<\/strong> (SSG). Next.js allows you to inject schema.org in getServerSideProps or getStaticProps — the JSON-LD appears in the raw HTML before any client execution. Nuxt offers similar behavior with asyncData.<\/p>

What mistakes should be absolutely avoided?<\/h3>

Never load critical fields<\/strong> (price, rating, availability) via asynchronous fetch() after the first render. If your back-office API takes too long to respond, Googlebot crawls a page with incomplete data — guaranteed mixed signal.<\/p>

Avoid unnecessary DOM transformations. Some devs inject a minimal JSON-LD server-side, and then JavaScript 'completes' it for purely aesthetic reasons (date reformatting, translations). Result: two versions of the same schema for zero user benefit. Consolidate everything server-side.<\/p>

How can I check if my site is compliant?<\/h3>

Systematically test with Google’s Rich Results Test<\/strong> and the Coverage Report<\/strong> in Search Console. However, these tools render JavaScript — they don’t always show the raw HTML.<\/p>

More reliably: inspect the raw source code (Ctrl+U), copy it all, paste it into the schema.org validator. Then compare it with the rendered version (Inspect > Elements). If you see differences in fields displayed in the SERPs, correct them immediately.<\/p>

  • Enable SSR or static generation (SSG) on modern JavaScript frameworks<\/li>
  • Inject all structured data server-side, not via asynchronous client-side fetch()<\/li>
  • Test the raw HTML (Ctrl+U) and compare it to the rendered DOM (Inspect)<\/li>
  • Use Google’s Rich Results Test after every structured modification<\/li>
  • Monitor Search Console errors for structured data (the 'Enhancements' tab)<\/li>
  • Avoid cosmetic DOM transformations that modify schema.org without functional reason<\/li><\/ul>
    If your technical architecture heavily relies on client-side JavaScript and reworking into SSR exceeds your internal resources, the stakes can quickly become complex. Between crawl budget, delayed rendering, and downgrading risks on enriched results, an implementation error can cost dearly in visibility. In this context, engaging a specialized SEO agency in JavaScript SEO can secure your migration and ensure that your structured data reaches Google without mixed signals.<\/div>

❓ Frequently Asked Questions

Google privilégie-t-il toujours le HTML brut sur le DOM rendu pour les données structurées ?
Non, mais le HTML brut est crawlé en premier et déclenche l'indexation immédiate. Le DOM rendu sert surtout à valider les résultats enrichis, avec un délai variable selon le crawl budget. En cas de divergence, Google peut ignorer les deux versions.
Le SSR (Server-Side Rendering) résout-il complètement le problème des signaux mixtes ?
Oui, à condition que toutes les données structurées soient générées côté serveur et présentes dans le HTML initial. L'hydratation JavaScript côté client ne doit pas modifier le schema.org déjà envoyé.
Peut-on ajouter des champs schema.org non-critiques via JavaScript sans risque ?
Techniquement oui, mais c'est une zone grise. Google n'a jamais défini quels champs sont « critiques ». Mieux vaut tout servir côté serveur pour éviter toute ambiguïté lors du crawl.
Les frameworks comme Next.js ou Nuxt règlent-ils automatiquement ce problème ?
Pas automatiquement. Il faut configurer explicitement le SSR ou la génération statique et injecter le JSON-LD dans les props serveur (getServerSideProps, getStaticProps). Un Next en mode client-only reproduit exactement le même problème qu'un site React pur.
Comment savoir si Google a détecté des signaux mixtes sur mon site ?
Search Console affiche parfois des avertissements dans le rapport « Résultats enrichis », mais pas systématiquement. Le test le plus fiable reste la comparaison manuelle HTML brut vs DOM rendu, couplée à un monitoring des rich snippets dans les SERP.

🎥 From the same video 21

Other SEO insights extracted from this same Google Search Central video · published on 15/04/2021

🎥 Watch the full video on YouTube →

💬 Comments (0)

Be the first to comment.

2000 characters remaining
🔔

Get real-time analysis of the latest Google SEO declarations

Be the first to know every time a new official Google statement drops — with full expert analysis.

No spam. Unsubscribe in one click.