Sitemap Last Submitted, Google Search Console

Tracks how long it has been since Search Console last successfully read your submitted sitemap, the canary for a broken or stale content-discovery pipeline. How to read it, why it matters, and how to act on it.

Metrics type: Supporting Metrics • Category: Sitemaps

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 the detail source (“Sitemap Last Submitted for the selected period”):

1. Call the Search Console sitemaps.list endpoint for the property to enumerate all submitted sitemaps and sitemap indexes.
2. For each entry, read lastSubmitted (when you, or an automated job, last told Google about the sitemap) and lastDownloaded (when Google last actually fetched and parsed it).
3. Take the most recent successful lastDownloaded across all sitemaps as the headline freshness date. If lastDownloaded is unavailable for a property, fall back to lastSubmitted.
4. Compute days_since = today − that date in the property’s reporting time zone.
5. Map to sentiment: days_since ≤ 7 healthy, 8 ≤ days_since ≤ 14 amber, days_since > 14 red (alert).

A sitemap stuck in 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

Headline value: Last read 06 Jun 26, 17 days ago. Alert firing.

Three observations:

1. The clock is measured from lastDownloaded, not lastSubmitted. 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.
2. 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.
3. 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, lastDownloaded advanced to 24 Jun 26, days ago reset 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.

Rule of thumb. If you publish weekly or more often, treat anything over 7 days as worth a look and over 14 days as a definite investigation. If you publish rarely, a longer gap is expected and the alert can be relaxed in the Alert Rules tab.

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

Reconciliation steps. (1) Open Indexing → Sitemaps and compare the “Last read” date to the card. (2) If they disagree by more than 3 days, allow for the standard Search Console data delay before treating it as a real divergence. (3) Fetch the sitemap URL directly in a browser to confirm it returns HTTP 200 and valid XML. (4) If the URL is healthy but the read date is still old, remove and re-add the sitemap in Search Console to force a fresh read.

This card is not a substitute for the native Sitemaps report; it is a watch that tells you when to open that report.

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 Alert Rules 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 new lastDownloaded 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.

---

Tracked live in Vortex IQ Nerve Centre

Sitemap Last Submitted 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 or book a demo to see this metric running on your own data.