An XML sitemap tells search engines which URLs to index. When every one of them names a hostname other than the one you crawled, and that hostname also answers in its own right, the sitemap is pointing search engines at a second copy of the site. Crawl Cove's sitemap-lists-other-host check reports exactly that case, and stays silent for the healthy one where the other host redirects back.
What this finding means
Two things must both be true. First, every <loc> in the sitemap names a different hostname from the one the audit crawled. Second, during the crawl Crawl Cove fetched one sampled sitemap URL on that other host and it answered HTTP 200 with no redirect. A real finding reads:
Every one of the 212 sitemap URLs names www.example.com, but this audit crawled example.com. https://www.example.com/pricing answered HTTP 200 with no redirect, so both hostnames serve the site.
The finding is site-level and reported once. If the crawled pages' canonical tags already point at the other host, the recommendation says so: you crawled the non-canonical hostname, and the audit should be re-run on the one your pages name.
Why it matters
Two hostnames that both serve the site split its links and rankings between two copies. Search engines have to pick one, and the sitemap is telling them to pick the copy you did not choose, while your internal links and canonicals may say the other. Duplicate-content handling usually resolves it eventually, but it does so by guessing, and every backlink earned by the losing copy is signal the winning one never receives. In the September 2026 sample this check was built against, one site in 92 with a readable sitemap had the problem, so it is rare, but when it is present it is a real indexing fault with a concrete fix.
How to fix it
- Pick one hostname. The usual choice is whichever your canonical tags and most of your backlinks already use. Changing it is a migration; keeping it is free.
- Redirect the other hostname to it with a 301, at the server or the CDN, for every path:
# Apache (.htaccess), redirect example.com to www.example.com
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]
# Nginx
server {
server_name example.com;
return 301 https://www.example.com$request_uri;
}
- Make the sitemap, canonical tags and internal links all use the host you kept. A sitemap generated by a CMS usually follows its configured site URL; check that setting rather than editing the file by hand.
- Re-run the audit on the hostname you kept. With the redirect in place the check stays silent, and the sitemap check that reads individual entries confirms none of them redirect any more.
- Set the preferred host in Google Search Console by verifying a domain property, which covers both hostnames, so you can watch the consolidation happen in one report.
Heads up
If your canonical tags already point at the other host, do not "fix" the sitemap to match the host you crawled. The pages have already chosen; make the redirect and the sitemap agree with them, then re-run the audit there.
False positives and edge cases
- A redirecting hostname never triggers this. If the sampled URL on the other host answers with a 301 or 302 back, a non-2xx status or a connection error, the check stays silent. That is the healthy shape, and redirecting sitemap entries are the non-indexable sitemap URL check's job.
- A mixed sitemap is not reported here. The check fires only when every sitemap URL names the other host. A sitemap that mixes hostnames is a different fault, reported entry by entry by the same non-indexable URL check.
- A sitemap for a genuinely separate site, such as a sitemap index that also lists a sister domain, is reported by this check only if that domain serves your site's pages without redirecting, which a separate site does not.
- Staging crawled under a production sitemap fits this shape too: if staging.example.com serves a sitemap listing www.example.com, and production answers 200, the finding is accurate. The fix there is to stop the staging copy publishing the production sitemap, not to redirect production.
Related reading
Check any sitemap's entries for free with the XML sitemap validator. For the page-level version of the same choice, see URL consistency and Redirect normalisation. If you are retiring a hostname for good, the site migration SEO checklist covers the redirect map, and Duplicate without user-selected canonical explains what Search Console reports while two copies compete.
Google documentation: Build and submit a sitemap
Frequently asked questions
- My sitemap lists www but I crawled the bare domain. Is that this finding?
- Only if both hostnames serve the site. If www redirects to the bare domain (or the other way round) with a 301, the check stays silent, because search engines are being pointed at one copy. It fires when the other host answers 200 in its own right, which means there are two copies.
- Which hostname should I keep?
- The one your canonical tags, internal links and existing backlinks already favour. If the crawled pages' canonicals point at the other host, the finding says so and tells you to re-run the audit there, because you crawled the copy you have already decided against.
- Is a 302 redirect good enough?
- Use a 301. A permanent redirect tells search engines to consolidate signals on the destination; a temporary one asks them to keep the original, which is the opposite of what you want when retiring a hostname.
- Why does the check sample only one sitemap URL on the other host?
- Because the question is whether the other host serves the site at all, and one 200 with no redirect answers it. Probing every URL would slow the crawl for no extra information; the fix is the same whether one page or every page is duplicated.