URL inspection planning before spending Google quota.

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

How should these URLs be allocated across properties and daily URL Inspection capacity?

• A large site needs limited, repeatable index monitoring.
• You need to see whether extra URL-prefix properties would improve ownership coverage.

Command facts

Report id

index-coverage-plan

Execution

Local process

Outputs

JSON and Markdown

Example parameters

site, sitemaps, dailyLimit, targetCycleDays, maxUrls

Agent discovery

seo reports describe index-coverage-plan --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 to collect Google index verdicts now rather than plan future coverage. Recommended report: Collect Google index snapshots. Run index monitor after checking the proposed sample and quota. It spends the configured URL Inspection capacity, stores exact provider results locally, and keeps deferred and failed requests separate.
• You need to decide whether every sitemap URL deserves indexing. No automated report can infer page intent or business value from a sitemap. Review the intended page types and canonical strategy with the people who own the site, then use this plan to create a representative inspection cycle.

Data sources and inputs

• XML sitemap inventories. Provide the limited URL population that needs an inspection plan.
• Available Search Console properties and quota. Define ownership coverage, daily capacity, and the target monitoring cycle.

What this report checks

• Assigns eligible sitemap URLs to the most specific available Search Console property.
• Calculates cycle capacity and suggests URL-prefix properties where meaningful folders lack practical coverage.

How it works

• Deduplicates discovered URLs, assigns eligible properties, estimates a monitoring cycle, and keeps unassigned URLs visible.

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

Plan an inspection cycle without spending URL Inspection quota. Agents and CI should inspect the live schema before their first run.

seo index-watch --site sc-domain:example.com --sitemaps https://example.com/sitemap.xml --plan

seo reports describe index-coverage-plan --json

seo reports run index-coverage-plan --params '{"site":"sc-domain:example.com","sitemaps":["https://example.com/sitemap.xml"],"dailyLimit":200,"targetCycleDays":7,"maxUrls":50000}' --json

Project 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.

{
  "id": "index-coverage-plan"
}

{
  "id": "index-coverage-plan",
  "params": {
    "site": "sc-domain:example.com",
    "sitemaps": [
      "https://example.com/sitemap.xml"
    ],
    "dailyLimit": 200,
    "targetCycleDays": 7,
    "maxUrls": 50000
  }
}

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.

npm install seo

import { executeReport } from 'seo/mcp'

const result = await executeReport(
  'index-coverage-plan',
  {
  "site": "sc-domain:example.com",
  "sitemaps": [
    "https://example.com/sitemap.xml"
  ],
  "dailyLimit": 200,
  "targetCycleDays": 7,
  "maxUrls": 50000
},
)

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

• URL inventory counts, property allocations, daily capacity, target cycle, and uncovered or unassigned URLs.
• Suggested URL-prefix properties and representative paths, with no URL Inspection quota spent.
• Use the cycle estimate to choose a representative inventory and sustainable quota. Unassigned URLs need property-access review.

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

• A sitemap is a discovery hint, not proof that every listed URL is indexed or should be indexed.

What to do next

1. Run index monitor with a limited daily sample.
2. Add appropriate URL-prefix property access if important URLs cannot be inspected.

Related reports

• Collect Google index snapshots. Inspect a quota-limited sitemap sample and save Google indexed-state snapshots for later comparison.
• Review Google index changes. Inspect a limited URL set and separate current index issues, regressions, recoveries, and operational failures.

Sources behind the guidance

These primary sources define the provider data or search controls used in the interpretation above.

• Google sitemap guidance
• Search Console URL Inspection API reference

Browse all reports in Technical monitoring.