SEO Indexation Ledger from Publication to Ranking

Learn why separating indexation states is critical for SEO tracking, and get clear definitions and evidence sources for eight distinct states from published to ranked.

Why Track Indexation States Separately?

When you publish a URL, it does not mean Google has indexed it. When Google crawls a URL, it does not mean the URL is indexed. Conflating these states leads to misdiagnosis and wasted effort.

For example, you might see a drop in rankings and assume Google deindexed the page, when in reality the page was never indexed in the first place—it was only crawled.

Or you might submit a sitemap and assume all URLs are indexed, but submission only tells Google the URLs exist; it does not guarantee crawling or indexing.

A clear model separates each stage of a URL’s lifecycle. Think of it as a state machine: each state has entry criteria and evidence that confirms the URL is in that state.

Without this separation, you cannot accurately diagnose issues or measure the impact of your SEO actions. For instance, if you improve content but see no ranking change, you need to know whether the URL is even indexed.

If it is not indexed, your content changes are irrelevant until Google picks it up.

Tracking states separately also helps you prioritize. If many URLs are discovered but not crawled, you might need to improve internal linking or server response times. If URLs are crawled but not indexed, you might have a quality or duplication issue.

Each state requires a different fix. A ledger that records each state with evidence lets you spot patterns and take targeted action.

Moreover, evidence-based tracking prevents assumptions. Instead of guessing whether a URL is indexed, you check the evidence: a `site:` query, Google Search Console’s URL Inspection, or server logs. Each state has a specific evidence source.

By recording the evidence and timestamp, you build a reliable history. This is especially important for large sites where manual checking is impractical. A structured ledger allows you to audit hundreds of URLs systematically.

In summary, separating indexation states gives you clarity, prevents misdiagnosis, and enables data-driven decisions. The following section defines eight distinct states and the evidence that confirms each.

Defining the Eight States with Evidence

To build a useful indexation state ledger, you need to define each state precisely and know what evidence confirms it. Here are eight states that cover a URL’s lifecycle from publication to ranking.

For each state, we list the definition, entry criteria, and evidence sources.

### 1. Published

**Definition:** The URL is live on your server and returns a successful HTTP status code (typically 200 OK). This is the baseline state; it does not imply any search engine awareness.

**Entry criteria:** The URL is accessible via a direct browser request without authentication or errors.

**Evidence:** Use a browser or an HTTP status checker (e.g., curl, Screaming Frog) to confirm the URL returns HTTP 200. Record the date and time of the check.

### 2. Accessible

**Definition:** The URL is not blocked from search engine crawling by robots.txt, meta robots tags, or other technical barriers. Accessibility is a prerequisite for crawling.

**Entry criteria:** The URL is not disallowed in robots.txt, does not contain a `noindex` meta tag, and does not require login or other access restrictions.

** Use Google Search Console’s URL Inspection tool to see if Google can access the URL. Alternatively, check robots.txt and the page’s HTML for `noindex` directives. Record the inspection result.

### 3. Submitted

**Definition:** You have explicitly notified search engines about the URL via a sitemap or manual submission (e.g., in Google Search Console). Submission does not guarantee crawling or indexing.

**Entry criteria:** The URL is included in a sitemap that you have submitted to the search engine, or you have used a submission tool.

** In Google Search Console, check the sitemap report to see if the URL is listed and the submission date. For manual submission, you can see the submission history in the URL Inspection tool. Record the submission date and method.

### 4. Discovered

**Definition:** The search engine knows the URL exists but has not yet attempted to crawl it. Discovery can happen through sitemaps, internal links, or external links.

**Entry criteria:** The search engine has recorded the URL in its index of known URLs, but no crawl request has been made.

** In Google Search Console, the URL Inspection tool may show "URL is known to Google" but not yet crawled. Server logs will show no crawl requests from Googlebot. Record the discovery date if available.

### 5. Crawled

**Definition:** The search engine has successfully fetched the URL. Crawling does not imply indexing; the content may be processed and then discarded.

**Entry criteria:** A search engine crawler (e.g., Googlebot) has made an HTTP request to the URL and received a successful response.

** Check server logs for requests from Googlebot’s user agent. In Google Search Console, the URL Inspection tool may show the last crawl date. Record the crawl date and HTTP status.

### 6. Indexed

**Definition:** The URL is stored in the search engine’s index and is eligible to appear in search results. Indexing means the content has been processed and deemed worthy of inclusion.

**Entry criteria:** The search engine has decided to include the URL in its index after crawling and processing.

