Summary
Volume 3 is the normative AI-Ready Web specification surface. The machine-readable registry at ai-ready-web-requirements.json is the canonical requirement list; this page explains the requirement families and how to apply them without overclaiming support.
Agent implementation contract
When a user sends an agent to this AI-Ready Web guidance, the assignment is to apply the strategy to the user's target site, repository, or publication package. Treat UAIX as the reference standard and checklist. Do not copy UAIX page content into the target site, do not create a page about UAIX guidance, and do not publish an "AI-Ready Web" explainer unless the user explicitly asks for that output.
The expected target-site evidence set is concrete: public manifest, .well-known discovery, route inventory, readiness result, robots.txt, sitemap, llms.txt, structured data, visible support boundaries, targeted checks, and package or root-file output when publication is requested.
| Agent step | Do the real implementation | Do not do this |
|---|---|---|
| Resolve the target | Identify the target domain, repo root, public routes, build system, CMS, deployment package, root-file output path, and current evidence before editing. | Assume UAIX.org is the target site, summarize this page, or make a new guidance page because this page was provided as a reference. |
| Audit the existing site | Check human HTML, headings, metadata, canonical URLs, robots, sitemaps, schema, .well-known files, llms files, APIs, route inventories, readiness records, accessibility, privacy, and support boundaries. | Skip the target-site audit and only restate AEO/GEO/SEO definitions. |
| Implement improvements | Update the target site's pages, navigation, structured data, discovery files, route inventory, readiness records, public evidence, AEO/GEO/SEO copy, no-op guidance, review paths, and publish-package root files where the audit shows gaps. | Keyword-stuff, cloak, add hidden bot-only text, inject prompts for models, fabricate citations, or create synthetic doorway pages. |
| Verify and package | Run the site's targeted checks, record changed files and routes, name skipped checks and blockers, and provide the requested root files, root ZIP, or publish package when the user asks for deployable output. | Claim readiness, certification, endorsement, ranking gains, live publication, or agent authority without evidence. |
Requirement families
| Family | Requirement IDs | Result |
|---|---|---|
| Core architecture | ARW-001 to ARW-003 | Human-first surface, explicit support boundary, stable maturity labels. |
| Accessibility and rendering | ARW-010 to ARW-014 | Accessible semantic page surface, keyboard/focus reliability, no JavaScript-only critical facts. |
| Discovery and content | ARW-020 to ARW-027 | Robots, sitemap, .well-known, llms advisory file, route inventory, canonical IDs, alternate representations, ethical AEO/GEO, and target-site implementation guidance. |
| APIs and capabilities | ARW-030 to ARW-037 | OpenAPI routes, idempotency, Problem Details, capability matrix, no-op fallback, human review URL. |
| Identity, security, privacy | ARW-040 to ARW-049 | Least privilege, consent, data minimization, rights signals, auth boundaries, secret exclusion. |
| Provenance and operations | ARW-050 to ARW-058 | Trace Context, audit packets, freshness, monitoring, incident review, release evidence. |
| Governance and lifecycle | ARW-060 to ARW-066 | Claim review, maturity register updates, roadmap gates, validator results, translation parity. |
AEO/GEO: do the right thing
SEO means Search Engine Optimization. AEO means Answer Engine Optimization. GEO means Generative Engine Optimization. UAIX treats SEO/AEO/GEO as one public-interest publishing discipline: make pages useful for humans first, then make answers easy to find, verify, quote, compare, and route back to source evidence without hiding content from humans or trying to manipulate model output.
| Do | Do not | Why it matters |
|---|---|---|
| Write direct answer sections with stable headings, plain definitions, examples, limitations, dates when needed, and links to canonical evidence. | Stuff repeated keywords, publish AI-only doorway copy, or hide facts from the human page while showing them to bots. | Answer engines and generative systems need the same trustworthy source that a human reviewer can inspect. |
| Expose provenance: author or owner, last-reviewed state, primary source links, schema IDs, route IDs, checksums, release notes, and review paths where relevant. | Invent authority, cite stale reports as current truth, or use structured data that says more than the visible page supports. | Good AEO/GEO makes answers citable and correctable instead of merely extractable. |
| Use semantic HTML, accessible names, lists, tables, definitions, FAQ-style sections when helpful, JSON-LD where accurate, sitemaps, well-known manifests, and optional llms files that agree with canonical pages. | Treat llms.txt, schema markup, hidden prompts, or synthetic summaries as replacements for clear public content. | Machine-readable layers should reinforce the public page, not become a parallel truth surface. |
| State support boundaries, no-op behavior, unsafe-action handling, and human review routes beside claims. | Imply that AI visibility grants permission to scrape, authenticate, post, mutate data, validate credentials, certify safety, or bypass local policy. | Responsible AEO/GEO helps agents stop safely when the request exceeds public authority. |
| Keep content fresh through release notes, route inventories, readiness results, localization checks, and drift audits. | Chase model-specific hacks, fake citations, auto-generated pages with no review, or unverifiable ranking promises. | The durable win is a better web: accurate pages, stable routes, transparent evidence, and fewer hallucinated answers. |
Normative language
MUST means the site cannot claim that profile without evidence. SHOULD means the site needs either implementation evidence or a documented exception. MAY means optional or ecosystem-dependent. Proposal and research-track mechanisms must not be the only evidence behind a current support claim.
Stable standards baseline
- WCAG 2.2 and semantic HTML are the baseline for both people and agent-visible accessibility trees.
- HTTP Semantics, HTTP Caching, and Robots Exclusion Protocol anchor delivery and crawl boundaries.
- JSON Schema 2020-12, OpenAPI, Problem Details, and Trace Context anchor structured exchange, errors, and evidence.
- JSON-LD 1.1 and Schema.org anchor public entity clarity where appropriate.
Support boundary
AI-Ready Web requirements describe public site preparation and review evidence. They do not authorize scraping, bypass terms, validate credentials, grant tools, certify agent behavior, or prove safety. When requested work exceeds declared support, the correct behavior is no-op plus human review through Contact and Review.
Machine-readable registry
- Requirement registry JSONStable ARW requirement identifiers, tests, evidence, and anti-patterns.
- Maturity register JSONCurrent stable, configuration-specific, proposal, research, and unsupported mechanisms.
- Route inventory JSONSource/live audit facts, publication boundary, and route exposure plan.
- AI-Ready site manifest schemaPortable declaration for discovery, capabilities, policies, evidence, and support boundaries.
- AI-Ready site manifest exampleConcrete UAIX-flavored example without claiming hosted runtime execution.
- Readiness result schemaAssessment result model for automated checks plus manual review evidence.
- Readiness result exampleExample scoring packet with warnings, blockers, and no certification claim.