Open Search Console on almost any treatment center website that has been live for a few years and you will usually find a line in the Page indexing report that reads “Duplicate, Google chose different canonical than user.” It is not really an error. It is Google telling you that the signals on your site disagree with the canonical tag you wrote, and that it believed the other signals.
This post covers what a canonical tag does, the three declaration methods Google documents, the specific conditions under which Google sets your choice aside, what we did on our own site, and a two-minute check you can run today.
What a canonical tag actually does
When the same content is reachable at more than one URL, Google groups those URLs and picks one to show in search results. That chosen URL is the canonical. Links and other signals for the group are consolidated onto it, and the other addresses are treated as duplicates that usually do not appear in results.
A treatment center site produces duplicates without anyone intending to. The same admissions page can be reachable with and without a trailing slash, with a ?utm_source= tag from a Google Business Profile website link, with a gclid parameter appended by Google Ads, or under both an old and a new path after a redesign. Google’s own documentation uses nearly this exact case as its example: a page reached through a URL carrying a gclid parameter instead of its clean address.
The three methods Google documents, and how strong each one is
Google’s canonicalization documentation lists three ways to declare a preferred URL, ranked by how strongly each influences the outcome: a permanent redirect is a strong signal, a rel=”canonical” link annotation is a strong signal, and inclusion in an XML sitemap is a weak signal. A canonical tag is therefore a hint that Google weighs against other evidence, not a command it is required to follow. When the redirects, the sitemap and the internal links all name the same URL as the canonical tag, the signals stack; when they name different URLs, Google decides between them itself.
That is from Google Search Central’s guide to specifying a canonical URL, which also notes that none of these methods is strictly required. If you declare nothing, Google picks the version it judges best. The reason to declare one anyway is control: you choose which address searchers see, and you keep reporting for a page in one place instead of spread across parameter variants.
Google also applies signals you never set explicitly. It prefers HTTPS over HTTP as the canonical, unless the HTTPS version has an invalid certificate, redirects through HTTP, loads insecure dependencies other than images, or itself carries a canonical pointing to the HTTP version.
Why Google sets aside the canonical you declared
Any one of these, each drawn from Google’s documentation, can produce that status.
- Canonical placed after an invalid head element: Google’s valid page metadata guidance says that once it finds an element such as an
imgoriframeinside<head>, it assumes the head has ended and stops reading, so a canonical tag below that point is never seen. - Conflicting declarations: Google says not to name one URL for a page in the sitemap and a different URL for the same page in rel=”canonical”, because the two cancel each other out as a statement of preference.
- Internal links to the duplicate: Google asks sites to link internally to the canonical URL, so a menu or footer that links to the parameterized or non-preferred version keeps pointing Google toward the address you told it not to use.
- A relative or rewritten canonical: Google supports relative paths but recommends absolute URLs, and says JavaScript should not change a canonical element already set in the HTML source.
- A broken HTTPS setup: an invalid certificate or an HTTPS-to-HTTP redirect makes Google prefer the HTTP version very strongly, and Google states that HSTS cannot override that preference.
- Two canonical tags on one page: when a theme and an SEO plugin each write their own, the page sends two answers to one question, which is the same conflict as the sitemap case in a different place.
The head-element problem staff never see
The first cause on that list is the one we look for first in an audit, because it is invisible from every screen a marketing team normally checks. The SEO plugin settings show the right canonical. View Source shows the tag is present. The page looks normal. What nobody sees is that something earlier in the head has already closed it, as far as Google is concerned.
On behavioral health sites the culprit is usually not code a developer wrote. It tends to be a third-party snippet pasted into the header through a “header scripts” box: an advertising pixel whose <noscript> fallback contains an <img>, a verification-of-benefits or chat widget that injects an <iframe>, or a tracking tag installed by a vendor who has since moved on. Google’s guidance is explicit that if you must use such elements in the head, place them after the elements you want Google to read. Moving the snippet below the SEO plugin’s output, or into the body where it belongs, fixes it without touching the canonical at all.
Healthcare sites have a second reason to look closely at those header snippets: tracking pixels on pages about treatment can raise their own privacy and HIPAA questions, separate from SEO, and the audit that finds them is a good moment to review what each one collects.
What we did on our own site: redirects, not canonical tags
In September 2026 we consolidated our own internet-marketing-services-{city} location pages into the matching digital-marketing-agency-{city} pages. That retired ninety URLs. We could have left both sets live and pointed canonical tags from the old pages to the new ones. We did not, for the reason Google gives in the same documentation: redirects are the method to use when deprecating a duplicate page. A canonical tag leaves the duplicate live, crawlable and reachable by visitors from old links; a 301 sends people and crawlers to one address. So each of the ninety old URLs now returns a 301 to its replacement, the old pages are unpublished, and our publishing process refuses to link to the retired addresses, so our own internal links do not keep pointing at them.
The operational lesson is the inconvenient one: a canonical tag is the cheapest fix to apply and the easiest one for Google to overrule. If a page should no longer exist, redirect it. Keep canonical tags for duplicates that genuinely need to remain live, such as tracking-parameter URLs.
A two-minute check you can run today
- In Search Console, run the URL Inspection tool on your admissions page and your insurance page. Compare “User-declared canonical” with “Google-selected canonical.” If they differ, Google has overruled you on that page.
- Open the same page in Chrome, press F12, choose Console, and paste this line:
[...document.querySelectorAll('link[rel="canonical"]')].map(l => l.href + ' in ' + l.parentElement.tagName)
You want exactly one result, an absolute URL matching the address you want indexed, followed byin HEAD. If it saysin BODY, something above the tag closed the head early; the browser’s parser handles animgoriframein the head the same way Google describes. If you get two results, two tools are writing canonicals. - In the Page indexing report, open “Duplicate, Google chose different canonical than user” and look at the example URLs. Parameter variants there are usually harmless; core service or admissions pages there are not.
What not to do instead
Google’s documentation lists several fixes that look reasonable and are not. Do not use robots.txt to handle duplicates; a blocked URL can still be indexed without its content, which we cover in robots.txt vs. noindex. Do not use the Search Console Removals tool, which hides every version of a URL rather than choosing one. Do not add noindex to duplicates within the same site, because it removes the page from Search entirely instead of consolidating it. And do not point a canonical at a URL fragment, since Google generally does not support fragments.
Why this matters for AI search as well
Google’s AI Overviews and AI Mode draw on the same index as standard results, and Google states there are no additional technical requirements for appearing in them beyond normal Search eligibility. That means canonicalization decides which version of your admissions page is even in the pool. If Google has selected a parameter URL or a retired path, that is the URL any citation would point to. There is no special AI tag that changes this; getting the ordinary canonical signals to agree is the work. Our answer engine optimization service starts from exactly that kind of technical baseline.
If your Page indexing report shows core pages in the “Google chose different canonical” bucket and you are not sure which signal is responsible, our SEO services include the head-element, redirect and internal-link review described above.