** Use a `site:` query in the search engine (e.g., `site:[source URL]/your-page`) to see if the URL appears. In Google Search Console, the URL Inspection tool will show "URL is on Google." Record the date you confirmed indexing.

### 7. Impressed

**Definition:** The URL has appeared in search results for at least one query, meaning it has been shown to users. Impressions do not guarantee clicks.

**Entry criteria:** The URL is indexed and has been served in search results for any query.

** In Google Search Console, the Performance report shows impressions for specific URLs. Record the date range and query that triggered the impression.

### 8. Ranked

**Definition:** The URL has achieved a specific position in search results for a given query. Ranking is relative and changes over time.

**Entry criteria:** The URL appears in search results for a query and has a measurable position.

** Use a rank tracking tool (e.g., SEMrush, Ahrefs) or manual search to record the position. In Google Search Console, the Performance report shows average position. Record the query, position, and date.

### Ledger Template

To track these states, use a ledger with the following fields. For each URL, record the current state and evidence.

For each state, note the evidence source (e.g., Google Search Console, server logs, site: query) and the date you last verified it. This template helps you see at a glance which URLs are stuck and what evidence supports each state.

### Common Misconceptions

– **Published means indexed:** False. A URL can be live for months without being indexed.
– **Crawled means indexed:** False. Google may crawl a page and decide not to index it due to quality or duplication.
– **Submitted means indexed:** False. Submission only notifies the search engine; it does not guarantee crawling or indexing.
– **Indexed means ranked:** False. A page can be indexed but not rank for any meaningful query.

By separating these states, you avoid these misconceptions and can take appropriate action. For example, if a URL is crawled but not indexed, you might need to improve content quality or remove duplicate content.

If it is indexed but not impressed, you might need to target different keywords.

### Tools and Methods

To gather evidence, use these tools:

– **Google Search Console:** URL Inspection, Performance report, Sitemaps report.
– **Server logs:** Analyze crawl requests from Googlebot.
– **Site: queries:** Quick check for indexing.
– **HTTP status checkers:** Verify published state.
– **Rank tracking tools:** Monitor positions.

Remember to record the date and time of each check, as states can change. A ledger is only useful if it is current.

In the next part, we will discuss how to build and maintain your ledger, including automation and common pitfalls.

Ledger Fields: What to Record Per URL

Building a reliable SEO indexation state ledger requires a structured set of fields that capture both the current state and the evidence supporting it.

The goal is to create a single source of truth for each URL’s lifecycle in search engines, enabling you to spot anomalies and take corrective action. Below is a practical field list, designed to be extensible and adaptable to your workflow.

**Core Identification Fields**
– **URL**: The full canonical URL, including protocol (https) and trailing slash if applicable. Use a consistent format to avoid duplicates. – **Page Title**: The current title tag as rendered in HTML.

This helps identify content changes that might affect indexing. – **Last Modified Date**: The date the page content was last updated, based on your CMS or file system. This is crucial for understanding recrawl triggers.

– **Target Keywords**: The primary keywords the page is intended to rank for. This helps align state tracking with SEO goals.

**State Status Fields**
For each of the eight states—published, accessible, submitted, discovered, crawled, indexed, impressed, and ranked—record a status. Use a Boolean (true/false) or a date when the state was first observed.

For example:
– **Published**: Date when the page went live. – **Accessible**: Boolean, with a note if HTTP status is not 200. – **Submitted**: Date when the URL was submitted via sitemap or Search Console.

– **Discovered**: Date when the crawler first fetched the URL (from logs). – **Crawled**: Date of the last successful crawl (HTTP 200 for HTML). – **Indexed**: Date when the URL appeared in the index (via URL Inspection).

– **Impressions**: Boolean or date when impressions first appeared in Performance reports. – **Ranked**: Boolean or date when the page achieved a position for a target keyword.

**Evidence Source Fields**
For each state, record the evidence source. This is critical for verification. Use a text field to note the tool and specific data point, e. g.

, "Search Console URL Inspection, indexed on 2026-09-01" or "Server log entry, crawl at 2026-09-02 03:14 UTC." Include a timestamp for when the evidence was captured.

**Notes and Action Items**
A free-text field for anomalies, such as sudden de-indexing, crawl errors, or manual actions. Also track action items like "resubmit after content update" or "check for duplicate content."

