Sitemap Status, Google Search Console

Lists every submitted sitemap with its errors and warnings, because a sitemap Google cannot parse blocks discovery of your new content. How to read it, why it matters, and how to act on it.

Metrics type: Supporting Metrics • Category: Sitemaps

A live error table for your sitemaps. Any sitemap with a non-zero error count is a sitemap Google may be refusing to read, and a closed door on new-content discovery.

At a glance

Sitemap Status is the per-sitemap health table for your Search Console property. For each submitted sitemap it shows the processing status, the count of errors, the count of warnings, and the discovered-pages count. It fires the moment any sitemap reports errors_count > 0, because errors block Google from reliably discovering the URLs in that sitemap. As the detail puts it: “Submitted sitemap list with errors / warnings per sitemap. Errors block Google from discovering new content.” SEO and technical teams use it as the first stop when new pages are not getting picked up.

What it tracks	One row per submitted sitemap: status (Success, Has errors, Couldn’t fetch), errors_count, warnings_count, content type, and discovered-pages count. The headline state is the worst row.
Data source	The Search Console Sitemaps report plus sitemaps.list / sitemaps.get (errors, warnings, isPending, isSitemapsIndex, per-content-type submitted and indexed counts). Source meaning: “Submitted sitemap list with errors / warnings per sitemap. Errors block Google from discovering new content.”
Time window	RT (real-time, evaluated on each refresh). No trailing period: it always reflects the current parse state of each sitemap.
Alert trigger	any sitemap with errors_count > 0. Warnings raise an amber state but do not page; errors raise red.
Units	Integer counts of errors and warnings per sitemap, plus a status label.
Roles	owner, marketing
Why it matters	A sitemap with parse errors is the silent killer of content discovery. Pages listed in a broken sitemap may never be announced to Google, so new products, articles, and categories sit undiscovered while your published-content count keeps rising. This card surfaces the break the moment it appears, before Indexed Pages sags.

Calculation

The card builds a row for every sitemap registered against the property and flags the worst one. Grounded in the detail source, the logic is:

1. Call sitemaps.list for the property to enumerate all sitemaps and sitemap indexes.
2. For each sitemap, call sitemaps.get (or read the list payload) to obtain errors, warnings, isPending, isSitemapsIndex, and the per-content-type submitted and indexed counts.
3. Render a row per sitemap: path, content type, status, errors_count, warnings_count, discovered pages.
4. Derive a headline status from the worst row: any errors_count > 0 → red (alert); otherwise any warnings_count > 0 → amber; otherwise → healthy.
5. For a sitemap index, child sitemaps are listed beneath the index so an error can be traced to the specific child file.

Errors and warnings carry distinct weight. Errors (unreachable file, invalid XML, URLs outside the property, wrong namespace) genuinely block discovery. Warnings (a URL not indexed, a slightly oversized file) flag friction but do not stop Google reading the rest.

Worked example

A homeware brand migrated to a new theme and, in the process, changed its product-URL structure. A few days later the Sitemap Status card reads:

Sitemap	Type	Status	Errors	Warnings	Discovered pages
sitemap_index.xml	Index	Has errors	1	0	n/a
/products.xml	Sitemap	Has errors	142	3	0
/collections.xml	Sitemap	Success	0	0	84
/blog.xml	Sitemap	Success	0	1	211

Headline: Alert firing, 142 errors on /products.xml.

Three observations:

1. The error count points straight at the regression. All 142 errors are on the products sitemap, and its discovered-pages count is 0. The migration changed product URLs, but the sitemap still listed the old URLs, which now 404. Search Console flags each dead URL as an error and discovers no valid product pages from that file. The collections and blog sitemaps, untouched by the URL change, are clean.
2. The index error is a knock-on, not a separate problem. The single error on sitemap_index.xml is Google reporting that a child sitemap (the products file) has issues. Fixing the products sitemap clears the index error too. Always work from the child sitemaps up.
3. The fix. The team regenerated /products.xml from the live store so it listed the new product URLs, confirmed the file returned HTTP 200 with valid XML, and re-submitted it in Search Console. Because Search Console data lags 2 to 3 days, the error count did not drop to 0 immediately. Two days later errors_count fell to 0, discovered pages climbed to 96, and the card returned to healthy. The matching Sitemap Last Submitted card confirmed a fresh read on the same date.

Rule of thumb. Read the rows, not just the headline. Errors concentrated on one sitemap point to a content or URL problem in that file’s scope; errors spread across all sitemaps point to a property-wide problem (server returning 5xx, robots blocking, or the whole domain unreachable).

Sibling cards merchants should reference together

