TL;DR. On July 10, 2026, Google updated its canonicalization troubleshooting guide. The new detail: even after you fix duplicate content, Google may keep your pages inside a duplicate cluster for up to two weeks. That delay had never been put in writing. In practice: your fixes don't land instantly, and stacking more changes during the wait is the fastest way to break everything.
On July 10, 2026, Google updated its "Fix canonicalization issues" guide on Search Central, adding a detail that had never appeared in the documentation before: after you fix the underlying content problems, Google's systems can still hold the pages in a duplicate cluster for up to two weeks. The page now carries the note "Last updated 2026-07-10 UTC".
The exact wording, under a bolded heading reading "Re-evaluation takes time", is: "Even after fixing content issues, Google might hold pages in a duplicate cluster for up to two weeks" (Google Search Central).
What the documentation actually says
Google added two points, both bolded in its own doc:
- "Re-evaluation takes time": the re-evaluation window can run to two weeks after your fix.
- "Content difference matters": pages generally split out of the cluster faster "if the difference between the new content and the other clustered pages is clear and significant".
On the same day, Google also updated its page on consolidating duplicate URLs, restating an old but widely ignored recommendation: "We recommend adding this same self-referential rel="canonical" link element to the canonical page itself as well" (Google Search Central).
Why this matters
Until now, the "Duplicate, Google chose a different canonical than user" message in Search Console was a wall with no clock on it. You fixed the page, you requested reindexing, and you had no idea what a normal delay looked like. The result: SEO teams re-running URL inspection every other day, concluding after 72 hours that "the fix didn't work", and stacking a second round of fixes on top of the first.
Google has now put a number on it. This is not a penalty and not a manual action. It is processing time. The pages in the cluster have to be recrawled, then their similarity re-assessed. Two weeks is the stated upper bound.
Key nuance: the clock does not start when you publish the fix. It starts when Google recrawls the pages in the cluster. If your duplicate pages are crawled once a month, the real-world window is longer than two weeks.
Who this actually hits
The delay lands hardest on four very common situations:
- Site migrations. You replatform, you fix the canonicals, and for two weeks Search Console keeps showing the wrong canonical URL. Don't roll back.
- E-commerce with variants. Sizes, colours, filters: near-identical product pages end up clustered. Differentiating "a bit" won't cut it, because Google wants a difference that is clear and significant.
- Programmatic SEO. Hundreds of pages generated from one template: if the genuinely unique content per page is too thin, they get clustered. This is precisely why we enforce a real unique-content threshold per page rather than swapping variables in a template.
- Poorly tagged multilingual sites. Incomplete hreflang plus crossed canonicals, and Google picks a single version for everyone.
The link to crawling is direct: if Googlebot doesn't come back, nothing gets re-evaluated. It's the same principle as Googlebot's HTML crawl limit: what the crawler doesn't read doesn't exist. And the way Google treats 404s as a positive crawl signal shows that indexing is a continuous process, not a switch.
The angle everyone will miss: canonicals decide who the AI cites
Here's what standard SEO coverage will skip. Canonicalization doesn't just decide which URL gets indexed, it decides which URL is eligible to be cited. AI Overviews and AI Mode pull their citations from Google's index. If your cluster is unresolved, the URL that shows up as a source isn't the one you optimised: it's whichever variant Google elected canonical on your behalf.
And as we've documented, a majority of AI citations come from pages outside the organic top 10. In other words: a page that doesn't rank can still get cited, provided it's indexed under the right URL. An unresolved duplicate cluster makes you lose both games at once. To track the real effect, the Search Console AI visibility report is currently the only place to cross-reference indexing and citations.
What to do now
Differentiate properly, not cosmetically
Google says it plainly: pages split faster when the gap is "clear and significant". Rewriting three sentences on a product page won't do it. Change the angle, add content specific to the variant, cut what is strictly identical.
Ship the self-referential canonical
On the canonical page itself. It's explicitly recommended, it's trivial to deploy, and it's still missing from a majority of badly configured CMS setups.
Fix once, then wait 14 days
Date your fix. Don't re-judge it before two weeks of crawling. The worst possible move is stacking a noindex, a redirect and a new canonical during the re-evaluation window: you make the signal unreadable and reset the clock.
Check that crawling keeps up
Two weeks assumes Googlebot comes back. Check crawl frequency for the affected pages in Search Console. An up-to-date sitemap and internal links pointing at the fixed pages speed up the recrawl.
What this article does not cover
Three limits, stated plainly:
- Google gives an upper bound, not a guarantee. "Up to two weeks" does not mean "within two weeks". A rarely crawled site can wait longer.
- No field data published yet. This update is four days old: nobody has an aggregate measurement of the real post-fix delay. We won't invent one.
- This is not about penalties. A duplicate cluster is not a sanction. If your traffic drop lines up with an algorithm update, canonicalization is probably not your problem.
The Cicéro take
This update doesn't change the technique, it changes the tempo. The real cost of duplicate content was never the content itself: it's the round-trip time with Google. Two weeks per iteration means a site that picks the wrong fix three times loses a quarter.
The lesson is blunt and simple: ship genuinely different pages the first time. A page with no reason to exist separately doesn't need a canonical: it needs to be merged or deleted.
Frequently asked questions
How long does Google take to recognise a duplicate content fix?
How can I get pages out of a duplicate cluster faster?
Should the canonical page carry a self-referential canonical tag?
Is the two-week delay a penalty?
Sources
- → Google Search Central, Fix canonicalization issues: primary source, updated July 10, 2026 ("Re-evaluation takes time", "Content difference matters").
- → Google Search Central, Consolidate duplicate URLs: primary source, updated July 10, 2026, self-referential canonical recommendation.
- → Search Engine Land: coverage of Google's clarification.
- → Search Engine Roundtable: analysis of the documentation change.
Growth and SEO content strategist, I founded Cicéro to help businesses build lasting organic visibility, on Google and in AI-generated answers alike. Every piece of content we produce is designed to convert, not just to exist.
LinkedIn