Google Search Console indexing status log
Record URL Inspection findings over time and export a local CSV log. This browser-only worksheet helps you compare which URLs share a reported status, sitemap observation, or canonical choice. A sitemap being processed does not mean every URL will be indexed, and this tool cannot inspect Search Console or diagnose why Google made an indexing decision.
Log URL observations
Use one row per URL per check date. Enter the status shown in Search Console and copy canonical values from URL Inspection when available. Do not include private query data or credentials.
| Checked date | Page URL | Page indexing status | In submitted sitemap? | User-declared canonical | Google-selected canonical | Remove row |
|---|
Rows stay in this page until you leave or reload. No data is sent to this site.
Summary and review prompts
Canonical groups in this worksheet
Rows are grouped by the exact Google-selected canonical URL you entered. Compare the declarations within each group; a mismatch is a review cue, not a diagnosis.
Fixed URL comparison: earliest versus latest check date
The comparison needs repeated observations on at least two distinct dates.
| Page URL | Earliest date · status | Latest date · status | Change |
|---|
Only URLs with exactly one row on both boundary dates are compared. The dates and status labels are observations you entered; a change does not identify its cause. This is a fixed-sample comparison, not a sitewide indexing rate.
Log sitemap report observations
Use one row for each check of a sitemap in a specific Search Console property. Copy the latest status, Submitted date, Last read date, and Discovered pages from the Sitemaps report. Keep the check date separate from the report's submission and read dates.
| Checked date | Search Console property | Exact sitemap URL | Submitted date | Last read date | Latest status | Discovered pages | Report error or note | Remove row |
|---|
Entries stay in this page until you leave or reload. No data is sent to this site.
Latest status comparison in this worksheet
| Property · sitemap URL | Earliest check | Latest check | Recorded change |
|---|
This compares only the observations entered here. It cannot establish why a status changed or whether listed pages were crawled or indexed.
How should I interpret a sitemap report history?
The Sitemaps report shows the latest request for each sitemap in the current property. “Success” means fetched and read without errors; “Has errors” means Google could fetch it but encountered parsing errors, and URLs parsed without errors are queued; “Couldn't fetch” means the sitemap itself could not be retrieved. Record the exact property because Search Console does not show a sitemap submitted to a different property, and it does not list sitemaps found only through robots.txt or other discovery.
Keep four dates or values distinct: when you checked the report, when it says the sitemap was last submitted, when Google last read it, and the latest request status. A browser opening the sitemap is not proof that Google Search Console processed it. The discovered-page count is not a count of crawled or indexed URLs; use the Page indexing report when reviewing indexing.
- Choose the exact Search Console property and copy the sitemap URL shown in its report.
- On each review, record the check date and copy the current Submitted, Last read, Status, and Discovered pages fields; leave absent values blank.
- Open the sitemap row for error details. Use the separate fetch troubleshooting guide for retrieval failures; use this history to compare report observations over time.
- Compare only the same property and exact sitemap URL. A changed status is an observation, not a causal explanation. Google's report shows the latest request and can display up to 1,000 submitted sitemap requests.
How should I use this indexing log?
- Choose a fixed set of important canonical URLs and keep that sample unchanged between review dates. Record the same URLs again; adding or dropping URLs changes the sample and makes a raw total comparison misleading.
- For each check, use the Page indexing report for the reported reason and URL Inspection's indexed data for a specific URL's index details and canonical values. A live test cannot predict Google's canonical choice.
- Record the exact status and date shown for each URL. Use the same property, URL form, and status source at each review; leave unavailable fields blank rather than inferring index status from sitemap membership.
- Compare the earliest and latest dates for URLs present exactly once on both dates. Review the report history and page/deployment changes for context, but do not treat timing or co-occurrence as a cause.
- Export the rows for a dated record. The comparison reports only this entered sample and does not calculate population rates, verify Google data, or explain changes.
What do common Page indexing statuses mean?
Google distinguishes URLs it has discovered but not crawled from URLs it has crawled but not indexed. “Crawled – currently not indexed” means Google crawled the URL but did not index it at that time; Google says it may or may not be indexed later and says resubmitting that URL is not needed. “Discovered – currently not indexed” means the URL was found but not yet crawled. A duplicate or alternate status can be expected when another URL is the canonical version. Read the current report details before changing a page.
When the declared and selected canonical URLs differ, inspect both URLs and the report's canonical fields. The difference is evidence to investigate, not by itself proof of a technical fault. For a set of similar URLs, record each URL separately; this worksheet groups rows by the entered Google-selected canonical so you can spot declarations that disagree within that group. A sitemap helps Google discover URLs; it is not a guarantee of crawling or indexing.
A Search Central Community post titled “Previously indexed pages suddenly became ‘Crawled – currently not indexed’” is one example of a site owner reporting a group of status changes. It is a single site's account, not evidence that other sites share the same cause. The comparison below is designed to check whether the same sampled URLs changed labels across two dates; the Page indexing report's issue history and per-URL inspection provide context, but timing alone cannot establish why a change happened.
What does this worksheet check?
It validates that each non-empty row has a parseable HTTP or HTTPS URL and a check date, then groups exact status labels and compares any declared/selected canonical values you entered. It does not connect to Google, verify that a URL is indexed, fetch a sitemap, read your site, detect a cause, or estimate indexing rates. Its prompts are review reminders based on Google's status descriptions, not an automated diagnosis.
Frequently asked questions
Does a processed sitemap mean Google indexed every listed page?
No. Sitemap processing and URL indexing are separate observations. Google's Page indexing report says not to expect every URL to be indexed; the goal is for important canonical pages to be indexed.
Should I repeatedly request indexing for a crawled but not indexed URL?
Google's current status description says this URL may or may not be indexed in the future and says there is no need to resubmit it for crawling. Review the URL and the official report guidance instead of treating repeated requests as a fix.
Does this page store the URLs I enter?
No. The worksheet runs in your browser and creates a CSV download only when you request it. It does not call a site server or Google API. The rows disappear when you leave or reload the page.
Can the summary tell me why indexing changed?
No. It groups observations you entered and flags canonical values that differ. Compare the source pages, inspection details, and changes made to your site; this worksheet does not establish a cause.
Why compare the same URLs across dates?
A fixed sample keeps the set of URLs visible in the comparison. The page compares only exact URLs with one recorded row on both the earliest and latest dates; it does not turn that sample into a sitewide rate or show that any change caused another.
Sources · checked November 3, 2026
- Google Search Console Help: Page indexing report · status meanings and canonical guidance
- Google Search Console Help: URL Inspection tool · page index details
- Google Search Console Help: Sitemaps report · processing and fetch status
- Search Central Community discussion · one report of a sitemap URL appearing accessible while Search Console reported a fetch problem; qualitative example only
- Search Central Community discussion · sitemap processed while new pages were reported unindexed; one user's question, not prevalence data
- Search Central Community discussion · one report of changing discovery/inspection observations
- Search Central Community discussion · one report of previously indexed URLs moving to “Crawled – currently not indexed”; qualitative example only
Related: separate live tests from indexed observations, troubleshoot sitemap fetch reports, and see how this site records evidence limits.
Methodology and limitations
The fixed-sample comparison pairs exact URLs with one recorded observation on each boundary date, excludes missing or duplicate boundary rows, and reports only entered status labels. It does not connect to Google, verify observations, calculate a sitewide rate, or infer causes. Google documentation and the cited Search Central Community post were checked November 3, 2026; the post is a single qualitative case.
Affiliate placeholder {{AFF_TOOLNAME}} — referral link not configured.