Why might Google merge your JS pages if the meta tags are identical?

What does the term "non-rendered version" of a JavaScript page actually mean?

When Googlebot crawls a page, it first retrieves the raw HTML served by the server. This is the non-rendered version. If your site relies on JavaScript to generate the main content or meta tags, these elements do not exist at this stage.

Google will then attempt to render the page — that is, execute the JavaScript to see the final content. However, this rendering process takes time, consumes resources, and is not always done immediately. Sometimes, indexing is temporarily or permanently based on the initial HTML.

Why do identical meta tags cause page merging?

Google uses the meta tags (title, description, canonical, robots, etc.) as signals to understand the content and uniqueness of a page. If two URLs return exactly the same meta tags in the initial HTML, Google may consider this as duplicate or redundant content.

The engine will then look to merge these pages under a single canonical URL. This deduplication mechanism is meant to clean up the index. However, if your pages are indeed different but only differ due to JS, Google has no way of knowing this before rendering. And that's where the problem arises.

When does indexing occur without full rendering?

JavaScript rendering is resource-intensive for Google. The engine prioritizes sites based on their crawl budget, popularity, and technical complexity. If your site has speed issues, a poor crawl budget, or a very heavy JS architecture, rendering can be delayed by several days — or may never occur.

Moreover, some pages may be indexed quickly based on the initial HTML, especially if Google detects a high freshness rate (news, e-commerce). In this context, relying solely on JS to differentiate your pages is a risky bet.

• Unique meta tags from the initial HTML: don’t rely on JS to generate title, description, canonical
• Rendering is not instantaneous: Google may index before executing JavaScript
• Incorrect merging: two URLs with identical meta tags may be treated as duplicates even if the rendered content differs
• Limited crawl budget: JS-heavy sites consume more resources, potentially slowing or blocking rendering
• SSR or pre-rendering recommended: to ensure Google sees the correct content from the first crawl

Is this statement consistent with real-world observations?

Absolutely. There are regular instances where Google indexes the raw HTML before rendering JavaScript, especially on high-volume sites or Single Page Applications (SPAs). Martin Splitt confirms a well-documented phenomenon here: indexing can occur in two stages, with the first pass based solely on the initial HTML.

What's interesting is that Google explicitly acknowledges that this delay can cause incorrect merging. This validates the historical recommendations of experienced SEOs: never rely solely on JS to differentiate pages, especially for critical meta tags.

What nuances should be considered regarding this statement?

Google does not specify what criteria trigger immediate versus delayed rendering. We know that crawl budget, URL popularity, and loading speed play a role, but the exact thresholds remain opaque. [To be verified]: Google also does not indicate how much time can elapse between the initial crawl and full rendering — some tests show delays of several weeks for low-priority sites.

Another point: the statement mentions "incorrect merging" but does not say anything about the reversibility of this process. If Google mistakenly merges two pages, how long does it take to rectify this after adding unique meta tags? Real-world observations show that this can take weeks and may even require a forced re-indexing request.

In what cases does this rule not apply?

If you're using Server-Side Rendering (SSR) or static pre-rendering, the problem largely disappears. The initial HTML already contains the final content and meta tags, so Google doesn't need to execute JavaScript to understand the page. This is the recommended solution for high-stakes SEO sites.

Similarly, if you have very few pages and your crawl budget is generous, Google will likely have the time to render each page correctly. However, this is a risky bet: it’s better to secure from the outset with unique meta tags in the initial HTML.

What specific actions should be taken to avoid this issue?

The most robust solution is to implement Server-Side Rendering (SSR) or Static Site Generation (SSG). This ensures that the initial HTML already contains unique meta tags and complete content, without depending on client-side JavaScript. Frameworks like Next.js (React), Nuxt.js (Vue), or Angular Universal facilitate this transition.

If SSR is not feasible in the short term, opt for dynamic pre-rendering: a service like Prerender.io or Rendertron detects bots and serves them a pre-rendered HTML version. This is an effective intermediate solution, but ensure that it is not seen as cloaking — the content served to bots must be strictly identical to what users see.

What mistakes should be absolutely avoided?

Never generate the title, meta description, or canonical tags solely via client-side JavaScript. This is a classic SPA error: the initial HTML contains a generic title ("My App") and the real title only appears after executing the JS. Google may index with the generic title or even merge all your pages under the same URL if they share these identical tags.

Another common mistake: assuming that Google will render your JS quickly. Tests show that on low-priority sites, rendering can be delayed by several days. If you launch a new section of the site, it may remain invisible in the SERPs during this period. Always validate that the raw HTML contains the critical signals.

How can I check if my site is compliant?

Use the Inspect URL tool in Search Console and compare the "HTML" tab (raw version) with the "Rendered" tab (version after JS). If you see major differences in the meta tags or main content, that's a warning signal. Ideally, both versions should be almost identical.

Also test with curl from the command line to retrieve the raw HTML of your critical pages. If two URLs return the same title or meta description, you have a problem. Finally, monitor the index coverage reports: pages excluded for "Duplicate, user did not select a canonical page" may indicate an incorrect merge due to identical meta tags.

• Implement SSR or SSG on strategic pages (categories, product sheets, articles)
• Verify that title, meta description, and canonical are unique in the initial HTML
• Use the Inspect URL tool in Search Console to compare raw HTML and rendered content
• Test with curl or a simple scraper to validate server-side HTML
• Regularly audit coverage reports to detect incorrect merges
• Avoid generic titles or meta tags generated only on the client side