Quota-aware URL inspection monitoring for Google index status changes.

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 monitored URLs changed indexed state or need verification?

• You have important URLs or stored inspection history to compare.
• You need operational failures separated from SEO findings.

Command facts

Report id

index-watch

Execution

Local process

Outputs

JSON and Markdown

Example parameters

site, urls, dailyLimit

Agent discovery

seo reports describe index-watch --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 do not yet know which URLs deserve direct inspection. Recommended report: Index coverage signals. Run index coverage first. It compares crawl, sitemap, and returned Search Console evidence to build a limited review sample without spending URL Inspection quota on every discovered URL.
• You need to decide whether a noindex, canonical, or exclusion is intentional. No automated report can recover the site owner’s intent. Compare the page purpose with the canonical and index strategy, then use this report’s exact Google verdict and history to check whether the observed state contradicts that decision.

Data sources and inputs

• Explicit URL sample. Defines the exact limited pages whose Google index state should be checked.
• Google URL Inspection evidence. Provides the current indexed verdict, coverage state, canonical, crawl details, and provider status.
• Previous local index snapshots. Provide the baseline used to classify regressions and recoveries.

What this report checks

• Inspects only the selected URLs within quota and compares successful results with compatible saved snapshots.
• Separates current review states, regressions, recoveries, unchanged results, quota blocks, invalid inputs, and provider failures.

How it works

• Compares exact supported state fields per URL and classifies current issues, regressions, recoveries, unchanged results, and failures.

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

Check selected URLs against earlier Google index snapshots. Agents and CI should inspect the live schema before their first run.

seo index-watch --site sc-domain:example.com --urls https://example.com/page

seo reports describe index-watch --json

seo reports run index-watch --params '{"site":"sc-domain:example.com","urls":["https://example.com/a","https://example.com/b"],"dailyLimit":25}' --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-watch"
}

{
  "id": "index-watch",
  "params": {
    "site": "sc-domain:example.com",
    "urls": [
      "https://example.com/a",
      "https://example.com/b"
    ],
    "dailyLimit": 25
  }
}

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-watch',
  {
  "site": "sc-domain:example.com",
  "urls": [
    "https://example.com/a",
    "https://example.com/b"
  ],
  "dailyLimit": 25
},
)

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

• Per-URL Google indexed-state evidence with current classification and previous snapshot comparison.
• Summary counts, operational failures, retry guidance, source limits, and caveats for intentional directives and incomplete samples.
• Verify regressions against page intent and live technical controls. A recovery describes the inspected snapshot, not guaranteed search visibility.

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

• Uninspected and failed URLs remain unknown. The indexed snapshot can lag a live deployment.

What to do next

1. Audit a regressed URL directly.
2. Run redirect trace when the inspected canonical or destination is unexpected.

Related reports

• Collect Google index snapshots. Inspect a quota-limited sitemap sample and save Google indexed-state snapshots for later comparison.
• Audit one page. Inspect one live URL before changing its metadata, canonical, directives, structured data, links, or content.
• Trace a redirect chain. Follow every hop from one URL to its final page and catch loops, long chains, broken destinations, or conflicting index signals.

Sources behind the guidance

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

• Search Console URL Inspection API reference

Browse all reports in Technical monitoring.