Methodology

How the public buying-information test works

What we read, how we interpret it, and where the evidence stops. Public-page findings are kept separate from untested workflows and business outcomes.

What the test measures

This is a public buying-information diagnostic. It checks whether the pages we retrieve explain what the business sells, who the offer fits, its price or quote process, applicable terms and where a buyer can take the next step.

The result can help a business make those facts clearer for people and AI assistants. It does not test completed purchases, live availability, recommendation rankings, conversion improvement or eligibility for an AI platform.

Retrieval and page selection

We request your home page, then follow ordinary links and your sitemap to find pages that may contain buying information: pricing, products or services, booking, contact, FAQ, about, locations and policies.

A bounded selection of pages is read per test. Pages are prioritized by likely relevance to a buying decision. The result lists what was retrieved; it is not an exhaustive site audit.

Public pages only

We do not sign in, submit forms, create accounts, attempt payment or place bookings, and we do not try to reach private or restricted areas.

A link, button, form, published price or protocol declaration is evidence of what the site presents. It is not proof that a workflow succeeds, that stock or a date is currently available, or that an assistant has permission to act.

Business classification

Language, page structure and commercial signals help classify the business and its selling model, including one-time purchases, subscriptions and quoted engagements. Findings should reflect that model: a documented quote process can be the appropriate pricing route.

Classification carries a confidence level. Low confidence stays visible, and we do not offer a paid plan based on a business we could not identify confidently enough.

Category adaptation

When evidence supports scoring, six public-information categories contribute: offer clarity, buyer answers, pricing, published access and fit facts, support for claims, and a discoverable next step. Two separate diagnostics describe the published route and the content actually retrieved. They remain visible but are excluded from the aggregate to avoid double counting. No criterion tests transaction completion or platform eligibility.

Availability means the information published about stock, capacity, dates or how to ask. Transaction means the published buying, booking or inquiry route. Neither category verifies a live transaction or reservation.

Offer, comparison and next-step information

The three capability indicators summarize whether the retrieved pages explain the offer, support comparison and identify a next step. Some structured outputs use the labels readable, selectable and transactable for these indicators.

These are evidence-based descriptions of public information. They do not establish that an assistant will recommend the business or can complete an action on a customer's behalf.

Published action-path evidence

The action-path indicator distinguishes published human handoff, browser routes, direct links, structured actions and agent-commerce declarations. It records the kind of route found, not a tested level of purchasing capability.

A public profile such as /.well-known/ucp can describe an integration, but retrieval alone does not validate its implementation, access permissions or successful execution. Advanced interfaces are not requirements for every business.

Machine-readable and access evidence

Where public requests expose them, we read Product and Offer data, published shipping and return information, feed references, declared order or reservation actions, post-purchase instructions and agent access rules.

Access restrictions describe what happened to this checker. Other browsers and assistants may be treated differently. An llms.txt file, API mention or product feed does not prove agent access, platform eligibility or transaction capability.

Evidence and uncertainty

Findings distinguish confirmed (observed in retrieved content), inferred (suggested by that content), missing (not found within the retrieved scope) and inaccessible (could not be retrieved). Confirmed means observed, not independently validated.

An unavailable page or an untested workflow remains an unknown. A verification task is a question to resolve, not evidence that the business is broken. Even a missing finding describes the pages read, not everything the business may publish elsewhere.

Complete, limited and inconclusive results

A numeric score is issued only when the retrieval checks support a complete assessment. Complete refers to this test's evidence threshold, not full coverage of every page or workflow.

Limited results distinguish retrieved evidence from what could not be checked. Inconclusive results do not turn failed retrieval into a low score or invented blockers. A result can still contain material unknowns even when it has a score.

Deterministic scoring

Fixed rules produce the score from retrieved evidence. The same evidence under the same model version produces the same score. It summarizes public-information signals; it is not a probability of a sale, an assistant recommendation or transaction success.

Retail policy credit requires substantive terms in retrieved content. A shipping or returns link alone does not establish the policy. FAQ links, headings and empty markup do not establish that questions were answered. Supporting findings cite the page and content actually read.

Evidence-based buyer scenarios

Buyer scenarios organize the evidence around questions a buyer might ask. They are not transcripts from ChatGPT, Gemini, Copilot or any other product, and no assistant is asked to buy from you.

Each scenario identifies the information needed, the retrieved evidence and questions that remain unresolved. A supported answer does not imply a successful checkout or a recommendation ranking.

Free diagnosis and paid guidance

The free result shows the public buying-information diagnosis, supporting sources, coverage limits and leading gaps. The $49 AI Buyer Action Plan runs a deeper public-page audit, including additional relevant pages when available. It provides source-backed buyer answers, evidence organized by page, three evidence-based buyer scenarios and specific changes where justified, with suggested owners, effort and acceptance checks.

The prioritized implementation sequence follows dependencies rather than a fixed calendar. A clear site may need few or no changes; the report still records the supported answers, sources and unresolved questions. Untested workflows remain separate from confirmed defects. The report is delivered as a private page; human review is not included.

Versioning and repeatability

Results record the model version and assessment date. Retesting can compare the public evidence retrieved at two points in time; differences may also reflect changed access or page coverage.

Ongoing monitoring is not available in this offer.

Current limitations

JavaScript-only content, bot protection, time limits and unreadable pages can reduce the evidence available. The result identifies these limits; information we could not retrieve must not be treated as a confirmed business defect.

The test does not observe private workflows, submit requests, validate legal compliance or measure customer outcomes. Any purchase, booking, live stock or delivery claim needs separate verification in an authorized flow.

Scoring model version
bba-public-information-2026-10-14-price-boundaries
Report generator
bba-report-2026-10-14-billing-basis
Last methodology update
14 October 2026