Canonical Only in the Rendered DOM: Why to Move It to the HTML
- April 2, 2022
- Indexation, Canonical Issues
The short version
This flags when the raw HTML Google downloads has no rel="canonical", and the tag only appears after JavaScript runs and builds the rendered DOM. Google can process JS-injected canonicals, but it does so in a later, slower, best-effort pass — so a canonical that exists only after render is a canonical that might be missed, delayed, or overridden in the meantime.
The two-wave problem
Google crawls in roughly two phases. The first wave parses the raw HTML response the instant it arrives — the exact bytes you'd see with curl, before a single line of JavaScript executes. The second wave, rendering, happens later when resources free up, and only then does client-side JS get a chance to inject or rewrite the canonical. If your canonical lives only in that second wave, it's absent for the entire window between fetch and render.
During that gap Google may make an indexing or canonicalization decision on a page it believes has no canonical — falling back to its own selection, exactly as if the tag were missing. When the rendered canonical finally lands it can reconcile, but you've introduced a race condition into something that should be deterministic. Other engines and AI crawlers are stricter still: many read raw HTML only and never see a rendered-DOM canonical at all.
Why it matters
A canonical that depends on rendering is fragile in ways an HTML-head canonical never is. If the JS fails to execute — a script error, a blocked bundle, a timeout, a disallowed JS file in robots.txt — the canonical simply never appears, and the page is canonicalized by guesswork. Even when rendering succeeds, the delay means duplicate URLs can get indexed in the interim and the wrong version can win the first round. Crawlers that don't render JavaScript (a large share of non-Google bots and LLM fetchers) treat the page as having no canonical, full stop. You've made a critical indexing signal contingent on a fragile, deferred process for zero benefit.
Raw vs. rendered: seeing the gap
The whole diagnosis is one comparison. The raw response is empty of canonical:
$ curl -s -A 'Mozilla/5.0' https://example.com/page/ | grep -i canonical
# (no output — nothing in the raw HTML)But the rendered DOM, after JS runs, has one:
<!-- present only after a script executes, e.g. -->
<script>
var l = document.createElement('link');
l.rel = 'canonical';
l.href = 'https://example.com/page/';
document.head.appendChild(l);
</script>
<!-- resulting rendered DOM: -->
<link rel="canonical" href="https://example.com/page/">The fix is to move the declaration into the raw HTML head so it's present in the first byte of the response, no rendering required:
<!-- server-rendered, in the initial HTML <head> -->
<head>
<link rel="canonical" href="https://example.com/page/" />
</head>Where the canonical lives vs. how reliable it is
| Delivery method | In raw HTML? | Seen by non-rendering bots? | Reliability |
|---|---|---|---|
| Server-rendered head tag | Yes | Yes | Highest — deterministic, first wave |
HTTP Link: header | Yes (in headers) | Yes | High — but avoid pairing with a conflicting tag |
| SSR/prerendered then hydrated | Yes, if SSR emits it | Yes | High — verify SSR output, not just the client |
| JS-injected (this check) | No | No | Low — deferred, race-prone, invisible to many bots |
How to detect it
- curl vs. View Rendered Source. The definitive test:
curl -s -A 'Mozilla/5.0' URL | grep -i canonicalfor the raw HTML, then load the URL through a "View Rendered Source" extension or DevTools and check the rendered DOM. Canonical absent in one and present in the other = this exact flag. - GSC URL Inspection → View Crawled Page + rendered HTML. Inspect the live URL, open the rendered HTML, and see whether Google's render picked up the canonical. Compare against the crawled raw response; if the canonical only shows in the rendered version, confirmed.
- Screaming Frog with JS rendering toggled. Crawl once in text-only mode and once with JavaScript rendering enabled. A canonical that appears only in the rendered crawl — and is blank in the raw crawl — is the fingerprint. Frog surfaces this under its JavaScript issue group.
- Disable JavaScript and reload. Turn JS off in the browser, load the page, and view source. If the canonical vanishes, it was never in the HTML to begin with.
How to fix it
- Emit the canonical server-side so it's in the initial HTML response's
<head>before any JS runs. This is the whole fix — everything else is verification. - If you're on a JS framework, move the canonical into the SSR/SSG output (the framework's head manager) rather than injecting it client-side after mount.
- As an alternative, set the canonical via the HTTP
Link:response header at the server or CDN — just don't also emit a conflicting head tag. - Remove the client-side injection script so you don't end up with two sources fighting each other.
- Re-crawl in text-only mode and confirm the canonical is now present in the raw HTML, then re-inspect in GSC to confirm the crawled (not just rendered) page carries it.
FAQ
Google renders JavaScript now — so does this even matter?
It does, because rendering is deferred and best-effort, not guaranteed or immediate. A raw-HTML canonical is processed in the first crawl wave with zero dependencies; a JS canonical waits for the render queue and can be skipped if a script fails. You're trading a deterministic signal for a probabilistic one, and getting nothing in return.
What if my whole site is a JavaScript SPA?
Then render the canonical server-side through SSR or static generation so it's baked into the HTML you serve, not appended after hydration. Modern frameworks all have a head-management path that runs during SSR — use it. Client-side injection after mount is the pattern this check exists to catch. See the JavaScript SEO rendering guide for the full picture.
Will non-Google crawlers see my rendered-DOM canonical?
Usually not. Bing renders selectively, and most SEO tools, social scrapers, and AI/LLM fetchers read raw HTML only. A canonical that exists solely in the rendered DOM is invisible to that entire population, which increasingly matters as AI crawlers grow.
My JS injects the canonical reliably in testing. Isn't that good enough?
Reliable in your browser isn't the same as reliable in Google's render queue under load, or in a bot that doesn't run JS at all. "Works when everything goes right" is a weak guarantee for a signal that decides which URL gets indexed. Put it in the HTML and remove the variable.
Is a rendered-DOM canonical better than no canonical?
Marginally, for Google specifically, since it does render. But it's strictly worse than an HTML-head canonical and it hides the fragility behind "it worked in the render." The correct state isn't "rendered canonical" — it's "canonical in the raw HTML." Aim there.
Related reading
See the canonical tag glossary and Canonical Tags reference for placement rules. Rendering is the core issue here, so pair with the JavaScript SEO rendering guide and, if a blocked bundle is the cause, the disallowed JavaScript file check. If you'd rather serve it via headers, read why the rel="canonical" HTTP header is faster.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
