Check a list of URLs without crawling the whole site

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

What technical evidence and repeated issues appear across these chosen URLs?

• A release, template, migration batch, or priority list needs a limited audit.
• The exact URL set matters more than site discovery.

Command facts

Report id

audit-urls

Execution

Local process

Outputs

JSON and Markdown

Example parameters

urls, includeIssues, saveReport

Agent discovery

seo reports describe audit-urls --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 know which URLs are affected and need the crawler to discover pages from links and sitemaps. Recommended report: Crawl a site for technical SEO issues. Run a site crawl. It discovers an explicitly limited same-origin page set before applying the technical checks. A selected-URL audit never widens the supplied list.
• You already saved two crawl reports and need to compare new, resolved, and changed findings. Recommended report: Compare two saved crawls. Compare the saved crawls. It checks whether both scopes are comparable and then reports page, issue, score, and summary movement between the two snapshots.

Data sources and inputs

• Explicit URL list. Defines the exact pages to fetch and the maximum scope of the audit.
• Optional Search Console and GA4 project context. Adds available first-party page value without widening the URL list.

What this report checks

• Fetches only the supplied URLs and runs the maintained technical SEO rules on each successful response.
• Keeps failed, redirected, skipped, partial, and capped pages distinct and never starts a discovery crawl.

How it works

• Fetches the explicit list within configured bounds, runs the shared crawl rules, and records failures separately from page findings.

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

Audit an explicit URL list without crawling the rest of the site. Agents and CI should inspect the live schema before their first run.

seo crawl --mode list --urls https://example.com/a,https://example.com/b

seo reports describe audit-urls --json

seo reports run audit-urls --params '{"urls":["https://example.com/","https://example.com/pricing"],"includeIssues":true,"saveReport":true}' --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": "audit-urls"
}

{
  "id": "audit-urls",
  "params": {
    "urls": [
      "https://example.com/",
      "https://example.com/pricing"
    ],
    "includeIssues": true,
    "saveReport": true
  }
}

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(
  'audit-urls',
  {
  "urls": [
    "https://example.com/",
    "https://example.com/pricing"
  ],
  "includeIssues": true,
  "saveReport": true
},
)

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

• A compact summary with page status, grouped technical findings, top fixes, warnings, and caveats.
• Optional limited page and issue inventories plus a saved report id when storage is requested.
• Separate fetch failures from valid-page findings. Look for repeated evidence across the chosen template without claiming sitewide coverage.

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

• The report says nothing about URLs outside the supplied list. Client-rendered content may require JavaScript mode.

What to do next

1. Inspect affected URLs for a repeated rule.
2. Save and compare the report after the release is fixed.

Related reports

• Find URLs affected by a crawl issue. Open the exact URLs behind a crawl finding and turn a summary count into a limited review or fix list.
• Compare two saved crawls. See which pages and technical issues appeared, disappeared, or changed between two saved crawl snapshots.
• Audit one page. Inspect one live URL before changing its metadata, canonical, directives, structured data, links, or content.

Sources behind the guidance

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

• Google JavaScript SEO guidance
• Google canonical URL guidance
• Google structured data guidance

Browse all reports in Crawling and technical checks.