> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # 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. **Card class:** [Sensitivity](/nerve-centre/overview#card-classes-explained) • **Category:** [Sitemaps](/nerve-centre/connectors#connectors-by-type) > 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](/nerve-centre/kpi-cards/google-search-console/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](/nerve-centre/kpi-cards/google-search-console/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](/nerve-centre/kpi-cards/google-search-console/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](/nerve-centre/kpi-cards/google-search-console/sitemap-errors-alert) | The dedicated hard alert for sitemap errors; this table is the detail behind it. | | [Pages Not Indexed](/nerve-centre/kpi-cards/google-search-console/pages-not-indexed) | Where the undiscovered pages end up. Sitemap errors often correlate with a rise in not-indexed pages. | | [Index Coverage Drop Alert](/nerve-centre/kpi-cards/google-search-console/index-coverage-drop-alert) | Fires when indexed coverage falls; a broken sitemap is a prime upstream cause. | | [Indexed Pages](/nerve-centre/kpi-cards/google-search-console/indexed-pages) | The discovery outcome this card protects. | | [Indexing Trend](/nerve-centre/kpi-cards/google-search-console/indexing-trend) | The over-time view that shows whether sitemap errors are biting your coverage. | | [Total Pages Indexed](/nerve-centre/kpi-cards/google-search-console/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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.