Google Chose www as Canonical? Diagnose Non-www Indexing

A BigSEO migration case reported that four old www pages remained indexed after a move to non-www, despite a claimed 301 redirect. That observation does not, by itself, prove that Google chose www as canonical: it could reflect old crawl data, a redirect failure on specific URLs, or a genuine canonical-signal conflict.

If Google chose www as canonical in Search Console—or you suspect it has—you need to identify which situation applies before requesting more indexing. This guide gives you a repeatable way to verify redirects, rel="canonical", internal links, XML sitemaps, and Google Search Console so the preferred non-www URLs have consistent signals.

First, separate the observation from the diagnosis

Seeing a www URL in a site: search, analytics report, or old search result is not the same as seeing a canonical decision in Google Search Console. Google may continue displaying old URLs while it recrawls and processes a host migration, and site: queries are not a complete or definitive index report.

The specific Search Console diagnosis is Duplicate, Google chose different canonical than user. In URL Inspection, that diagnosis is supported by two fields: User-declared canonical and Google-selected canonical. Only when those values differ do we know Google selected a different representative URL than the page requested.

For example, these are three distinct situations:

1. Four www pages remain visible, but the non-www URLs have not been recrawled. This is usually an incomplete processing or recrawl question, not yet proof of a canonical conflict.
2. `https://www.example.com/services/` still returns `200 OK`. This is a redirect implementation problem because both hosts can serve duplicate content.
3. The non-www page self-canonicalizes, but URL Inspection says Google-selected canonical is www. This is a canonical-signal conflict or a decision Google has not yet reassessed.

Google’s canonicalization documentation explains that redirects and rel="canonical" are strong signals, while sitemap inclusion is weaker. No single method guarantees Google’s selection; consistency across the site gives Google the clearest evidence.

Use this decision tree before requesting indexing

Test one representative URL at a time. Start with a high-value page such as https://www.example.com/services/, then test the homepage, one category or product page, and one recently published URL. A sample of four to 10 URLs often reveals whether the issue is sitewide or template-specific.

1. Does the old www URL make one direct permanent redirect to the matching non-www URL? If not, repair redirects first.
2. Does the final non-www URL return `200 OK` and declare its own non-www canonical? If not, fix page markup or delivery.
3. Do active XML sitemaps, internal links, hreflang values, and structured-data URLs use non-www? If not, remove the old-host references.
4. Can Google crawl and index the final non-www page? Check URL Inspection for robots rules, noindex, errors, and the last crawl date.
5. After Google recrawls the corrected page, do Google-selected and user-declared canonicals still differ? If yes, audit the duplicate cluster and page quality rather than repeatedly submitting the same URL.

This sequence prevents a common mistake: asking Google to recrawl a URL while a sitemap, template, or redirect still tells Google that www is preferred. Submission can encourage discovery or recrawling; it cannot override Google’s canonicalization systems.

Verify redirects across every old URL variant

A www-to-non-www migration should preserve the equivalent path and relevant query string. A valid pattern looks like this:

• http://www.example.com/ → https://example.com/
• https://www.example.com/about/ → https://example.com/about/
• https://www.example.com/product?id=42 → https://example.com/product?id=42

Use curl -I, browser developer tools, or an HTTP status checker. The old URL should return a server-side 301 Moved Permanently or 308 Permanent Redirect, and the final destination should return 200 OK. Google documents redirects as a strong signal for URL moves, but the redirect must be available when Google crawls the old URL.

Three redirect tests that catch most migration faults

Test inner pages, not only the homepage. A CMS rule may redirect www.example.com/ correctly while www.example.com/services/ loads as a duplicate, redirects to the homepage, or returns an error. Google evaluates the individual URLs it discovers.

Eliminate unnecessary chains. http://www → https://www → https://non-www may still be processed, but a one-hop redirect to the final HTTPS non-www URL is clearer and easier to maintain. Check that CDN rules, such as Cloudflare redirects, do not conflict with Apache, Nginx, or application-level rules.

Test the public response. A local configuration file is not proof of live behavior. Caches, reverse proxies, geographic routing, and host settings can change the response after deployment. Also avoid blocking the old www URLs in robots.txt if Google needs to crawl them to see the permanent redirect.

Make the final non-www page self-canonical

After redirect testing, inspect the HTML source and rendered page for the final destination. A normal self-referencing canonical looks like this:

<link rel="canonical" href="https://example.com/services/">

The final 200 OK non-www page is the priority. It should not declare https://www.example.com/services/ as canonical, point to the homepage, or contain multiple contradictory canonical tags. Google advises using absolute URLs in canonical annotations to reduce ambiguity.

Look beyond the main page template

Check at least one URL from each template family: posts, category pages, products, paginated archives, language variants, and faceted pages where applicable. A WordPress SEO plugin, custom theme, CDN, and ecommerce extension can each influence canonical output.

Also inspect canonical HTTP headers. A server can send a Link: <...>; rel="canonical" header even when the HTML contains a different value. If two systems emit conflicting declarations, remove the conflict instead of assuming Google will honor the preferred one.

A canonical annotation on an old URL that already redirects is generally secondary to the redirect. The decisive markup is on the final non-www page that Google can crawl and potentially index.

Replace stale www URLs in discovery signals

Google uses links and sitemaps to discover URLs and understand site structure. An XML sitemap does not force indexing, but listing old www URLs after a non-www migration sends a weaker, avoidable contradictory signal.

Search every active sitemap file for www.. The live sitemap should list only canonical, indexable non-www URLs that return 200 OK; it should not include redirected pages, noindex URLs, or alternate-host duplicates. Submit the corrected sitemap in the relevant Google Search Console property.

