Search Console diagnosis · SEO

A sitemap API zero is not an indexing verdict

Treat each Search Console surface as evidence for its own question; do not turn a deprecated field into a sitewide alarm.

  1. Discard the zeroGoogle labels contents[].indexed deprecated and says not to use it.
  2. Keep the datesThe API summary, live XML and index report may represent different snapshots and different measurements.
  3. Check actual pagesFilter Page Indexing by sitemap, then inspect representative affected URLs.

A monitoring script calls the Search Console Sitemaps API, reads contents[].indexed: 0, and sends a “nothing is indexed” alert. That conclusion does not follow. In the Sitemaps resource reference, Google explicitly marks contents[].indexed as deprecated; do not use. Zero in that field is not a usable count of indexed pages, even when the same response contains other sitemap metadata.

The practical mistake is to merge four different questions into one number: what URLs are published in XML, whether Google read a sitemap, what Page Indexing reports for URLs associated with it, and what Google knows about one inspected URL. We found this exact mismatch in a dated PolymathDesk audit. It is a useful example of how to investigate without claiming that the whole site is healthy.

The zero belongs to a deprecated API field

The contents array in Google's Sitemaps API describes sitemap content types. Its submitted field is documented as a count of URLs in that resource. Its indexed field is documented as deprecated. A dashboard that divides one by the other or treats the latter as a health threshold is giving a precise-looking answer to a question the API no longer answers.

First remove contents[].indexed from the alarm and its percentage calculations. Keep the raw response, retrieval time, sitemap path and field names in a log so the change is auditable. Do not replace the zero with the number of XML entries: a sitemap is a list of submitted URLs, not a receipt proving Google indexed them. Google says a sitemap helps discovery but does not guarantee indexing.

A second metadata trap is lastDownloaded. The API describes it as the time the sitemap resource was last downloaded. It is not a universal timestamp for every child sitemap in an index, nor an indexed-page count. If it looks old, check which resource the response names, its status and errors, and the corresponding report before interpreting it as a crawl failure.

Four surfaces answer four different questions

Four evidence sources: Sitemaps API indexed field is deprecated; live XML lists published URLs; Page Indexing filtered by sitemap shows coverage; URL Inspection checks one URL.
The broken counter is the deprecated API field. Live XML, Page Indexing and URL Inspection each answer a separate, narrower question. Public XML count dated 28 September 2026; product definitions from Google documentation.
  • Live XML: opens the actual sitemap and lists URLs the publisher currently exposes. An XML entry is not proof of discovery, crawl, eligibility or indexing.
  • Sitemaps report and API metadata: tell you about submitted resources, retrieval and parsing. Investigate a real fetch or parse error here; do not use the deprecated indexed property as a coverage metric.
  • Page Indexing: use Google's sitemap filter to examine indexed and not-indexed URLs associated with that sitemap. This is the appropriate report for a coverage question, subject to its own update timing and scope.
  • URL Inspection: the default view describes Google's indexed version for one URL. The live test checks whether the current page might be indexable; it does not mean the page is now indexed. Google documents that distinction.

If the Sitemaps report shows a processing error, fix that error on its own evidence. If Page Indexing shows a group of excluded URLs, investigate that group. If one inspected page is indexed, you have learned about one URL, not the total. This separation prevents both a false emergency and a false all-clear.

Our 212-to-365 mismatch is a dated comparison, not an index total

In a PolymathDesk Search Console audit dated 24 September 2026, one Sitemaps API summary showed 212 submitted Web URLs, indexed: 0 and a lastDownloaded date of 18 April. On that same September day, a direct count of the live post sitemap XML found 355 URL entries. URL Inspection for five selected pages returned indexed results. Those observations contradict the interpretation “zero pages on the site are indexed.” They do not prove that all 355 URLs were indexed.

A fresh recount on 28 September 2026 found 200 entries in post-sitemap1.xml and 165 in post-sitemap2.xml: 365 current post URLs. That number is a publisher-side inventory on a later date. We cannot infer from the three totals exactly when Google last fetched each child map, which URLs it indexed, or why the API summary differed. They are different snapshots and different instruments.

The 24 September Search Console audit is a first-party working record, not a public dashboard or a reproducible third-party measurement. The public XML links above let a reader check the later inventory, while the Google API reference establishes why the zero must be discarded. That distinction matters more than the apparent 212-versus-365 gap.

A stop rule for a real indexing investigation

1. Repair the metric, then ask whether a real problem remains

Find every alert, chart, export and client report that reads contents[].indexed. Label historic values as deprecated rather than silently preserving a false index-rate series. Keep submitted, status, errors and retrieval dates only for the questions those fields actually support. Compare the exact sitemap path and observation time with live XML; if the paths or dates differ, record that before explaining any numerical gap.

2. Check coverage in the product that reports coverage

Open Page Indexing in the verified property and filter by the relevant sitemap. Look for a material group of not-indexed URLs, its reason and its trend. Sample URLs from that group and inspect them individually. Compare the indexed version with a live test where it helps explain a current fix. If Search Console reports “Crawled – currently not indexed,” use the affected page's content and internal linking evidence; our guide to that status covers the separate remediation question.

3. Escalate only on evidence you can name

A failed sitemap fetch, parse error, persistent Page Indexing exclusion affecting important pages, or URL Inspection result showing a specific indexing barrier is actionable. A deprecated API zero by itself is not. An indexed inspection for a handful of pages is also not a sitewide pass. For a page whose live HTML differs from the rendered version, our JavaScript noindex case shows why the exact delivered document matters. For a URL reported as a soft 404, compare the HTTP response and render before blaming the map.

This is a measurement fix, not a promise that sitemap submission will make pages rank. The safe outcome is a dashboard that stops shouting about a dead field and a narrower investigation grounded in Page Indexing and specific URLs. A similar reporting discipline applies to Search Console query-click totals: a number available through an interface need not be the denominator you thought it was.

Questions about the sitemap zero

Does an API zero mean none of my pages are indexed?

No. Google labels contents[].indexed in the Sitemaps API deprecated and says not to use it. Check Page Indexing and specific URLs for actual indexing evidence.

Does a valid sitemap mean every URL in it is indexed?

No. A sitemap helps Google discover URLs but does not guarantee indexing. XML entries count published URLs, not Google indexed pages.

Why does the API submitted count differ from live XML?

First verify that the exact sitemap path, content type and observation date match. Different resources and dated snapshots can differ; the numbers alone do not identify the cause.

Does a successful live URL Inspection test prove indexing?

No. A live test asks whether the current URL may be indexable. The default indexed view reports what Google knows about the inspected URL, still only one URL.

Primary sources and observation dates

Google documentation and the public XML checked 28 September 2026