Are canonical tags and headers rendered in JavaScript truly ignored by Google?

Why is there a distinction between initial HTML and JavaScript rendering?

Google crawls and indexes pages in two distinct phases. The raw HTML is analyzed first, before any JavaScript processing. Canonical tags, Link headers with rel="canonical", and other critical directives must be included in this initial server response.

If your framework (React, Vue, Angular, Next.js) injects these elements later via JavaScript, Google may see them during deferred rendering, but will not apply them. The bot does not trust post-load modifications for canonicalization or redirection directives.

What elements are affected by this strict rule?

Canonical tags (<link rel="canonical">) and HTTP Link headers must be present in the initial server response. This also applies to redirection headers, hreflang directives, and potentially some cache or security headers.

Metadata added dynamically (title, meta description, Open Graph) may work in JavaScript for social display, but for strict SEO, it is better not to rely solely on deferred rendering. Google can index before complete rendering.

How can you verify what Google sees in raw HTML?

Use curl -I or wget --server-response to inspect the raw HTTP headers. For the initial HTML, disable JavaScript in Chrome DevTools (Cmd+Shift+P > Disable JavaScript) and reload the page.

If your canonicals disappear without JS, you have a problem. The URL inspection tool in Search Console displays both the raw HTML and the rendering, but does not always clearly show which element comes from which phase.

• Canonical tags must be present in the source HTML before any script
• HTTP Link headers (rel="canonical") must be included in the initial server response
• Any critical element for crawling or indexing must not depend on JavaScript for its existence
• Modern JavaScript frameworks require server-side rendering (SSR) or static pre-generation to ensure the presence of these elements
• Pure Single Page Applications (SPAs) are particularly vulnerable to this issue if they do not use SSR

Is this statement consistent with what we observe in the field?

Yes, and it serves as a welcome reminder. Too many sites are migrating to JavaScript-first architectures without understanding that Google does not trust rendering for critical directives. We regularly see poorly configured Next.js or Nuxt sites losing their canonicalization for weeks.

The problem is that Google does render JavaScript for other aspects (content, internal links), which creates a legitimate confusion. Developers believe that if Google sees the rendered content, it also sees the rendered canonicals. This is false.

What are the unclear gray areas?

Google does not specify the exact timing. If a canonical appears after 50ms of JS but before the renderer passes, is it taken into account? [To verify] on real cases. Official documentation remains vague on the timing between the initial crawl and rendering.

Another point: changes to canonicals during a session (SPA navigation). If a user navigates from page A to page B without reloading, and the canonical changes via JS, does Google ignore this change during a subsequent crawl of that URL? Probably, but no official data explicitly confirms this.

In what cases does this rule cause the most problems?

E-commerce sites with dynamic filters are trapped. If your facets generate parameterized URLs and the canonical only points to the version without filter through JavaScript, Google might index all the variants.

Multilingual sites using client-side routing (SPA) to change language without SSR will lose their hreflang if these are injected post-render. Result: inter-language cannibalization and poor geographic targeting in SERPs.

What should you do concretely to remain compliant?

First step: audit your tech stack. If you use React, Vue, or Angular, ensure that server-side rendering (SSR) or static generation (SSG) is enabled. Next.js with getServerSideProps or getStaticProps, Nuxt in universal mode, Angular Universal are your friends.

Second action: check that your canonical tags appear in the <head> of the raw source HTML. Test with curl, with JavaScript disabled, and via the URL inspection tool in Search Console. If they don’t appear in all three, you have an issue.

What errors should you absolutely avoid?

Never delegate the injection of canonicals to a JavaScript plugin or tag manager (GTM, Segment). These tools load too late in the page lifecycle. Google will have already read the raw HTML.

Avoid wobbly hybrid solutions where some pages use SSR and others pure CSR. This creates a processing inconsistency that complicates diagnosis and multiplies the risks of indexing errors.

How can you test that your implementation is working?

Use continuous monitoring of HTTP headers and raw HTML on your critical templates. A Lighthouse CI script or a Puppeteer test can automate the verification that the canonicals are present before any JS.

Systematically compare what you see in the browser (with JS) and what curl returns (without JS). If the difference is significant on critical SEO elements, correct it immediately server-side.

• Enable server-side rendering (SSR) or static generation (SSG) for all strategic templates
• Check that canonical tags appear in the raw HTML (curl test or JS disabled)
• Configure HTTP Link headers rel="canonical" directly at the server level for critical pages
• Audit your JavaScript frameworks: Next.js, Nuxt, Angular Universal must be correctly configured
• Test with the URL inspection tool in Search Console for the presence of canonicals before rendering
• Avoid injecting SEO directives via GTM, Segment, or any third-party tag manager