How to www vs non www indexing (step by step)

You wake up to find your search traffic has cratered because Google is showing both your www and non-www versions, effectively splitting your link equity down the middle. This isn’t just a technical annoyance; it’s a crawl-efficiency nightmare that often triggers the very deindexing issues I spent six months recovering from.

The mechanics of the www vs non-www split

Technically, “www” is just a hostname. When you set up a server, you can point your domain to the raw root (example.com) or the subdomain (www.example.com). The mistake most site owners make is leaving both live. When both respond with a 200 OK status code, Google’s bot treats them as two separate websites.

If you have 500 pages, you effectively have 1,000 URLs in the eyes of the search engine. This confuses the crawler, spreads your backlink profile thin, and makes your analytics look like a mess. You aren’t “doubling your presence”; you are essentially competing against yourself for every single query.

The danger here is more than just duplicate content. It is about how Google allocates your “crawl budget”—the number of pages they decide to index and the frequency at which they re-crawl them. If Googlebot spends 50% of its time crawling your site’s duplicate version, it is spending 50% less time indexing your new content or updating your schema changes. Over time, this leads to sluggish indexing, where new articles stay “Discovered - currently not indexed” for weeks, simply because the bot is busy wandering through the wrong version of your site.

Selecting your canonical preference

I recommend sticking to whichever version you started with unless there is a pressing technical reason to switch, like needing to host cookies on a specific subdomain. If you’re starting fresh, the non-www version is cleaner and easier to type, but the www version is sometimes perceived as more “enterprise-grade” by legacy systems.

Pick one. It doesn’t matter which one you choose for rankings, but it matters that you are consistent. Once you decide, write it down. Every configuration step from here on out will be based on that single decision.

If your site is already indexed, check Google Search Console. Go to the “Pages” report and look at the “Duplicate without user-selected canonical” error. If Google is already picking one for you, align your preference with their choice to avoid unnecessary friction. If you have significant backlinks pointing to the www version, keep that as your primary. Don’t fight the existing link equity; steer the ship toward the harbor with the most traffic.

Implementing server-side 301 redirects

You cannot rely on a plugin to do this if you want it done right. You need to touch the server configuration. For Nginx, you want to use a block that forces a permanent redirect. If you chose non-www as your primary, your configuration should look like this:

server {
    listen 80;
    server_name www.example.com;
    return 301 $scheme://example.com$request_uri;
}

If you are on Apache, add this to your .htaccess file:

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

Do not use 302 redirects. A 302 tells Google the move is temporary, and they will continue trying to index the version you don’t want. A 301 is a permanent transfer of authority.

Test this at the individual page level. If you have a deep page like www.example.com/blog/topic-a, it must redirect to https://example.com/blog/topic-a. A common mistake is redirecting everything to the homepage. This is “soft 404” behavior and will tank your rankings. Your redirect must maintain the URI string perfectly.

Cleaning up internal links and site architecture

Redirects are a safety net, not a substitute for good architecture. If your site has 2,000 internal links pointing to www.example.com/page-1 and you have redirected that to the root, every single click forces a server-side redirect. This adds latency to your page load time and creates a “redirect chain.”

Run a crawl using a tool like Screaming Frog. Look for all internal links that point to the non-preferred version. Use a find-and-replace plugin or a database query to update these links to your preferred canonical version. You want your site to be “clean” so that the crawler arrives at the correct page on the first attempt, every single time.

Update your hardcoded links in the header, footer, sidebar, and sitemap. If you are using a CMS like WordPress, use a plugin like “Better Search Replace” to perform a safe SQL search-and-replace across your wp_posts table. Be careful with serialized data; always back up your database before running a mass replace.

Updating your canonical tags

Even with 301s in place, you should have a canonical tag in the <head> of your HTML pointing to the preferred URL. This is a belt-and-suspenders approach. If you chose non-www, every single page on your site—including the www version if it somehow gets accessed—should have:

<link rel="canonical" href="https://example.com/page-path" />

This tells the bot, “Even if you found this via a weird route, the only version that matters is the one at this specific address.” Do not point the canonical tag to the www version if you’ve decided to use non-www. It sounds obvious, but I’ve seen developers leave this as a relative link or hardcode it to the wrong subdomain.

If you are using a dynamic site, ensure your canonical tag generation script is pulling the protocol (HTTPS) and the domain correctly. Check the page source of five different pages to ensure the tag is outputting the absolute URL, not a relative path like /page-path.

Costs and trade-offs of the migration