**Ledger Template Example**
| URL | Page Title | Last Modified | Target Keywords | Published | Accessible | Submitted | Discovered | Crawled | Indexed | Impressions | Ranked | Evidence Source | Last Checked | Notes |
|—–|————|—————|—————–|———–|————|———–|————|———|———|————-|——–|—————–|————–|——-|
| [source URL] | Example Page | 2026-08-15 | example keyword | 2026-08-15 | Yes | 2026-08-16 | 2026-08-17 | 2026-08-18 | 2026-08-19 | Yes | No | Search Console URL Inspection | 2026-09-05 | None |

This template is a starting point; you can add custom fields for specific needs, such as content type or campaign. The key is to maintain discipline in updating the ledger regularly, ideally weekly, to reflect the latest evidence.

Common Misconceptions Clarified

Many SEO professionals conflate states or assume that one state guarantees another. Clarifying these misconceptions is essential for accurate tracking and effective troubleshooting.

**Misconception: Crawled means indexed. **
A page can be crawled but not indexed for various reasons, including duplicate content, low quality, or canonicalization issues.

Google’s own guidance emphasizes that indexing is a separate step after crawling, and not all crawled pages are stored in the index. For example, a page with thin content might be crawled but excluded from the index.

Use Search Console’s URL Inspection tool to see the actual indexing status, not just server logs.

**Misconception: Impressions imply ranking. **
Impressions in Search Console indicate that a page appeared in search results, but it might be for a low-competition query or in a position that doesn’t receive clicks.

A page can have impressions without ranking for its target keywords. For instance, a page might show up for a long-tail variant but not for the main keyword. Cross-reference the Performance report with keyword data to see which queries generate impressions.

**Misconception: Indexed is a permanent state. **
Pages can be de-indexed due to noindex tags, robots. txt changes, or algorithmic actions.

Google’s documentation notes that pages can be removed from the index if they violate guidelines or if the URL returns a 404. Therefore, the ledger should track the indexed state as a dynamic field, not a one-time event.

Regularly check URL Inspection and monitor for drops in indexed pages.

**Misconception: Submitting a sitemap guarantees indexing. **
Submitting a sitemap is a signal, not a guarantee. Google states that submitting a sitemap does not ensure that all URLs will be crawled or indexed.

The ledger should record submission as a separate state, but it does not imply that the page will be indexed. Compare submission dates with actual crawl dates from server logs.

**Misconception: HTTP 200 means the page is indexable. **
A 200 status code indicates accessibility, but the page might still be excluded from indexing due to meta robots tags, canonical tags, or content quality.

For example, a page with a noindex meta tag will return 200 but not be indexed. Use URL Inspection to see the indexing decision, not just the HTTP status.

By understanding these distinctions, you can avoid false assumptions and focus on the evidence that confirms each state.

Tools and Evidence Sources

To maintain an accurate ledger, you need reliable tools and evidence sources. Below are practical options, each with its strengths and limitations.

**Google Search Console (GSC)**
– **URL Inspection**: Provides the current indexing status, including whether the page is indexed and any issues. This is the most direct evidence for the indexed state.

– **Indexing reports**: Show which pages are indexed and which are not, with reasons for exclusion. – **Performance reports**: Provide impressions and clicks data, useful for tracking impressions and ranking states.

– **Sitemaps**: Allows you to submit URLs and see the submission status.

**Server Logs**
– Analyze crawler hits to confirm crawl behavior. Look for user agents like Googlebot and record the timestamp, URL, and HTTP status. This is the primary evidence for the discovered and crawled states.

– Tools like Splunk or custom scripts can parse logs to extract crawl data.

**Site: Queries**
– Performing a `site:[source URL]/page` search on Google can give a quick indication of indexing, but it is not exhaustive. Google’s documentation notes that site: queries are not a complete list of indexed pages.

Use this as a supplementary check, not as definitive evidence.

**Third-Party Tools**
– **Screaming Frog**: Can crawl your site and simulate Googlebot, providing data on HTTP status, meta robots, and canonical tags. It helps identify potential indexing barriers.

– **Sitebulb**: Offers similar features with visualizations and audit reports. – **Custom Scripts**: For advanced users, writing scripts to pull data from GSC API and server logs can automate ledger updates.

**Evidence Boundaries**
Each tool has limitations. GSC data is not real-time and may have delays. Server logs only show crawls that occurred, not why a page wasn’t crawled. Site: queries are incomplete.

Therefore, triangulate evidence from multiple sources to confirm a state. For example, if GSC says a page is indexed, but server logs show no recent crawl, the page might be indexed from an older crawl.

In practice, a combination of GSC for indexing and impressions, server logs for crawl activity, and a crawler tool for on-page factors provides a robust evidence base. Regularly update your ledger with timestamps to track changes over time.

Next step

Download our free CSV template to start your own indexation state ledger.