How to interpret technical AI Readiness

What is evaluated: Readable Schema.org markup in at least one supported format.

Why it matters: Structured data exposes entity types, properties and relationships explicitly instead of leaving them to inference from prose.

What is evaluated: Syntactically readable JSON-LD blocks using Schema.org vocabulary.

Why it matters: JSON-LD is a common way to publish structured entities separately from the surrounding HTML markup.

What is evaluated: Schema.org markup embedded in HTML through Microdata attributes.

Why it matters: Microdata is a valid structured-data format, but it does not need to duplicate an already correct JSON-LD or RDFa representation.

What is evaluated: Schema.org markup embedded in HTML through RDFa attributes.

Why it matters: RDFa is another valid structured-data format and should be evaluated as an alternative, not as a mandatory companion to JSON-LD.

What is evaluated: robots.txt access for supported search/discovery crawler controls; answer-use, user retrieval and model-use policies are reported separately.

Why it matters: Search/discovery controls affect whether automated search systems can crawl public content, while training or model-use policy is a separate publisher choice and should not reduce this score.

What is evaluated: A valid Sitemap directive published in robots.txt.

Why it matters: A Sitemap directive gives automated systems a standard discovery path to the site’s published URL inventory.

What is evaluated: An absolute canonical URL aligned with the final public document address.

Why it matters: Canonical metadata helps distinguish the preferred document from duplicates and technical URL variants.

What is evaluated: A non-empty HTML title element.

Why it matters: The document title provides a concise identity for browsers, search systems and other metadata consumers.

What is evaluated: A non-empty page description meta tag.

Why it matters: A description gives machine consumers a concise summary of the page without replacing the primary content.

What is evaluated: Indexing directives published in the page-level robots meta tag.

Why it matters: A noindex directive can prevent search discovery regardless of otherwise strong technical signals.

What is evaluated: Core Open Graph properties for the page identity and preview.

Why it matters: Consistent preview metadata makes the page identity more portable across systems that consume Open Graph.

What is evaluated: Indexing directives published in the final HTTP response headers.

Why it matters: X-Robots-Tag can restrict indexing independently of the HTML robots meta tag.

What is evaluated: Sampled sitemap URLs are checked for agreement between their publication signals and preferred page address.

Why it matters: The sitemap should describe public pages consistently with the pages themselves.

What is evaluated: The sample checks document title and description presence plus duplicate titles between sampled pages.

Why it matters: Page identity and concise document context should exist beyond the homepage.

What is evaluated: A usable public HTML response from the site homepage.

Why it matters: A failed or non-HTML homepage does not provide a defensible base document for the rest of the technical assessment.

What is evaluated: Availability and basic readability of the public robots.txt file.

Why it matters: robots.txt is the standard publication point for crawl rules and Sitemap discovery.

What is evaluated: Availability and basic readability of the public XML sitemap.

Why it matters: A sitemap helps automated systems discover public URLs without implying that those URLs will be indexed or ranked.

What is evaluated: An interpretable HTML Content-Type and related document-delivery headers.

Why it matters: Incorrect response metadata can prevent reliable automated interpretation even when HTML is present.

What is evaluated: Useful page content present in the received HTML without executing external JavaScript.

Why it matters: Not every automated consumer executes client-side JavaScript before reading a page.

What is evaluated: A bounded sample of up to two sitemap URLs is checked for usable HTML and useful initial content.

Why it matters: A successful homepage does not prove that internal site pages are equally reachable to automated systems.

What is evaluated: The public redirect path, including origin changes and protocol downgrades.

Why it matters: Redirects determine the actual document URL and can cross trust or transport boundaries before content is reached.

What is evaluated: Delivery of the final page over HTTPS.

Why it matters: HTTPS protects response integrity and confidentiality between the site and the client.

What is evaluated: Strict-Transport-Security on HTTPS responses.

Why it matters: HSTS tells supporting browsers to use HTTPS for subsequent requests and reduces downgrade exposure.

What is evaluated: A Content-Security-Policy response header.

Why it matters: CSP constrains allowed resource and execution sources and can reduce the impact of content-injection attacks.

What is evaluated: Public restrictions on embedding the page in frames.

Why it matters: frame-ancestors or X-Frame-Options can reduce clickjacking and unwanted framing of the interface.

What is evaluated: The nosniff response directive.

Why it matters: nosniff tells browsers not to reinterpret resources as a different content type from the declared Content-Type.

What is evaluated: A policy controlling referrer information sent to other origins.

Why it matters: Referrer-Policy limits unintended disclosure of source URLs and their parameters to external recipients.

What is evaluated: A policy restricting selected browser capabilities.

Why it matters: Permissions-Policy can reduce unnecessary access to browser features, although it is diagnostic and does not affect AI Readiness.

What is evaluated: Explicit HTTP resource references inside an HTTPS page.

Why it matters: Insecure subresources can be blocked by browsers and weaken the integrity of an otherwise HTTPS page.

What is evaluated: Forms on HTTPS pages that submit to an insecure HTTP URL.

Why it matters: Submitting form data over HTTP can expose or alter user input in transit.

What is evaluated: Statically detectable browser-side WebMCP tool registration.

Why it matters: WebMCP can expose structured page-level tools to browser agents, but it remains an emerging capability and is not required for AI Readiness.

What is evaluated: Availability of the proposed /llms.txt machine-context document.

Why it matters: llms.txt can provide additional machine-readable navigation context, but its presence does not guarantee discovery, indexing or citation.

What is evaluated: Availability of an extended proposed LLM context document.

Why it matters: llms-full.txt can expose more machine-readable context, but it remains optional and does not guarantee use by an AI system.

What is evaluated: Static coverage of native interactive controls, accessible names and selected ARIA roles and states.

Why it matters: Browser agents can use accessible names, roles and states to interpret actions, but this diagnostic is not a ranking factor and does not replace a browser accessibility audit.

What is evaluated: Product or ProductGroup with offer semantics on sampled product pages.

What is evaluated: Machine-readable name, description and image coverage.

What is evaluated: Machine-readable price paired with a clear currency.

What is evaluated: Machine-readable product availability state.

What is evaluated: Machine-readable brand information where applicable.

What is evaluated: Stable identifiers such as SKU or globally recognized product IDs.

What is evaluated: A stable product URL aligned with canonical metadata.

What is evaluated: Machine-readable relationship between product variants and their offers.

What is evaluated: Unambiguous visible price and JSON-LD price do not contradict each other.

What is evaluated: Unambiguous visible availability and JSON-LD availability do not contradict each other.

What is evaluated: Version-aware validation of a published Universal Commerce Protocol discovery profile.

What is evaluated: Supported public Agent Card structure and safe declared interfaces.

What is evaluated: A public machine-readable HTTP contract where agent-facing operations are declared.

What is evaluated: A declared MCP-facing integration surface in the bounded commerce discovery context.

What is evaluated: Declared agent-facing endpoints avoid unsafe local/private/credential-bearing publication patterns.