Google Index Checker for Every URL You Publish

verdict is the first field the index checker reads on every inspection. Google returns one of four values, and SearchAnalysis.io stores the value with the check, in the same row as the time and the source of that inspection.

PASS is one of two ways a URL becomes Indexed. The other is a coverageState that says the page is indexed. Either way, green means verified and nothing else. A notification Google accepted through the Indexing API never turns a row green on its own.

Where the Verdict Shows

• The URL detail page, under the latest verdict fields.
• The full inspection history for the URL, one row per check.
• The Monitor, which lists every URL with its per-channel statuses.
• Per-URL, per-channel state from the SearchAnalysis.io REST API at GET /api/v1/submissions/{batchId}.

Until the first PASS arrives, the URL keeps climbing the inspection ladder, and after the ladder a daily fallback keeps checking.

coverageState is the coverage state Google reports for the inspected URL. The index checker stores it on every inspection and shows it in each check history row next to the state (INDEXED, NOT_INDEXED or ERROR). A coverage state that says indexed confirms the URL, the same as a PASS verdict.

For pages that are not indexed, the Page indexing report in Search Console names a reason. These are the reasons you meet most often when you read a coverage state:

Reasons Worth Knowing by Name

Every check history row keeps the coverage state from the day of that check. Read the rows in order and you see how a page moved from one state to the next across inspections, and on which date the change appeared.

robotsTxtState tells you whether robots.txt lets Google crawl the URL. It has two values, and the index checker stores whichever one comes back on each inspection. Because the state is stored again on every check, the check history shows the first inspection where a rule started blocking the URL, and the first one after the block was lifted.

• ALLOWED: no robots.txt rule blocks the URL.
• DISALLOWED: a robots.txt rule blocks the URL.

A DISALLOWED state lines up with the Page indexing report reason “URL blocked by robots.txt”. Google lists a related warning too, “Indexed, though blocked by robots.txt”, so a blocked URL may still appear in the index while Google cannot crawl it.

Test the Rule Before the Next Inspection

The free indexability checker reads robots.txt with these rules: the Googlebot group wins over *, the longest matching rule decides, and Allow wins a tie. Run it after you edit robots.txt, then let the next ladder check or 7-day recheck record the new state in the check history.

User-agent: Googlebot
Disallow: /drafts/
Allow: /drafts/published/

In this example, a URL under /drafts/published/ is allowed for Googlebot, because the longer Allow rule decides. Any other URL under /drafts/ comes back DISALLOWED. indexingState has its own robots.txt value, BLOCKED_BY_ROBOTS_TXT, so read the two stored fields together on the URL detail page.

indexingState reports whether a directive keeps the page out of the index. SearchAnalysis.io stores it as the indexing state on each inspection, next to the verdict and the coverage state. Google returns one of four values.

A blocked meta tag or header lines up with the Page indexing report reason “URL marked 'noindex'”. The value names the place the directive lives, which tells your developer whether to look in the page template or in the server configuration.

Find and Remove the Directive

1. Run the URL through the indexability checker. Its fourth check reads noindex or none in meta robots and in X-Robots-Tag.
2. Remove the directive from the template, plugin setting or server config that adds it.
3. Leave the URL in SearchAnalysis.io. The ladder, then the daily fallback, keep inspecting unconfirmed URLs.
4. Read the indexing state on the next check history row. INDEXING_ALLOWED means the directive is gone.

A cleared directive does not force Google to index the page. It removes one reason Google gave for leaving it out, and the next inspections show whether Google indexes the page after its next crawl.

pageFetchState is a field the URL Inspection API returns about Google's attempt to fetch the page. It sits outside the six fields SearchAnalysis.io stores, so treat it as part of the API's full answer. The index checker's stored fields carry the outcome; this field names the fetch result behind it.

Page Indexing Report Reasons on the Same Theme

• Server error (5xx)
• Redirect error
• Not found (404)
• Soft 404
• Blocked due to unauthorized request (401)
• Blocked due to access forbidden (403)
• URL blocked due to other 4xx issue

