# AI Website Check — assessment criteria

Research date: 2026-11-07 · Version: 0.2.0-proposed · Status: proposed, not implemented.

38 distinct criteria: 12 Basic and 26 additional Pro criteria. Pro/Business include all applicable Basic criteria across the agreed page scope.

## Interpretation

- Outcomes: pass, issue, review, not_tested, not_applicable. Unknown is never silently a pass or a failure.
- Importance is a product judgment for the chosen task: Blocker prevents it in the tested environment; High affects its main purpose; Medium helps robustness/clarity; Informational records an option. This is not a revenue forecast.
- Established means a documented mechanism supports measurement, not that a universal AI ranking factor has been proven. Heuristic needs interpretation/calibration. Optional is not required for ordinary business websites.
- Phase 1: bounded HTTP/HTML and evidence candidates. Phase 2: semantic and cross-page comparison. Phase 3: isolated browser and optional protocol inspection. Tier and implementation phase are separate.
- Basic checks a homepage; Pro is proposed for up to 5 chosen pages; Business for up to 50 selected pages plus deeper review. These are one-time assessments, not subscriptions.
- Preserve training opt-outs. A scanner response is not proof of genuine provider access. Absence of sitemap, structured data, llms.txt, MCP, or WebMCP is not automatically a failure.
- Each finding must include URL, timestamp, observed evidence, rule version and scope. No universal score, indexing/citation guarantee, security certification or automatic legal/compliance verdict.
- Source documents explain underlying concepts; importance, algorithms and packaging below are our proposed design, not endorsement by those sources.

- A01–A03 are paid capability-discovery checks for contact, demo, meeting and quote actions: read Discovery, Schema and State only. They reuse P03–P05 evidence without double-counting. Never call business tools, fill forms or create test bookings. API documentation, ordinary UI and observed registered tools are distinct.

## Catalog

| ID | Check | Category | Tier | Importance | Evidence | Phase |
|---|---|---|---|---|---|---|
| T01 | Fetch succeeds | Access & discovery | Basic | Blocker | Established | 1 |
| T02 | Crawler preferences | Access & discovery | Basic | High | Established | 1 |
| T03 | Challenge or access wall | Access & discovery | Basic | Blocker | Established | 1 |
| T04 | Indexing directive | Access & discovery | Basic | High | Established | 1 |
| T05 | Search preview limits | Access & discovery | Pro | High | Established | 1 |
| T06 | Sitemap discovery | Access & discovery | Basic | Medium | Established | 1 |
| T07 | Crawlable links | Access & discovery | Basic | High | Established | 1 |
| T08 | Canonical address | Access & discovery | Pro | Medium | Established | 1 |
| T09 | Content in initial HTML | Readable content | Basic | High | Established | 1 |
| T10 | Rendered content difference | Readable content | Pro | High | Heuristic | 3 |
| T11 | Page title | Readable content | Basic | Medium | Heuristic | 1 |
| T12 | Main content structure | Readable content | Pro | Medium | Heuristic | 1 |
| T13 | Page language | Readable content | Basic | Medium | Established | 1 |
| T14 | Structured data syntax | Readable content | Basic | Medium | Established | 1 |
| T15 | Structured data agreement | Readable content | Pro | High | Heuristic | 2 |
| T16 | Control names and states | Agent interaction | Pro | High | Established | 3 |
| T17 | Form labels | Agent interaction | Pro | High | Established | 3 |
| T18 | Keyboard navigation | Agent interaction | Pro | High | Heuristic | 3 |
| T19 | Obstructed controls | Agent interaction | Pro | High | Heuristic | 3 |
| T20 | Key link destination | Agent interaction | Pro | High | Established | 1 |
| B01 | Business identity | Business clarity | Basic | High | Heuristic | 1 |
| B02 | Offers and intended audience | Business clarity | Basic | High | Heuristic | 1 |
| B03 | Service area or remote scope | Business clarity | Pro | Medium | Heuristic | 2 |
| B04 | Contact facts discoverable | Business clarity | Pro | High | Heuristic | 2 |
| B05 | Price or quote policy | Business clarity | Pro | Medium | Heuristic | 2 |
| B06 | Opening hours | Business clarity | Pro | Medium | Heuristic | 2 |
| B07 | Attributable expertise claims | Business clarity | Pro | Medium | Heuristic | 2 |
| B08 | Cross-page fact consistency | Business clarity | Pro | High | Heuristic | 2 |
| B09 | Freshness evidence | Business clarity | Pro | Medium | Heuristic | 2 |
| B10 | Service terms | Business clarity | Pro | Medium | Heuristic | 2 |
| P01 | llms.txt discovery | Optional interfaces | Pro | Informational | Optional | 3 |
| P02 | Markdown alternate and parity | Optional interfaces | Pro | Informational | Optional | 3 |
| P03 | OpenAPI documentation | Optional interfaces | Pro | Informational | Optional | 3 |
| P04 | Advertised MCP endpoint | Optional interfaces | Pro | Informational | Optional | 3 |
| P05 | WebMCP declarations | Optional interfaces | Pro | Informational | Optional | 3 |
| A01 | Contact and booking tool discovery | Action capabilities | Pro | High | Heuristic | 3 |
| A02 | Action input and output declarations | Action capabilities | Pro | High | Established | 3 |
| A03 | Exposed action state and prerequisites | Action capabilities | Pro | Medium | Heuristic | 3 |

