Should you serve meta tags server-side or accept that they might be changed by JavaScript?

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

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.

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 server-side and JS injects a second one, the browser keeps the first one (standard DOM behavior), but you create noise for Googlebot.

Also, avoid thinking that Dynamic Rendering is a sustainable solution. Google has explicitly labeled it a temporary workaround, not a target architecture. If you use it, start planning a migration to SSR or SSG now — it’s a technical debt that will eventually cost you in crawl budget and ranking.

• Audit your site with JavaScript disabled to identify missing or differing meta tags
• Compare raw HTML vs JS rendering with Screaming Frog in "Render JavaScript" mode
• Migrate to Next.js, Nuxt.js, or Angular Universal if you are using a modern SPA framework
• If migration is not possible in the short term, inject generic meta tags server-side as a fallback
• Test your Open Graph tags with the Facebook Debugger and Twitter Card Validator — they do not execute JS
• Document your architectural choices for dev and SEO teams — multi-team consistency is key