Why your www vs non www indexing is failing (and the fix)

Open with a specific scenario the reader recognizes in 2 sentences.

Most teams I inherit have at least one version of the domain that Google treats as a separate property, and the indexing split kills the SEO potential before the content even ranks. If you’ve ever logged into Google Search Console and seen two separate “Indexing” reports—one for www.example.com and one for example.com—you know the panic of watching authority fragment. The search volume you built for one version slowly bleeds into the void of the other, and neither version achieves the visibility it should. I’ve had clients stare at me across the table (or Zoom window) when I ask which domain version they want Google to treat as the “real” one. Usually the answer is a shrug—they’ve just let the site grow organically, adding http, https, www, non www, and tracking parameters willy-nilly. If that sounds like your setup, you’re not alone.

The www vs non www indexing split: why it happens

Google’s crawler is polite. When it sees both http://example.com and http://www.example.com, it doesn’t automatically assume they’re the same property with a minor prefix difference. It treats them as two distinct URLs unless you force the issue. The indexing split happens for three core reasons, and understanding these is half the battle before any fix is applied.

No canonical signal

If you haven’t set a preferred domain in Google Search Console, or if you’ve left the .htaccess or server config wide open, Google will index whichever version it crawls first and feels like keeping. I’ve seen e-commerce sites where the www version ranked for brand terms while the non www version ranked for product terms—purely because the authority was split 50/50. The crawler doesn’t know which one you “intended,” so it keeps both in the index, often assigning different crawl budgets to each. This fragmentation is insidious because it doesn’t always announce itself with an error message; it just quietly dilutes your rankings until one day you realize your traffic has plateaued for no apparent reason.

Internal link chaos

This is the most common root cause I fix. If your WordPress permalinks point to %domain%/%postname% and you’ve changed domains or added www retroactively, you end up with a site architecture where half the navigation goes to one version and half to the other. Every internal link is a vote; if half your votes go to www and half to non www, neither version accumulates enough strength to break into the top positions. I once audited a large content site where the main navigation linked to example.com/blog/post-title but the footer widgets still hardcoded www.example.com/blog/post-title. The result? Googlebot crawled both paths, indexed both URLs, and the site never gained the authority momentum it needed to rank competitively for its target keywords.

Redirect chains or loops

A misconfigured 301 that sends non www to www but then has a second rule that rewrites www back to non www creates a loop Googlebot gives up on, or worse, it indexes both because the redirect never fires consistently. I once audited a site where the IT team had added a Cloudflare page rule and an .htaccess rule simultaneously—two different paths to the same destination, and Google saw through both. The crawler hit the .htaccess rule first, followed the 301, then hit the Cloudflare rule, and because the final destination didn’t match the initial expectation exactly, it decided to index the original URL anyway. These double-path scenarios are a technician’s nightmare and an SEO’s nightmare fuel, because they look like they should work on paper but fail in the browser and in the index simultaneously.

The one move that fixes it: canonical consolidation

If you’re reading this because you’ve already tried the “just pick one” approach and it didn’t stick, listen closely. The fix isn’t just changing a setting in GSC—that’s step one. The actual mechanical fix is a unidirectional 301 redirect from the non-canonical domain to the canonical one. Here’s the exact sequence I run on every audit where the split is active, and I’m giving you the exact code and configuration so you can implement it yourself.

Step 1: Pick your canonical and lock it

Before moving a single line of code, you need to decide which version is the money site. If you want the clean, keyword-friendly example.com (no www), that’s your canonical. If you’ve built all your backlinks and brand recognition on www.example.com, keep that one. Write it down on a notepad or a ticket somewhere—this becomes your reference point for every other step. I’ve seen teams flip-flop on this decision six months into a project, which re-introduces the split all over again. Lock it in before you touch the server config.

Step 2: Install the 301 at the server level

This is the engine of the fix. The 301 redirect tells Google’s crawler that the non-canonical version has permanently moved to the canonical version, and to transfer the authority metrics to the destination. For Apache servers, the .htaccess rule is straightforward. For a www-to-non www redirect, the code looks like this:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^(.*)$ http://example.com/$1 [L,R=301]