## How each check would work

### T01 — Fetch succeeds

Can the selected page be fetched successfully?

**Basic · Blocker · Established · Phase 1 · Relative implementation effort S**

**Why:** Content must arrive before it can be assessed.

**Method:** Bounded GET, DNS/TLS and redirect checks; distinguish empty/error bodies from 2xx.

**Implementation:** Retry a transient error once; store terminal URL, status, type, size and time.

**Evidence:** Redirect chain, terminal response metadata and bounded body excerpt.

**Limits:** Timeouts, rate limits and scanner network differences are review/not-tested, not universal bot bans.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/crawling/docs/troubleshooting/http-status-codes)

### T02 — Crawler preferences

Do declared crawler preferences match the owner’s discovery goals?

**Basic · High · Established · Phase 1 · Relative implementation effort M**

**Why:** Robots rules can restrict discovery crawlers.

**Method:** Parse robots.txt directives for relevant search crawlers and scanner.

**Implementation:** Show winning rule and separately label search, training and user-triggered fetch policies.

**Evidence:** robots.txt response, parser result, matched directive and path.

**Limits:** Missing file is not failure; no need to enable training; crawler policies vary by service.

**Primary sources:**

- [Source 1: www.rfc-editor.org](https://www.rfc-editor.org/rfc/rfc9309.html)
- [Source 2: developers.openai.com](https://developers.openai.com/api/docs/bots)
- [Source 3: docs.perplexity.ai](https://docs.perplexity.ai/docs/resources/perplexity-crawlers)
- [Source 4: support.claude.com](https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler)

### T03 — Challenge or access wall

Did the scan encounter a challenge or access wall?

**Basic · Blocker · Established · Phase 1 · Relative implementation effort M**

**Why:** A wall can prevent the tested fetch.

**Method:** Detect confirmed challenge markers and login/consent walls; review generic 403s.

**Implementation:** Capture status and redacted challenge evidence; never bypass.

**Evidence:** Status, challenge marker/header, redacted snippet.

**Limits:** Generic 403 does not establish cause or other agents’ access.

**Primary sources:**

- [Source 1: developers.cloudflare.com](https://developers.cloudflare.com/cloudflare-challenges/challenge-types/challenge-pages/detect-response/)

### T04 — Indexing directive

Is a public-intent page marked not to be indexed?

**Basic · High · Established · Phase 1 · Relative implementation effort S**

**Why:** An explicit noindex can conflict with a stated public discovery goal.

**Method:** Read robots meta and X-Robots-Tag directives.

**Implementation:** Report exact directive and ask applicability for private pages.

**Evidence:** Tag/header, scope, affected URL.

**Limits:** Does not reveal actual index membership; private pages can appropriately be excluded.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/crawling-indexing/block-indexing)

### T05 — Search preview limits

Do preview restrictions limit this page’s eligibility for Google AI search features?

**Pro · High · Established · Phase 1 · Relative implementation effort S**

**Why:** These Google controls can limit snippets/previews.

**Method:** Inspect nosnippet, max-snippet and data-nosnippet.

**Implementation:** Report Google-specific scope and affected text.

**Evidence:** Directive, value and DOM location.

**Limits:** No universal bad threshold; owner choice; not an AI-wide rule.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag)
- [Source 2: developers.google.com](https://developers.google.com/search/docs/appearance/ai-features)

### T06 — Sitemap discovery

Can key pages be discovered through a valid sitemap?

**Basic · Medium · Established · Phase 1 · Relative implementation effort M**

**Why:** Sitemap provides discovery hints.

**Method:** Discover and parse linked sitemap; compare selected pages in Pro.

**Implementation:** Bound parsing and URL scope; sample key URLs.

**Evidence:** Sitemap URL, parse status, selected-page membership.

**Limits:** Small well-linked sites may not need one; sitemap is not a guarantee.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview)

### T07 — Crawlable links

Are important destinations available as actual links?

**Basic · High · Established · Phase 1 · Relative implementation effort S**

**Why:** Links expose navigation destinations to crawlers and agents.

**Method:** Inspect anchor hrefs and resolve selected same-site destinations.

**Implementation:** Compare selected destinations with anchors; inspect rendered page in Pro.

**Evidence:** Anchor text/href and response.

**Limits:** Actions can be buttons; bounded scan cannot prove a page is orphaned.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/crawling-indexing/links-crawlable)

### T08 — Canonical address

Does the page point to a consistent canonical address?

**Pro · Medium · Established · Phase 1 · Relative implementation effort M**

**Why:** Canonical hints can consolidate duplicate URLs.

**Method:** Read HTML and HTTP Link canonical declarations; check conflicts.

**Implementation:** Resolve declared target within scope; report duplicates or unreachable target.

**Evidence:** Canonical declaration, target status and final URL.

**Limits:** Missing self-canonical is not automatically an issue; canonical is a hint.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/crawling-indexing/canonicalization)

