> ## 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 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. **Card class:** [Sensitivity](/nerve-centre/overview#card-classes-explained) • **Category:** [Sitemaps](/nerve-centre/connectors#connectors-by-type) > 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](/nerve-centre/kpi-cards/google-search-console/indexed-pages) and [Total Clicks](/nerve-centre/kpi-cards/google-search-console/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](/nerve-centre/kpi-cards/google-search-console/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](/nerve-centre/kpi-cards/google-search-console/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 Sensitivity tab. ## Sibling cards merchants should reference together | Card | Why pair it with Sitemap Last Submitted | | ---------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | [Sitemap Status](/nerve-centre/kpi-cards/google-search-console/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](/nerve-centre/kpi-cards/google-search-console/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](/nerve-centre/kpi-cards/google-search-console/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](/nerve-centre/kpi-cards/google-search-console/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](/nerve-centre/kpi-cards/google-search-console/index-coverage-drop-alert) | Fires when indexed coverage falls. A stale sitemap read is one of the upstream causes worth ruling out. | | [Indexing Trend](/nerve-centre/kpi-cards/google-search-console/indexing-trend) | The longer view of indexing health, useful for confirming whether a stale sitemap is biting over time. | | [Total Pages Indexed](/nerve-centre/kpi-cards/google-search-console/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 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 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](/nerve-centre/kpi-cards/google-search-console/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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.