Ch 8 — Canonicalization & duplication

Part IV — The index layer · The Technical SEO Reference

Playbook coupling: seo-checklist.md covers this in 5 lines (Phase 1, "Canonicalization & duplication", lines 86–90): one version resolves (HTTPS + one hostname, permanent redirects), rel=canonical correct sitewide as a hint, faceted/parameter handling, pagination self-canonicals, no duplicate clusters — plus the migration redirect-map item (line 223). This chapter adds: the actual selection mechanics (checksums, centerpiece, the 20+-signal stack), every implementation method with its documented failure modes, the HTTPS-preference exception list, the 2023 syndication reversal, hostile canonicalization, the hreflang interplay, the full GSC diagnosis layer, and the July 2026 two-week re-evaluation clock.

Canonicalization is a clustering system, not a judging system. Google does not penalize duplication; it detects pages whose primary content is the same or very similar, groups them into a cluster, and elects exactly one URL to represent the cluster in Search — crawling, evaluating, and crediting that URL most. Everything you control (redirects, rel=canonical, sitemaps, internal links, protocol/host hygiene) is a vote in that election, never a decree. The doctrine sentence for the whole chapter, from Google's own doc: "indicating a canonical preference is a hint, not a rule." Practitioner failures in this domain are almost never "Google ignored my tag out of spite" — they are dissimilar pages posing as duplicates, contradictory votes, or signals Google never saw. Diagnose accordingly.

8.1 Clustering, not judging: what canonicalization actually is

🟢 The definition, from What is URL canonicalization (last updated 2026-07-10): "Canonicalization is the process of selecting the representative –canonical– URL of a piece of content." The mechanism: "When Google indexes a page, it determines the primary content (or centerpiece) of each page. If Google finds multiple pages that seem to be the same or the primary content very similar, it clusters them together. Google then chooses the page that, based on the factors (or signals) the indexing process collected, is objectively the most complete and useful for search users, and marks it as the canonical."

