Sitemap submitted but not indexed is one of those problems where Search Console appears to be reassuring you and answering a different question at the same time. The Sitemaps report is green. It says Success. It shows a discovered-pages count that matches the number of URLs in the file. And the pages are not in Google.
Nothing is broken, and you have not misread the screen. The Sitemaps report was never telling you anything about indexing. It is a parser log, and I want to show you exactly what it does say, what the discovered count is counting, and the three clicks that get you a real answer.
What does Success mean in the Sitemaps report?
It means the file parsed. That is the whole claim.
Google’s documentation for the Sitemaps report gives the status as: “The sitemap was loaded and processed successfully with no errors. All URLs will be queued for crawling.” The summary list on the report itself words it even more narrowly: “The sitemap was fetched and read without any errors.”
Loaded, processed, read. Queued for crawling. There are only three values this column can take, and none of them is about your index:
- Success, the file parsed with no errors
- Has errors, the file parsed but some entries did not
- Couldn’t fetch, Google could not retrieve the file at all
So Success is a verdict on your XML. It tells you your generator produced valid markup at a URL Googlebot could reach. If you have ever chased a Couldn’t fetch status until it flipped green, this is the moment to know that green was the start of the process rather than the end of it.
What does “Discovered pages” count?
This is the number that does the most damage, because it looks like a scoreboard. Google’s definition is precise and worth reading in full:
“Discovered pages: The number of page URLs that were parsed from the sitemap. If this is a sitemap index, the number is the count of all URLs in all child sitemaps. Duplicate URLs are counted only once. There is no guarantee that a page URL discovered in a sitemap has been or will be crawled or indexed by Google. You can filter the Page indexing report by sitemap to see how many page URLs in this sitemap have been indexed.”
Parsed from the sitemap. That is a count of your file, not a count of Google’s index. It goes up when you add lines to an XML document. It does not require Googlebot to have fetched a single one of those URLs.
Which makes the most common false alarm I get sent an entirely upside-down reading of the screen. Someone shows me a discovered count of 412 next to a sitemap containing 412 URLs and reads the match as proof that everything is fine. The match proves the parser worked. If it had said 380 you would have learned something, because 32 lines went missing or 32 were duplicates counted once. A number that agrees with your own file is the least informative outcome available.
Is submitted the same as indexed?
No, and Google says so in two separate places without leaving room for interpretation.
The sitemaps overview puts it as: “A sitemap helps search engines discover URLs on your site, but it doesn’t guarantee that all the items in your sitemap will be crawled and indexed.”
The build-and-submit doc goes further and downgrades the submission itself: “Keep in mind that submitting a sitemap is merely a hint: it doesn’t guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site.”
A hint. Not an instruction, not a queue you have bought a place in. The mental model that causes the confusion is that a sitemap is a request form and Success is the receipt. It is closer to leaving a list of addresses somewhere Google is known to look.
There is one more piece of wording worth knowing, because it trips people up in the other direction. Google counts a URL as submitted “even if it was also discovered through some other mechanism (for example, by organic crawling from another page).” So the submitted bucket is not a clean measure of what your sitemap achieved either.
How do I see how many sitemap URLs are actually indexed?
Three clicks, and Google’s own documentation points you at them in the Discovered pages definition above.
- Open the Page indexing report, not the Sitemaps report.
- Use the dropdown above the chart. It has four options: All known pages (the default), All submitted pages, Unsubmitted pages only, and the specific sitemap URL.
- Pick the specific sitemap file, not All submitted pages.
That third step is the one people skip, and it matters more than it sounds. All submitted pages merges every sitemap on the property, including any listed in robots.txt, into a single number. If you run a sitemap index with a dozen children and exactly one of them is failing, the merged view averages the failure into invisibility. Filter to one file at a time and the broken child stands out immediately.
Now read the split. Indexed versus Not indexed, for that file only, with the reasons underneath. Those reasons are four completely different jobs wearing the same green Success upstream:
- Discovered, currently not indexed means Googlebot has never fetched the URL. Nothing on the page is the cause, so nothing on the page is the cure yet. This is a crawl scheduling problem.
- Crawled, currently not indexed means it was fetched and passed over. That is an opinion about the content, and it is the one place where editing the page is the right move.
- Duplicate without user-selected canonical means the content is in Google, under a different address than the one you submitted.
- Excluded by noindex tag means your sitemap and your robots meta tag are arguing with each other, and the meta tag is winning. A URL should not be in a sitemap and noindexed at the same time.
If you want the full map of what turns up here, every Search Console indexing status lists them with what each one is really telling you.
Why does my sitemap index show 0 discovered pages?
This one is worth separating out, because a zero looks like a catastrophic failure and usually is not one. A sitemap index file contains no page URLs of its own, only pointers to child sitemaps. The discovered count for the parent is the sum of the URLs in all the children, so a zero says Google has parsed the parent and has not yet parsed the children beneath it.
Check the children individually in the same report before you touch anything. If they show their own counts and their own Success, the parent will catch up. If a child shows Couldn’t fetch, you have found the actual fault, and it was never in the file you were staring at.
While you are in there, confirm you are not near a hard limit: Google caps a single sitemap file at 50,000 URLs and 50MB uncompressed, which is the reason large sites end up with an index file at all.
What I check first
I stopped opening the Sitemaps report first a long time ago, and it was a client account that taught me why. A skincare brand I have worked with for over two years sells the same catalogue through seven separate country storefronts. Every launch produces the identical screen: sitemap submitted, Success, discovered count matching the file exactly, and an index with almost nothing in it. Seven times. The sitemap was never the problem on any of them, and seven green Success statuses said nothing at all about the seven empty indexes sitting behind them.
So the pass I run now goes in the opposite order. Page indexing report first, filtered to one sitemap file at a time, and I read the not-indexed reasons before I look at the sitemap’s own status. The sitemap status only gets checked when the reasons point back at it, which in practice means when something says Couldn’t fetch.
The tool I built here does the same thing from the outside, without waiting on report refreshes: how much of your sitemap has Google actually indexed reads the file, checks the URLs, and gives you the coverage ratio the Sitemaps report will never show you. It exists precisely because Success was answering the wrong question often enough to be worth automating around.
One caution on timing. Search Console data lags, so a sitemap submitted this morning against a report that has not refreshed will look worse than it is. Give a new file a few days before you diagnose anything from it, and if the numbers look impossible rather than merely bad, check whether the data is simply delayed first.
Sources
- Google Search Console Help, Sitemaps report, for the Success definition, the three status values, the Discovered pages definition including the duplicate-counting and no-guarantee wording, and the pointer to filter the Page indexing report by sitemap, checked 5 September 2026
- Google Search Console Help, Page indexing report, for the four sitemap filter options and the wording that a URL counts as submitted even when discovered another way, checked 5 September 2026
- Google Search Central, Build and submit a sitemap, for the “merely a hint” wording and the 50,000 URL and 50MB limits, checked 5 September 2026
- Google Search Central, Sitemaps overview, for the statement that a sitemap does not guarantee crawling or indexing, checked 5 September 2026
- First-hand: the skincare brand case study on this site, for the seven-storefront pattern described in the last section