### T09 — Content in initial HTML

Is important content present in the initial HTML?

**Basic · High · Established · Phase 1 · Relative implementation effort M**

**Why:** Fetch-only readers may use the initial response.

**Method:** Extract main-body text separately from scripts and boilerplate.

**Implementation:** Identify empty app-shell pages and show extracted excerpt.

**Evidence:** Initial HTML text and selected factual phrases.

**Limits:** No word count proves quality; browser agents may render content.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/appearance/ai-features)
- [Source 2: developers.google.com](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)

### T10 — Rendered content difference

Does rendering reveal key content missing from the initial response?

**Pro · High · Heuristic · Phase 3 · Relative implementation effort L**

**Why:** Some sites load key facts after JavaScript execution.

**Method:** Compare raw response and isolated browser-rendered text/links.

**Implementation:** Record raw/rendered evidence and bounded wait budget.

**Evidence:** Two extracts, browser environment and difference.

**Limits:** Differences are diagnostic; consent, location, network and defenses affect result.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)

### T11 — Page title

Does each selected page have a useful, distinguishing title?

**Basic · Medium · Heuristic · Phase 1 · Relative implementation effort S**

**Why:** Titles orient readers and help identify pages.

**Method:** Detect empty and exact duplicate title elements.

**Implementation:** Show title with page URL and invite wording review.

