Sitemap broken = new content invisible. First place a content-launch failure shows up.
At a glance
A real-time alert that fires when any submitted sitemap reports one or more errors, or when a sitemap has not been resubmitted (fetched successfully) for more than 14 days. A sitemap is how you tell Google which URLs exist and when they changed; if it errors out or goes stale, newly published pages may never be discovered. This alert is the first place a content-launch failure or a CMS misconfiguration shows up, well before the missing pages would surface as lost clicks. The card is a fire-alarm bell for content discoverability, not a measurement of traffic.
| What it tracks | The health of every sitemap submitted to the property: the errors_count Google reports for each sitemap, and the date Google last successfully fetched it (last_submitted / last read). The alert fires if any sitemap has errors, or if the most recent successful fetch is older than 14 days. |
| Data source | Google Search Console Sitemaps report, read via the Search Console Sitemaps API. We poll each submitted sitemap’s status, error count, discovered-URL count, and last-read date. |
| Why it matters | New and updated pages rely on the sitemap for fast discovery. A sitemap that 404s, times out, contains malformed XML, or lists blocked or non-canonical URLs stops doing its job silently. The content team thinks the launch is live; Google never finds it. This alert closes that blind spot. |
| Time window | RT (real-time framing). The Sitemaps report updates each time Google re-reads the file; we surface a fresh error or a staleness breach on the next poll after Google publishes the status. |
| Alert trigger | any sitemap errors_count > 0 OR last_submitted > 14d ago, sentiment key gsc_sitemap_errors. Two failure modes in one rule: an explicit error, and silent staleness (Google has stopped re-reading the file). |
| Roles | owner, marketing |
Calculation
Calculated automatically from your Google Search Console data. For each submitted sitemap we read the error count and the last successful fetch date from the Sitemaps report; the alert fires if any sitemap has an error count above zero, or if the most recent successful fetch is more than 14 days old. See the At a glance summary above and the worked example below.Worked example
A UK speciality-food retailer on a headless stack, Search Console verified onthelarderco.co.uk. The site submits three sitemaps via a sitemap index: sitemap-products.xml, sitemap-pages.xml, and sitemap-blog.xml. The content team ships a 20-article seasonal campaign on 03 Jun 26.
| Sitemap | Submitted URLs | Last read by Google | Errors | Status |
|---|---|---|---|---|
| sitemap-products.xml | 4,210 | 22 Jun 26 | 0 | Healthy |
| sitemap-pages.xml | 96 | 21 Jun 26 | 0 | Healthy |
| sitemap-blog.xml | 0 | 02 Jun 26 | 1 | Alert: 1 error AND last read 20 days ago |
- The blog sitemap broke at the moment of the campaign launch. A deploy on 03 Jun changed the blog’s URL structure but the sitemap generator kept emitting the old paths, which now 404. Google read the file once on 02 Jun, then on 03 Jun hit a malformed entry, flagged an error, and stopped re-reading. The 20 new articles were listed under old, dead URLs, so Google never discovered the live versions. The team believed the campaign was live; in search it was invisible.
- Triage workflow when this card fires. Order of investigation: (a) open the offending sitemap URL directly in a browser, does it load valid XML, or 404 / 500 / return HTML? (b) validate the XML against the sitemap protocol, malformed tags, wrong namespace, or an HTML error page served with a 200 status are common; (c) check that every listed URL is canonical, returns 200, and is not blocked by robots or noindex, Google flags sitemaps full of non-indexable URLs; (d) confirm the
lastmoddates are accurate and not all set to “now” on every build, which trains Google to distrust them; (e) once fixed, resubmit the sitemap in the Sitemaps report to prompt an immediate re-read. - Why the alert leads the clicks cards. The 20 articles earned zero impressions because Google never indexed them; there was no click drop to detect, just an absence of the gains the campaign should have produced. A clicks-trend card cannot flag traffic that never existed. This alert caught the broken sitemap on the day Google logged the error, letting the team fix the URLs and resubmit; the articles were indexed within four days and began earning impressions, instead of staying invisible for the life of the campaign.
Sibling cards merchants should reference together
| Card | Why pair it with Sitemap-Errors Alert |
|---|---|
| Sitemap Status | The full per-sitemap status board: submitted, read, discovered URLs, and error state for every file. |
| Sitemap Last Submitted | The staleness companion. Shows the last-read date per sitemap so you can spot a file Google has quietly stopped fetching. |
| Index-Coverage-Drop Alert | The de-indexing alarm. A broken deploy often breaks the sitemap and the index together. |
| Pages Not Indexed | The downstream effect. URLs that should have been discovered show up here as “Discovered, currently not indexed” or “Crawled, not indexed”. |
| Indexed Pages | The headline count. New content that is invisible never lifts this figure. |
| Index Coverage Trend | The 30-day view of whether discovery is keeping pace with publishing. |
| Indexing Trend | The rate at which new URLs are entering the index, the metric a broken sitemap suppresses. |
| Slow-Indexed Pages | The cross-channel view of pages that are discovered but slow to index. |
Reconciling against the source
Where to look in Google Search Console:Indexing → Sitemaps. The submitted-sitemaps table lists every file with its type, last-read date, status (Success / Has errors / Couldn’t fetch), and discovered-URL count. This is exactly the data the alert watches. Click into a sitemap to see the specific issues Google found. URL Inspection tool. For a single new URL that should have been discovered, run a live test to see whether Google can fetch it and what canonical it picks. Useful for confirming the URL itself is fine and the problem is purely the sitemap listing.Other GSC views that are related but are not this alert:
- Pages report: shows index membership, not sitemap health. A URL can be indexed even if the sitemap is broken (Google found it another way), and a healthy sitemap does not guarantee indexing.
- Crawl stats (Settings → Crawl stats): crawl volume and response codes. A sitemap that times out shows up here as failed fetches.
| Reason | Direction of divergence |
|---|---|
| Reporting delay. Search Console updates a sitemap’s status only when it re-reads the file, and the report itself can lag 2 to 3 days. A sitemap you just fixed may still show “Has errors” until Google re-fetches it. | Lag of hours to days |
| Re-read cadence. Google decides when to re-fetch a sitemap; it is not on a fixed schedule. Our “last read > 14 days” rule uses Google’s own last-read date, so it tracks the UI exactly, but the underlying cadence is Google’s, not ours. | Matches UI |
| Sitemap index nesting. If you submit a sitemap index that references child sitemaps, the UI rolls some status up to the index level. We read each entry Google exposes; counts can differ from a quick glance at the index row. | Variable |
Warnings vs errors. GSC distinguishes hard errors from softer warnings. Our errors_count > 0 trigger keys on errors; a sitemap with only warnings (for example, some URLs blocked by robots) may read “Success with warnings” in the UI and not fire the alert. | Warnings do not fire |
| Card | Expected relationship | What divergences mean |
|---|---|---|
google_search_console.indexing-trend | A broken sitemap flattens the rate of new URLs entering the index. | A flat indexing trend with a healthy sitemap points to a content-quality or crawl-budget issue, not discovery. |
google_search_console.pages-not-indexed | New URLs that should have been discovered pile up in “Discovered, currently not indexed”. | Use it to confirm which specific URLs the broken sitemap failed to surface. |
google_analytics.organic-vs-paid-traffic | A failed launch shows as missing organic-session growth on the new landing pages. | Flat organic on new pages plus a sitemap error confirms the launch never reached search. |
Known limitations / merchant FAQs
I fixed the sitemap and resubmitted, but the alert is still red. Why? Search Console updates a sitemap’s status only when Google re-reads the file, and that can lag hours to a couple of days even after a manual resubmit. The alert tracks Google’s published status, so it will clear on the next poll after Google records a successful fetch. Use the Sitemaps report’s “Refresh” and confirm the last-read date has advanced before assuming the fix did not take. Why does a 14-day staleness window count as an error? A sitemap Google has not re-read for two weeks is either no longer being fetched (a discovery problem) or no longer changing (a publishing problem). Either way it has stopped doing its job of signalling fresh content. The 14-day window is long enough to absorb Google’s irregular re-read cadence on a healthy site, but short enough to flag a file that has genuinely gone quiet. My sitemap shows “Success with warnings”, not errors. Should I worry? Warnings are softer than errors and do not trip this alert by default. Common warnings include URLs in the sitemap that are blocked by robots.txt or that redirect; Google reads the file fine but flags that some listed URLs are not ideal. Worth cleaning up, but not the emergency that a hard error or a “Couldn’t fetch” status represents. Do I even need a sitemap if Google can crawl my site through links? For a small, well-linked site Google may discover everything via internal links. But sitemaps dramatically speed discovery of new and deep pages, and they are the standard way to signallastmod. For an ecommerce catalogue with thousands of URLs, a working sitemap is not optional, it is how you keep discovery fast and complete.
The sitemap is fine but my new pages still are not indexed. What gives?
A sitemap guarantees discovery, not indexing. Google can read the file, find your URLs, and still decide not to index them (thin content, duplicates, soft 404s, or crawl-budget limits). If this card is green but pages stay out, the problem is downstream: check Pages Not Indexed for the specific reason bucket.
Can multiple sitemaps trip the alert at once?
Yes. The trigger checks every submitted sitemap, so a single broken child sitemap in a large index will fire the alert even while the others are healthy. The card identifies which file is at fault so you can scope the fix, rather than implying the whole index is broken.
Can I change the staleness threshold?
Yes, sensitivity thresholds are configurable per profile in the Sensitivity tab. If your site publishes infrequently and a 14-day quiet period is normal, lengthen the window; if you publish daily and want tighter assurance that Google is re-reading, shorten it.