There is a real cost to fixing this, specifically in terms of temporary traffic volatility. When you implement a site-wide 301, you are essentially telling Google to re-index your entire site. In our experience, you can expect a 5-10% dip in traffic for about two weeks while the crawler processes the change.

The trade-off is that you are paying for long-term stability. If you don’t do this, you risk a manual action for duplicate content or, at the very least, a permanent suppression of your site’s potential because the crawler is wasting resources on irrelevant URLs. The technical labor is roughly two hours of work; the recovery time is a few weeks of patience.

Another trade-off is the impact on your CDN or load balancer. Some cloud-based WAFs (Web Application Firewalls) have their own redirect rules. If you configure a 301 at the server level, but your CDN is also trying to do a redirect, you might accidentally create a redirect loop. Always check your CDN’s “Page Rules” or “Redirect” settings to ensure they aren’t conflicting with your server-side code.

Worked scenario: The company that split its authority

Consider “AlphaTech,” a SaaS company with 1,200 indexed pages. They were running both versions, and 600 pages were indexed as www and 600 as non-www. They were seeing a 40% bounce rate on top-performing landing pages because of weird session-cookie resets when users jumped between the versions.

We spent 90 minutes updating their Nginx configs and running a SQL query on their WordPress database to fix 4,500 internal links. Within 21 days, their total indexed pages dropped from 1,200 to 600, but their organic traffic increased by 18%. By consolidating their backlink profile, they stopped splitting their domain authority, and their primary keywords finally broke into the top three results.

This scenario highlights the importance of the database update. By fixing the internal links, we reduced the server load, as fewer requests were triggering the redirect logic. This improved their Core Web Vitals, specifically the Largest Contentful Paint (LCP), because the browser didn’t have to wait for the server to send a 301 response before initiating the final connection.

Updating your search console and sitemaps

Google Search Console treats www and non-www as separate properties. You need to add both to your account, but you will only submit your sitemap to the preferred one.

Once your 301s are live, go to the Search Console property for the non-preferred version. Use the “Removals” tool if you are seeing a massive spike in errors, but usually, just letting the 301s do their work is safer. Ensure your robots.txt file is identical on both and that it allows the crawler to access the pages you want indexed.

A pro tip: if you have a massive site, monitor the “Crawl stats” report in the non-preferred property. You will see a spike in crawl activity as Google hits your 301s to verify the move. Once that traffic settles, you know the consolidation is effectively complete.

Verifying with cURL

Don’t trust your browser. Browsers cache redirects aggressively, which will lie to you about whether your fix is working. Open your terminal and run this command:

curl -I https://www.example.com

You should see a header that says HTTP/1.1 301 Moved Permanently. If you see a 200 OK on the www version, your server configuration failed. If you see a 404, you have a configuration error. Check this for both your homepage and a deep interior page to ensure the redirect rules are applying globally, not just at the root level.

Do this with the -L flag as well to follow the redirect: curl -IL https://www.example.com. This will show you the full chain, including the final 200 OK at your preferred destination. This is the only way to be 100% sure your redirect isn’t triggering a “too many redirects” error, which usually happens if you have a rule that loops back to itself.

Monitoring the consolidation phase

After you push the changes, watch your log files. You want to see the Googlebot hitting your site and receiving the 301 status code. If you see the bot continuing to crawl the old version repeatedly, check your internal links again; you likely missed a set of navigation menu links or footer links that are still pointing to the wrong version.

Be patient. Google’s index isn’t a light switch. It’s a massive database that updates in batches. If you don’t see results in 48 hours, it doesn’t mean you failed. It just means the crawler hasn’t re-processed your pages yet. Use the URL Inspection tool in Search Console to manually request re-indexing for your most important pages to speed up the process.

Keep a close eye on your “Coverage” or “Pages” report in Search Console. You are looking for a downward trend in the “Duplicate” category and a stabilization of the “Indexed” category. If you see a sudden drop in total indexed pages that exceeds the number of pages you have, re-check your robots.txt or your server access logs to ensure you haven’t blocked the crawler entirely.

The technical cleanup of your indexing is the foundation upon which your content strategy rests. If you don’t fix the host-name split, you are essentially building a house on a sinking foundation. Once the redirects are verified and the internal links are updated, your site will finally benefit from the full weight of your hard-earned authority.

If you find that your pages are still struggling to enter the index after you have resolved these redirect issues, InstantIndexingPro is the tool I use to force the issue and get those URLs into the index immediately.

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