What Does 'Canonicalized' Mean?

What canonicalized means

A canonicalized URL is an address whose rel="canonical" tag names a different address as the preferred version, or one that a search engine grouped with duplicates and chose another address to represent. The word describes a relationship between two addresses, not a verdict on the page, so an address marked canonicalized is not broken, penalized or removed by that fact alone.

Most readers meet the word as a label rather than in a sentence. A crawler prints "Canonicalised" next to a few hundred rows, a client forwards the export, and the question arrives as "is this bad?" Usually it is not. The label is a status report: this address defers to another one. Whether that deference is correct is a separate judgment, and it is the one that matters.

From canonical form to canonical URL

"Canonical" means standard or authoritative. In computing, a canonical form (also called a normal form) is the one agreed representation chosen from several that mean the same thing. Two file paths, two spellings of a host name in different letter case, or two encodings of the same character can be equivalent; converting each to a single standard version is what programmers call canonicalizing it. URL normalization, the practice of rewriting equivalent URL strings into one consistent form, is that idea applied to web addresses.

The web sense is narrower. RFC 6596, which defines the canonical link relation, calls the page carrying the link the "context IRI" and the preferred page the "target (canonical) IRI." A canonicalized URL is the context in that pairing: it hands the representative role to the target. The word forms line up like this:

"Canonicalized" and "canonicalised" are the same word in two spellings. Nothing about the British form signals a different state, a different engine or a different severity.

Behind the word sits a process: Google gathers duplicate URLs into a cluster, reads the signals a site gives it, and picks one representative, treating a declared preference as "a hint, not a rule." That process is covered in full in the guide on canonicalization in SEO; this page stays with the vocabulary and the label.

Where the "Canonicalised" label appears

Screaming Frog SEO Spider is the most common source. Its Canonicals tab includes a "Canonicalised" filter, defined as a page that "has a canonical URL that is different to itself." The same URLs surface in the Internal tab with an Indexability Status of Non-Indexable, and the reason given is that the page is "canonicalised" to another address. "Non-Indexable" there is the crawler's own model: the URL is not a candidate to be indexed under its own address. It is not a report of anything Google has done.

Other crawlers use the American spelling and split the idea into narrower findings:

• Sitebulb files "Canonical points to a different internal address" as an Insight, noting it is usually deliberate, and separately raises "Canonicalized URL in XML Sitemaps" and "Canonical points to another canonicalized URL."
• Ahrefs Site Audit reports "Non-canonical page in sitemap" and "Non-canonical page specified as canonical one."
• Screaming Frog also counts a declared target that is itself "canonicalised" under "Non-Indexable Canonical."

Search Console never prints the word. Its Page indexing report expresses the same relationship through statuses such as "Alternate page with proper canonical tag," "Duplicate without user-selected canonical" and "Duplicate, Google chose different canonical than user," each of which has its own guide. URL Inspection shows the pair directly as "User-declared canonical" and "Google-selected canonical."

What a canonicalized URL is, and what it is not

A URL can become canonicalized by two routes. The first is declared: the page's own markup or header names a different address as preferred. The second is selected: the page may declare nothing, or declare itself, and Google still clusters it under another address. Crawlers only see the declared route, because they read your markup. Search Console is the only place that shows the selected route. A crawl that shows zero canonicalized rows does not mean Google agrees with every page, and a crawl full of them does not mean Google accepted any of them.

Four misreadings account for most of the worry the label causes:

• Not an error. Parameter URLs, sort and filter views, print versions and tracking links are supposed to be canonicalized. A large count on a store with faceted navigation is normal.
• Not a penalty. Being left out of the index in favor of a duplicate is consolidation, not a sanction. The chosen address is generally the one shown in results and receives the combined signals.
• Not deleted. A canonicalized URL still loads for visitors. Unlike a redirect, the tag changes nothing about what a browser receives.
• Not binding. Declaring a preferred address makes Google's agreement more likely; it does not settle the matter.

<!-- served at https://www.example.com/shoes?sort=price -->
<link rel="canonical" href="https://www.example.com/shoes">

That sorted listing is canonicalized, correctly, and a crawler will list it under "Canonicalised" for exactly that reason.

Deciding whether a canonicalized URL is intended

Treat the label as a question to answer per address pattern, not per row. Export the "Canonicalised" filter, group the rows by template or parameter, and ask of each group:

1. Should this address rank on its own? If a searcher would never need this exact address, the tag is doing its job.
2. Is the target the page you would want shown? It should be the same content in its preferred form, not a parent category or a home page that merely resembles it.
3. Is the target clean? It should return 200, be indexable, reference itself as preferred and not point onward to a third address.
4. Does Google agree? Inspect a sample in URL Inspection and compare the declared and selected canonicals in the indexed result; the live test cannot show Google's choice.

If every group passes, the canonicalized URLs are intended and the right action is none. A group that fails tends to fail as a whole, because the tag usually comes from one template or one plugin setting. One fix at the source beats hundreds of edits.

When the label points to a real problem

The label becomes a symptom in a handful of situations, and nearly all of them come down to a canonicalized URL being treated elsewhere as if it were primary:

• A unique page is canonicalized. Paginated pages all pointing to page one, or product variants pointing to a parent that drops their distinct content, hide pages that should be indexed. Correct the tag to self-reference.
• Canonicalized URLs are in the XML sitemap. Listing URL A while A names B as its preferred address sends the mixed message Google asks sites to avoid. Keep only self-referencing, indexable URLs in the sitemap.
• Internal links point at canonicalized URLs. Navigation that links to tracking or variant URLs keeps crawlers returning to duplicates. Link to the preferred URL; use the crawler's Inlinks view to find the source templates.
• A canonicalized URL is someone else's target. A tag or hreflang annotation that points to an address which itself canonicalizes elsewhere creates a chain. Point straight at the final address.
• Google selected a different address. If its choice is reasonable, align your signals with it rather than fighting it.

Two tempting fixes make matters worse. Adding noindex to canonicalized URLs to "help" them drop out is not what Google recommends for duplicates within one site, and blocking them in robots.txt stops Google from reading the tag at all.

Frequently asked questions