The first two checks of the free indexability checker cover the same ground from outside Google. The page must return a 2xx status, or the check fails. Redirects are followed up to 5 hops, and because Google indexes the destination, you submit the destination URL.

The checker fetches as SearchAnalysisBot/1.0 with a 10-second timeout and a 2 MB page cap, so a slow or oversized page shows up there before you spend an inspection on it. It rejects localhost, private network addresses and URLs with credentials, so test the public address of the page that Google crawls.

googleCanonical is, in Google's words, “The URL of the page that Google selected as canonical”. The index checker stores it as the Google-selected canonical with each inspection. userCanonical is a field the API returns for the canonical your page declares.

When the Two Differ

If Google picks a different URL from the one you declared, the Page indexing report lists the page under “Duplicate, Google chose different canonical than user”. Two related reasons sit next to it: “Alternate page with proper canonical tag” and “Duplicate without user-selected canonical”.

• Compare the stored Google-selected canonical with the URL you submitted.
• Run the fifth check of the indexability checker: a self-referencing canonical passes, one pointing elsewhere warns, and a missing one warns.
• If Google's choice is the page you want in search, submit that URL and track it.
• If your declared URL is the right one, fix the duplicate signals and watch the next inspection.

The URL detail page shows the latest verdict fields, so the Google-selected canonical sits on the same screen as the verdict and coverage state. The check history keeps earlier snapshots for comparison, so you can see the exact inspection where Google's choice changed.

lastCrawlTime is the time Google last crawled the URL. The index checker stores it with every inspection, next to the time of the inspection itself, so each check history row carries two dates: when Google crawled, and when SearchAnalysis.io asked.

Reading the Two Dates Together

• A crawl time later than your publish date: Google fetched the page after you published it.
• A crawl time earlier than your last edit: Google has not fetched the new version yet.
• A coverage state of “Discovered, currently not indexed”: Google describes it as “The page was found by Google, but not crawled yet.”
• A crawl time that keeps moving while the state stays NOT_INDEXED: Google keeps fetching the page and keeps leaving it out.

The sitemap monitoring inventory keeps first seen and last seen dates for each URL in your sitemaps. Set those beside the crawl time and you can tell how long a page sat in the sitemap before Google fetched it.

Stored crawl times build up across the ladder: up to 6 checks over about 3 days, then a daily check until Google confirms the page, then one check every 7 days for as long as the site is connected. Each one adds a fresh crawl time.

crawledAs is a field the URL Inspection API returns for the crawler type Google used. It has two values, DESKTOP and MOBILE. It sits outside the six fields the index checker stores. Two list fields come back with each inspection as well, sitemap[] and referringUrls[], and both are returned by the API without being stored.

crawledAs: DESKTOP | MOBILE
sitemap[]
referringUrls[]

Stored Fields and Returned Fields

The stored column is what you see on the URL detail page and in each check history row. Developers read per-URL, per-channel status through the SearchAnalysis.io REST API and MCP server: GET /api/v1/submissions/{batchId} returns a batch with the state of every URL, and the check_url_index_status MCP tool returns a single URL's index status to an AI agent.

The public OpenAPI 3.1 document at /openapi.json describes each endpoint, and /llms.txt lists the machine endpoints for agents that need to find them.

The free indexability checker fetches as SearchAnalysisBot/1.0, one crawler identity, so it does not reproduce Google's mobile or desktop crawl. Use it for the signals both crawls share: the status code, redirects, robots.txt, indexing directives, the canonical and the amount of visible text on the page.

A site: search is the quickest index check most people know. You type the operator and a domain or path into Google and read the listings that come back. It needs no account and no verified property, and it works on any domain.

1. Open Google search.
2. Type the operator with your domain, or with a full path for one page.
3. Scan the listings for the page you expect.
4. Repeat for the next page, and the next.

site:example.com
site:example.com/blog/new-post

Use it as a first glance. When a page you expect is missing, the next step is an inspection on a property you own, or a pass through the free indexability checker to look for a noindex, a robots.txt block or a broken status code.

