Check← Back to home
ASSESSMENT METHODOLOGY
What we check.
Why it matters.
Our evidence-led catalog of observable website signals. Each rule explains the assessment, its importance and its limits. Live reports state which checks actually ran.
Live single-page pilot · partial coverage. The free pilot inspects initial HTML and bounded discovery metadata. Every report lists all 38 criteria and marks unsupported or unavailable checks as Not tested. Browser interactions, semantic judgments and runtime tool discovery are not implemented. Planned A01–A03 checks inspect contact and booking tools through Discovery, Schema and State, without calling business tools or creating data.
HOW SCOPE WORKS
One catalog.
Three levels of coverage.
Basic is a homepage teaser. Pro reviews up to 5 pages you choose. Business expands the review to up to 50 pages. Pro and Business include every applicable Basic rule.
These are one-off assessment proposals with no subscriptions. Optional protocols and files can offer useful context, but they are not requirements or a certification. No result can guarantee AI recommendations.
THE RULES
Browse the catalog
0.2.0-proposed · Research updated 2026-11-07
Showing 38 of 38 checks
T01Access & discoveryFetch succeedsCan the selected page be fetched successfully?Basic
Why it matters
Content must arrive before it can be assessed.
How we would check
Bounded GET, DNS/TLS and redirect checks; distinguish empty/error bodies from 2xx.
Implementation approach
Retry a transient error once; store terminal URL, status, type, size and time.
Evidence and limits
Redirect chain, terminal response metadata and bounded body excerpt.
Limit: Timeouts, rate limits and scanner network differences are review/not-tested, not universal bot bans.
T02Access & discoveryCrawler preferencesDo declared crawler preferences match the owner’s discovery goals?Basic
Why it matters
Robots rules can restrict discovery crawlers.
How we would check
Parse robots.txt directives for relevant search crawlers and scanner.
Implementation approach
Show winning rule and separately label search, training and user-triggered fetch policies.
Evidence and limits
robots.txt response, parser result, matched directive and path.
Limit: Missing file is not failure; no need to enable training; crawler policies vary by service.
T03Access & discoveryChallenge or access wallDid the scan encounter a challenge or access wall?Basic
Why it matters
A wall can prevent the tested fetch.
How we would check
Detect confirmed challenge markers and login/consent walls; review generic 403s.
Implementation approach
Capture status and redacted challenge evidence; never bypass.
Evidence and limits
Status, challenge marker/header, redacted snippet.
Limit: Generic 403 does not establish cause or other agents’ access.
T04Access & discoveryIndexing directiveIs a public-intent page marked not to be indexed?Basic
Why it matters
An explicit noindex can conflict with a stated public discovery goal.
How we would check
Read robots meta and X-Robots-Tag directives.
Implementation approach
Report exact directive and ask applicability for private pages.
Evidence and limits
Tag/header, scope, affected URL.
Limit: Does not reveal actual index membership; private pages can appropriately be excluded.
T05Access & discoverySearch preview limitsDo preview restrictions limit this page’s eligibility for Google AI search features?Pro
Why it matters
These Google controls can limit snippets/previews.
How we would check
Inspect nosnippet, max-snippet and data-nosnippet.
Implementation approach
Report Google-specific scope and affected text.
Evidence and limits
Directive, value and DOM location.
Limit: No universal bad threshold; owner choice; not an AI-wide rule.
T06Access & discoverySitemap discoveryCan key pages be discovered through a valid sitemap?Basic
Why it matters
Sitemap provides discovery hints.
How we would check
Discover and parse linked sitemap; compare selected pages in Pro.
Implementation approach
Bound parsing and URL scope; sample key URLs.
Evidence and limits
Sitemap URL, parse status, selected-page membership.
Limit: Small well-linked sites may not need one; sitemap is not a guarantee.
T07Access & discoveryCrawlable linksAre important destinations available as actual links?Basic
Why it matters
Links expose navigation destinations to crawlers and agents.
How we would check
Inspect anchor hrefs and resolve selected same-site destinations.
Implementation approach
Compare selected destinations with anchors; inspect rendered page in Pro.
Evidence and limits
Anchor text/href and response.
Limit: Actions can be buttons; bounded scan cannot prove a page is orphaned.
T08Access & discoveryCanonical addressDoes the page point to a consistent canonical address?Pro
Why it matters
Canonical hints can consolidate duplicate URLs.
How we would check
Read HTML and HTTP Link canonical declarations; check conflicts.
Implementation approach
Resolve declared target within scope; report duplicates or unreachable target.
Evidence and limits
Canonical declaration, target status and final URL.
Limit: Missing self-canonical is not automatically an issue; canonical is a hint.
T09Readable contentContent in initial HTMLIs important content present in the initial HTML?Basic
Why it matters
Fetch-only readers may use the initial response.
How we would check
Extract main-body text separately from scripts and boilerplate.
Implementation approach
Identify empty app-shell pages and show extracted excerpt.
Evidence and limits
Initial HTML text and selected factual phrases.
Limit: No word count proves quality; browser agents may render content.
T10Readable contentRendered content differenceDoes rendering reveal key content missing from the initial response?Pro
Why it matters
Some sites load key facts after JavaScript execution.
How we would check
Compare raw response and isolated browser-rendered text/links.
Implementation approach
Record raw/rendered evidence and bounded wait budget.
Evidence and limits
Two extracts, browser environment and difference.
Limit: Differences are diagnostic; consent, location, network and defenses affect result.
T11Readable contentPage titleDoes each selected page have a useful, distinguishing title?Basic
Why it matters
Titles orient readers and help identify pages.
How we would check
Detect empty and exact duplicate title elements.
Implementation approach
Show title with page URL and invite wording review.
Evidence and limits
Title element and duplicate locations.
Limit: Do not apply arbitrary length score; usefulness needs context.
T12Readable contentMain content structureDoes the document expose main content and meaningful section headings?Pro
Why it matters
Structure helps readers and agents understand page organization.
How we would check
Inspect main landmarks and headings; review accessibility tree in Pro.
Implementation approach
Phase 1 inventories raw-HTML headings and landmarks. Meaningfulness needs review; a rendered accessibility-tree extension arrives in phase 3.
Evidence and limits
Landmark roles, heading outline and selectors.
Limit: One H1 or a rigid heading count is not universal conformance.
T13Readable contentPage languageIs the primary language declared?Basic
Why it matters
Declared language supports assistive technology and language handling.
How we would check
Validate non-empty recognized html lang value.
Implementation approach
In Pro compare with dominant text; flag strong mismatches for review.
Evidence and limits
lang value and detected language estimate.
Limit: Multilingual and code-heavy pages complicate inference.
T14Readable contentStructured data syntaxIs existing structured data syntactically usable?Basic
Why it matters
Structured data can express page facts in machine-readable form.
How we would check
Parse JSON-LD syntax in v1; inventory Microdata and RDFa separately.
Implementation approach
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 and limits
Format, parsed blocks and exact errors.
Limit: Absence is not failure; syntax does not mean correct or eligible for rich results.
T15Readable contentStructured data agreementDoes structured information agree with visible facts?Pro
Why it matters
Material disagreement can confuse readers and parsers.
How we would check
Compare overlapping identity, offer, price, location, availability and URL facts.
Implementation approach
Normalize deterministically first; cite both values; use human review for ambiguity.
Evidence and limits
Markup value and visible text spans.
Limit: Dynamic, regional or dated values can differ legitimately; missing markup is not conflict.
T16Agent interactionControl names and statesCan an agent identify the purpose and state of important controls?Pro
Why it matters
Semantic controls expose intent and current state.
How we would check
Inspect accessible name, role and state for selected controls.
Implementation approach
Inspect browser accessibility snapshot; flag empty/contradictory names.
Evidence and limits
Role, accessible name, state and selector.
Limit: Not a complete accessibility audit; icon-only controls may be properly named.
T17Agent interactionForm labelsDo forms expose labels, required fields and instructions?Pro
Why it matters
Clear labels help users and agents complete a contact task.
How we would check
Inspect associated labels, accessible names and instructions.
Implementation approach
No real submission; record associations and required indications.
Evidence and limits
Control names, label associations and instruction snippets.
Limit: Cannot verify delivery without a sandbox; placeholders alone are weak.
T18Agent interactionKeyboard navigationCan selected navigation be operated with keyboard in a sensible order?Pro
Why it matters
Keyboard operation is a useful signal for operable journeys.
How we would check
Tab through scoped controls; record focus order, visible focus and traps.
Implementation approach
Use bounded read-only browser path.
Evidence and limits
Focus sequence and screenshots/selectors.
Limit: Order differences are not inherently wrong; scoped check is not WCAG certification.
T19Agent interactionObstructed controlsDo overlays or unstable controls obstruct selected interaction?Pro
Why it matters
Obscured or shifting controls can block a tested action.
How we would check
Compare snapshots and hit-testing on selected task controls.
Implementation approach
Observe modal/overlay and target movement without bypassing consent/auth.
Evidence and limits
Visibility/hit test and time-separated location.
Limit: Modal is not inherently bad; limited experimental heuristic.
T20Agent interactionKey link destinationDo important links reach the promised next step?Pro
Why it matters
Broken primary routes block a basic decision journey.
How we would check
Resolve selected service/contact/pricing links; follow read-only route in Pro.
Implementation approach
Bound HTTP checks; stop at write/submit boundary.
Evidence and limits
Link name, destination status and journey steps.
Limit: A contact page does not prove lead delivery or transaction success.
B01Business clarityBusiness identityIs the business name stated clearly?Basic
Why it matters
Clear identity lets readers associate the site and its claims.
How we would check
Find visible organization/business name in header, main content or footer; record variants.
Implementation approach
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 and limits
Candidate name, snippet, URL, markup candidate.
Limit: Stylized brands and legal entities can differ; candidate extraction may need review.
B02Business clarityOffers and intended audienceCan a reader tell what the business offers and whom it serves?Basic
Why it matters
Specific offers and audience help people understand fit.
How we would check
Extract named service/product offers and audience evidence from visible copy.
Implementation approach
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 and limits
Service names, descriptions and audience phrases with source URLs.
Limit: Scanner cannot judge quality or verify real-world offer; indicate uncertainty.
B03Business clarityService area or remote scopeIs the service area or remote availability stated where applicable?Pro
Why it matters
People need to know whether the service is available to them.
How we would check
Find geographic scope or remote/onsite wording.
Implementation approach
Extract locations and scope phrases; compare Service.areaServed if present.
Evidence and limits
Visible wording and optional markup value.
Limit: Not applicable to every business; never penalize omission by default.
B04Business clarityContact facts discoverableAre useful contact facts present in the assessed pages?Pro
Why it matters
A person needs a way to ask questions or take the next step.
How we would check
Detect visible phone, email, address or contact route as fact candidates.
Implementation approach
Report available channels and where found; do not test delivery here.
Evidence and limits
Visible contact value/snippet and URL.
Limit: Form usability and broken link behavior are covered by T17/T20; facts may be intentionally omitted.
B05Business clarityPrice or quote policyIs pricing or a quote policy stated when relevant?Pro
Why it matters
Pricing expectations can help users decide whether to proceed.
How we would check
Detect price/range/currency or explicit quote/consultation policy.
Implementation approach
Report found values/policy with page evidence.
Evidence and limits
Visible price or quote-policy snippet.
Limit: Applicability varies; not stated is not failure; values may be dynamic or region-specific.
B06Business clarityOpening hoursAre business/contact hours stated when relevant?Pro
Why it matters
Hours clarify when an in-person or phone service is available.
How we would check
Detect visible hours and optional LocalBusiness openingHours markup.
Implementation approach
Compare visible and structured values as candidates.
Evidence and limits
Hours snippet and markup values.
Limit: Not needed by every business; seasonal or branch-specific hours need review.
B07Business clarityAttributable expertise claimsAre expertise, credential or case-study claims attributed?Pro
Why it matters
Attribution helps readers assess the basis for claims.
How we would check
Find claims with named person, issuer, date or case evidence.
Implementation approach
Report presence and source only; do not verify truth.
Evidence and limits
Claim snippet and attribution candidate.
Limit: Not all businesses need credentials; scanner cannot validate licenses, reviews or outcomes.
B08Business clarityCross-page fact consistencyDo core business facts agree across the agreed pages?Pro
Why it matters
Conflicting facts can confuse a reader or agent.
How we would check
Compare name, phone, email, address, hours, area and prices across pages.
Implementation approach
Normalize cautiously but retain exact strings; output a fact-by-page matrix.
Evidence and limits
Compared values, source URLs and conflict candidates.
Limit: Branches, languages, departments and seasonal offers can explain variants.
B09Business clarityFreshness evidenceDo time-sensitive facts have a visible freshness signal?Pro
Why it matters
Time-sensitive prices, schedules and policies benefit from context about currency.
How we would check
Report visible reviewed/updated date and Last-Modified/ETag where available.
Implementation approach
Show dates/headers and age; label absence as no evidence.
Evidence and limits
Date text, response headers and observation time.
Limit: Signals are not proof of current truth; avoid rewarding date changes alone.
B10Business clarityService termsAre relevant terms or conditions discoverable?Pro
Why it matters
Relevant conditions help users understand an offer before acting.
How we would check
Look for terms, cancellation, refund, eligibility or service limitations when relevant.
Implementation approach
Report linked or visible terms evidence.
Evidence and limits
Terms link/text and URL.
Limit: Business and jurisdiction dependent; absence is not failure; no legal compliance judgment.
P01Optional interfacesllms.txt discoveryIs an llms.txt file discoverable?Pro
Why it matters
The community proposal offers a curated entry point for agents.
How we would check
Request the root or applicable path-level /llms.txt and parse its Markdown outline.
Implementation approach
Report availability and basic structure as optional informational evidence.
Evidence and limits
URL, status, content type and headings/links.
Limit: Informal proposal; no guarantee any assistant reads it; absence never fails.
P02Optional interfacesMarkdown alternate and parityAre Markdown alternates discoverable, and do they reflect the page?Pro
Why it matters
A clean Markdown alternate may make long reference content easier to consume.
How we would check
Inspect rel=alternate text/markdown links or proposal conventions; compare available page text.
Implementation approach
Only check pages that advertise an alternate; compare title and key text.
Evidence and limits
Alternate relation, response and text comparison.
Limit: Optional proposal, not required; parity heuristic; no citation promise.
P03Optional interfacesOpenAPI documentationAre public API docs discoverable, if the business offers an API?Pro
Why it matters
Some businesses provide machine-readable service integrations.
How we would check
Follow linked/conventional OpenAPI descriptions and parse the document.
Implementation approach
Inspect only public linked/conventional docs; do not brute-force endpoints.
Evidence and limits
Docs link, specification version, parse result, declared paths.
Limit: Optional; not a brochure requirement; presence does not prove authorization or usefulness.
P04Optional interfacesAdvertised MCP endpointIs an MCP integration explicitly advertised and discoverable?Pro
Why it matters
MCP can expose tools and resources to compatible clients.
How we would check
Inspect linked public docs for an advertised MCP endpoint; do not call arbitrary tools.
Implementation approach
Record advertised endpoint/docs only; no tool invocation or mutation.
Evidence and limits
Link and stated integration details.
Limit: Optional integration; cannot infer compatibility/usefulness; absence never fails.
P05Optional interfacesWebMCP declarationsDoes the page declare WebMCP tools?Pro
Why it matters
WebMCP is an emerging way for pages to expose structured browser tools.
How we would check
In browser-rendered pages, detect supported WebMCP registration/declarations.
Implementation approach
Report detection and browser/API context as experimental.
Evidence and limits
Declaration/tool names and browser version.
Limit: Proposed/origin-trial status can change; no tests/calls; absence never fails.
A01Action capabilitiesContact and booking tool discoveryAre machine-callable resources exposed for contact, demos, meetings or quotes?Pro
Why it matters
A relevant declared tool gives an agent an explicit route to a business action. A normal button or form is a separate UI route.
How we would check
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 approach
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 and limits
Action family, interface type, tool name or operationId, source URL, declaration/registration evidence, inspected pages, browser/protocol version and timestamp.
Limit: 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.
A02Action capabilitiesAction input and output declarationsDoes the discovered action explain its accepted inputs and expected output?Pro
Why it matters
Explicit parameter definitions reduce guesswork about how a tool should be used.
How we would check
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 approach
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 and limits
Tool/operation ID, schema dialect, required parameter names, validator diagnostics with schema paths, and output declaration present/absent/unsupported.
Limit: 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.
A03Action capabilitiesExposed action state and prerequisitesCan an agent discover the context and prerequisites for the action in the inspected state?Pro
Why it matters
An action can depend on the selected service, current page, authentication, timezone or a prior availability lookup.
How we would check
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 approach
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 and limits
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.
Limit: 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.
READING YOUR RESULT
Findings need context.
A status describes what happened for a selected task and scope. Severity applies only when a rule was tested for that task; unknown means the check could not be assessed, not that it failed.
- PassEvidence supports the expected behavior.
- IssueEvidence shows a gap relevant to the task.
- ReviewA person should inspect the evidence in context.
- Not testedThis rule was outside the assessment performed.
- Not applicableThe rule does not fit this site or task.