Should you avoid using the canonical tag on the server side if it’s incorrect at the first render?

Why could Google choose the wrong canonical?

The problem lies in Google's two-step rendering process. When the bot crawls a page, it first reads the raw HTML returned by the server. If a canonical tag points to URL A at this stage, Google records that information.

Later, during the JavaScript rendering, this tag may change to point to URL B. In rare cases, Google retains the first value — that from the server HTML — and ignores the client-side correction. The engine ends up with an incorrect canonical, which can lead to indexing or signal consolidation issues.

What does Martin Splitt mean by "prioritizing critical content"?

The idea is simple: visible and textual content should load before SEO metadata. If your JavaScript framework generates the canonical tag after several seconds, you create a window of opportunity where Googlebot may read an intermediate or absent value.

Splitt suggests not injecting a canonical on the server side if it risks being incorrect, even temporarily. It’s better to let Google determine the canonical itself than to provide erroneous information which will be corrected too late in the rendering cycle.

What scenarios trigger this confusion?

Observed cases mainly involve SPA (Single Page Applications) or headless CMSs that generate the DOM after hydration. For example: a React site that displays a default canonical in the static HTML, then dynamically replaces it based on the route or URL parameters.

Google does not specify how often these “rare” cases occur, making diagnosis difficult. The phenomenon is mostly observed on slow-rendering sites or with intermittent JavaScript errors that prevent the correction from executing properly.

• Server HTML takes precedence over client rendering in some undocumented cases.
• No canonical is better than an incorrect canonical on the server side.
• Textual content must load before metadata to avoid inconsistencies.
• SPA and headless sites are the most exposed to this risk of dual reading.
• Google does not quantify “rare” — difficult to assess the actual scale of the issue.

Is this statement consistent with field observations?

Yes, but with nuances. It is indeed observed that Googlebot may favor the initial HTML in certain scenarios, especially on sites with high rates of JavaScript errors or with a high Time to Interactive (TTI). Server logs sometimes show that Google indexes a URL while the final canonical points elsewhere.

However, stating that “in rare cases” it poses a problem is [To be verified] — no official metric quantifies this rarity. On poorly optimized sites for client-side rendering, this phenomenon can be frequent. Prudence is warranted even if Google downplays the impact.

Should we really omit the canonical on the server side?

Splitt suggests not including it if it risks being incorrect. In practice, it's a defensive piece of advice: if your architecture does not guarantee the correct value from the raw HTML, it’s better to leave it empty and only inject it on the client side, once the data is available.

But beware: omitting the canonical on the server side can slow down signal consolidation if Google has to wait until rendering to discover it. On sites with a high volume of pages or complex URL parameters, this is a risk. The choice depends on the ratio between the risk of error and the cost of rendering delay.

What nuances are missing from this statement?

Google does not specify how it arbitrates between server HTML and client rendering when they differ. Is there a timeout? A prioritization based on site type or allotted crawl budget? These details are lacking, complicating implementation.

Another point: [To be verified] Splitt says “prioritize critical content over metadata”, but no metric defines what is “critical”. Does an h1 suffice? Is 200 visible words necessary? The lack of a quantified threshold leaves practitioners in the dark.

What should you do concretely to avoid this problem?

The first rule: never inject a default or placeholder canonical in the server HTML. If your CMS or framework generates a tag with a temporary value (e.g., the root URL or a generic route), remove it from the server side and only add it on the client side, once the data is reliable.

The second point: favor Server-Side Rendering (SSR) or static generation for SEO high-stakes pages. A Next.js or Nuxt.js site configured in SSR returns complete HTML with the correct canonical from the server response, eliminating the risk of divergence. If the SPA is unavoidable, use pre-rendering for main landing pages.

How to verify that Googlebot reads the correct canonical?

Use the URL Inspection tool in Search Console: compare the raw HTML (tab “More Info” > “HTML source”) and the rendered HTML (tab