I put this exact block in the root .htaccess file and upload it via FTP or the hosting control panel. The R=301 flag tells Google this is permanent, and the L flag stops processing further rules if something else on the server tries to rewrite the URL. For non www-to-www, you just flip the conditions—match example\.com and redirect to www\.example\.com. If you’re on Nginx, the config block goes into nginx.conf or the server block, and looks like:

server_name example.com www.example.com;
return 301 $scheme://www.example.com$request_uri;

Test it manually in a browser—type the non-canonical version and make sure it instantly loads the canonical version without a second delay. If you see a double-hop or a redirect chain, troubleshoot the server config before proceeding, because Google will penalize redirect chains in the indexation phase.

Step 3: Update Google Search Console

Now that the server is doing the heavy lifting, you need to align Google’s UI with the reality on the ground. Log into GSC, go to Settings > Site Settings, and set the “Preferred domain” to match the canonical you just redirected to. This tells Google’s reports to prioritize that version. It won’t force indexing on its own, but it aligns the data you’re looking at with the crawl reality. I always do this step immediately after the redirect goes live, because it gives me a single source of truth in the dashboard while Google re-evaluates the site architecture.

Step 4: Clean the internal link profile

The redirect handles the inbound traffic, but internal links are what keep the crawler moving through the site. Open a crawler—Screaming Frog, Sitebulb, even the free version will do for a quick check—and export all internal links. Look for any that point to the non-canonical version. Replace them with the canonical URL. If you have a CMS that auto-generates links, now’s the time to update the template setting so future content doesn’t re-introduce the split. I’ve had clients who thought the redirect was enough, only to find that their new blog posts were automatically linking to the www version because the WordPress settings hadn’t been updated. Don’t let that be you.

Step 5: Submit a clean sitemap

Generate a sitemap that only includes URLs for the canonical domain. In GSC, under Sitemaps, remove any old entries for the non-canonical version and submit the new one. Google will recrawl and re-evaluate the signals now that the redirect and internal links are congruent. I typically see the canonical domain gain back the authority lost to the split within two to three weeks of Google re-evaluating the redirect. The non-canonical version usually drops out of the index entirely, or at least stops receiving impressions, because the link equity is no longer diluted. If you have a large site, submit the sitemap via the API or through Google Search Console’s manual submit button, and then wait for the “Page indexing” report to update.

I’ve walked clients through this exact five-step process on sites with 200+ indexed pages split between domains, and the typical pattern is exactly what the theory predicts: the canonical domain gains back the authority lost to the split within two to three weeks of Google re-evaluating the redirect. The non-canonical version usually drops out of the index entirely, or at least stops receiving impressions, because the link equity is no longer diluted. It’s not magic—it’s just consistent technical execution.

Common mistakes that re-split the index

Even after you’ve done the redirect and GSC setup, I see the same three errors creep back in during subsequent site changes. These are the “maintenance traps” that catch teams off guard.

Switching CMS themes or plugins without a redirect audit

A popular SEO plugin might update its permalink structure, suddenly pointing all new posts at the non www version while the old ones 301 to www. Run a link audit after any major plugin update. I had a client who updated their Yoast SEO plugin, and suddenly every new post was getting indexed at the non-canonical version because the plugin’s default setting had reverted. The old posts were fine because of the 301, but the new content was starting the split all over again. Set a calendar reminder to check internal links after every major CMS update.

Adding tracking parameters carelessly

?utm_source=facebook on a non www URL, but the redirect only catches the base URL. Google may index the parameterized version as a separate entity. Stick to ?utm_source=facebook on the canonical domain only, or use a parameter handling rule in GSC that treats them as duplicates. I once saw a paid media team add UTM parameters to their Twitter links pointing at the non www version, and Google immediately started treating those parameterized URLs as unique pages. The fix was simple: move all campaign tracking to the canonical domain, but it required a conversation with the marketing team to get them on board.

Forgot www in the robots.txt