🟢 Duplicate detection runs on checksums, and it precedes canonical selection. In Search Off the Record episode 9 (published November 4, 2020; official Google transcript via goo.gle/sotr009-transcription), Gary Illyes described dedup as "reducing the content into a hash or checksum and then comparing the checksums" — "a checksum is basically a hash of the content" (Martin Splitt's gloss: "A fingerprint"). Boilerplate is excluded: "we exclude the navigation from the checksum calculation, we remove the footer as well, and then we are left with what we call the centerpiece, which is the central content of the page." Two consequences worth internalizing: (1) matching checksums of centerpiece content — not whole-page similarity percentages — is what forms a cluster; (2) pages that differ only in boilerplate (nav, footer, sidebar) are duplicates to this system.

🟢 Duplication is normal, not a violation. Same canonicalization doc: "Some duplicate content on a site is normal and it's not a violation of Google's spam policies." Google's own taxonomy of why sites have duplicates (verbatim category labels and examples):

• "Region variants: for example, a piece of content for the USA and the UK, accessible from different URLs, but essentially the same content in the same language"
• "Device variants: for example, a page with both a mobile and a desktop version"
• "Protocol variants: for example, the HTTP and HTTPS versions of a site"
• "Site functions: for example, the results of sorting and filtering functions of a category page"
• "Accidental variants: for example, the demo version of the site is accidentally left accessible to crawlers"

Each row of that list maps to a section of this chapter: region variants → §8.8, protocol variants → §8.5, site functions → §8.7, accidental variants → §8.10 (and staging protection → Ch 7). 🟢 The documented cost of unmanaged duplication is UX and measurement, not punishment: "having the same content accessible through many different URLs can be a bad user experience… and it may make it harder for you to track how your content performs in search results."

⚠️ The real spam boundary sits elsewhere. The old standalone "scraped content" policy is now an example under scaled content abuse in the spam policies: 🟢 "Scraping feeds, search results, or other content to generate many pages (including through automated transformations like synonymizing, translating, or other obfuscation techniques), where little value is provided to users." Benign duplication is consolidated; scraping at scale is a named violation (→ Ch 18).

🟢 What the canonical election decides. Crawl allocation: "The canonical page will be crawled most regularly; duplicates are crawled less frequently in order to reduce the crawling load on sites." Evaluation: "Google uses the canonical page as the main source to evaluate content and quality." Display: "A Google Search result usually points to the canonical page, unless one of the duplicates is explicitly better suited for a search user" — e.g., the mobile variant shown to a mobile user.

🟢 Canonicalization is not ranking. Illyes, same transcript, [00:17:38]: "canonicalization is completely independent of ranking. But the page that we choose as canonical, that will end up in the search result pages and that will be ranked, but not based on these signals." Losing a canonical election does not demote the cluster; it decides which URL carries the cluster's fortunes.

8.2 The signal stack: how Google picks, and hint vs directive

🟢 The documented factor inventory, canonicalization doc: "There are a handful of factors that play a role in canonicalization: whether the page is served over HTTP or HTTPS, redirects, presence of the URL in a sitemap, and rel=\"canonical\" link annotations." And the hinge: "You can indicate your preference to Google using these techniques, but Google may choose a different page as canonical than you do, for various reasons. That is, indicating a canonical preference is a hint, not a rule."

🟢 Google labels the strength of each explicit method in How to specify a canonical (last updated 2026-07-10):

Signal	Google's own strength label
Redirects	"A strong signal that the target of the redirect should become canonical."
rel="canonical" link annotations	"A strong signal that the specified URL should become canonical."
Sitemap inclusion	"A weak signal that helps the URLs that are included in a sitemap become canonical."

🟢 Signals stack: "Keep in mind that these methods can stack and thus become more effective when combined." And none are mandatory: "While we encourage you to use these methods, none of them are required; your site will likely do just fine without specifying a canonical preference."

🟢 Internal linking is a documented preference signal: "When linking within your site, link to the canonical URL rather than a duplicate URL. Linking consistently to the URL that you consider to be canonical helps Google understand your preference." A site whose templates link to ?ref=nav variants is voting against its own canonical tags on every page.

🟢 Two implicit site-setup signals live in the doc's "Other signals" section: "preferring HTTPS over HTTP, and URLs in hreflang clusters" (§8.5 and §8.8 respectively).

🟢 The full stack is 20+ ML-weighted signals. Illyes, SOTR ep. 9 transcript [00:13:01]: "So, we employ, I think, over 20 signals. We use over 20 signals to decide which page to pick as canonical from a dupe cluster." Named examples from the same passage:

• Content itself ("one is, obviously, the content").
• PageRank: "which page has higher page rank, because we still use page rank after all these years."
• Protocol and sitemap presence: "especially on same site, which page is on an HTTPS URL, which page is included in a sitemap."
• Redirects: "if one page is redirecting to the other page, then that's a very clear signal that the other page should become canonical."
• rel=canonical: "the link rel=canonical tag is quite a strong signal again because people or someone specified that that other page should be the canonical."

Weighting: "each of these signals that we use have their own weight. And we use some machine learning voodoo to calculate the weights for these signals," with the worked example that a "301 redirect or any sort of redirect, actually, should be much higher weight when it comes to canonicalization than whether the page is on an HTTP URL or HTTPS." Note this is a dated (2020) recorded statement, not the documentation set — the doc-level inventory is the paragraphs above; the transcript is the only official source naming PageRank as a canonicalization input.

🟢 Google can override you, and says why it might: "Even if you explicitly designate a canonical page, Google might choose a different canonical for various reasons, such as the quality of the content" (Fix canonicalization issues, last updated 2026-07-10).

8.3 Implementation methods and their failure modes

🟢 Why bother at all, given that "none of them are required"? The consolidate doc gives three reasons to declare a preference: "To specify which URL that you want people to see in search results" (the doc's example: prefer https://www.example.com/dresses/green/green-dress.html over https://example.com/dresses/cocktail?gclid=ABCD); "To consolidate signals for similar or duplicate pages… to consolidate the signals they have for the individual URLs (such as links to them) into a single, preferred URL"; and "To simplify tracking metrics for a piece of content." Note what is documented about equity consolidation: that signals such as links consolidate — never a percentage, ratio, or 301-equivalence (§8.2 lore quarantine).

Two annotation channels exist, plus the sitemap. 📘 rel=canonical is a web standard: the doc states "Google supports explicit rel canonical link annotations as described in RFC 6596," and the header form rides the HTTP Link header "as defined by RFC5988."

The <head> link element. The doc's own example form:

<html>
<head>
  <title>Explore the world of dresses</title>
  <link rel="canonical" href="https://example.com/dresses/green-dresses" />
  <!-- other elements -->
</head>

🟢 Placement is strict: "The rel=\"canonical\" link element is only accepted if it appears in the <head> section of the HTML, so make sure at least the <head> section is valid HTML." ⚠️ An invalid <head> — an unclosed tag, or an injected widget/element that implicitly closes <head> early — silently drops every annotation after the breakage point. This is a leading cause of "Google ignored my canonical." 🟢 Scope limit: "Only works for HTML pages, not for files such as PDF."

The HTTP header. The doc's example, for pointing a .docx duplicate at the PDF canonical:

Link: <https://www.example.com/downloads/white-paper.pdf>; rel="canonical"

🟢 The only canonical mechanism for PDFs and other non-HTML types (→ Ch 2 for indexable file types). Documented pro: "Doesn't increase page size." Documented scope: "Google supports this method for web search results only." 🟢 "As with the rel=\"canonical\" link element, use absolute URLs in the rel=\"canonical\" HTTP header."

Pick one channel. 🟢 "We recommend that you choose one of these and go with that; while supported, using both methods at the same time is more error prone (for example, you might provide one URL in the HTTP header, and another URL in the rel=\"canonical\" link element)."

The sitemap. 🟢 "All pages listed in a sitemap are suggested as canonicals; Google will decide which pages (if any) are duplicates, based on similarity of content." A sitemap listing duplicates alongside canonicals is casting weak, contradictory votes (→ Ch 9 for sitemap mechanics).

Google's own comparison table, condensed (all cell text 🟢 verbatim from the consolidate doc):

Method	Documented pros	Documented cons
rel="canonical" link element	"Can map an infinite number of duplicate pages."	"Can be complex to maintain the mapping on larger sites, or sites where the URLs change often." "Only works for HTML pages, not for files such as PDF."
rel="canonical" HTTP header	"Doesn't increase page size." "Can map an infinite number of duplicate pages."	"Can be complex to maintain the mapping on larger sites, or sites where the URLs change often."
Sitemap	"Simple to implement and maintain, especially on large sites."	"Google must still determine the associated duplicate for any canonicals that you declare in the sitemap." "Less powerful signal to Google than the rel=\"canonical\" mapping technique."
Redirects	"Use permanent redirects to tell Google that a redirected URL is a worse version than the URL it redirects to."	"Use this only when deprecating a duplicate page." (§8.4)

🟢 The table's fifth row covers AMP: "If one of your variants is an AMP page, follow the AMP guidelines to indicate the canonical page and AMP variant."

The rules (all 🟢, consolidate-duplicate-urls best practices): - "Use absolute paths rather than relative paths" with the link element — relative paths are supported but "can cause problems." - Self-referential canonicals are recommended, not required: "Do include a rel=\"canonical\" link on the canonical page itself (also known as a self-referential canonical)" — but remember "none of them are required." - "Don't specify different URLs as canonical for the same page using different canonicalization techniques." - "Don't specify a URL fragment as canonical, as Google generally doesn't support URL fragments."

The anti-methods (all 🟢, same doc): "Don't use the robots.txt file for canonicalization purposes" — "Google may still index URLs that are disallowed in robots.txt without their content," and a disallowed duplicate can never show Google its canonical annotation at all (→ Ch 3). "Don't use the URL removal tool for canonicalization. It hides all versions of a URL from Search." And: "We don't recommend using noindex to prevent selection of a canonical page within a single site, because it will completely block the page from Search" — rel=canonical annotations "are the preferred solution." ⚠️ Hold that last rule next to §8.6: within one site noindex is the wrong dedup tool; across syndication partners it is Google's recommended one. Practitioners collapse these constantly.

⚠️ Attribute poisoning. 🟢 "rel=\"canonical\" annotations that suggest alternate versions of a page are ignored; specifically, rel=\"canonical\" annotations with hreflang, lang, media, and type attributes are not used for canonicalization." Clarified in the changelog on February 15, 2024, with the note: "This is a documentation change only; Google has always ignored these rel=\"canonical\" annotations for canonicalization purposes." Templates that merge canonical and alternate declarations into one <link> element silently lose the canonical.

JavaScript-injected canonicals. 🟢 The consolidate doc (section added December 17, 2025): "If you're using client-side rendering with JavaScript, it's important to make sure that the information about the canonical URL is as clear as possible. The best way to do this is to specify the canonical URL in the HTML source code and make sure that JavaScript doesn't change the canonical link element. If you can't set the canonical URL in the HTML source code, leave it out and only set it with JavaScript." The rationale lives in the changelog entry itself (Dec 17, 2025, "Clarifying canonicalization best practices for JavaScript"): 🟢 "Canonicalization happens before and after rendering, so it's important to make the canonical URL as clear as possible. With JavaScript, this means setting the canonical URL to the same URL as in the original HTML or if that isn't possible, to leave the canonical URL out of the original HTML." ⚠️ The operational consequence: a source-HTML canonical that JS later rewrites presents two different votes to two phases of the same pipeline — source-vs-rendered canonical conflict is a first-class failure mode, not a cosmetic one (→ Ch 6 for rendering mechanics).

8.4 Redirects as canonical signals — and the "alternate names" phenomenon

The full redirect-type taxonomy is Ch 16's home topic (→ Ch 16); this section covers only what redirects mean to canonicalization.

🟢 Redirects and Google Search (last updated 2026-04-14): "Google Search uses certain types of redirects as a signal that the redirect target should be canonical." The split:

• Permanent — "Permanent redirects: Show the new redirect target in search results." Mechanism: "Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical."
• Temporary — "Temporary redirects: Show the source page in search results." Mechanism: "Googlebot follows the redirect, but the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical. The target page might still be indexed if other canonicalization signals are present."

⚠️ Temporary redirects don't vote for the target. A site that 302s its HTTP→HTTPS or non-www→www hops is withholding the single strongest canonicalization signal it owns (per Illyes: redirects outweigh protocol; per the docs: redirects are "a strong signal"). This is the most common self-inflicted host-consolidation wound.

🟢 Scope discipline from the consolidate doc: "Use permanent redirects to tell Google that a redirected URL is a worse version than the URL it redirects to. Use this only when deprecating a duplicate page." And speed: "All permanent redirection methods have the same effect on Google Search, however the time it takes for search engines to notice the different redirect methods may differ. For the quickest effect, use HTTP (also known as server-side) redirects."

🟢 Alternate names: why old URLs keep showing after a migration. From the redirects doc: "When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical; which one, depends on signals such as whether the redirect was temporary or permanent." The loser doesn't vanish: "The other URL becomes an alternate name of the canonical URL. Alternate names are different versions of a canonical URL that users might recognize and trust more. Alternate names may appear in search results when a user's query hints that they might trust the old URL more." After a domain move, "it's very likely that Google will continue to occasionally show the old URLs in the results, even though the new URLs are already indexed. This is normal" — not a failed migration (→ Ch 16 for the migration playbook).

🟢 One GSC edge case belongs here because it defuses two common panics. The "Page with redirect" status, per the Page indexing report help: "This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed. The target URL of the redirect might or might not be indexed, depending on what Google thinks about that target URL." And its inverse: "A canonical URL with a redirect can be indexed." Panic one: "my redirecting URLs aren't indexed" — by definition, they shouldn't be. Panic two: "an indexed page of mine redirects" — permitted; canonical status and redirect behavior are recorded separately.

8.5 Host & protocol consolidation: the HTTPS preference and its documented breakers

🟢 One hostname. If the home page is reachable at https://example.com/home, https://home.example.com, and https://www.example.com: "Pick one of those URLs as your canonical URL, and use redirects to send traffic from the other URLs to your preferred URL" (consolidate doc). ⚪ Which variant you pick is not a ranking decision — Google documents no preference between www and non-www, trailing-slash or case variants; the only documented requirement is consolidating on one. Anyone selling "www is better for SEO" is selling lore.

🟢 The HTTPS preference — and its exact exception list. From the consolidate doc's "Other signals" section (the only current official home of this doctrine — see the caution below): "Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals such as the following:"

• "The HTTPS page has an invalid SSL certificate."
• "The HTTPS page contains insecure dependencies (other than images)."
• "The HTTPS page redirects users to or through an HTTP page."
• "The HTTPS page has a rel=\"canonical\" link to the HTTP page."

🟢 Ways to guarantee the HTTPS canonical: redirect HTTP→HTTPS; add a rel=canonical from the HTTP page to the HTTPS page; "Implement HSTS." ⚠️ But HSTS is not a trump card: "Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly. Implementing HSTS cannot override this strong preference." The same avoid-list adds two corollaries (🟢 verbatim):

• "Don't include the HTTP version of your pages in your sitemap or hreflang annotations rather than the HTTPS version."
• "Avoid implementing your SSL/TLS certificate for the wrong host-variant. For example, example.com serving the certificate for subdomain.example.com. The certificate must match your complete site URL, or be a wildcard certificate that can be used for multiple subdomains on a domain."

(HTTPS as a security/ranking topic → Ch 17; here it is purely a canonicalization input.)

⚠️ Citation trap: there is no live dedicated "HTTPS for Search" doc — …/search/docs/crawling-indexing/https hard-404s and never hosted this content; the retired /search/docs/advanced/security/https URL now redirects to web.dev's server-setup guide, which contains none of the canonical-preference wording. Cite consolidate-duplicate-urls and nothing else for this doctrine.

🟢 The dead control. The GSC preferred-domain setting was removed June 18, 2019: "Note that with the deprecation we will no longer use any existing Search Console preferred domain configuration" (Bye Bye Preferred Domain setting). Host/protocol preference is expressed today only through redirects, rel=canonical, and sitemaps. Playbooks still prescribing the setting are unmaintained.

8.6 Cross-domain canonicals, the syndication reversal, and hostile duplication

Legitimate cross-domain use. 🟢 Supported since December 15, 2009: "you can use the rel=\"canonical\" link element across domains to specify the exact URL of whichever domain is preferred for indexing," with the standing caveat "While the rel=\"canonical\" link element is seen as a hint and not an absolute command, we do try to follow it where possible" (2009 announcement). The post's Q&A still carries the operating rules:

• Similarity: "Do the pages have to be identical? No, but they should be similar. Slight differences are fine."
• 1:1 mapping, never a home-page funnel: pointing all old URLs at the new home page — "No; this could result in problems. A mapping from old URL to new URL for each URL on the old site is the best way to use rel=\"canonical\"."
• No noindex on canonical-annotated pages: "No, since those pages would not be equivalent with regards to indexing—one would be allowed while the other would be blocked."
• Crawlability: "it's important that these pages are not disallowed from crawling through a robots.txt file, otherwise search engine crawlers will not be able to discover the rel=\"canonical\" link element."
• Migration hierarchy: "If it's at all possible, you should work with your webhost or web server to do a 301 redirect" — cross-domain canonical is the fallback when redirects are impossible, not the primary tool (→ Ch 16).

⚠️ The syndication reversal (May 2, 2023) — the big one. Google's current doctrine, troubleshooting doc: 🟢 "The canonical link element is not recommended for those who want to avoid duplication by syndication partners, because the pages are often very different. The most effective solution is for partners to block indexing of your content." The change is datable to the changelog entry "May 2 [2023]: Updated our documentation about canonicalization with explicit recommendations for syndicated content," and Google retro-annotated its own 2009 post, which now opens: 🟢 "Specifically, rel=\"canonical\" is no longer recommended for syndicated content." The implementation, from Publisher Center help: partners add <meta name="Googlebot-News" content="noindex"> to stay out of Google News, or 🟢 <meta name="Googlebot" content="noindex"> "to restrict syndicated content from both Google News and Google Search"; whereas "If you publish the same article on multiple pages within your own site, you can use the rel=\"canonical\" link element." Any playbook still prescribing partner-side canonicals for syndication is running 2010s doctrine — the mechanistic reason it fails is §8.9's similarity rule: canonical hints between dissimilar pages are never honored. (noindex semantics → Ch 7.)

Hostile duplication — three documented scenarios (all 🟢, troubleshooting doc):

1. Canonical/redirect injection on hacked sites: "Some attacks on websites introduce code that returns an HTTP 3xx redirect or inserts a cross-domain rel=\"canonical\" link annotation into the HTML <head> or HTTP header, usually pointing to a URL hosting malicious or spammy content. In these cases, our algorithms may choose the malicious or spammy URL" — audit the served head and headers, not your CMS template (→ Ch 17 for incident response).
2. Copycat sites: "In rare situations, our algorithm may select a URL from an external site that is hosting your content without your permission" — remedies are a host takedown request and a DMCA request to Google.
3. Misconfigured servers: "A server may be misconfigured to return content from example.com in response to a request for a URL on other.example," and "Two unrelated web servers may return identical soft 404 pages that Google fails to identify as error pages" — both produce cross-domain canonical selection nobody chose (soft-404 mechanics → Ch 2).

8.7 Parameter, facet, and session duplication

Faceted navigation as an architecture problem is Ch 10's home topic (→ Ch 10); here is strictly the duplication/crawl calculus. Google's guidance became formal documentation on December 17, 2024 ("While the information was already public in form of a blog post, it was never officially made into documentation" — changelog) and migrated in December 2025 to developers.google.com/crawling/docs/faceted-navigation (last updated 2025-12-18). ⚠️ Cite the new URL; the old /search/docs/crawling-indexing/crawling-managing-faceted-navigation path currently 301-redirects there (verified 2026-08-04), but the /crawling/docs/ site is the maintained home.

🟢 The documented harms of crawlable facet spaces are "Overcrawling" and "Slower discovery crawls: … if crawling is spent on useless URLs, the crawlers have less time to spend on new, useful URLs." If facet URLs shouldn't be indexed: "Use robots.txt to disallow crawling of faceted navigation URLs," or use URL fragments for filters, since "Google Search generally doesn't support URL fragments in crawling and indexing."

⚠️ Canonical is the weakest tool for crawl control. 🟢 "Using rel=\"canonical\" to specify which URL is the canonical version of a faceted navigation URL may, over time, decrease the crawl volume of non-canonical versions of those URLs" — a slow frequency reduction, not a stop. The doc's worked example: "if you have 3 filtered page types, consider pointing the rel=\"canonical\" to the unfiltered version: https://example.com/items.shtm?products=fish&color=radioactive_green&size=tiny specifies <link rel="canonical" href="https://example.com/items.shtm?products=fish">." rel="nofollow" on anchors to filtered pages "may be beneficial," but 🟢 canonical and nofollow "are generally less effective in the long term than the previously mentioned methods." If the goal is crawl reduction, robots.txt wins; if the goal is index consolidation with facets still crawlable, canonical is the right hint. Know which problem you are solving.

🟢 If facet URLs must be indexable: "Use the industry standard URL parameter separator '&'" — commas, semicolons, and brackets "are hard for crawlers to detect as parameter separators" — and "Return an HTTP 404 status code when a filter combination doesn't return results."

🟢 Session duplication: "Wherever possible, avoid the use of session IDs in URLs and consider using cookies instead" (URL structure best practices, last updated 2025-12-10).

🟢 The dead control. "We're deprecating the URL Parameters tool in Search Console in 1 month. There's no action required from the current users of the tool" (March 28, 2022). Parameter handling now runs entirely on URL design, robots.txt, canonical hints, and Google's own inference.

8.8 hreflang × canonical

The hreflang spec is Ch 11's home topic (→ Ch 11 for methods, return links, codes, x-default). Canonicalization touches it at four documented points:

1. 🟢 Translations are not duplicates. "Different language versions of a single page are considered duplicates only if the primary content is in the same language" (canonicalization doc); "Localized versions of a page are only considered duplicates if the main content of the page remains untranslated" (localized-versions doc, last updated 2025-12-22). ⚠️ Corollary: same-language regional variants (US/UK/AU) can be clustered and collapsed into one canonical. 🟢 The documented fix for surfacing the right regional page: "adding hreflang annotations to your pages can help the right pages surface for users in different regions" (troubleshooting doc).
2. 🟢 The same-language canonical rule. "If you're using hreflang elements, make sure to specify a canonical page in the same language, or the best possible substitute language if a canonical page doesn't exist for the same language" (consolidate doc).
3. 🟢 Cluster membership is itself a canonicalization signal. "To help with sites' localization efforts, for canonicalization purposes Google prefers URLs that are part of hreflang clusters." The doc's example: if /de-de/cats and /de-ch/cats reciprocally reference each other but neither references /de-at/cats, "the pages for de-de and de-ch will be preferred as canonicals instead of the /de-at/ page that doesn't appear in the hreflang cluster." Broken return links therefore cost canonical preference, not just serving accuracy.
4. ⚠️ The attribute trap bites international sites hardest (§8.3): a rel=canonical carrying an hreflang or lang attribute is ignored for canonicalization — "Instead, use the appropriate link annotations to specify alternate versions of a page."

🟢 One tooling blind spot to remember when reading GSC: "Alternate language pages are not detected by Search Console" (Page indexing report help, under "Alternate page with proper canonical tag") — hreflang health needs external tooling; the report will never account for localized alternates.

8.9 Reading canonicals in Search Console

The full Page indexing status taxonomy is Ch 7's home topic (→ Ch 7); the three canonical-family reasons and the canonical-specific instruments are this chapter's.

🟢 The report's framing sentence, Page indexing report help: "Your goal is to get the canonical version of every important page indexed. Duplicate or alternate pages shouldn't be indexed."

The three current canonical statuses:

• 🟢 "Alternate page with proper canonical tag" — "This page is marked as an alternate of another page… This page correctly points to the canonical page, which is indexed, so there is nothing you need to do."
• 🟢 "Duplicate without user-selected canonical" — "This page is a duplicate of another page, although it doesn't indicate a preferred canonical page. Google has chosen the other page as the canonical for this page, and so will not serve this page in Search… This is not an error, but is working as intended, because Google does not serve duplicate pages." ⚠️ Not an error class to drive to zero; the only actionable question is whether Google picked the URL you wanted. If not: inspect to find Google's choice, mark a canonical explicitly, or "ensure that the content differs substantially between the two pages."
• 🟢 "Duplicate, Google chose different canonical than user" — "This page is marked as canonical for a set of pages, but Google thinks another URL makes a better canonical. Google has indexed the page that we consider canonical rather than this one."

The help page's own debug sequence for that last status (all 🟢 verbatim):

1. "Inspect this URL to see the Google-selected canonical URL under Page indexing > Google-selected canonical."
2. "Look at the canonical you chose under Page indexing > User-declared canonical."
3. "In your browser, look at the current page, the user-declared canonical, and the Google-selected canonical." — because "This error means that Google thinks that the tested page isn't a duplicate of the user-declared canonical. Instead, Google thinks that the tested page is a duplicate of the Google-selected canonical." Edge reading: "If the Google-selected canonical is the tested page, then Google thinks that the tested page isn't similar to any other pages."

The doctrine sentence that resolves most of these cases: 🟢 "If the user-declared canonical is not similar to the current page, then Google won't ever choose that URL as canonical. A duplicate page must be similar to the canonical. (That's what duplicate means.)" This is why home-page-funnel cross-domain canonicals (§8.6) and syndication canonicals between dissimilar pages fail: they are similarity violations, not tag mistakes.

⚠️ Status drift: the legacy reason "Duplicate, submitted URL not selected as canonical" still appears in the URL Inspection help's status list but is absent from the current Page indexing report help — treat the three statuses above as the current taxonomy.

URL Inspection's canonical fields (all 🟢, URL Inspection help): User-declared canonical — "You can declare a canonical URL in several ways: a <link rel="canonical"> tag, an HTTP header, a sitemap, or a few other methods. There is no guarantee that Google will choose your preferred canonical, but we will take this into consideration." Google-selected canonical — "If the page has no alternate versions, the Google-selected canonical is the inspected URL." Cross-property limit: canonical information is shown "if the canonical version is in a property that you own" (→ Ch 19 for property mechanics).

⚠️ The live test cannot verify canonicals. 🟢 "You can determine the canonical version only in the indexed data; the live test cannot predict whether or not the tested version will be considered canonical" (URL Inspection help); 🟢 "Most notably, duplicate or canonical conditions are not tested in the live test" (Page indexing help); 🟢 "Information about Google's canonical choice is determined at indexing time." A green live-test result proves availability, never canonical selection.

🟢 Metric attribution makes the Performance report a canonicalization instrument. Since April 10, 2019, Search Console assigns "search metrics to the (Google-selected) canonical URL, rather than the URL referred to by Google Search"; "At an individual URL level, you will see traffic shift from any non-canonical (duplicate) URLs to the canonical URL" (Consolidating your website traffic on canonical URLs, Feb 6, 2019). 🟢 The same post fixes the mechanism's scope: "Your alternate property traffic probably won't drop to zero in Search Console because canonicalization is at the page, not the property level, and your mobile property might have some canonical pages." ⚠️ Consequences: a traffic "drop" on a duplicate URL is often consolidation, not loss; a canonical flip moves metrics between URLs — or entire properties — with zero ranking change; and 🟢 "if a canonical URL is in a Search Console property that you don't own, you won't be able to see any of the traffic for your duplicate page" (troubleshooting doc). Rule out a canonical flip before diagnosing any single-URL traffic move (→ Ch 21).

🟢 Serving nuance to keep expectations straight: "The canonical URL is not always the one shown in Search results: for example, if a page has both a desktop and a mobile version, Google will probably show the URL appropriate for the user's device" (URL Inspection help).

8.10 Fixing canonicalization: remediation doctrine and the two-week clock

🟢 Start with the counter-question: "Before troubleshooting, think about whether the Google-selected canonical makes more sense than your preferred canonical URL for your users coming from Google Search" (troubleshooting doc). Google's pick is frequently the defensible one.

🟢 The fix is content-side, not tag-side. Fixing wrong-canonical cases "technically boils down to ensuring that the pages that are clustered together are sufficiently different." Adding a louder tag to a page whose centerpiece checksum matches another page's changes nothing — you must change what gets checksummed (§8.1), then re-cast consistent votes.

🟢 The clock (new July 10, 2026). "Re-evaluation takes time: Even after fixing content issues, Google might hold pages in a duplicate cluster for up to two weeks." And: "Content difference matters: Pages will generally split out faster if the difference between the new content and the other clustered pages is clear and significant." The changelog entry ("Updated the canonicalization troubleshooting guide with clarifications on re-evaluation time… To provide better expectations about how long it takes for canonicalization changes to take effect," July 10, 2026) makes this the first public latency figure for cluster splits — set remediation expectations, and re-crawl monitoring windows, to two weeks minimum.

🟢 Escalation: after fixing, "you can use the Request Indexing feature… to ask Google to re-evaluate the pages that are clustered. However, because this feature is subject to quotas, reserve it for your most important URLs" (→ Ch 19 for quota mechanics).

🟢 CMS failure modes: "Some content management systems (CMS) or CMS plugins can make incorrect use of canonicalization techniques to point to undesired URLs" — verify the rendered head in browser devtools/URL Inspection, and check for both wrong rel=canonical and wrong 3xx redirects; report to the CMS provider. ⚪ SEO-plugin stacking (two plugins each emitting a canonical) and staging URLs baked into templates at deploy are the two most common concrete instances — industry observation, not Google's list.

⚪ The assembled repair sequence (house ordering; each step's mechanism is documented where cited):

1. Confirm the problem is real: is Google's pick actually worse for searchers? (🟢 the counter-question above.)
2. Read the verdict: URL Inspection → Google-selected vs user-declared canonical (§8.9's debug sequence).
3. If the pages should be separate: change centerpiece content until the difference is "clear and significant" — tags alone cannot split a cluster (§8.1, §8.10).
4. If the pages should be merged onto your preferred URL: align every vote — permanent redirect where the duplicate is deprecated, one canonical annotation channel, sitemap listing canonicals only, internal links to the canonical, HTTPS hygiene per §8.5.
5. Remove contradictions: attribute-poisoned link elements, JS canonical rewrites, mixed 302s, robots.txt blocks that hide your annotations (§8.3, §8.4).
6. Request Indexing for the most important URLs only (🟢 quota-bound), then hold for the two-week window before concluding failure.

A docs-history note for citation hygiene: the current three-page set (What is / How to specify / Fix issues) dates to the February 2, 2023 refactor ("the original documentation is split in three distinct sections" — changelog); all three pages showed last-updated 2026-07-10 at fetch time, but the changelog names only the troubleshooting guide in the July 2026 entry.

8.11 Lore quarantine

The field's most durable duplication myths, against what the sections above verified:

The belief	The verified reality	Where
"Duplicate content penalty"	⚠️ Duplication is consolidated, never demoted: "Some duplicate content on a site is normal and it's not a violation of Google's spam policies." Only scraping at scale is a violation — under scaled content abuse.	§8.1
"rel=canonical is a directive"	⚠️ "a hint, not a rule"; Google "might choose a different canonical for various reasons, such as the quality of the content."	§8.2
"Canonical passes X% of link equity / equals a 301"	⚠️ Only that signals (e.g., links) consolidate is documented; no percentage or 301-equivalence exists anywhere. Documented strength labels are qualitative.	§8.2, §8.3
"Keep similarity below N% / trust tool thresholds"	⚠️ No similarity threshold is documented; the mechanisms are centerpiece checksums and "sufficiently different" content.	§8.1, §8.10
"Self-referential canonicals are mandatory"	⚠️ Recommended ("Do include…"), but "none of them are required."	§8.3
"Canonical tags stop Google crawling duplicates"	⚠️ Documented effect is frequency reduction only — duplicates "are crawled less frequently"; on facets, "may, over time, decrease the crawl volume."	§8.1, §8.7
"Have syndication partners canonical back to you"	⚠️ Reversed May 2, 2023 — partner-side noindex is the recommended tool; canonicals between dissimilar pages are never honored.	§8.6
"Set preferred domain / URL parameters in GSC"	⚠️ Both controls are dead (June 18, 2019 and April 2022).	§8.5, §8.7
"www (or non-www) ranks better"	⚪ Google documents no host-variant preference; the only requirement is consolidating on one.	§8.5
"'Duplicate without user-selected canonical' is an error to eliminate"	⚠️ Google: "This is not an error, but is working as intended."	§8.9
"One bad canonical makes Google distrust them sitewide"	⚠️ Per-cluster evaluation; "canonicalization is at the page, not the property level."	§8.9
"hreflang overrides canonical (or vice versa)"	⚠️ Neither: translations aren't duplicates, canonicals must be same-language, and cluster membership is itself a canonical signal.	§8.8

Symptoms & diagnosis

Symptom	Likely cause	Where
"Duplicate, Google chose different canonical than user" on pages you consider distinct	Pages not "sufficiently different" — centerpiece checksums match (boilerplate doesn't count)	§8.1, §8.10
Canonical tag present but apparently ignored	Invalid <head> (element implicitly closes head before the tag); or attribute poisoning (hreflang/lang/media/type on the link element); or conflicting votes across channels	§8.3
Source HTML and rendered HTML show different canonicals	JS rewrites the canonical — pipeline reads it before and after rendering	§8.3, → Ch 6
HTTP URL indexed despite HTTPS version existing (HSTS enabled)	A documented HTTPS-preference breaker: bad certificate, HTTPS→HTTP redirect, insecure dependencies, or canonical pointing at HTTP — HSTS cannot override	§8.5
Old domain's URLs still appearing months after migration	"Alternate names" — normal post-redirect behavior, not a failed migration	§8.4
www/non-www both indexed	Missing or temporary (302) host redirects — temporary redirects don't vote for the target	§8.4, §8.5
Syndication partner outranks you on your own article	Partner didn't noindex; partner-side canonical is no longer the recommended tool and fails on dissimilar pages	§8.6
Google-selected canonical is on a domain you don't control	Copycat site, misconfigured server answering for your host, injected canonical/redirect (hacked), or identical soft-404 twins	§8.6, → Ch 17
Traffic "moved" from one URL/property to another with stable rankings	Canonical flip + metric attribution to the Google-selected canonical (since Apr 2019)	§8.9
Duplicate URL shows zero traffic in your property	Canonical is in a property you don't own — cross-property attribution blindness	§8.9
Live test passes but wrong canonical persists	Live test cannot test canonical/duplicate conditions; selection happens at indexing time	§8.9
Facet/parameter URLs dominating crawl despite canonicals	Canonical only reduces crawl of duplicates over time; robots.txt disallow is the crawl-control tool	§8.7, → Ch 10
Same-language regional pages collapsing into one result	Same-language variants are dedup-eligible; missing/broken hreflang cluster (which is itself a canonical preference signal)	§8.8, → Ch 11
Fixed the content but cluster hasn't split	Up-to-two-week re-evaluation window; difference not "clear and significant"	§8.10

Sources

• What is URL canonicalization — https://developers.google.com/search/docs/crawling-indexing/canonicalization (fetched 2026-08-04; page last-updated 2026-07-10)
• How to specify a canonical with rel="canonical" and other methods — https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls (fetched 2026-08-04; page last-updated 2026-07-10)
• Fix canonicalization issues — https://developers.google.com/search/docs/crawling-indexing/canonicalization-troubleshooting (fetched 2026-08-04; page last-updated 2026-07-10)
• Redirects and Google Search — https://developers.google.com/search/docs/crawling-indexing/301-redirects (fetched 2026-08-04; page last-updated 2026-04-14)
• Google Search documentation updates (changelog) — https://developers.google.com/search/updates (fetched 2026-08-04; entries: Jul 10 2026; Dec 17 2025; Dec 17 2024; Feb 15 2024; May 2 2023; Feb 2 2023)
• Page indexing report — Search Console Help — https://support.google.com/webmasters/answer/7440203 (fetched 2026-08-04)
• URL Inspection tool — Search Console Help — https://support.google.com/webmasters/answer/9012289 (fetched 2026-08-04)
• Avoid article duplication in Google News — Publisher Center Help — https://support.google.com/news/publisher-center/answer/9606800 (fetched 2026-08-04)
• Handling legitimate cross-domain content duplication — Google Search Central Blog, Dec 15 2009 (with current disclaimer) — https://developers.google.com/search/blog/2009/12/handling-legitimate-cross-domain (fetched 2026-08-04)
• Consolidating your website traffic on canonical URLs — Google Search Central Blog, Feb 6 2019 — https://developers.google.com/search/blog/2019/02/consolidating-your-website-traffic-on (fetched 2026-08-04)
• Bye Bye Preferred Domain setting — Google Search Central Blog, Jun 18 2019 — https://developers.google.com/search/blog/2019/06/bye-bye-preferred-domain-setting (fetched 2026-08-04)
• Spring cleaning: the URL Parameters tool — Google Search Central Blog, Mar 28 2022 — https://developers.google.com/search/blog/2022/03/url-parameters-tool-deprecated (fetched 2026-08-04)
• Managing crawling of faceted navigation URLs — https://developers.google.com/crawling/docs/faceted-navigation (fetched 2026-08-04; page last-updated 2025-12-18)
• Localized versions of your pages — https://developers.google.com/search/docs/specialty/international/localized-versions (fetched 2026-08-04; page last-updated 2025-12-22)
• URL structure best practices — https://developers.google.com/search/docs/crawling-indexing/url-structure (fetched 2026-08-04; page last-updated 2025-12-10)
• Spam policies for Google web search — https://developers.google.com/search/docs/essentials/spam-policies (fetched 2026-08-04)
• Search Off the Record, episode 9 — official transcript PDF (published Nov 4 2020; via goo.gle/sotr009-transcription) — https://traffic.libsyn.com/secure/search-off-the-record/Search_Off_the_Record_-_9th_episode_1.pdf (fetched 2026-08-04; V2 re-fetched the PDF and re-confirmed all quoted passages and timestamps verbatim; the Nov 4 2020 publication date re-confirmed against the libsyn episode page, 2026-08-04)