**Evidence:** Title element and duplicate locations.

**Limits:** Do not apply arbitrary length score; usefulness needs context.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/appearance/title-link)

### T12 — Main content structure

Does the document expose main content and meaningful section headings?

**Pro · Medium · Heuristic · Phase 1 · Relative implementation effort M**

**Why:** Structure helps readers and agents understand page organization.

**Method:** Inspect main landmarks and headings; review accessibility tree in Pro.

**Implementation:** Phase 1 inventories raw-HTML headings and landmarks. Meaningfulness needs review; a rendered accessibility-tree extension arrives in phase 3.

**Evidence:** Landmark roles, heading outline and selectors.

**Limits:** One H1 or a rigid heading count is not universal conformance.

**Primary sources:**

- [Source 1: www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/headings-and-labels.html)
- [Source 2: web.dev](https://web.dev/articles/ai-agent-site-ux)

### T13 — Page language

Is the primary language declared?

**Basic · Medium · Established · Phase 1 · Relative implementation effort S**

**Why:** Declared language supports assistive technology and language handling.

**Method:** Validate non-empty recognized html lang value.

**Implementation:** In Pro compare with dominant text; flag strong mismatches for review.

**Evidence:** lang value and detected language estimate.

**Limits:** Multilingual and code-heavy pages complicate inference.

**Primary sources:**

- [Source 1: www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html)

### T14 — Structured data syntax

Is existing structured data syntactically usable?

**Basic · Medium · Established · Phase 1 · Relative implementation effort M**

**Why:** Structured data can express page facts in machine-readable form.

**Method:** Parse JSON-LD syntax in v1; inventory Microdata and RDFa separately.

**Implementation:** Pin parser/schema profile and report syntax separately from semantics. Implement JSON-LD first; explicitly mark unimplemented Microdata/RDFa validation as not tested until those adapters ship.

**Evidence:** Format, parsed blocks and exact errors.

**Limits:** Absence is not failure; syntax does not mean correct or eligible for rich results.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)

### T15 — Structured data agreement

Does structured information agree with visible facts?

**Pro · High · Heuristic · Phase 2 · Relative implementation effort L**

**Why:** Material disagreement can confuse readers and parsers.

**Method:** Compare overlapping identity, offer, price, location, availability and URL facts.

**Implementation:** Normalize deterministically first; cite both values; use human review for ambiguity.

**Evidence:** Markup value and visible text spans.

**Limits:** Dynamic, regional or dated values can differ legitimately; missing markup is not conflict.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)

### T16 — Control names and states

Can an agent identify the purpose and state of important controls?

**Pro · High · Established · Phase 3 · Relative implementation effort M**

**Why:** Semantic controls expose intent and current state.

**Method:** Inspect accessible name, role and state for selected controls.

**Implementation:** Inspect browser accessibility snapshot; flag empty/contradictory names.

**Evidence:** Role, accessible name, state and selector.

**Limits:** Not a complete accessibility audit; icon-only controls may be properly named.

**Primary sources:**

