The freshness clock on your content-discovery pipeline. If Google has not re-read your sitemap in over two weeks, new and updated pages may be sitting undiscovered.
At a glance
Sitemap Last Submitted reports the date Google Search Console last successfully processed your submitted sitemap (or sitemap index), and how many days ago that was. It is a real-time freshness check, not a performance metric. It fires when more than 14 days have passed since the last successful submission, because a sitemap that Google has stopped reading is one of the quietest ways for new content to go undiscovered. SEO and content teams use it as an early-warning canary, well before a click or impression drop shows up on the Performance cards.
| What it tracks | The lastSubmitted (and where available lastDownloaded) timestamp Search Console reports for each submitted sitemap, surfaced as a date plus a days-since count. For a sitemap index, the most recent successful read across the index is used. |
| Data source | The Search Console Sitemaps report and the matching Search Console API sitemaps.list / sitemaps.get response (lastSubmitted, lastDownloaded, isPending, warnings, errors). Source meaning: “Sitemap Last Submitted for the selected period.” |
| Time window | RT (real-time, read on each refresh). There is no trailing-period aggregation: the card always shows the single most recent successful read. |
| Alert trigger | >14 days since last successful submission. Sentiment escalates from healthy (read in the last 7 days) to amber (8 to 14 days) to red (over 14 days). |
| Units | A calendar date (dd MMM yy) plus an integer “days ago” count. |
| Roles | owner, marketing |
| Why it matters | Google does not crawl on a fixed schedule. A sitemap it has stopped reading means new product pages, blog posts, or category pages may wait far longer to be discovered and indexed. This card catches a stalled discovery pipeline before the downstream Indexed Pages and Total Clicks cards visibly degrade. |
Calculation
The card reads every sitemap registered against the property in Search Console and takes the most recent successful processing timestamp. The logic, grounded in thedetail source (“Sitemap Last Submitted for the selected period”):
- Call the Search Console
sitemaps.listendpoint for the property to enumerate all submitted sitemaps and sitemap indexes. - For each entry, read
lastSubmitted(when you, or an automated job, last told Google about the sitemap) andlastDownloaded(when Google last actually fetched and parsed it). - Take the most recent successful
lastDownloadedacross all sitemaps as the headline freshness date. IflastDownloadedis unavailable for a property, fall back tolastSubmitted. - Compute
days_since = today − that datein the property’s reporting time zone. - Map to sentiment:
days_since ≤ 7healthy,8 ≤ days_since ≤ 14amber,days_since > 14red (alert).
isPending: true, or one that has never been downloaded, is treated as “not yet read” and counts against the freshness clock from its submission date.
Worked example
A UK outdoor-clothing retailer runs a content programme: roughly eight new buying-guide articles and a dozen new product pages every month. Their Search Console property has one sitemap index,sitemap_index.xml, pointing at three child sitemaps (products, collections, blog).
On 23 Jun 26 the card reads:
| Sitemap | Last submitted | Last downloaded (read) | Days ago | Status |
|---|---|---|---|---|
sitemap_index.xml | 02 Jun 26 | 06 Jun 26 | 17 | Red: over 14 days |
/products.xml | 02 Jun 26 | 06 Jun 26 | 17 | Stale |
/collections.xml | 02 Jun 26 | 06 Jun 26 | 17 | Stale |
/blog.xml | 02 Jun 26 | 06 Jun 26 | 17 | Stale |
- The clock is measured from
lastDownloaded, notlastSubmitted. The team last submitted on 02 Jun 26 and Google last read it on 06 Jun 26. Seventeen days of silence since the last read is the meaningful number: it means every article and product published since roughly 06 Jun 26 has not been announced to Google through the sitemap channel. They may still be discovered through internal links, but the fast lane is closed. - Cross-check before you panic. A long gap is normal for a low-change site, Google reads less often when little changes. It is a problem for this retailer specifically because they publish weekly. The card pairs with Indexed Pages: if indexed-page count has flatlined while you keep publishing, the stale sitemap is the likely cause.
- The fix and what “fixed” looks like. The team re-submitted the sitemap index in Search Console and confirmed it returned HTTP 200 with valid XML. Within four days,
lastDownloadedadvanced to 24 Jun 26,days agoreset to 1, and the card returned to healthy. Had re-submission not helped, the next step is the Sitemap Status card to check for parse errors, and a manual fetch of the sitemap URL to confirm it is reachable and not returning a 404, 5xx, or redirect.
Sibling cards merchants should reference together
| Card | Why pair it with Sitemap Last Submitted |
|---|---|
| Sitemap Status | The companion. If the sitemap is stale because it has parse errors, this card lists the errors and warnings per sitemap. Always check both together. |
| Sitemap Errors Alert | The hard alert that fires on sitemap errors. A stale sitemap is often a symptom of an error Google keeps hitting. |
| Indexed Pages | The downstream effect. A stalled sitemap read tends to flatten the indexed-page count if you are publishing new content. |
| Pages Not Indexed | Shows the pages Google knows about but has not indexed; a stale sitemap can leave new pages stuck here. |
| Index Coverage Drop Alert | Fires when indexed coverage falls. A stale sitemap read is one of the upstream causes worth ruling out. |
| Indexing Trend | The longer view of indexing health, useful for confirming whether a stale sitemap is biting over time. |
| Total Pages Indexed | The headline indexed total this card ultimately protects. |
Reconciling against the source
Where to look in Google Search Console:
Indexing → Sitemaps. The “Submitted sitemaps” table shows each sitemap with a “Last read” date and a status (Success, Has errors, Couldn’t fetch). The “Last read” date is the same lastDownloaded value this card uses. Click a sitemap row to see the discovered-pages count and any issues.
The matching API is webmasters.sitemaps.list (and sitemaps.get for a single sitemap), which returns lastSubmitted, lastDownloaded, isPending, isSitemapsIndex, warnings, errors, and a per-content-type discovered/indexed breakdown.
Why our value may legitimately differ from the Search Console UI:
| Reason | Direction of divergence |
|---|---|
| Data delay. Search Console data, including sitemap processing timestamps, is typically 2 to 3 days behind real time. A sitemap read “today” may not surface in either the UI or the API for a couple of days. | Card may lag the true read date by 2 to 3 days |
| Index vs child sitemaps. We headline the most recent read across the whole index; the UI lists each child sitemap separately. If one child was read more recently than the index file, the numbers can look different until you expand the rows. | Card shows the freshest; UI shows per-file detail |
| Time-zone boundary. Our “days ago” count uses the property’s reporting time zone; a read late in the day can flip the day count by one depending on zone. | ±1 day |
Submitted vs downloaded. The UI’s “Last read” is lastDownloaded. If you only ever look at when you submitted the file, you will see a different (usually earlier or later) date. | We use lastDownloaded by design |
Known limitations / FAQs
My sitemap shows “Success” in Search Console but the card still says it is stale. Why? “Success” means the last read parsed cleanly; it says nothing about when that read happened. If the last successful read was 20 days ago, the status is still “Success” but the freshness clock has run out. This card watches the date, not the status, which is exactly why the two complement each other. Is a long gap always bad? No. Google reads sitemaps more often for sites that change often. A site that rarely publishes can go weeks between reads and be perfectly healthy. The 14-day default suits a site that publishes weekly. If you publish rarely, relax the threshold in the Sensitivity tab so the card does not cry wolf. I re-submitted the sitemap an hour ago and the card has not updated. Is it broken? Almost certainly not. Search Console processing and its reported timestamps lag real time by roughly 2 to 3 days. Re-submission triggers a re-read, but the newlastDownloaded date can take a day or two to surface in both the UI and the API. Check back in 48 to 72 hours.
Does this card cover multiple sitemaps?
Yes. It enumerates every sitemap and sitemap index registered against the property and headlines the most recent successful read across all of them. Use Sitemap Status when you need the per-sitemap breakdown.
The card fired but my new pages are getting indexed fine. Should I ignore it?
Not entirely. Pages can still be discovered through internal links and external backlinks even when the sitemap is stale, so indexing may continue. But you have lost your fastest, most explicit discovery channel, which matters most for pages that are not yet well linked (new products, fresh articles). Treat the alert as “fix the discovery fast lane” rather than “indexing is broken”.
Why use lastDownloaded rather than lastSubmitted?
lastSubmitted only records that you, or a job, pinged Google about the sitemap. lastDownloaded records that Google actually fetched and parsed it. Only the latter proves the discovery pipeline is live, so that is the figure the freshness clock is built on.