Fixing a canonical tag is satisfying. You find a duplicate cluster, point the canonical at the right URL, and move on. But the work is not done. Google must recrawl and reprocess the affected URLs before its selected canonical can change. Depending on site size and crawl demand, visible convergence may take days or weeks.
Most teams discover this delay after changing a product template and seeing the old selected canonical remain in inspection data. That delay does not prove the deployment failed, but neither does it guarantee Google will accept the new hint.
Why canonical re-evaluation is not instant
Google does not recanonicalise every page instantly. It must fetch enough members of the duplicate cluster and reassess signals such as redirects, canonical annotations, internal links, sitemap inclusion, and content similarity. Until that happens, inspection data may continue showing the previous selected canonical.
The practical effect is a delayed feedback loop. You can verify the deployed HTML immediately, but Google's selected canonical will only reflect a later crawl and processing cycle.
Validate deployment before measuring convergence
Separate the signal you control from Google's later selection. Sample each affected URL pattern and verify the live response:
- the duplicate returns the intended status and canonical declaration;
- the canonical target returns
200and self-references; - internal links and sitemap entries use only the preferred URL;
- no template, locale, parameter, or CDN layer rewrites the canonical differently.
For HTML pages, inspect the canonical element in the rendered <head>. A canonical HTTP Link header is useful for supported non-HTML documents, such as PDFs, but duplicating the same hint across mechanisms does not make processing faster.
Accelerating propagation
You cannot guarantee faster canonical selection by requesting indexing for every duplicate. You can, however, remove conflicting signals and make the intended target easier to process:
First, reinforce the canonical target internally. Google's canonical selection considers internal link signals. If the target URL gains new internal links while the duplicate loses them, Google converges faster. Add contextual cross-links to the canonical target from related pages.
Second, submit the canonical target URL in your sitemap, not the duplicate. Google uses sitemap URLs as canonical hints. If your sitemap lists the duplicate, you are telling Google the wrong page is authoritative.
Third, keep the canonical declaration consistent. Use one correct HTML canonical for HTML pages, and do not mix competing values across templates or response headers.
Detecting stuck clusters
After the affected URLs have been recrawled, a cluster that still shows the unexpected selected canonical deserves a signal audit. Google may disagree with your hint, or it may not have processed every member yet. Sample representative URLs in Search Console URL Inspection and compare the user-declared and Google-selected canonicals. Search Analytics performance rows do not expose canonical selection, so they cannot confirm convergence on their own.
Canonical convergence is not immediate or guaranteed. Plan verification around recrawling and consistent signals rather than a fixed two-week deadline.
Turn the note into a sprint
GSC indexing and crawl cleanup
If this matches the live symptom, send the URL, what changed, and the affected pages so the first pass can stay bounded.