Why Google Is Ignoring Your Sitemap and How to Diagnose It
You did everything right. You generated a valid XML sitemap, submitted it in Search Console, and waited. Weeks later the coverage report still shows a fraction of your URLs indexed, or Search Console reports the sitemap as read but most of the pages sit in “Crawled, currently not indexed” or “Discovered, currently not indexed.” It feels like Google is ignoring the file entirely.
In a sense, it is. Not because the file is broken, but because a sitemap does not work the way most people assume. Understanding what a sitemap actually promises, and what it does not, is the difference between endless resubmitting and a real fix. This guide walks through why Google discounts a sitemap, and how to diagnose which reason is hitting your site.
A Sitemap Is a Hint, Not a Command
The single most important thing to internalize is that a sitemap is a suggestion. It tells search engines, here are URLs I consider worth looking at. It does not force crawling, it does not force indexing, and it never has. Google has said this plainly for years: submitting a URL in a sitemap does not guarantee it will be crawled, and being crawled does not guarantee it will be indexed.
Compare that to robots.txt, which is a directive. When you disallow a path, compliant crawlers obey it. A sitemap has no equivalent power. It is closer to a recommendation letter than a work order. Google reads the letter, weighs it against everything else it knows about your site, and then decides on its own schedule and its own priorities.
Once you accept that framing, the question changes. It is no longer “why is Google ignoring my list,” it is “why is Google choosing not to act on these particular URLs.” That is a question you can actually answer, and the answers fall into four buckets.
Reason 1: The URLs You Submitted Are Not the URLs Google Wants
This is the most common cause by far, and the most invisible. Your sitemap lists a URL, but that URL is not the clean, indexable, canonical version of the page. Google follows it, finds a reason not to index that exact address, and quietly moves on. A few patterns show up again and again.
The URL redirects. Your sitemap lists http:// when the site runs on https://, or it lists a slug that now 301s somewhere else. Google follows the redirect, indexes the destination, and treats the sitemap entry as stale. Every redirected URL in a sitemap is a wasted signal.
The page carries a noindex tag. The sitemap says “index this,” the page header or meta robots tag says “do not index.” The page tag wins, every time. A sitemap listing a noindexed URL is a direct contradiction, and Google resolves it against you.
The canonical points elsewhere. You submit /product?color=blue, but the page declares a canonical of /product. Google honors the canonical and drops the parameter version. If your sitemap is full of parameter URLs, faceted variations, or session tagged addresses, most of it is redundant from Google’s point of view.
The page is blocked by robots.txt. A sitemap URL that is disallowed in robots.txt cannot be crawled at all. Google may still discover it exists, but it will not fetch the content, which usually lands the page in “Discovered, currently not indexed.” If you are seeing that status in bulk, this is a prime suspect. Our guide on why pages get stuck as discovered but not indexed breaks that status down in detail.
The fix for all of these is the same principle: a sitemap should contain only canonical, self referencing, indexable, 200 status URLs. Nothing that redirects, nothing that is blocked, nothing that points its canonical elsewhere. When the sitemap and the page finally agree with each other, Google stops discounting the file.
Reason 2: Google Stopped Trusting Your lastmod
The lastmod field is meant to tell crawlers when a URL last changed in a meaningful way, so they can prioritize fresh content and skip pages that have not moved. Used honestly, it genuinely helps large sites get recrawled faster.
Used dishonestly, it becomes noise Google learns to ignore. Many content systems and plugins stamp today’s date on every URL in the sitemap on every rebuild, even when nothing on the page changed. When every page claims to have been modified this morning, the field carries no information. Google notices the pattern, decides your lastmod values are unreliable, and starts disregarding them for the whole site. From that point the field does nothing for you.
The diagnosis is simple. Open your sitemap and look at the lastmod values across a sample of URLs. If pages you have not touched in a year all show a recent date, your lastmod is lying, and Google probably knows. The fix is to emit lastmod only when the page content actually changes, and to leave it out entirely rather than fake it. An accurate field on a subset of pages is worth more than a fabricated field on all of them. The mechanics of building this correctly are covered in our deeper guide on building and validating XML sitemaps at scale.
Reason 3: The File Was Never Cleanly Fetched
Sometimes Google is not discounting your sitemap on the merits. It never fully read it. These failures are quieter than a hard error because Search Console often reports “Success” for a sitemap it only partially processed.
A handful of issues cause this. The sitemap sits at a URL that is itself blocked by robots.txt. The file is served with the wrong content type, so it is treated as a web page rather than XML. It exceeds the limits, 50,000 URLs or 50 MB uncompressed, and the overflow is silently dropped. It is served with broken gzip encoding. Or the sitemap index references child sitemaps at URLs that 404. Any of these can leave Google with a partial or empty view of your URLs while the report still looks green.
To diagnose, fetch the sitemap the way a crawler would, not in a browser tab that helpfully renders it. Request the raw file, confirm it returns a 200 status with an XML content type, check that it is under the size limits, and if it is a sitemap index, confirm every child sitemap it lists actually resolves. A file that a human can open in a browser is not proof that a bot fetched it cleanly.
Reason 4: The Pages Are Real, but Google Is Rationing Attention
Suppose the URLs are clean, the lastmod is honest, and the file fetches perfectly. Google can still leave pages out, and here the reason is quality and budget rather than mechanics.
Google does not owe every page an index slot. It allocates crawling and indexing based on how much it trusts a site and how much value it expects from a given page. On a large site, thin pages, near duplicate pages, and low value templated pages compete for a limited share of attention, and many lose. This is where “Crawled, currently not indexed” tends to come from: Google fetched the page, judged it not worth an index slot, and left it out. Piling more URLs into the sitemap does not help, because the constraint is not discovery, it is worth. Our guide on how crawl budget gets spent on low value pages covers the mechanics of that competition.
The uncomfortable fix is to make the sitemap smaller and stronger, not bigger. Remove thin and duplicate URLs, consolidate overlapping pages, and submit only the pages you would genuinely defend as worth indexing. A tight sitemap of strong pages earns more of Google’s attention than a bloated one padded with filler.
How to Diagnose This on Your Own Site
The pattern across all four reasons is a gap between what your sitemap claims and what your pages actually are. You cannot see that gap from Search Console alone, because Search Console tells you the outcome, not the cause. What you need is a full crawl of your own site that you can compare against the sitemap, line by line.
That is the kind of audit a desktop crawler is built for. Run a crawl of your domain, then cross reference it with the URLs in your sitemap and ask the questions each reason raises. Which sitemap URLs return a status other than 200. Which ones redirect. Which carry a noindex tag or a canonical pointing elsewhere. Which are disallowed in robots.txt. Which pages have almost no unique content. Every one of those is a URL your sitemap should not be asking Google to index, and finding them turns a vague “Google is ignoring my sitemap” into a concrete list of fixes.
This is exactly the sort of check you can run yourself for free. Seodisias crawls your whole site on your own machine, on Windows, macOS, or Linux, with no URL cap and no data leaving your computer, so you can line up your live pages against your sitemap and see the mismatches directly. When the pages you submit and the pages Google finds finally describe the same site, the sitemap stops looking ignored, because there is nothing left in it for Google to discount.
Conclusion
Google is not ignoring your sitemap out of spite, and resubmitting it will not change anything. A sitemap is a hint, and Google discounts that hint for concrete reasons: the URLs contradict the pages through redirects, noindex tags, or canonicals, the lastmod field has lost its credibility, the file was never cleanly fetched, or the pages simply are not worth an index slot. Each of those is diagnosable, and each is fixable, but only once you stop treating the sitemap as a command and start treating it as a claim you have to back up.
The next step is to stop guessing and look. Crawl your own site, compare it against the sitemap, and let the mismatches tell you which of the four reasons is in play. Fix those, keep the file to clean canonical URLs you would defend, and give Google a sitemap it has no reason to ignore.