Google index coverage report for crawl, sitemap, and GSC checks.
Use this Google index coverage report to compare a saved crawl, sitemap inventory, and Search Console page data. It finds page groups that deserve URL Inspection without treating a missing Search Console row as proof that Google has not indexed the URL.
Run this report from the CLI, an MCP client, or application code. Every surface uses the same report definition and returns the same evidence. JSON is the source of truth; Markdown makes it readable without hiding dates, limits, warnings, or skipped work.
What this report helps you decide
Which pages deserve URL Inspection because crawl, sitemap, and Search Console evidence do not line up?
- You need an evidence-based sample for an index coverage investigation.
- A current saved crawl and Search Console page data are available for the same site.
Command facts
- Report id
index-coverage- Execution
Local process- Outputs
JSON and Markdown- Example parameters
site, crawlReportId, sitemaps, days, rowLimit- Agent discovery
seo reports describe index-coverage --json- Interactive prompts
Human CLI commands only
When this report is not the right tool
These cases need a different report, more evidence, or a human decision. Do not force this report to answer a question its data cannot support.
- You need Google’s current indexed verdict for a specific URL. Recommended report: Review Google index changes. Run index watch for a limited URL set. It adds direct URL Inspection verdicts and saved-history comparisons instead of inferring index state from crawl, sitemap, or Search Analytics data.
- You need a definitive count of every indexed URL on a large site. No automated report can produce that count from Search Analytics or a quota-limited URL Inspection sample. Use this report to select representative URLs, inspect them directly, and review Search Console indexing reports alongside the site’s intended URL inventory.
Data sources and inputs
- Saved crawl report. Provides the pages fetched locally, their current crawl controls, and explicit crawl scope and completeness.
- XML sitemap inventory when available. Adds pages the site submitted for discovery. A saved crawl can provide declared sitemap document URLs, but it does not contain a complete sitemap inventory by itself.
- Finalized Search Console page rows. Shows which pages appeared with Google Search impressions in the chosen date range, up to the explicit row limit.
What this report checks
- Separates pages found in Search Console, crawlable review candidates, current crawl controls, sitemap-only URLs, and Search Console-only URLs.
- Keeps source completeness, date range, row caps, invalid rows, duplicate rows, and omitted detail beside the result.
- Groups repeated URL templates for representative sampling only. It does not label them as poor quality or index bloat.
How it works
- Normalizes URLs across the available sources, keeps crawl controls separate, and groups crawlable pages missing from the returned Search Console data for review.
- Groups repeated URL templates to help choose representative checks without diagnosing the template or its index state.
The JSON result keeps dates, thresholds, limits, skipped work, and source completeness beside the finding. Missing, partial, capped, filtered, and complete data remain different states.
Run the report from the CLI
Choose representative pages for URL Inspection from crawl, sitemap, and Search Console evidence. Agents and CI should inspect the live schema before their first run.
Run it from the CLI
seo index-coverage --project exampleCheck the agent input schema
seo reports describe index-coverage --jsonRun it from an agent or script
seo reports run index-coverage --params '{"site":"sc-domain:example.com","crawlReportId":"crawl_saved","sitemaps":["https://example.com/sitemap.xml"],"days":90,"rowLimit":100000}' --jsonProject profiles can fill supported property and analytics inputs for the human-facing commands. The catalog form shown here is explicit by design, so agents and CI jobs do not prompt or guess.
How an MCP agent should use it
Call seo_describe_report first so the agent sees when this report is useful and gets the current input schema. Then callseo_run_report with the validated parameters. Read the status, warnings, source limits, and skipped sections before acting on a finding.
Describe the report with MCP
{
"id": "index-coverage"
}Run the report with MCP
{
"id": "index-coverage",
"params": {
"site": "sc-domain:example.com",
"crawlReportId": "crawl_saved",
"sitemaps": [
"https://example.com/sitemap.xml"
],
"days": 90,
"rowLimit": 100000
}
}Use a follow-up report returned by the result instead of guessing the next tool. The local MCP server and CLI use the same report definition and evidence. Their outer transport envelopes differ.
Use the report in a TypeScript app
Install seo as a project dependency, then call the same report catalog used by the CLI and MCP. executeReportrejects an unknown report id or invalid parameters. Provider and runtime failures come back as structured results withisError set.
Install the library
npm install seoRun this report from TypeScript
import { executeReport } from 'seo/mcp'
const result = await executeReport(
'index-coverage',
{
"site": "sc-domain:example.com",
"crawlReportId": "crawl_saved",
"sitemaps": [
"https://example.com/sitemap.xml"
],
"days": 90,
"rowLimit": 100000
},
)
console.log(result)The TypeScript library guide also covers direct core functions, schema discovery, and the difference betweenexecuteReport and runReport.
What comes back and how to read it
- Exact cross-source counts plus limited URL lists for each evidence group.
- A representative review queue, template samples, source details, and caveats that explain what missing Search Console rows cannot prove.
- Start with source completeness. A crawlable page missing from returned Search Console rows is a review candidate, not proof that the page is unindexed.
Start with dataStatus, source details, warnings, and caveats. Then inspect the observed evidence before derived findings or suggested actions.
What this report cannot tell you
- Search Analytics is not an index inventory. Missing rows can mean no impressions in the returned data, a row cap, privacy filtering, or a URL that needs direct inspection.
- Saved crawl reports do not retain a full sitemap inventory. The report can fetch sitemap documents declared in captured robots.txt evidence, or use sitemap URLs supplied explicitly.
What to do next
- Choose representative URLs from important page types and template groups.
- Run URL Inspection for that limited sample and keep provider failures separate from page findings.
Related reports
- Review Google index changes. Inspect a limited URL set and separate current index issues, regressions, recoveries, and operational failures.
- Collect Google index snapshots. Inspect a quota-limited sitemap sample and save Google indexed-state snapshots for later comparison.
- Plan Google index monitoring. Turn sitemap URLs, Search Console properties, and daily URL Inspection limits into a realistic monitoring cycle.
Sources behind the guidance
These primary sources define the provider data or search controls used in the interpretation above.
- Search Console Search Analytics API guidance
- Google sitemap guidance
- Search Console URL Inspection API reference
Browse all reports in Technical monitoring.