Update internal links too, including navigation, breadcrumbs, HTML sitemaps, hreflang annotations, Open Graph URLs, structured data, and links in JavaScript menus. A sitewide footer link to www is only one signal among many, and is unlikely to determine canonicalization alone, but it can add to an otherwise inconsistent migration.

Google’s site-move guidance recommends updating internal links after redirects are in place. Redirects should protect visitors and legacy links; normal site architecture should point directly to the preferred non-www URLs.

For ongoing publishing, our guide to automatically submitting new pages to Google explains why checking freshly generated sitemap entries matters. A plugin update or separate product sitemap can otherwise reintroduce www URLs long after the original migration.

Confirm Google’s actual decision in Search Console

Use URL Inspection on both host versions, beginning with the preferred non-www URL. For https://example.com/services/, record these fields:

• User-declared canonical: should be the exact non-www URL.
• Google-selected canonical: should ultimately match the non-www URL.
• Last crawl: tells you whether Google has seen the corrected version.
• Crawl allowed and indexing allowed: should be positive for a page intended to rank.
• Page fetch and rendering results: useful when JavaScript or an error page may be masking the real content.

Then inspect https://www.example.com/services/. Once Google processes the migration, it should understand the non-www destination as the representative URL. Search Console’s Page indexing report provides grouped examples, but individual URL Inspection is better for confirming the exact source and destination in a high-priority case.

Use a Domain property where possible because it covers protocols and subdomains under the verified domain. URL-prefix properties can still be useful when diagnosing a specific host, but they can make a single migration look fragmented across http, https, www, and non-www variants.

Our comparison of Search Console and indexing tools explains the practical division: Search Console shows Google’s reported indexing and canonical state, while a monitoring workflow helps us detect newly published URLs and stale sitemap entries.

When the old host remains after you fix everything

Google does not publish a fixed number of days for recognizing a changed canonical. Its recrawl guidance says updates may take from a few days to a few weeks, depending on crawl scheduling and site conditions. A host move across hundreds or thousands of URLs can take longer because Google must revisit old URLs, follow redirects, process destinations, and reassess duplicate groups.

Treat a www result as a likely processing delay when the inspected non-www URL has an old crawl date. Treat it as a stronger diagnostic signal when Google has recrawled the corrected non-www page and repeatedly continues selecting www.

Use this controlled recheck process:

1. Record URL Inspection results for five to 10 representative URLs.
2. Fix redirects, canonicals, internal links, and sitemaps before making recrawl requests.
3. Request indexing through URL Inspection for the most valuable non-www pages.
4. Recheck after the Last crawl date changes rather than checking the same stale report daily.
5. Compare organic landing-page URLs and Page indexing samples for recurring www patterns.

If the problem persists after recrawling, inspect whether the non-www pages are substantially equivalent to stronger www URLs, whether another sitemap is still active, or whether non-www pages have separate quality problems such as soft 404s, thin content, login walls, or noindex headers.

Where Indexa and submission workflows fit

Technical consolidation comes first. Indexa can monitor XML sitemaps locally for new and changed URLs, helping teams catch a newly generated www URL, a stale sitemap export, or a page that needs discovery after the correct non-www signals are live. It does not make Google accept a canonical that conflicts with redirects, page markup, or internal linking.

There is also an important Google limitation: Google’s Indexing API is intended for pages with JobPosting structured data and BroadcastEvent pages in a live stream. It is not a general-purpose API for ordinary service pages, category pages, ecommerce products, or blog posts. We should not use it to imply that those ordinary URLs can legitimately be pushed into Google’s index.

For eligible job-posting and livestream URLs, Indexa’s Google submission workflow can be relevant after the URL architecture is corrected. For broader URL-change notifications, Indexa can also send discovered sitemap URLs through IndexNow-supported search-engine workflows. Neither Google API notifications nor IndexNow guarantees indexing or changes Google’s canonical choice.

Our Google Indexing API setup guide covers the eligibility boundary, while our comparison of Google Indexing API versus IndexNow for bulk URLs explains why these are separate workflows. For this migration, use automation to maintain clean discovery signals—not as a substitute for fixing the host setup.

FAQ

Why is Google choosing the www version as canonical instead of the non-www version?

Google may be seeing stronger evidence for www, such as incomplete redirects, non-www pages that still declare www canonicals, stale internal links, or old sitemap URLs. It can also be normal processing delay. Confirm the diagnosis in URL Inspection by comparing User-declared canonical with Google-selected canonical; an indexed www result alone does not prove the cause.

How do I redirect the www version to the non-www version?

Configure a server-side 301 or 308 from every www URL to its exact non-www equivalent. Preserve paths and relevant query strings, then test both HTTP and HTTPS variants. For example, https://www.example.com/page/ should make one direct hop to https://example.com/page/, which should return 200 OK.

How long does Google take to recognize a changed canonical URL?

Google gives no guaranteed timeline. Its guidance says recrawling and indexing updates can take days to weeks, and a large host migration can take longer. Check the Last crawl date in URL Inspection. If Google has recrawled the corrected non-www URL and still chooses www, re-audit redirects, canonicals, links, sitemaps, and page quality.

What does “Duplicate, Google chose different canonical than user” mean?

It means Google considers the inspected page a duplicate or near-duplicate and selected a different representative URL than the one you declared. Compare the User-declared canonical and Google-selected canonical fields in URL Inspection. Then make redirects, self-canonicals, internal links, and XML sitemap entries consistently support the preferred host.

Should both www and non-www versions be indexed, and how can I verify the preferred one?

No. Identical content should normally have one indexed host, with the other permanently redirected. Inspect representative non-www URLs in Search Console and confirm that Google-selected canonical matches the non-www address. Also verify that active sitemaps and internal links use non-www; use site: searches only as a supporting spot check.