Canonicalization: Why Google Indexes the 'Wrong' URL

Canonicalization is the process by which Google picks one URL to stand for a group of pages it considers duplicates. You published one page. Google may have found it at four addresses: with and without www, with and without a trailing slash, perhaps with a tracking parameter attached. Google will not index all four. It chooses one, calls it the canonical, and files the rest as duplicates of it. Most of the time the choice is sensible. Sometimes it is not the URL you wanted, and the page you keep checking for appears to be missing while a version you never promoted sits in the index instead.

That is the situation this post untangles: what canonicalization is, why Google sometimes overrules you, and how to find out which URL actually made it in.

One page, many addresses

Duplicate URLs are rarely a sign of carelessness. Ordinary publishing produces them:

Protocol and host variants. http:// and https://, www and bare domain. Four combinations of the same homepage before you have written a word.
Trailing slashes and case. /pricing and /pricing/ are different URLs. So are /Pricing and /pricing on most servers.
Parameters. Session IDs, UTM tags, sort orders and filters. ?utm_source=newsletter creates a new URL with identical content.
Syndication and staging. The same article republished on a partner site, or reachable on a forgotten staging subdomain.
CMS quirks. Many platforms serve the same post under a date path, a category path and a short permalink at once.

Google’s crawler treats each of these as a distinct URL, fetches them, and notices the content matches. At that point canonicalization begins: the duplicates are clustered, and one member of the cluster is selected to represent the rest. Ranking signals for the group consolidate onto that one URL. The others are known to Google but not indexed in their own right.

How canonicalization actually works

The important, frequently misunderstood point is that the rel="canonical" tag is a signal, not a command. Google’s own documentation is plain about this: your annotation is one input among several, and Google reserves the right to select a different canonical if the other evidence disagrees with you.

The inputs Google weighs include:

Redirects. A 301 from one variant to another is a strong statement that the destination is the real page.
Your rel="canonical" annotation. Respected in most cases, but only when it is consistent with everything else.
Sitemap inclusion. Google takes the URLs you list in a sitemap as a hint about which versions you consider primary.
Internal linking. If your own navigation links to the parameterised version a thousand times, you are voting against your own canonical tag.
HTTPS. Given an otherwise equal pair, Google prefers the secure version.

When these signals agree, canonicalization is invisible. You never think about it because the URL you meant is the URL Google picked. When they conflict, Google arbitrates, and the outcome can surprise you. A canonical tag pointing at page A, a redirect chain landing on page B, and internal links favouring page C is not a specification. It is an argument, and Google settles arguments its own way.

There is one detail worth stressing: a canonical tag is not a noindex. Pointing page A’s canonical at page B does not forbid Google from indexing page A. If Google decides the two pages are not really duplicates, it can index both, or index A and ignore your tag entirely.

What the ‘wrong’ URL looks like in practice

The wrong-URL problem usually announces itself in one of two ways.

The first is a Search Console status. The Page indexing report has two entries for this exact situation. “Duplicate without user-selected canonical” means Google found duplicates, you expressed no preference, and it chose for you. “Duplicate, Google chose different canonical than user” means you did express a preference and Google overruled it. Neither status is an error in Google’s eyes. Both are worth your attention, because the indexed version may lack the analytics tags, the layout or the URL structure you actually maintain.

The second is quieter: a page you submitted simply never shows up as indexed, with no error anywhere. This is one of the classic cases where a page that looks perfectly fine is declined, because from Google’s side nothing was declined at all. The content is indexed. It is just indexed under a different address, and every check you run against your preferred URL comes back empty.

This is also where the gap between submitting and indexing gets expensive. Submission hands a specific URL to a pipeline; indexing is Google’s decision about what to keep, and Google’s decision includes which address to keep it under. The two events are not the same thing and should never be read as the same thing. You can deliver https://example.com/page?ref=home flawlessly, and Google can respond by indexing https://example.com/page. The delivery succeeded. The exact URL you tracked was still, strictly speaking, not indexed.

Making your preferred URL the obvious choice

You cannot force canonicalization, but you can make disagreement between your signals impossible. That is the whole strategy: remove the argument.

Pick one format and redirect everything else to it. One protocol, one host, one slash convention. Server-level 301s from every variant. This single step resolves most protocol and host duplication.
Add a self-referencing canonical to every indexable page. Each page states its own preferred URL. This defends you against parameters you did not anticipate, because ?utm_source=x copies will carry a canonical pointing back at the clean URL.
Put only canonical URLs in your sitemap. A sitemap containing parameterised or non-preferred variants contradicts your tags in a place Google explicitly reads.
Link internally to canonical URLs only. Audit templates, not just content. A navigation component that appends a parameter undermines everything above it on every page it appears on.
Keep syndication honest. When content is republished elsewhere by arrangement, ask the partner to canonical to your original, and be aware that cross-site canonicals are weighed like any other signal, not obeyed.

None of this settles the outcome, because nothing does; Google decides. What it does is remove every reason for Google to decide against you.

Checking which URL Google actually picked

Diagnosis comes before any fix. Two checks tell you most of what you need.

In Search Console, the URL Inspection tool shows both the canonical you declared and the canonical Google selected, side by side. When they differ, you have found your problem, and the signals above tell you where to look for the contradiction.

Beyond a single URL, the useful discipline is checking your exact preferred URLs against live Google results, on a schedule, rather than assuming a clean submission meant a clean outcome. This is the reason AIndexify reports submitted and indexed as two separate events and verifies the second one itself: for each URL you give it, it checks live results over the following days and records either the date the URL was found indexed or “Not indexed as of” the last check. A batch of pages sitting at “Not indexed” while their content clearly exists in Google is a canonicalization signature, and it is far easier to spot across a list than one inspection at a time.

Canonicalization sits inside the larger machinery of crawling, evaluation and selection, and it makes more sense once you see the whole pipeline in order; the full guide to Google indexing walks through where canonical selection fits and what happens on either side of it.

The wrong-URL problem is one of the few indexing problems that is invisible until you measure it precisely, because the content is indexed and every casual check looks fine. If you want to know which of your exact URLs Google is actually returning, submit your URLs and read back what happened, date by date.