site:yourdomain.com returns a mix of http://yourdomain.com/article, https://yourdomain.com/article, http://www.yourdomain.com/article, and https://www.yourdomain.com/article — four URLs serving identical content. Each variant has collected its own slice of backlinks over the years, but to Google they look like four thin near-duplicates competing with each other instead of one strong page.
Fastest fix: pick ONE canonical host (e.g. https://yourdomain.com), then make the other three return a 301 redirect to it at the platform/server level — not just a rel="canonical" tag. A rel="canonical" tag alone is a hint, not a rule; the 301 is what actually forces consolidation. Add HSTS, point your sitemap and internal links at the canonical, then wait 4–12 weeks for Google to follow the redirects and merge the equity.
This guide consolidates HTTPS not forced and www and non-www both open into one migration plan.
Which bucket are you in
Run these two checks first — they tell you which redirects are actually missing:
# 1. Do all four variants resolve to a 200 (bad) or 301 (good)?
for u in http://yourdomain.com https://yourdomain.com \
http://www.yourdomain.com https://www.yourdomain.com; do
echo "$u -> $(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' "$u")"
done| What you see | What it means | Fix |
|---|---|---|
Any http:// returns 200 | HTTPS is not forced | Steps 2–3 (301 + HSTS) |
Both apex and www return 200 over HTTPS | No host redirect | Step 2 (pick one, 301 the other) |
All non-canonical variants already 301 | Redirects are fine; it’s an index-lag / history problem | Steps 4–8 (signals + patience) |
Then confirm what Google actually thinks. In Search Console, run the URL Inspection tool on a non-canonical variant and read Page indexing → Google-selected canonical. If it does not match your User-declared canonical, Google is overriding your tag because the redirect or other signals are missing or conflicting. (Note: the live test never shows Google-selected canonical — only the indexed result does.)
Common causes
Ordered by hit rate, highest first.
1. Site predates HTTPS-by-default and http was never redirected
Sites launched before roughly 2018 often served http natively. HTTPS was bolted on later but http was left answering 200 with no forced redirect, so years of backlinks accumulated on the insecure variant.
How to spot it: site:yourdomain.com returns http:// URLs; the curl loop above shows http:// returning 200 instead of 301.
2. Both www and apex serve content
Hosting exposed both hostnames and no host-level redirect was configured.
How to spot it: curl -sI https://yourdomain.com and curl -sI https://www.yourdomain.com both return HTTP/2 200.
3. Years of external links used inconsistent versions
Even with HTTPS forced today, third-party sites still link to old www/non-www variants. Google’s index still has those URLs mapped from past crawls.
How to spot it: A backlink report (Ahrefs, Majestic, or Search Console → Links → External links) shows inbound links spread across multiple host/protocol variants.
4. CDN serves all four variants directly
A CDN or proxy without canonical-redirect rules answers every variant from cache.
How to spot it: Check the CDN’s redirect/rewrite rules. With none configured, all four hostnames pass straight through to origin.
5. Self-canonical tags set per variant
http://yourdomain.com/article canonicals to itself; https://www.yourdomain.com/article canonicals to itself. With no redirect, all four self-canonical and Google has no signal to unify them.
How to spot it: View source on each variant. If all four declare a different self-canonical, no version is winning.
6. Sitemap lists multiple variants
The sitemap mixes http and https, or www and non-www. Since sitemap inclusion is itself a (weak) canonicalization signal, this actively muddies the picture.
How to spot it: grep -oE 'https?://[^<]+' sitemap.xml | sed -E 's#(https?://[^/]+).*#\1#' | sort -u — should print exactly one origin.
Shortest path to fix
Step 1: Decide the canonical host
Pick one and write it down:
https://yourdomain.com/(apex), orhttps://www.yourdomain.com/(www)
There is no SEO difference. Practical tiebreakers: www is a CNAME so it’s easier to point at a CDN and survives apex-flattening quirks; apex is shorter and friendlier in print.
Step 2: 301-redirect the other three to canonical
Every non-canonical variant must answer with a 301 (permanent) — not 302, not a meta-refresh — and preserve the path:
| From | To (example: apex canonical) |
|---|---|
http://yourdomain.com/* | https://yourdomain.com/[path] |
http://www.yourdomain.com/* | https://yourdomain.com/[path] |
https://www.yourdomain.com/* | https://yourdomain.com/[path] |
Platform notes:
- Vercel: add both domains, mark one as primary; Vercel auto-301s the rest. See Vercel domain redirects.
- Cloudflare: use a Redirect Rule or Bulk Redirects (Page Rules are legacy). Enable Always Use HTTPS for the protocol leg.
- Nginx:
return 301 https://yourdomain.com$request_uri;in the non-canonicalserverblocks. - Firebase Hosting: redirects in
firebase.jsonplus a canonical custom domain.
Step 3: Add HSTS
Send this response header from the canonical host:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preloadThis tells browsers to skip http entirely on future visits. To later qualify for the HSTS preload list, the header needs max-age of at least 31536000 (one year), includeSubDomains, and preload; every subdomain must serve valid HTTPS and every http request must 301 (not 302) to HTTPS. Only submit once that’s been stable for a while — preload is hard to reverse.
Step 4: Point internal links at the canonical
# Find hardcoded non-canonical or protocol-relative URLs in the codebase
grep -rnE "http://yourdomain\.com|//www\.yourdomain\.com" src/ public/Internal links are a consolidation signal, so a stray http:// or www link works against you. Use absolute canonical URLs in nav, footers, and content.
Step 5: Regenerate the sitemap with canonical URLs only
One entry per page, on the canonical host. Remove any leftover http or non-canonical-host entries, then resubmit in Search Console.
Step 6: Make every page self-canonical to the canonical host
<link rel="canonical" href="https://yourdomain.com/article/" />Use absolute URLs and keep trailing-slash usage consistent with what the server actually serves (a /article vs /article/ mismatch creates yet another duplicate).
Step 7: File Change of Address only for a true domain change
The Change of Address tool is for moving between different domains (old.com → new.com), not for unifying http/https/www on the same domain — host/protocol consolidation is handled entirely by the Step 2 301s. If you are also changing the registrable domain: Search Console → Settings → Change of address, with the new property already verified. As of 2026 Google recommends submitting the request for all old variants (apex, www, and any subdomains) even ones you don’t actively use. Signals forward for 180 days, so keep the redirects live at least that long. See Site moves with URL changes.
Step 8: Wait 4–12 weeks and monitor
Google has to re-crawl each variant, see the 301, and merge the equity — this is not instant. Watch:
- Search Console → Pages (Indexing): non-canonical variants should move into the “Page with redirect” bucket.
- URL Inspection: for a non-canonical URL, Google-selected canonical should now equal your canonical host.
- Performance: total clicks should hold steady or rise as split traffic consolidates onto one URL.
How to confirm it’s fixed
- The curl loop in “Which bucket are you in” shows every non-canonical variant returning
301to the canonical, with the path preserved. curl -sI https://yourdomain.com | grep -i strict-transportreturns your HSTS header.- URL Inspection on an old variant reports Google-selected canonical = your canonical host (only visible for indexed URLs, so this lags the redirect by weeks).
site:yourdomain.comincreasingly returns only canonical URLs. Old variants linger in the index for weeks — that’s normal, not a regression.
Easy to misdiagnose as
Adding <link rel="canonical"> and assuming you’re done. The tag is a hint Google may ignore; both versions still return 200 and keep getting indexed. The platform-level 301 is the strong signal that forces consolidation. Per Google’s canonicalization docs, redirects and HTTPS-vs-HTTP both carry weight alongside the canonical tag and sitemap.
When this is not on you
Even after every fix is in place, old indexed variants persist for weeks while Google re-crawls. Do not panic over each stale URL still showing in a site: query, and do not use the URL Removal tool to “clean them up” — it hides all versions, including your canonical, and does nothing for consolidation.
Prevention
- Force HTTPS and choose
www-vs-apex on day one of any new site. - Use absolute canonical URLs in canonical tags, sitemap, OG tags, and JSON-LD.
- After any infrastructure or DNS change, re-run the curl loop to confirm all variants still
301to canonical. - Audit external backlinks quarterly; for high-value links pointing at a non-canonical variant, ask the linking site to update where practical (the
301already forwards equity, so this is polish, not a fire).
FAQ
- www or non-www — does it matter for SEO? No. Pick one and stay consistent.
wwwis easier to point at a CDN (it’s a CNAME); apex is a shorter URL. - Will Google actually merge the link equity? Yes, through the
301— typically over 4–12 weeks. Backlinks to non-canonical variants keep passing equity through the redirect. - Do I need the Change of Address tool for an http-to-https switch? No. Same domain, just protocol/host — the
301s handle it. Change of Address is only for moving to a different registrable domain. - Why does Search Console still show “Duplicate, Google chose a different canonical than user”? Conflicting signals: a missing redirect, internal links to the wrong variant, or a sitemap listing multiple hosts. Fix the redirect first (Step 2), then align internal links and sitemap.
- Is a
302redirect good enough? No. Use301(permanent). A302signals a temporary move, won’t forward equity reliably, and disqualifies you from HSTS preload. - My host won’t let me redirect the apex — now what? Use a CDN/proxy in front (Cloudflare Redirect Rules, or a Vercel/Netlify domain) to issue the apex
301, since many DNS providers can’t redirect a bare apex directly.