Canonicalization: Why a 1 to 3 Week Fix Can Take Months
Google reportedly needs 1 to 3 weeks to process a canonical change, and months when your signals conflict. How it picks a canonical, and when to worry.
Canonicalization is Google choosing one representative URL for a set of duplicate pages. A change to that choice typically takes 1 to 3 weeks, according to figures reported from Google's Barcelona event, and months when your own signals disagree. The short version:
- How Google picks: It clusters similar pages, selects one canonical and consolidates signals onto it, as John Mueller explained it in Barcelona per John Campbell's recap for ROAST.
- The reported timings: Canonicalisation change: typically 1 to 3 weeks, slowest months. Site move: typically 1 to 3 months, slowest 6 months to a year or more. Removal: 1 to 3 weeks.
- What Google has written down: Its canonical troubleshooting guide says pages can stay in a duplicate cluster for up to two weeks after you fix content issues.
- What makes it months: Conflicting signals: a redirect, a rel=canonical tag, the sitemap, internal links, hreflang and HTTPS pointing at different URLs for the same page.
- Where to check: URL Inspection in Search Console shows User-declared canonical next to Google-selected canonical. When they differ, audit the signals before you touch the tag again.
The timings are attendee-reported and Google has not published them. Treat them as a planning range, not a service level.
This is a read of how Google chooses a canonical URL and how long a change takes, built on Google's documentation and attendee reports from Barcelona. CrawlRaven's part comes at the end: its crawl finds the pages where your own canonical signals disagree. Try CrawlRaven free: 1 site, no credit card →
You fixed the canonical tag three weeks ago and Search Console still shows the old URL. Is the fix broken, or is Google just slow?
Canonicalization is the process of Google selecting one representative URL, the canonical, from a group of pages with the same or nearly the same content. A change to that selection typically takes 1 to 3 weeks, according to figures reported from Google's Barcelona event this month, and months when your own signals conflict.
What is canonicalization?
Canonicalization is how a search engine decides which of several duplicate URLs represents a piece of content. Google's canonicalization documentation says the chosen page becomes the main source it uses to evaluate content and quality.
If five addresses all open the same page, the canonical is the one address Google files it under. The other four are treated as copies that point back to it.
A canonical tag is your vote in that decision, not the decision itself. The same documentation calls a canonical preference "a hint, not a rule". Three terms carry the rest of this post:
- User-declared canonical. The URL your page names in its rel=canonical link.
- Google-selected canonical. The URL Google actually chose after weighing every signal it collected.
- Cluster. The group of duplicate or near-duplicate URLs the choice is made from.
Both keywords are searched steadily: "canonical tag" about 2,400 times a month and "canonicalization" about 1,900 (DataForSEO, US, October 2026). Most of what ranks defines the tag. Very little of it says how long the process takes.
How Google picks a canonical: cluster, select, consolidate
Google ran Search Central Live Deep Dive Europe in Barcelona from 30 September to 2 October 2026. It published no official recap, so what follows comes from attendees, chiefly John Campbell's Day 2 recap for ROAST.
According to that recap, John Mueller described duplication handling in three moves. Google groups similar pages into clusters, picks one page in each cluster as the canonical, and assigns the signals from every version to it.
Cluster, select, consolidate
Canonicalization as John Mueller described it in Barcelona
Google groups pages that are the same or nearly the same.
One URL in the cluster is picked as the canonical.
Signals from every version are assigned to that one URL.
Mueller gave four reasons for working this way, as Campbell reports them:
- Cleaner results. Duplicates stay out of the search results.
- Room for unique content. Storage is not spent on copies.
- Nothing is lost. Signals from every version are kept and consolidated on the canonical.
- Alternates are understood. Google can connect hreflang variants, rebrands and migrations to the page they belong with.
The clusters are often bigger than you expect. In a lightning talk on Day 1, Tobias Schwarz listed where near-duplicate URLs come from, again per the ROAST recaps:
- Encoding differences. The same path written with different character encoding.
- Protocol. http and https versions both resolving.
- Host. www and non-www both resolving.
- Parameter order. The same parameters arranged differently, such as
?a=1&b=2and?b=2&a=1.
Why a site: search still shows the old domain
The fourth reason has a visible side effect. Because Google keeps alternates connected to their canonical, Campbell's recap notes that a site: search on an old domain can still return results after a migration.
So old-domain URLs in a site: search are not proof the move failed. Measure a migration by where the clicks land, which is what tracking a site migration in Search Console covers.
How long a canonicalization change takes
On Day 3, Gary Illyes showed slides on how long each Search process takes, with a typical and a slowest time for each. Three rows matter here, as reported by ROAST and reproduced by Search Engine Roundtable.
| Process | Typical | Slowest |
|---|---|---|
| Canonicalisation change | 1 to 3 weeks | Months (conflicting signals) |
| Removal | 1 to 3 weeks | Months |
| Site move | 1 to 3 months | 6 months to 1 year or more |
The recaps add that a small site move can be done in a few weeks. They also carry a caveat worth keeping: Illyes told Barry Schwartz the slides were an exercise to see whether the audience could relate to numbers Google pulled internally. Treat them as a range to plan around.
Signals agree vs signals conflict
Typical and slowest times reported from Gary Illyes' slides
Google's own documentation carries one related figure. Its guide to fixing canonicalization issues says that even after you fix content issues, Google might hold pages in a duplicate cluster for up to two weeks.
- What that sentence covers. Pages Google clustered because their content looked the same. It adds that pages split out faster when the difference between them is clear and significant.
- What it does not cover. Site moves, removals, or a site whose signals contradict each other.
- When it was added. PPC Land dates the change to 10 July 2026. The page showed a last-updated date of 21 August 2026 when I opened it on 8 October.
Two weeks in the documentation and 1 to 3 weeks on a slide are close enough to plan with. The full set of reported timings is in how long Google takes to index a page.
Conflicting signals: what turns weeks into months
The slowest value on the canonicalisation row was reported with a cause attached in brackets: conflicting signals. That is the only row among these three that names why it gets slow, and it is the part you control.
Google's guide to consolidating duplicate URLs ranks three methods by how strongly they influence the choice, and says they stack when combined. The reverse follows: point them at different URLs and you have handed Google a disagreement to resolve.
Six canonical signals and how they disagree
The middle column below is what Google's documentation states. The right-hand column is how each signal ends up arguing with the others. Google ranks only the first three, so I have not ranked the rest.
| Signal | What Google's docs say | How it conflicts |
|---|---|---|
| Redirects | A strong signal that the redirect target should become canonical. A permanent redirect is used as a canonical signal; a temporary one is not. | The redirect sends users to URL A while the sitemap, internal links or the target's own tag still name URL B. Chains that end somewhere unexpected. |
| rel=canonical | A strong signal that the specified URL should become canonical. Still a hint, not a rule. | The tag names a URL that redirects elsewhere, or names one URL while the sitemap lists another. Google's guide names that second case as a thing not to do. |
| Sitemap inclusion | A weak signal that helps the included URLs become canonical. | The sitemap lists parameter, HTTP or non-preferred host versions that your canonical tags point away from. |
| Internal links | Not ranked. Google says to link to the canonical URL, and that consistent linking helps it understand your preference. | Navigation and body links point at the duplicate (a tracking parameter, a trailing-slash variant) while the tag names the clean URL. |
| hreflang | Not ranked. Google prefers URLs that are part of hreflang clusters, and says to specify a canonical in the same language. | The canonical points at a different language or region version, or at a URL that is missing from the hreflang set. |
| HTTPS | Google prefers HTTPS over equivalent HTTP pages as canonical, unless there are issues or conflicting signals. | An invalid certificate, insecure dependencies other than images, an HTTPS page that redirects through HTTP, or a canonical tag pointing at the HTTP version. |
Here is the pattern on one page. A redirect and the rel=canonical tag both name /shoes, and HTTPS is valid. The sitemap, the internal links and the hreflang set all name /shoes?ref=nav. Google now has two candidates where a consistent site offers one.
Same page, two sets of signals
Which URL each signal points at
| Signal | Site that agrees | Site that conflicts |
|---|---|---|
| Redirect | /shoes | /shoes |
| rel=canonical | /shoes | /shoes |
| Sitemap entry | /shoes | /shoes?ref=nav |
| Internal links | /shoes | /shoes?ref=nav |
| hreflang cluster | /shoes | /shoes?ref=nav |
| HTTPS | Valid | Valid |
| What Google sees | One candidate. Nothing to resolve. | Two candidates. Google has to choose. |
Google also lists things that are not canonicalization methods at all, and reaching for them is its own kind of conflict:
- robots.txt. Google says not to use it for canonicalization. A blocked URL can still be indexed without its content.
- noindex. Not recommended for choosing a canonical within one site, because it removes the page from Search entirely.
- The URL removal tool. It hides every version of the URL from Search, including the one you wanted kept.
- URL fragments. Google says to avoid specifying a fragment as the canonical.
Loops and clusters with no clear leader
Tobias Schwarz gave a second lightning talk on Day 2 about broken canonical setups. Campbell's recap names two patterns from it:
- Canonical loops. Page A names B as canonical and B names A, sometimes through a longer chain.
- Clusters with no clear leader. A group of duplicates where no single URL collects the signals.
Schwarz reportedly used a visualisation to make these visible to developers and stakeholders. That is the right instinct: a loop is nearly impossible to see one URL at a time and obvious once drawn.
301 vs 302 redirect: one attendee's note
This part rests on a single source. One attendee, Enrique Hidalgo, reported hearing that a 301 is a strong canonical signal rather than a "better crawl" than a 302, and that hreflang does not prevent clustering of near-identical URLs. No other recap I have read repeats it, so weigh it accordingly.
It does line up with what Google has published. Its redirects documentation splits the two this way:
- Permanent (301, 308). The indexing pipeline uses the redirect as a signal that the target should be canonical.
- Temporary (302, 303, 307). The pipeline does not use the redirect as that signal, though the target might still be indexed if other canonicalization signals are present.
So the "301 vs 302 redirect" question (about 880 US searches a month, DataForSEO, October 2026) is a canonicalization question. A 301 redirect casts a vote for the target. A 302 abstains and leaves the other signals to decide. The free redirect checker shows which one each hop returns.
Mueller's seven recommendations
Mueller closed the session with seven recommendations for handling duplicates. These are as reported by ROAST, in the recap's order and close to its wording:
- Use redirects for site migrations.
- Use HTTP result codes, and don't block agents.
- Check your rel=canonical links.
- Use hreflang links to help Google localise.
- Report unusual canonicals in the forums.
- Make secure pages that work.
- Keep canonical signals clear.
The seventh contains the other six. Redirects, status codes, tags, hreflang and working HTTPS are each a signal, and the list is a request that they say the same thing.
Reading the recaps, what stood out to me is that the slowest case got a named cause. Google did not say canonical changes are sometimes slow. It reportedly said they are slow when the site contradicts itself.
That matches how these problems usually look to me. A tag that "Google ignored" is often outvoted by the same site's sitemap and navigation. Editing the tag again changes nothing, because the tag was never the dissenting signal.
How to check which canonical Google chose
Search Console shows the outcome in two places. Start with URL Inspection, which answers the question for one URL:
- Inspect the URL you want indexed. Paste it into the search bar at the top of Search Console.
- Open the Page indexing section. Find User-declared canonical and Google-selected canonical.
- Compare them. If they match, Google accepted your preference. If they differ, Google found better evidence for another URL.
- Note the last crawl date. If it is older than your fix, Google has not seen the change yet.
One limit, from Google's URL Inspection help page: canonical choice is determined at indexing time, so the live test cannot predict it. You are always reading the indexed result, never a preview.
For the site-wide view, open the Page indexing report. Google's report documentation defines three canonical statuses:
- Duplicate without user-selected canonical. The page duplicates another and declares no preference, so Google chose the other page and will not serve this one.
- Duplicate, Google chose different canonical than user. The page is marked canonical, but Google thinks another URL is a better one and indexed that instead.
- Alternate page with proper canonical tag. The page correctly points at an indexed canonical. Nothing to do.
The second status is the conflict signature. "Duplicate without user-selected canonical" alone draws about 480 US searches a month (DataForSEO, October 2026), and every status is walked through in the Page indexing report explained. To read the tag on a live page, use the free canonical checker.
How long to wait before you worry
This is my reading of the reported timings, not a schedule from Google. The clock that matters starts when Google recrawls the page, not when you deploy.
That gap can be large. The same slides reportedly put a typical refresh of a known URL at about 30 days, and the recaps note that linked processes stack their delays. A canonical change on a rarely crawled page can sit unseen before its 1 to 3 weeks begin.
| Where you are | How it compares | What to do |
|---|---|---|
| Under 3 weeks since Google recrawled the page | Inside the reported typical range | Leave it alone. Confirm the last crawl date is after your change. |
| 3 weeks past the recrawl, Google-selected canonical unchanged | Outside typical for a canonicalisation change | Audit the six signals for a disagreement before changing anything. |
| Site move, under 3 months | Inside the reported typical range of 1 to 3 months | Keep redirects in place and watch the trend, not individual URLs. |
| Site move, past 3 months and still mixed | Heading toward the slowest reported range | Look for redirect gaps, old URLs in sitemaps and internal links to the old host. |
Google's troubleshooting guide suggests using Request Indexing after a fix, and notes it is quota-limited, so save it for your most important URLs. It prompts a re-evaluation. It does not settle a disagreement between your own signals.
If the page is not indexed at all, the problem may sit earlier in the pipeline than canonical selection. The two statuses that describe that are compared in crawled vs discovered, currently not indexed.
What this means for you
The same finding lands differently depending on your seat.
- In-house SEO. Put 1 to 3 weeks in the ticket, counted from recrawl. It stops a correct fix being reverted in week two.
- Agency. Report User-declared against Google-selected canonical for the affected templates, not a count of tags fixed.
- Migration lead. Plan reporting around 1 to 3 months, and warn stakeholders that old URLs can linger in site: searches. The SEO migration checklist covers the redirect work.
- Developer. Generate the sitemap, the canonical tag and internal links from one URL function, so they cannot drift apart.
- Founder. If the right page already ranks, a "Duplicate" row in Search Console is housekeeping, not an emergency.
Where CrawlRaven fits
Everything above can be checked by hand for one URL. The hard part is finding which of several thousand URLs have signals that disagree, and which of those are worth an afternoon.
CrawlRaven joins Search Console, GA4 and a 200-point crawl into one ranked plan. For canonicals, that means the pages where the tag, the redirect and the sitemap entry disagree are listed together and ordered by the traffic involved.
- What it checks. Canonical tags, redirect chains and loops, and sitemap entries, read against each other.
- What it cannot do. Make Google decide faster. The timings above apply whichever tool found the problem.
- Cost. The free plan covers 1 site with no credit card. Lifetime licences launched at $49 for 3 sites. Lifetime pricing steps up as licenses sell, so check the pricing page for the current batch. See pricing.
Key Takeaways
- →The definition: Canonicalization is Google selecting one representative URL from a cluster of duplicates. Your canonical tag is a hint in that decision, not a rule.
- →The mechanism: Cluster, select, consolidate. Signals from every duplicate are assigned to the chosen URL, as John Mueller described it per ROAST's recap.
- →The typical wait: 1 to 3 weeks for a canonicalisation change and for a removal, 1 to 3 months for a site move, as reported from Gary Illyes' slides.
- →The slow case: Months, with conflicting signals named as the cause. Site moves at their slowest were reported at 6 months to a year or more.
- →What Google documents: Pages can be held in a duplicate cluster for up to two weeks after content fixes. Redirects and rel=canonical are strong signals; sitemap inclusion is weak.
- →The check: URL Inspection, User-declared canonical against Google-selected canonical, plus the last crawl date. A mismatch means audit the signals, not the tag.
Sources used in this post
- Google Search Central: What is canonicalization
- Google Search Central: How to specify a canonical URL (signal strengths, HTTPS, hreflang, what not to use)
- Google Search Central: Fix canonicalization issues (the two-week line)
- Google Search Central: Redirects and Google Search
- Search Console Help: URL Inspection tool and Page indexing report
- ROAST: Search Central Live Deep Dive Barcelona, Day 2 recap (Mueller's session, the seven recommendations, Schwarz)
- Search Engine Roundtable: the timing data and Illyes' comment
- PPC Land: coverage of the timing slides and the July documentation change
Related reading on CrawlRaven
- How long Google takes to index a page: every timing row reported from Barcelona.
- Crawled vs discovered, currently not indexed: when the page is not in the index at all.
- SEO migration checklist and tracking a site migration in Search Console.
- Shopify canonical tags and duplicate content: the platform-specific version of this problem.
- Free tools: canonical checker and redirect checker.
Frequently asked questions
What is canonicalization in SEO?
Canonicalization is the process by which Google selects one representative URL, the canonical, from a set of pages with the same or very similar content. That URL is the one shown in search results, and Google's documentation says the canonical page is the main source it uses to evaluate content and quality. You can state a preference with redirects, rel=canonical tags and sitemaps, but Google makes the final choice.
How long does it take Google to process a canonical change?
Typically 1 to 3 weeks, and months when signals conflict, according to timing slides Gary Illyes showed at Search Central Live Deep Dive Europe on 2 October 2026, as reported by ROAST and Search Engine Roundtable. Google has not published those figures. Separately, Google's canonical troubleshooting guide says pages can be held in a duplicate cluster for up to two weeks after content issues are fixed.
What does 'Duplicate without user-selected canonical' mean?
It means Google found the page to be a duplicate of another page, the page does not declare a preferred canonical, and Google chose the other page. Google's Page indexing help says it will not serve this page in Search. If the other page is the one you wanted indexed, nothing is wrong. If it is not, add a rel=canonical tag and line up your other signals behind it.
What does 'Duplicate, Google chose different canonical than user' mean?
It means the page declares itself (or is declared) canonical for a set of pages, but Google decided another URL makes a better canonical and indexed that one instead. Your stated preference lost to other evidence. Use URL Inspection to see the Google-selected canonical, then check whether your redirects, sitemap, internal links and hreflang point at your preferred URL or at Google's.
Is a canonical tag a directive or a hint?
A hint. Google's canonicalization documentation says indicating a canonical preference is "a hint, not a rule". The same documentation describes rel=canonical as a strong signal, alongside redirects, with sitemap inclusion as a weak one. Strong is not the same as binding: Google weighs the tag with the other signals it collected for the page and can select a different URL.
What is the difference between a 301 and a 302 redirect for canonicalization?
A 301 is a permanent redirect and a 302 is a temporary one. Google's redirects documentation says its indexing pipeline uses a permanent redirect as a signal that the target should be canonical, and does not use a temporary redirect that way. The target of a 302 can still be indexed if other canonicalization signals are present. For a move you intend to keep, use a 301 or 308.
Why does a site: search still show my old domain after a migration?
Because Google keeps the old URLs as known alternates of the new ones. At the Barcelona event, John Mueller listed understanding alternate versions, including migrations, as one reason Google canonicalizes, and John Campbell's recap for ROAST says that explains why a site: search on an old domain can still return results. It does not by itself mean the move failed.
How long does a site move take in Google?
Typically 1 to 3 months, with the slowest cases running 6 months to a year or more, according to the timings reported from Gary Illyes' Barcelona session. The same reports note that a small site move can be done in a few weeks. These are attendee-reported figures based on what Google described as internal analysis, not a published commitment.
Does hreflang stop Google treating similar pages as duplicates?
Not on its own. Google's documentation says different language versions are duplicates only when the primary content is in the same language, which is exactly the case for regional variants such as US and UK English. It recommends using both canonicalization and hreflang together. One attendee at the Barcelona event also reported hearing that hreflang does not prevent clustering of near-identical URLs.
15+ years of growing SaaS websites through SEO | Author, 200-Point Audit Checklist
Aditi has spent 15+ years helping SaaS companies scale organic traffic through technical SEO and content strategy. She is the author of the CrawlRaven 200-Point Audit checklist used by agencies and in-house teams to systematically improve search performance.