Official statement
It is recommended to always render meta tags consistently before JavaScript intervention, or at minimum to omit them if the server version and the JavaScript-rendered version cannot be consistent.
15:27
Other statements from this video 11 ▾
- 1:01 Faut-il vraiment contacter l'équipe AdSense pour résoudre vos problèmes de performance PageSpeed ?
- 1:01 Faut-il vraiment retarder le JavaScript AdSense pour booster votre SEO ?
- 2:35 Pourquoi Google refuse-t-il de communiquer les dimensions du viewport de Googlebot ?
- 3:07 Comment Googlebot gère-t-il réellement le contenu en bas de page ?
- 3:38 Faut-il abandonner l'infinite scroll pour être correctement indexé par Google ?
- 4:08 L'Intersection Observer est-il vraiment crawlé par Googlebot ?
- 6:24 Pourquoi Googlebot utilise-t-il un viewport de 10 000 pixels ?
- 9:23 Pourquoi Google refuse-t-il d'indexer le contenu qui dépend du viewport ?
- 10:11 Pourquoi Google fixe-t-il la largeur du viewport de son crawler à 1024 pixels ?
- 12:38 Les meta tags no-archive en JavaScript fonctionnent-ils vraiment ?
- 14:24 Google analyse-t-il vraiment les meta tags avant ET après le rendu JavaScript ?
Official statement from
(5 years ago)
⚠ A more recent statement exists on this topic
Does Google really render every HTML page even if most don't need JavaScript?
View statement →
TL;DR
Google recommends serving consistent meta tags before JavaScript executes, or omitting them entirely if you cannot guarantee that consistency between the two versions. In simple terms: if your SPA or JS framework modifies the title, description, or canonical tags after the initial render, you create friction for Googlebot. The safest alternative remains Server-Side Rendering or server-side hydration, not client-side hacks.
What you need to understand
Why does Google emphasize the consistency of meta tags before JavaScript?
Googlebot crawls your page in two phases: first the raw HTML returned by the server, then — after adding the page to a rendering queue — it executes JavaScript and retrieves the final DOM. This two-phase architecture creates a time delay that can reach several seconds, or even minutes in some cases.
If your meta tags (title, description, canonical, robots) change between these two passes, Google has to decide which version to index. Martin Splitt does not specify which signal takes precedence, and that’s precisely where the issue lies: you introduce uncertainty that you cannot control.
Which meta tags are affected by this recommendation?
All of those that influence indexing and display in the SERPs: title tag, meta description, meta robots (noindex, nofollow), canonical, hreflang, Open Graph, and Twitter Cards if you target social sharing. Conversely, purely technical tags like viewport or charset pose no issue if they are injected by JS — Google doesn’t care.
The real concern involves the React, Vue, Angular, Svelte frameworks that build the interface client-side and modify the
afterward. If you use libraries like react-helmet or vue-meta without SSR, you fall squarely within the scope targeted by this statement.What happens if the meta tags differ between the initial HTML and the JS version?
Google has to make a decision. In some observed cases, it’s the server version that gets indexed; in others, the JS version prevails. No official documentation clarifies this — it’s opaque, and opacity in SEO is pure risk.
Another problem: third-party crawlers (Facebook, LinkedIn, Twitter, Pinterest) generally do not execute JavaScript. If your Open Graph tags are only present after the JS is rendered, your social snippets will be empty or broken. Google is not the only player to consider.
- Googlebot crawls in two distinct phases, with potentially long delays between raw HTML and JS rendering
- Critical meta tags (title, description, canonical, robots, hreflang) must be identical in both versions — or absent from the initial HTML
- Social crawlers (Facebook, LinkedIn, Twitter) do not execute JavaScript: your Open Graph tags must be server-side
- Completely omitting a meta tag server-side is preferable to serving a different value that will be overwritten by JS
- Modern SPA frameworks (React, Vue, Angular) create this problem by default without SSR or pre-rendering enabled
SEO Expert opinion
Is this recommendation consistent with field observations?
Yes, but with a major nuance: Google has been able to crawl and index full-JS SPAs for years. Thousands of React or Vue sites without SSR rank properly. So why this statement now?
Because Google’s ability to handle JavaScript does not mean it is optimal. JS rendering consumes crawl budget, introduces latency, and increases the risk of errors — timeouts, malformed JS, blocked resources. Splitt pushes for architectural recommendations, not an absolute technical rule.
What gray areas remain in this statement?
Splitt does not say which signal prevails when the two versions diverge. He also does not clarify whether Google retains both versions or merges signals. [To verify]: no official data documents this arbitration behavior — we are navigating without clear visibility.
Another unclear point: what do we mean by "consistent"? Is a title tag of 55 characters server-side and 58 characters after JS inconsistent? What about an identical meta description but reformatted with different spaces? Google does not set a tolerance threshold, leaving room for interpretation.
In what cases can this rule be circumvented without risk?
If you have implemented Dynamic Rendering (serving a pre-rendered version to Googlebot and the JS version to users), you can technically ignore this recommendation for humans. But caution: Google has officially discouraged this practice as a permanent workaround.
Another exception: meta tags not critical for indexing (Open Graph, Twitter Cards) can be injected by JS if you do not care about social sharing or use a third-party pre-rendering service for social crawlers. But frankly, it’s better to standardize everything server-side and avoid unnecessary complexity.
Note: If you are working on an e-commerce site with thousands of client-generated product pages, this recommendation becomes critical. A title/canonical inconsistency between initial HTML and JS can fragment your indexing and dilute your ranking. Don’t take that risk on strategic pages.
Practical impact and recommendations
How can you check that your meta tags are consistent between server HTML and the JS version?
The first step: disable JavaScript in Chrome DevTools (Settings → Debugger → Disable JavaScript) and reload your page. Inspect the
: if your critical meta tags are missing or differ from the enabled JS version, you have an issue.The second approach: use curl or Screaming Frog in "Render JavaScript" mode to compare the two versions. Screaming Frog shows you the raw HTML and the rendered DOM side by side — it’s a huge time saver for large site audits.
What technical solutions can ensure this consistency?
The reference solution is Server-Side Rendering (SSR): Next.js for React, Nuxt.js for Vue, Angular Universal for Angular. These frameworks generate the final HTML server-side with all the meta tags in place before sending it to the client. Google receives the complete version directly.
Credible alternative: Static Site Generation (SSG) with pre-rendering at build time (Gatsby, Astro, Eleventy). Each page is compiled into static HTML with fixed meta tags. No JS is needed for indexing, but it’s less flexible for dynamic content.
Last recourse if you remain in a full-client SPA: inject generic meta tags server-side (title and fallback description) and let JS refine later. Google will index the server version, which is suboptimal but avoids inconsistency. That said, why complicate your life?
What mistakes should you absolutely avoid in implementation?
Never serve an empty title server-side thinking that JS will fill it in time — Google might index the empty version. Do not duplicate tags either: if you have a