SearchAnalysis.io replaces the repeat step. The Monitor lists every submitted URL with its Search Console status, so you stop re-running the same searches each week to see which pages are still there. Each status comes from URL Inspection on your own property, with a saved history behind it.

The URL Inspection tool in Search Console answers the index question for one URL on a property you have verified. You paste a URL, Google runs an inspection, and you read the result on screen. It is Google's own answer, which is why it beats a site: search for pages you own.

Where It Fits

• A single page you just published and want to confirm.
• A page that dropped out and needs a closer look.
• A spot check on a canonical or a robots.txt result.

Where It Slows You Down

• Every URL is a separate paste and a separate wait.
• The Request Indexing button on the same screen works one URL at a time.
• Keeping a record of past answers is up to you, so a second look next week starts from zero.
• A team managing many sites repeats the steps for every property.

Google opened the same kind of inspection to software when it launched the URL Inspection API on January 31, 2022. That API is what SearchAnalysis.io calls for every URL you submit, within Google's limit of 2,000 inspections a day and 600 a minute per property.

Keep the tool for one-off questions. For a batch of new pages, or a site with thousands of indexed pages to watch, let the index checker run the inspections on its schedule and read the results in the Monitor or through the SearchAnalysis.io API.

The Page indexing report in Search Console shows which pages of a site Google indexed and groups the rest under a reason. It is where you go to see which pages are not indexed by Google across a whole property. These are the reasons Google lists, in Google's wording:

• Server error (5xx); Redirect error; Not found (404); Soft 404
• Blocked due to unauthorized request (401); Blocked due to access forbidden (403); URL blocked due to other 4xx issue
• URL blocked by robots.txt; URL marked 'noindex'
• Crawled, currently not indexed; Discovered, currently not indexed
• Alternate page with proper canonical tag; Duplicate without user-selected canonical; Duplicate, Google chose different canonical than user
• Page with redirect
• Warnings: Indexed, though blocked by robots.txt; Page indexed without content

How It Compares With a Per-URL Check

Use both. The report tells you how many pages share a problem. The index checker tells you when a specific URL changed state. For a reason many site owners meet on new pages, read the guide to Crawled, currently not indexed.

SearchAnalysis.io calls the URL Inspection API for every URL you submit, on your connected Search Console property. This is the index checker this page describes, running without a paste per URL.

The Schedule

Repeated failures back off exponentially from 6 hours, capped at 7 days. Every inspection lands in the URL's check history with its time, state, coverage state and source (inspection, daily check or monitor recheck).

Reading the Results

The Monitor lists every URL with per-channel statuses, filters (All, Indexed, Pending, Failed; by site; by live state), live polling, CSV export and bulk retry. The Google index card per site counts verified indexed pages, with coverage printed with its denominator. Agents use the MCP server:

claude mcp add --transport http searchanalysis https://searchanalysis.io/mcp

The check_url_index_status tool answers for one URL, and the SearchAnalysis.io developer surface documents the rest. The REST API returns the same per-URL, per-channel state at GET /api/v1/submissions/{batchId}, and GET /api/v1/quota reports the engine quota you have left.

The Google Indexing API has a getMetadata call, and at first glance it looks like an index check. It reports the notifications you sent for a URL (URL_UPDATED and URL_DELETED). It does not report whether the URL is in Google's index.

Google documents a narrow scope for the API: “The Indexing API can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.” SearchAnalysis.io reads each page's HTML for that structured data and shows an eligibility badge: Eligible, Best-effort or Unknown.

How SearchAnalysis.io Labels Indexing API Results

• An accepted notification (HTTP 2xx) shows as Processing, “ping accepted”.
• It never shows as Indexed, because the notification does not confirm indexing.
• Up to 100 URLs go in one batch request, inside the 200-a-day project quota.
• URLs over the day's quota wait for the next UTC window and keep their place in line.

Index status comes from the separate Search Console row, which only URL Inspection can turn green. Read how the notification channel works on the Google Indexing API submission page. For pages without that structured data, submission proceeds best-effort, and the index checker still reports what Google decided.