SEO Skill

llms.txt audit for agent-readable site guidance.

Use this llms.txt audit after choosing to publish the optional file. It checks the fetch status, structure, linked pages, and crawl-backed coverage without treating llms.txt as a Google requirement or a shortcut to AI visibility.

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

Is an llms.txt file present, fetchable, and consistent with useful crawl evidence?

  • A publisher has chosen to maintain llms.txt or wants to assess the optional format.
  • You need candidate pages for a draft.

Command facts

Report id
llms-txt-audit
Execution
Local process
Outputs
JSON and Markdown
Example parameters
reportId
Agent discovery
seo reports describe llms-txt-audit --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 check the site’s wider crawl, indexability, snippet, and page-structure controls for AI search. Recommended report: Check AI search technical readiness. Run AI readiness on the crawl. It checks the controls and page evidence that apply beyond the optional llms.txt file, while still avoiding unsupported visibility or citation predictions.
  • You need to know whether llms.txt improved AI citations, rankings, or visibility. No automated report can attribute those outcomes to llms.txt. Keep a dated record of the change, review referral and visibility evidence over time, and treat any movement as observational rather than proof that the file caused it.

Data sources and inputs

  • Saved or fresh crawl report. Provides the observed llms.txt response and candidate source pages.
  • Current Google AI feature guidance. Keeps optional file observations separate from Google crawl and indexing requirements.

What this report checks

  • Checks whether llms.txt was found, fetched successfully, parsed, and linked to usable destinations.
  • Compares listed pages with limited crawl candidates while keeping normal crawl and indexing controls separate.

How it works

  • Checks the optional file independently from normal crawl and indexing controls.

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 an optional llms.txt file and its linked pages. Agents and CI should inspect the live schema before their first run.

Run it from the CLI

seo llms audit --project example

Check the agent input schema

seo reports describe llms-txt-audit --json

Run it from an agent or script

seo reports run llms-txt-audit --params '{"reportId":"crawl_example_20260710"}' --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.

Describe the report with MCP

{
  "id": "llms-txt-audit"
}

Run the report with MCP

{
  "id": "llms-txt-audit",
  "params": {
    "reportId": "crawl_example_20260710"
  }
}

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 seo

Run this report from TypeScript

import { executeReport } from 'seo/mcp'

const result = await executeReport(
  'llms-txt-audit',
  {
  "reportId": "crawl_example_20260710"
},
)

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

  • The observed file status, parsed entries, broken or questionable destinations, and candidate pages.
  • Clear caveats explaining that presence or absence does not predict crawling, citations, rankings, or AI visibility.
  • Fix broken or misleading content if you intentionally publish the file. Leave it absent if it adds no maintained value.

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

  • Presence does not prove that any crawler reads the file or that an AI product will use its links.

What to do next

  1. Generate a draft only if someone will own it.
  2. Keep normal crawl, index, and snippet controls correct.
  • Create an llms.txt draft. Build a concise llms.txt draft from selected crawl evidence when someone has decided to maintain the optional file.
  • Check AI search technical readiness. Review crawl access, indexability, snippet controls, page structure, and optional agent resources without inventing an AI visibility score.
  • Check Google AI search controls. Find crawl, indexability, and snippet controls that can block Google AI search eligibility on selected pages.

Sources behind the guidance

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

Browse all reports in Crawling and technical checks.