Second page SEO report for queries close to page one.

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 visible pages just beyond the first results page deserve investigation?

• You need a compact page-oriented opportunity set.
• You can verify query intent and page quality before edits.

Command facts

Report id

second-page

Execution

Local process

Outputs

JSON and Markdown

Example parameters

site, range, minImpressions, limit, includeBrand, verifyContent, verifyLimit

Agent discovery

seo reports describe second-page --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 want repeated query and URL patterns grouped into shared actions rather than a flat page list. Recommended report: Find striking-distance opportunities. Run striking distance. It keeps query and page pairs together, groups repeated patterns, and separates content, snippet, internal-link, and technical investigations across the selected rows.
• You need to know whether a specific page should be rewritten. Recommended report: Audit one page. Audit that page first. It adds a fresh fetch, technical controls, metadata, headings, schema, links, and available Search Console query evidence. The second-page position filter alone cannot justify a rewrite.

Data sources and inputs

• Returned Search Console page and query rows. Provides impressions, clicks, CTR, and average position for the selected finalised window.
• Optional live-page verification. Checks a limited number of candidate pages before returning investigation prompts.

What this report checks

• Finds primary query and page combinations in the documented position range.
• Compares impressions, clicks, CTR, average position, and supporting queries for each URL.
• Ranks URLs consistently and keeps failed or skipped page verification visible.

How it works

• Filters the documented average-position range, applies evidence thresholds, ranks consistently, and bounds fetched verification.

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

Find visible pages averaging positions above 10 through 20. Agents and CI should inspect the live schema before their first run.

seo second-page --project example

seo reports describe second-page --json

seo reports run second-page --params '{"site":"sc-domain:example.com","range":28,"minImpressions":50,"limit":10,"includeBrand":false,"verifyContent":true,"verifyLimit":5}' --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": "second-page"
}

{
  "id": "second-page",
  "params": {
    "site": "sc-domain:example.com",
    "range": 28,
    "minImpressions": 50,
    "limit": 10,
    "includeBrand": false,
    "verifyContent": true,
    "verifyLimit": 5
  }
}

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(
  'second-page',
  {
  "site": "sc-domain:example.com",
  "range": 28,
  "minImpressions": 50,
  "limit": 10,
  "includeBrand": false,
  "verifyContent": true,
  "verifyLimit": 5
},
)

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 page-oriented opportunity list with the supporting queries, metrics, position range, and source status.
• Evidence-grounded prompts for SERP, intent, content, internal-link, and technical review, with no ranking forecast.
• Treat the result as a queue for SERP, intent, content, link, and technical review. Average position is not a fixed rank.

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 appearances vary by query, device, location, and feature. Returned rows can be capped or incomplete.

What to do next

1. Audit the best-supported page.
2. Use internal links or content optimization only when the evidence points there.

Related reports

• Audit one page. Inspect one live URL before changing its metadata, canonical, directives, structured data, links, or content.
• Build a content optimization brief. Create a focused brief for one existing page from its own search queries and the content observed on the live URL.
• Find internal link candidates. Find fetched pages with relevant search evidence that do not currently contain a verified contextual link to a chosen target.

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

Browse all reports in Reporting.