Can you really lose control of your canonical by leaving the href attribute empty at load time?

Why is an empty canonical tag problematic?

When the initial HTML contains <link rel="canonical" href="">, Googlebot interprets this tag before JavaScript even executes. An empty value in the href attribute is technically resolved as a reference to the page itself, which triggers auto-canonicalization.

The issue is that this self-reference is not always the developer's intention. If the script later fills this tag with a different URL — for example, to point to a consolidated version —, Google has already recorded the first value. The signal becomes contradictory, and the engine has to arbitrate between two directives.

How does Google handle JavaScript changes to the canonical tag?

Google executes JavaScript and can therefore see the final value after hydration. But timing is crucial: if the crawler indexes the page before the script completes execution, or if JavaScript rendering fails for any technical reason, it is the empty tag that prevails.

Martin Splitt reminds us that even in a well-optimized JavaScript environment, there’s a moment when the raw HTML is parsed. It is this initial HTML that anchors the first signals: hreflang, canonical, meta robots. Relying solely on JS to correct these critical elements introduces a structural risk.

What is the recommended alternative from Google?

Two options emerge. The first: set the canonical on the server, directly in the initial HTML, with the correct value. This is the most robust solution, which eliminates any ambiguity and ensures that all crawlers — including those that do not execute JavaScript — capture the correct signal.

The second option, for architectures where this is impossible: do not include the tag at all in the initial HTML, and create it entirely via JavaScript. No <link rel="canonical"> left empty, but a complete injection of the DOM element with all its attributes filled upon insertion. This avoids the intermediate phase where an incomplete tag exists in the DOM.

• Empty canonical tag in the HTML = risk of involuntary auto-canonicalization
• Google reads the initial HTML before the JavaScript and can log the empty value as a directive
• Solution 1: set the canonical on the server with the correct value at the initial render
• Solution 2: do not include the tag at all, then create it entirely via JavaScript if necessary
• Never leave a canonical tag with an empty href in production, even temporarily

Is this statement consistent with observed practices in the field?

Absolutely. We regularly see sites with a hybrid SPA or SSR architecture leaving empty meta, canonical, or hreflang tags in the HTML shell, then filling them via React, Vue, or Angular. The result? Unexplainable indexing fluctuations, randomly consolidated URLs, or worse: pages that self-canonicalize when they should point to a hub version.

What Splitt doesn’t explicitly state — but what every practitioner knows — is that not all crawlers are equal when it comes to JavaScript. Googlebot executes JS, certainly, but with a limited crawl budget and variable timeouts. Bing, Yandex, social media bots? Much less reliable. An empty canonical is a corrupted signal for a considerable portion of traffic and social signals.

What nuances should be added to this recommendation?

The recommendation is clear for traditional sites, but in Jamstack or client-side Next.js architectures, there’s a gray area. If the SSR is well configured, the canonical tag should never be empty in the HTML served to the bot. It’s a matter of framework-side configuration, not a technical limitation.

However, if you’ve inherited a legacy where redoing server-side templating costs three sprints, the solution of not injecting the tag at all and then creating it via JS remains a fragile compromise. [To be verified] on high-volume sites: does Googlebot systematically index after complete JS execution, or could there be cases where the crawler switches to a “light” mode and skips rendering? No public data confirms this guarantee 100%.

In what cases does this rule not fully apply?

If your page does not need a canonical — because it is unique, without variants, without pagination — then the absence of a tag is not an issue. Google defaults to considering a page without a canonical as self-canonical. No empty tag, no risk.

But as soon as you manage syndicated content, e-commerce filters, distinct AMP or mobile versions, or multilingual content, the canonical becomes a critical signal. In these contexts, leaving it empty even for 200 ms is like leaving a flashing red light: you introduce uncertainty into a system that needs clarity.

What should you do concretely if you have empty canonicals in production?

Start by auditing. Use "View Source" (Ctrl+U) on your strategic URLs, not the inspector. If you see <link rel="canonical" href=""> or <link rel="canonical"> without an attribute, it’s a bug that needs immediate correction. Then compare with the inspector after full loading: if the tag changes, you confirm that JS is involved.

Next, prioritize according to the architecture. If you control the server (PHP, Node, Python, etc.), generate the canonical directly in the server-side template. This is the cleanest and most sustainable solution. If you are in modern SSR (Next.js, Nuxt), ensure that getServerSideProps or the equivalent properly injects the tag with the correct value before sending the HTML to the bot.

What mistakes should you avoid when correcting this?

Do not replace an empty tag with a late JavaScript injection without testing the rendering timing. If your script loads in defer or async and Googlebot snapshots the page beforehand, you’ve gained nothing. Test with Search Console (URL inspection) or a tool like Screaming Frog in “render JavaScript” mode to verify that the canonical appears correctly in the final DOM viewed by Google.

Another pitfall: creating the tag via JS but forgetting to manage dynamic parameters (UTM, session ID, etc.). If your script injects the canonical with the current URL without cleaning it, you lose all the directive’s value. Ensure that the JavaScript or server logic normalizes the URL (removes unnecessary parameters, enforces HTTPS, consistent trailing slash).

How can I check that my site is compliant after correction?

Perform a complete crawl with Screaming Frog or Sitebulb in JavaScript rendering mode. Export the "Canonical Link Element 1" column and check that there are no empty rows, no involuntary self-references. Compare with a crawl without JS: if differences appear, it means you still depend on JavaScript for critical signals.

Also use Google Search Console: inspect 10-15 representative URLs (homepage, categories, products, articles). Look at the “Coverage” section > “Inspected URL” > “HTML retrieved.” If the canonical appears correctly filled, you’re good. If it’s absent or empty, the issue persists on the Googlebot rendered side.

• Audit the raw HTML (View Source) for detecting empty canonical tags
• Generate the canonical on the server or via SSR, never just client-side
• If JS injection is necessary: create the complete element, not an empty tag to fill
• Test Google's rendering with Search Console (URL inspection) and Screaming Frog (JS rendering)
• Ensure the canonical normalizes the URL (no irrelevant parameters, consistent protocol)
• Compare crawl with/without JS to identify critical dependencies on JavaScript