Submitting both WWW and non-WWW versions of your sitemap signals duplicate content to search engines, diluting your SEO authority and potentially harming your rankings. The solution is to choose one canonical version and enforce it with permanent 301 redirects.

Duplicate Sitemaps: The Silent SEO Killer and How to Fix It

I still remember the frantic Slack message at 10 PM on a Tuesday. “Darian, traffic’s tanking. Search console is throwing duplicate content warnings everywhere.” It was from our new junior dev, bless his heart. We’d just launched a marketing microsite, and what started as a small dip in traffic was turning into a nosedive. We spent two hours digging through logs on `prod-web-01` and `prod-web-02` before we found it: a misconfigured build script was generating two sitemaps, one for `https://techresolve.io/sitemap.xml` and another for `https://www.techresolve.io/sitemap.xml`. It’s a rookie mistake, but one that can absolutely cripple a site’s visibility. It’s the digital equivalent of giving someone two different sets of directions to the same place. Let’s make sure it never happens to you.

The Root of the Problem: A Case of Mistaken Identity

Here’s the core issue: to a search engine like Google, www.yourdomain.com and yourdomain.com are two completely different websites. They don’t automatically know they’re the same entity. When you provide a sitemap for each, you’re essentially telling Google:

• “Hey, here’s a map to my house at 123 Main Street.”
• “Oh, and here’s another map to my other house, also at 123 Main Street.”

Google gets confused. It doesn’t know which one is the “real” source of truth, or the canonical version. This confusion leads to split “link juice” (your SEO authority gets divided), duplicate content penalties, and a generally poor understanding of your site’s structure. You end up competing against yourself for rankings, and that’s a battle you’ll always lose.

The Fixes: From a Band-Aid to a Permanent Cure

Okay, enough theory. You’re here because you need to fix this, probably yesterday. Here are three ways to handle it, ranging from a quick patch to the architecturally sound solution.

1. The Quick Fix: The Robots.txt Band-Aid

This is the “I need to stop the bleeding RIGHT NOW” approach. It’s not a permanent solution, but it’s effective in a pinch. You simply tell search engine crawlers to ignore the sitemap you don’t want them to see by adding a rule to your `robots.txt` file.

Let’s say your preferred version is https://www.yourdomain.com. You would modify your `robots.txt` file to explicitly block the non-www sitemap.

User-agent: *
Disallow: /some-private-directory/

# Add your sitemap here, pointing to the CANONICAL version
Sitemap: https://www.yourdomain.com/sitemap.xml

# Explicitly block the wrong one if it's somehow still accessible
# This is a bit redundant if you have redirects, but provides a safety net.
# Note: This doesn't work for most major crawlers as Disallow is for paths,
# not full URLs. The real fix is a redirect. This is more of a signal.

The Real Quick Fix: A better approach than `Disallow` is to ensure your `Sitemap:` directive in `robots.txt` points ONLY to the single, canonical sitemap. Remove any others. This is the first place a crawler looks.

A Word of Warning: This is a temporary fix. It doesn’t solve the root problem, which is that both versions of your site are accessible. A savvy user (or a less common crawler) can still access the non-preferred version. Use this to put out the fire, then implement the permanent fix.

2. The Permanent Fix: The Server-Side 301 Redirect

This is the right way to do it. You need to pick one version (www or non-www) as your champion and force all traffic to use it. A 301 “Moved Permanently” redirect tells browsers and search engines that the old location is gone for good and all future requests should go to the new one. All your precious link juice gets consolidated into one place.

For Nginx (My personal preference):

Edit your server block configuration. This example forces non-www to www.

# Redirect non-www to www
server {
    listen 80;
    listen 443 ssl;
    server_name yourdomain.com;
    # ssl_certificate and other cert info would go here...
    return 301 https://www.yourdomain.com$request_uri;
}

# The main server block for the canonical version
server {
    listen 80;
    listen 443 ssl;
    server_name www.yourdomain.com;
    # ... your full configuration for the site goes here
}

For Apache (.htaccess):

If you’re on a shared host or using Apache, you can add this to your `.htaccess` file.

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

Once this is in place, any request for `yourdomain.com/sitemap.xml` will be automatically and permanently redirected to `www.yourdomain.com/sitemap.xml`.

3. The ‘Nuclear’ Option: Canonical Tags & Search Console

You should do this in addition to the 301 redirect, especially if the duplicate content has been live for a while. This is about explicitly cleaning up the mess with Google and other search engines.

Step 1: The `rel=”canonical”` Tag
Ensure that every single page on your site has a canonical link element in the HTML `` section. This tag is the ultimate tie-breaker, telling search engines which URL is the master copy.

<link rel="canonical" href="https://www.yourdomain.com/your-page-url" />

Even the page at `https://www.yourdomain.com/your-page-url` should have this tag pointing to itself. It’s a clear, unambiguous signal.

Step 2: Google Search Console Cleanup
Go directly to the source.

1. Log in to Google Search Console.
2. Make sure you have added and verified properties for both the www and non-www versions of your site.
3. Go to Settings > Preferred domain and set your canonical version (e.g., `www.yourdomain.com`). Google is phasing this out in favor of canonical signals, but it’s a good practice if the option is there.
4. Submit only the correct sitemap (e.g., `https://www.yourdomain.com/sitemap.xml`) under the Sitemaps section. If the old, incorrect sitemap is listed, remove it.

This combination tells Google from every possible angle—server, page-level, and directly in its own tool—which version of your site to index.

Quick Comparison

Solution	Pros	Cons
Robots.txt	Extremely fast to implement.	Just a suggestion to crawlers; doesn’t fix the root cause. A “hacky” feel.
301 Redirect	The correct, permanent solution. Consolidates SEO value. Best for users and bots.	Requires server access. A misconfiguration can cause redirect loops.
Canonical Tag & GSC	Provides an explicit, undeniable signal to search engines. Helps clean up existing index issues.	Doesn’t redirect users. Must be implemented alongside a 301 redirect for best results.

Don’t be the dev who tanks the marketing launch. Pick a canonical version, enforce it with 301s, and double-check your sitemaps. Your SEO team (and your PagerDuty alerts) will thank you.

---

🤖 Frequently Asked Questions