- [Source 1: www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html)
- [Source 2: web.dev](https://web.dev/articles/ai-agent-site-ux)

### T17 — Form labels

Do forms expose labels, required fields and instructions?

**Pro · High · Established · Phase 3 · Relative implementation effort M**

**Why:** Clear labels help users and agents complete a contact task.

**Method:** Inspect associated labels, accessible names and instructions.

**Implementation:** No real submission; record associations and required indications.

**Evidence:** Control names, label associations and instruction snippets.

**Limits:** Cannot verify delivery without a sandbox; placeholders alone are weak.

**Primary sources:**

- [Source 1: www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions)
- [Source 2: www.w3.org](https://www.w3.org/WAI/tutorials/forms/labels/)

### T18 — Keyboard navigation

Can selected navigation be operated with keyboard in a sensible order?

**Pro · High · Heuristic · Phase 3 · Relative implementation effort L**

**Why:** Keyboard operation is a useful signal for operable journeys.

**Method:** Tab through scoped controls; record focus order, visible focus and traps.

**Implementation:** Use bounded read-only browser path.

**Evidence:** Focus sequence and screenshots/selectors.

**Limits:** Order differences are not inherently wrong; scoped check is not WCAG certification.

**Primary sources:**

- [Source 1: www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html)
- [Source 2: www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html)

### T19 — Obstructed controls

Do overlays or unstable controls obstruct selected interaction?

**Pro · High · Heuristic · Phase 3 · Relative implementation effort L**

**Why:** Obscured or shifting controls can block a tested action.

**Method:** Compare snapshots and hit-testing on selected task controls.

**Implementation:** Observe modal/overlay and target movement without bypassing consent/auth.

**Evidence:** Visibility/hit test and time-separated location.

**Limits:** Modal is not inherently bad; limited experimental heuristic.

**Primary sources:**

- [Source 1: web.dev](https://web.dev/articles/ai-agent-site-ux)

### T20 — Key link destination

Do important links reach the promised next step?

**Pro · High · Established · Phase 1 · Relative implementation effort M**

**Why:** Broken primary routes block a basic decision journey.

**Method:** Resolve selected service/contact/pricing links; follow read-only route in Pro.

**Implementation:** Bound HTTP checks; stop at write/submit boundary.

**Evidence:** Link name, destination status and journey steps.

**Limits:** A contact page does not prove lead delivery or transaction success.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/crawling-indexing/links-crawlable)

### B01 — Business identity

Is the business name stated clearly?

**Basic · High · Heuristic · Phase 1 · Relative implementation effort S**

**Why:** Clear identity lets readers associate the site and its claims.

**Method:** Find visible organization/business name in header, main content or footer; record variants.

**Implementation:** In Basic, extract visible candidate names from headings, title and site identity markup without an LLM. Keep original snippets and return review when candidates are ambiguous; semantic confirmation is phase 2.

**Evidence:** Candidate name, snippet, URL, markup candidate.

**Limits:** Stylized brands and legal entities can differ; candidate extraction may need review.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/appearance/structured-data/organization)

### B02 — Offers and intended audience

Can a reader tell what the business offers and whom it serves?

**Basic · High · Heuristic · Phase 1 · Relative implementation effort M**

**Why:** Specific offers and audience help people understand fit.

**Method:** Extract named service/product offers and audience evidence from visible copy.

**Implementation:** In Basic, show candidate offer/audience statements from main text and headings without a model verdict. Return review for ambiguous wording. Phase 2 can add structured model extraction with verified source spans.

**Evidence:** Service names, descriptions and audience phrases with source URLs.

**Limits:** Scanner cannot judge quality or verify real-world offer; indicate uncertainty.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/fundamentals/creating-helpful-content)
- [Source 2: schema.org](https://schema.org/Service)

### B03 — Service area or remote scope

Is the service area or remote availability stated where applicable?

**Pro · Medium · Heuristic · Phase 2 · Relative implementation effort M**

**Why:** People need to know whether the service is available to them.

**Method:** Find geographic scope or remote/onsite wording.

**Implementation:** Extract locations and scope phrases; compare Service.areaServed if present.

**Evidence:** Visible wording and optional markup value.

**Limits:** Not applicable to every business; never penalize omission by default.

**Primary sources:**

- [Source 1: schema.org](https://schema.org/Service)

### B04 — Contact facts discoverable

Are useful contact facts present in the assessed pages?

**Pro · High · Heuristic · Phase 2 · Relative implementation effort S**

**Why:** A person needs a way to ask questions or take the next step.

**Method:** Detect visible phone, email, address or contact route as fact candidates.

**Implementation:** Report available channels and where found; do not test delivery here.

**Evidence:** Visible contact value/snippet and URL.

**Limits:** Form usability and broken link behavior are covered by T17/T20; facts may be intentionally omitted.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/appearance/structured-data/organization)
- [Source 2: www.w3.org](https://www.w3.org/WAI/tutorials/forms/labels/)

### B05 — Price or quote policy

Is pricing or a quote policy stated when relevant?

**Pro · Medium · Heuristic · Phase 2 · Relative implementation effort M**

**Why:** Pricing expectations can help users decide whether to proceed.

**Method:** Detect price/range/currency or explicit quote/consultation policy.

**Implementation:** Report found values/policy with page evidence.

**Evidence:** Visible price or quote-policy snippet.

**Limits:** Applicability varies; not stated is not failure; values may be dynamic or region-specific.

**Primary sources:**

- [Source 1: schema.org](https://schema.org/Service)

### B06 — Opening hours

Are business/contact hours stated when relevant?

**Pro · Medium · Heuristic · Phase 2 · Relative implementation effort S**

**Why:** Hours clarify when an in-person or phone service is available.

**Method:** Detect visible hours and optional LocalBusiness openingHours markup.

**Implementation:** Compare visible and structured values as candidates.

**Evidence:** Hours snippet and markup values.

**Limits:** Not needed by every business; seasonal or branch-specific hours need review.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/appearance/structured-data/local-business)

### B07 — Attributable expertise claims

Are expertise, credential or case-study claims attributed?

**Pro · Medium · Heuristic · Phase 2 · Relative implementation effort M**

**Why:** Attribution helps readers assess the basis for claims.

**Method:** Find claims with named person, issuer, date or case evidence.

**Implementation:** Report presence and source only; do not verify truth.

**Evidence:** Claim snippet and attribution candidate.

**Limits:** Not all businesses need credentials; scanner cannot validate licenses, reviews or outcomes.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/fundamentals/creating-helpful-content)

### B08 — Cross-page fact consistency

Do core business facts agree across the agreed pages?

**Pro · High · Heuristic · Phase 2 · Relative implementation effort L**

**Why:** Conflicting facts can confuse a reader or agent.

**Method:** Compare name, phone, email, address, hours, area and prices across pages.

**Implementation:** Normalize cautiously but retain exact strings; output a fact-by-page matrix.

**Evidence:** Compared values, source URLs and conflict candidates.

**Limits:** Branches, languages, departments and seasonal offers can explain variants.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/appearance/structured-data/organization)
- [Source 2: developers.google.com](https://developers.google.com/search/docs/appearance/structured-data/local-business)

### B09 — Freshness evidence

Do time-sensitive facts have a visible freshness signal?

**Pro · Medium · Heuristic · Phase 2 · Relative implementation effort M**

**Why:** Time-sensitive prices, schedules and policies benefit from context about currency.

**Method:** Report visible reviewed/updated date and Last-Modified/ETag where available.

**Implementation:** Show dates/headers and age; label absence as no evidence.

**Evidence:** Date text, response headers and observation time.

**Limits:** Signals are not proof of current truth; avoid rewarding date changes alone.

**Primary sources:**

- [Source 1: developers.google.com](https://developers.google.com/search/docs/fundamentals/creating-helpful-content)
- [Source 2: developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Last-Modified)
- [Source 3: developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/ETag)

### B10 — Service terms

Are relevant terms or conditions discoverable?

**Pro · Medium · Heuristic · Phase 2 · Relative implementation effort M**

**Why:** Relevant conditions help users understand an offer before acting.

**Method:** Look for terms, cancellation, refund, eligibility or service limitations when relevant.

**Implementation:** Report linked or visible terms evidence.

**Evidence:** Terms link/text and URL.

**Limits:** Business and jurisdiction dependent; absence is not failure; no legal compliance judgment.

**Primary sources:**

- [Source 1: schema.org](https://schema.org/Service)

### P01 — llms.txt discovery

Is an llms.txt file discoverable?

**Pro · Informational · Optional · Phase 3 · Relative implementation effort S**

**Why:** The community proposal offers a curated entry point for agents.

**Method:** Request the root or applicable path-level /llms.txt and parse its Markdown outline.

**Implementation:** Report availability and basic structure as optional informational evidence.

**Evidence:** URL, status, content type and headings/links.

**Limits:** Informal proposal; no guarantee any assistant reads it; absence never fails.

**Primary sources:**

- [Source 1: llmstxt.org](https://llmstxt.org/)

### P02 — Markdown alternate and parity

Are Markdown alternates discoverable, and do they reflect the page?

**Pro · Informational · Optional · Phase 3 · Relative implementation effort M**

**Why:** A clean Markdown alternate may make long reference content easier to consume.

**Method:** Inspect rel=alternate text/markdown links or proposal conventions; compare available page text.

**Implementation:** Only check pages that advertise an alternate; compare title and key text.

**Evidence:** Alternate relation, response and text comparison.

**Limits:** Optional proposal, not required; parity heuristic; no citation promise.

**Primary sources:**

- [Source 1: llmstxt.org](https://llmstxt.org/)

### P03 — OpenAPI documentation

Are public API docs discoverable, if the business offers an API?

**Pro · Informational · Optional · Phase 3 · Relative implementation effort M**

**Why:** Some businesses provide machine-readable service integrations.

**Method:** Follow linked/conventional OpenAPI descriptions and parse the document.

**Implementation:** Inspect only public linked/conventional docs; do not brute-force endpoints.

**Evidence:** Docs link, specification version, parse result, declared paths.

**Limits:** Optional; not a brochure requirement; presence does not prove authorization or usefulness.

**Primary sources:**

- [Source 1: spec.openapis.org](https://spec.openapis.org/oas/latest.html)

### P04 — Advertised MCP endpoint

Is an MCP integration explicitly advertised and discoverable?

**Pro · Informational · Optional · Phase 3 · Relative implementation effort M**

**Why:** MCP can expose tools and resources to compatible clients.

**Method:** Inspect linked public docs for an advertised MCP endpoint; do not call arbitrary tools.

**Implementation:** Record advertised endpoint/docs only; no tool invocation or mutation.

**Evidence:** Link and stated integration details.

**Limits:** Optional integration; cannot infer compatibility/usefulness; absence never fails.

**Primary sources:**

- [Source 1: github.com](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2025-11-25/server/tools.mdx)

### P05 — WebMCP declarations

Does the page declare WebMCP tools?

**Pro · Informational · Optional · Phase 3 · Relative implementation effort L**

**Why:** WebMCP is an emerging way for pages to expose structured browser tools.

**Method:** In browser-rendered pages, detect supported WebMCP registration/declarations.

**Implementation:** Report detection and browser/API context as experimental.

**Evidence:** Declaration/tool names and browser version.

**Limits:** Proposed/origin-trial status can change; no tests/calls; absence never fails.

**Primary sources:**

- [Source 1: developer.chrome.com](https://developer.chrome.com/docs/ai/webmcp)
- [Source 2: developer.chrome.com](https://developer.chrome.com/blog/ai-webmcp-origin-trial?hl=en)

### A01 — Contact and booking tool discovery

Are machine-callable resources exposed for contact, demos, meetings or quotes?

**Pro · High · Heuristic · Phase 3 · Relative implementation effort M**

**Why:** A relevant declared tool gives an agent an explicit route to a business action. A normal button or form is a separate UI route.

**Method:** Inventory tools registered in the inspected page context, metadata from explicitly advertised MCP endpoints, and documented OpenAPI operations. Classify action intent from names, descriptions and schemas; ambiguous intent requires review.

**Implementation:** Reuse P03/P04/P05 adapters. Parse public declarations first; use version-matched browser discovery for runtime tools and metadata-only MCP listing when supported. Never invoke business tools, fill forms or create records. Record ordinary links/forms as UI fallback only; do not invent endpoint paths.

**Evidence:** Action family, interface type, tool name or operationId, source URL, declaration/registration evidence, inspected pages, browser/protocol version and timestamp.

**Limits:** Registered tool observed, API documented only, UI only, not found in inspected scope, and could not inspect are distinct observations. A documented operation is not proof it is registered or usable now. Unsupported runtime, auth wall or incomplete iframe coverage means could not inspect. Absence is an opportunity for direct tool support, not proof that browser agents cannot use the website.

**Primary sources:**

- [Source 1: developer.chrome.com](https://developer.chrome.com/docs/ai/webmcp)
- [Source 2: modelcontextprotocol.io](https://modelcontextprotocol.io/specification/2025-11-25/server/tools)
- [Source 3: spec.openapis.org](https://spec.openapis.org/oas/v3.2.1.html)

### A02 — Action input and output declarations

Does the discovered action explain its accepted inputs and expected output?

**Pro · High · Established · Phase 3 · Relative implementation effort M**

**Why:** Explicit parameter definitions reduce guesswork about how a tool should be used.

**Method:** Inspect declared input types, required fields, descriptions, enumerations and any output contract. Validate schemas against their declared dialect and protocol version without generating or submitting payloads.

**Implementation:** Use an offline schema validator for supported dialects. Resolve only bounded, approved public schema references through the safe fetcher. Unsupported dialects or unresolved references are not_tested. Preserve the distinction between a missing optional output schema and an invalid required input schema.

**Evidence:** Tool/operation ID, schema dialect, required parameter names, validator diagnostics with schema paths, and output declaration present/absent/unsupported.

**Limits:** Schema validity does not prove the tool works or the business semantics are correct. MCP outputSchema is optional; WebMCP and OpenAPI have their own version-specific contracts. No sample customer data, test bookings or payload execution are needed.

**Primary sources:**

- [Source 1: json-schema.org](https://json-schema.org/understanding-json-schema/reference)
- [Source 2: modelcontextprotocol.io](https://modelcontextprotocol.io/specification/2025-11-25/server/tools)
- [Source 3: webmachinelearning.github.io](https://webmachinelearning.github.io/webmcp/)

### A03 — Exposed action state and prerequisites

Can an agent discover the context and prerequisites for the action in the inspected state?

**Pro · Medium · Heuristic · Phase 3 · Relative implementation effort M**

**Why:** An action can depend on the selected service, current page, authentication, timezone or a prior availability lookup.

**Method:** Read the current tool inventory and publicly exposed context. Record explicit prerequisites and state bindings. Distinguish observed context, declared state resources and unobserved state.

**Implementation:** Capture a bounded metadata snapshot in the initial page context. Inventory any advertised availability/state lookup as a resource without calling it. Do not log in, enter information, choose a slot, trigger validation or run actions to manufacture state.

**Evidence:** Observed context fields and source, documented prerequisites, relevant resource/tool names, observation timestamp and inspection limits. Record actual availability as not verified unless already exposed in the inspected context.

**Limits:** There is no universal state schema across WebMCP, MCP and OpenAPI. A get_availability declaration does not prove any slot is free. Static HTML cannot prove runtime registration. No exposed state is review/unknown when context may be hidden or unnecessary, not an automatic website failure.

**Primary sources:**

- [Source 1: developer.chrome.com](https://developer.chrome.com/docs/ai/webmcp)
- [Source 2: webmachinelearning.github.io](https://webmachinelearning.github.io/webmcp/)
- [Source 3: modelcontextprotocol.io](https://modelcontextprotocol.io/specification/2025-11-25/server/tools)

## Acceptance before launch

Validate rule behavior against labeled positive and negative fixtures, including policy choices and valid alternatives. Every Issue needs evidence; heuristic claims default to Review until calibrated. Browser journeys stop before submitting, booking, purchasing or creating an account. Record what was not tested. Re-test with the same scope and method version, or disclose changes.