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.
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.
Three numbered observations:
- 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
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.
Cross-connector reconciliation:
This card is not the source of truth for sitemap health; Google Search Console is. It mirrors the figures Google publishes in the Sitemaps report and raises the alarm the moment a file errors or goes stale, so a content-launch failure surfaces on launch day rather than weeks later when someone notices the new pages earned nothing.
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, alert thresholds are configurable per profile in the Alert Rules 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.