Quick reminder: what is canonical and why does it exist?

Canonicalization is the process by which Google selects the most representative URL for content when multiple similar or identical versions of a page exist. A canonical URL is this "representative" version that Google prefers to show in search results. 

In e-commerce, duplicate URLs are commonplace as stores generate variants and combinations:

• filtering and sorting (URL parameters),
• pagination,
• product variants (color/size),
• campaign parameters (UTM),
• language versions,
• different paths to the same content (category → product vs search engine → product).

When canonical is set incorrectly, the consequences can be painful:

• Google is indexing the wrong addresses (mess in the index),
• signals (links, authority, behavioral data) are distributed across multiple URLs,
• you're wasting your crawl budget on duplicates,
• the visibility of key categories and products decreases.

 What exactly did Google say about the canonical being set in JS?

The message is simple:

• It is best to set canonical in HTML (in "
• If you can't , you can set the canonical via JavaScript — but do so so that the canonical is consistent and unambiguous.
• Canonicalization happens before and after rendering , so having the canonical "in source" and "after render" cross over is asking for problems.

Google also emphasizes a very practical rule: if the canonical is already in the HTML, JS shouldn't change it to a different address. And if it's impossible to insert the canonical into the HTML, it's better not to include it at all and add it via JS (correctly, in " ).

Why is "canonical set after render" risky?

Because Google doesn't always see your website the same way a user sees it in a browser. In simple terms, there are two "moments":

• HTML before rendering (what the server returns immediately),
• HTML after rendering (what is created after JavaScript is executed).

If canonical appears only after render, then:

• you increase your dependency on Google rendering JS correctly,
• you create space for crossovers (different canonical in the source, different after render),
• it is easier to make mistakes in frameworks (e.g. duplicated "<link rel=”canonical”> ” or inserting it in the wrong place).

Google explicitly reminds that canonical is accepted when it is in " , and with JS you need to "inject" it correctly.

When does canonical make sense in JS in practice?

There are situations where this can be a reasonable compromise:

• SPA application rendered on the client side, where generating " on the server is difficult,
• legacy CMS/platform where you don't have full control over the template " ,
• dynamic views, where the canonical depends on the application state (though special care is needed here).

In online stores (especially headless frameworks), the canonical is sometimes set by libraries like Head Manager (e.g., React Helmet, Next.js Head). This works, but only if a single , consistent canonical remains after rendering and there are no conflicting signals.

The most important rule: canonical consistency "before" and "after" render

If you remember one thing from this article, let it be this:

Don't create a situation where the canonical in HTML points to A and the canonical after rendering points to B.

Google itself points out that canonicalization takes place at different stages, so "mixed signals" reduce unambiguity and increase the risk of the algorithm choosing a different version. 

In e-commerce, such a crossover often happens through:

• filters and sorting generating different URLs,
• automatic parameter binding in JS,
• routing errors (e.g. slash / no slash),
• differences in canonical addresses between mobile and desktop versions.

Step by step: how to implement canonical settable in JS without mins

Step 1: Decide what will be canonical (business logic)

First, establish the rules. Examples in a store:

• the product has a canonical to the "clean" URL without campaign parameters,
• the category has a canonical to unsorted version,
• filter pages: either canonical to the base category, or (if filters make SEO sense) canonical to a specific combination — but then there must be an indexing strategy.

Step 2: make sure there is one canonical after render

Not two, not three. One. In " . Google reminds you to insert canonical correctly and in the appropriate section of the document.

Step 3: If you can't insert the canonical into HTML, don't insert it at all

This is an important nuance from Google's clarification: it's better to have no canonical in the source than to have a different one than the one you set later in JS. 

Step 4: Test in Google Search Console

Google recommends testing your rendering and canonical using tools like Search Console to ensure Google sees what you're trying to achieve. URL Inspection is helpful when it comes to canonicalization, as it shows, among other things, the canonical you've specified and the canonical Google has chosen. 

Step 5: Monitor "Google chose a different canonical" crossovers

If Google often chooses a different canonical than you set, it is a signal that:

• the content is not similar enough (the algorithm considers it not a duplicate),
• signals are contradictory (internal linking, redirects, sitemaps),
• canonical indicates a URL of lower quality (e.g. with errors, no content, with different parameters).

Google describes that even if you specify canonical, the algorithm may choose a different version for various reasons, and it is worth checking whether Google's choice makes sense from a functional perspective. 

Common e-commerce mistakes that break canonical (especially with JS)

Duplicate canonical

The framework injects the canonical, and the store platform adds the second one in the template. After rendering, you have two different "<link rel=”canonical”> ”. Effect: the signal becomes unreadable.

Canonical set outside<head>

Google repeatedly emphasizes that the canonical should be in " . If it ends up in " , it is sometimes ignored.

Canonical points to URL with parameters

Most often, canonical should point to the "clean" version. If canonical points to a URL with UTM, sorting, or filtering, you quickly create a maze.

Canonical depends on the application state

The user clicked a filter, and JS changed the canonical. As a result, the robot might see different versions in different render passes. This is difficult to control, and the risk of indexing chaos increases.

What does this change in practice for online stores?

If you run an e-commerce business, Google refinement has two real effects:

• Less fear in headless/SPA projects - canonical in JS can work when implemented consistently.
• More responsibility on the implementation side - because the "best practice" is still canonical in HTML, and JS is a fallback variant.

In stores that have many URL combinations (filters, parameters, variants), canonicalization is one of the main tools for organizing the index. A well-configured canonicalization supports category and product visibility, while an incorrectly set one can hinder growth.

Checklist: What to check in your store today 

• Open the product card and check the page source to see if the canonical is in " .
• Check if there is still only one canonical after render (e.g. in dev tools).
• Go to the URL with parameters (UTM / sorting) and see if the canonical links to the base version.
• In Search Console, use URL Inspection and compare: declared canonical vs canonical chosen by Google. 
• If the canonical is set in JS - check if there is no crossover with HTML (or if HTML has no canonical at all, if JS is supposed to set it). 

Where is swiatcyfrowy.pl in this place?

If you want to make sure that canonical, JS rendering, and indexing are set correctly, the fastest way to do this is usually through a technical SEO audit (with e-commerce elements).

In the Digital World, you can treat this topic as part of a larger diagnosis: tidying up indexing, eliminating duplication, improving the visibility of categories and products, and tightening the SEO funnel → product card → kupi.swia