Card	Why pair it with Sitemap Status
Sitemap Last Submitted	The freshness companion. A sitemap with errors often also stops being read; check both to see whether the file is stale, broken, or both.
Sitemap Errors Alert	The dedicated hard alert for sitemap errors; this table is the detail behind it.
Pages Not Indexed	Where the undiscovered pages end up. Sitemap errors often correlate with a rise in not-indexed pages.
Index Coverage Drop Alert	Fires when indexed coverage falls; a broken sitemap is a prime upstream cause.
Indexed Pages	The discovery outcome this card protects.
Indexing Trend	The over-time view that shows whether sitemap errors are biting your coverage.
Total Pages Indexed	The headline indexed total a healthy sitemap feeds.

Reconciling against the source

Where to look in Google Search Console:

Indexing → Sitemaps. The “Submitted sitemaps” table shows each sitemap with a status column (Success, Has errors, Couldn’t fetch). Click any sitemap with “Has errors” to open the detail view, which lists the specific issues and links into the relevant Pages (Indexing) report so you can see exactly which URLs failed.

The matching API is webmasters.sitemaps.list and sitemaps.get, returning the errors and warnings counts, isPending, and the per-content-type submitted / indexed breakdown this card renders.

Why our value may legitimately differ from the Search Console UI:

Reason	Direction of divergence
Data delay. Search Console sitemap data is typically 2 to 3 days behind. A sitemap you fixed today may still show old error counts in both the UI and the API for a couple of days.	Card may lag the true state by 2 to 3 days
Error vs warning classification. We headline on errors_count; warnings raise only amber. If you are reading the UI’s combined “issues” view, our error-only headline can look lower.	Card headline counts errors, not warnings
Index roll-up. We list child sitemaps beneath their index. If you read only the index row in the UI, a child’s errors may not be obvious until you expand it.	Card surfaces child detail; UI needs a click
Pending reads. A freshly submitted sitemap can show isPending with no counts yet. We treat pending as “not yet evaluated”, not as healthy.	Card shows pending; UI may show a dash

Reconciliation steps. (1) Open Indexing → Sitemaps and match the status and error count per sitemap. (2) For any mismatch, allow for the 2 to 3 day Search Console data delay. (3) Click into the failing sitemap to read the specific issues; they fall into a small set of patterns (unreachable file, invalid XML, URLs outside the property’s scope, HTTP errors on listed URLs). (4) Fetch the sitemap URL directly to confirm it returns HTTP 200 and valid XML, then fix the underlying cause and re-submit.

This card is the watch; the native Sitemaps report and its per-URL drill-down remain the place to read the exact issue text.

Known limitations / FAQs

What is the difference between an error and a warning here? Errors genuinely block discovery: the file is unreachable, the XML is invalid, the URLs sit outside the property, or the listed URLs return HTTP errors. Warnings flag friction without stopping the read, for example a listed URL that is currently not indexed, or a sitemap nudging the size limit. This card fires on errors and raises amber on warnings.

My sitemap shows errors but my pages are still indexed. How? Pages can be discovered through internal links and backlinks even when a sitemap is broken, so indexing can continue for well-linked pages. The risk is concentrated in poorly linked new content (fresh products, new articles) that relies on the sitemap as its discovery route. Treat persistent errors as a real problem even if your headline indexed count looks fine for now.

I fixed the sitemap but the error count has not dropped. Why? Search Console processing and its reported counts lag real time by roughly 2 to 3 days. After you fix and re-submit, the error count typically clears within a couple of days. Confirm the file itself is healthy (HTTP 200, valid XML) and then wait for the next processing cycle.

The whole property shows errors on every sitemap at once. What does that mean? Errors spread across every sitemap usually point to a property-wide cause rather than a content problem: the server returning 5xx, robots.txt blocking the sitemap path, the domain being unreachable, or an HTTPS or redirect misconfiguration. Check site reachability and robots.txt first, then re-evaluate per-sitemap.

Does “Couldn’t fetch” count as an error? Yes. “Couldn’t fetch” means Google could not retrieve the sitemap file at all, which is as blocking as a parse error. We treat it as a red state. Confirm the URL is reachable, not behind authentication, not blocked by robots.txt, and returns HTTP 200.

How many sitemaps can this card track? All of them. It enumerates every sitemap and sitemap index registered against the property. For very large indexes the table is paginated, with the worst rows surfaced first so errors are never buried.

---

Tracked live in Vortex IQ Nerve Centre

Sitemap Status is one of hundreds of KPI pulses Vortex IQ tracks across Google Search Console and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English.

Start for free or book a demo to see this metric running on your own data.