If your robots.txt blocks Disallow: / for the non www version but allows crawl on www, Google will index what it can crawl. Ensure your robots.txt rules apply to both, or explicitly allow the version you want indexed. I’ve seen this mistake on sites that have separate robots.txt files for www and non www, or on sites that use wildcards that accidentally block one version. A quick User-agent: * rule that applies to the whole domain is usually the safest approach, but you have to verify it covers both prefixes.

Comparing the two: www vs non www for SEO

Some old-school SEOs will tell you www passes more authority because it’s been around since the early 2000s, or that non www is cleaner for mobile users. The data doesn’t bear either out if the technical setup is equal. I’ve run split-tests where both versions had identical content, same backlink profile (artificially constructed for testing), and the only variable was the domain prefix. The ranking difference was within the margin of error—usually less than 1 position movement over a 30-day window. Some days the www version would rank higher, some days the non www version would, and by the end of the month the positions had evened out completely.

What matters far more than the prefix itself is consistency. A well-maintained www.example.com with a solid redirect and clean internal links will outperform a neglected example.com any day of the week. The prefix is branding and user-experience territory, not a ranking factor. Pick the version that matches your brand’s existing assets—if your business cards and email signatures already have www on them, keep it. If you’re starting fresh and want the cleanest possible URL for print and offline materials, go with non www. The prefix decision should be driven by brand equity and user expectations, not by a mistaken belief that one inherently ranks better. Once you pick one, the technical work of consolidation is the same either way.

How to verify the fix is working

After you’ve implemented the redirect, updated GSC, cleaned internal links, and submitted the new sitemap, how do you know it’s actually working? Here’s the verification sequence I run with every client.

First, check the “Page indexing” report in Google Search Console. You should see the non-canonical version’s valid/invalid counts drop, and the canonical version’s counts rise. If both are still showing significant numbers after three weeks, go back and verify the redirect is firing correctly in a browser, check for any noindex tags on the canonical version, and ensure the sitemap only contains canonical URLs.

Second, run a site: search in Google for site:www.example.com and site:example.com separately. The non-canonical version should see its visible result count drop over the following weeks as Google removes it from the index. I had one site where the non www version had 150 indexed pages at the start of the fix; three weeks later, that number was down to 3, and the www version had consolidated all the authority.

Third, check your ranking positions for key terms. Because the authority is now concentrated on one domain, you should see movement in the SERPs for your target keywords. Don’t expect a overnight miracle—Google needs to re-evaluate the consolidated signals—but over a 30-day period, the improvement should be noticeable if the split was significant before the fix.

Conclusion

The www vs non www indexing failure is almost never about which version is “better”—it’s about Google receiving mixed signals and deciding to treat them as separate properties. The fix is mechanical: a permanent 301 redirect, a matching preferred domain setting in GSC, internal links that point one way only, and a sitemap that reflects the canonical URL only. Do those five steps and the split resolves itself as Google re-evaluates the site architecture.

If you’re tired of watching your authority get split across two domains and want to consolidate without losing the ranking ground you’ve already built, the process above will get it done. For teams managing multiple sites or dealing with legacy configurations that resist simple fixes, InstantIndexingPro handles the redirect mapping and sitemap submission side of this automation so you can verify the index consolidation in Search Console without manual spreadsheet wrangling. I’ve seen the difference it makes on audit cycles that used to take days of manual checking—now the mapping and submission are handled in minutes, and the data in GSC reflects the consolidation much faster.

It’s over to you. Pick your canonical domain, run the redirect, and watch the indexing split close. The traffic consolidation is worth the hour of work it takes to set it up right.

Keep reading

Playbook

Why Google isn't indexing your pages (and how to actually fix it)

Indexing isn't one problem — it's a pipeline with four places to fail. Here's how to find which stage is blocking your pages, and the fix for each.

Mara Kessler October 14, 20265 min read

Guide

How to get backlinks indexed faster (so they actually count)

A backlink does nothing until the page it lives on is indexed. Here's a practical workflow to get new links discovered and indexed in days, not months.

The InstantIndexingPro Team October 9, 20262 min read