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 reportserrors_count > 0, because errors block Google from reliably discovering the URLs in that sitemap. As thedetailputs 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 thedetail source, the logic is:
- Call
sitemaps.listfor the property to enumerate all sitemaps and sitemap indexes. - For each sitemap, call
sitemaps.get(or read the list payload) to obtainerrors,warnings,isPending,isSitemapsIndex, and the per-content-typesubmittedandindexedcounts. - Render a row per sitemap: path, content type, status,
errors_count,warnings_count, discovered pages. - Derive a headline status from the worst row: any
errors_count > 0→ red (alert); otherwise anywarnings_count > 0→ amber; otherwise → healthy. - For a sitemap index, child sitemaps are listed beneath the index so an error can be traced to the specific child file.
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 |
/products.xml.
Three observations:
- 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.
- The index error is a knock-on, not a separate problem. The single error on
sitemap_index.xmlis 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. - The fix. The team regenerated
/products.xmlfrom 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 latererrors_countfell 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.
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 |
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.