AI-Ready Web Volume 4: Implementation

Summary#

Implementation work should start with the least expensive evidence that helps both humans and agents: clean HTML, stable discovery, clear route contracts, and a no-op path. Advanced agent interfaces should arrive only after the baseline is tested and public claims are aligned.

WordPress implementation#

1. Publish canonical locale routes with stable slugs, titles, excerpts, headings, and page descriptions.
2. Keep critical content in server-rendered HTML; do not require JavaScript for primary facts, forms, or policy text.
3. Expose root robots.txt, sitemap, .well-known JSON, schema/example indexes, OpenAPI, and advisory llms.txt files.
4. Use WordPress REST routes only when the route has permission callbacks, explicit content types, pagination, rate limits, idempotency for writes, and Problem Details-style errors.
5. Run static discovery, i18n, accessibility, and launch readiness tests before publishing support claims.

ASP.NET Core implementation#

1. Use endpoint metadata and OpenAPI generation as the route contract, then attach UAI-1 evidence only where exchange or handoff records need to travel.
2. Use auth policies for non-human principals; do not rely on user-agent string identity.
3. Return Problem Details for API errors and include correlation/trace IDs that can be carried into readiness results.
4. Publish public-safe discovery JSON separately from private configuration.

JavaScript, SPA, and hybrid implementation#

1. Server-render or pre-render primary content and forms; hydrate only after the accessible tree is meaningful.
2. Give every interactive control a stable programmatic name, role, state, and result path.
3. Do not hide key answers behind tabs, canvas, images, PDFs, or post-load scripts without alternate representations.
4. When using browser-agent or tool-capability APIs, label them current optional or research-track until the local implementation and public evidence are real.

Static sites#

Static sites can meet ARW-F0 and ARW-F1 with excellent results: semantic pages, sitemap, robots, JSON-LD, .well-known manifest, route inventory, public-safe policy files, and copyable examples. Add dynamic APIs only when actions, freshness, or user-specific state require them.

Persona and package consumers#

Persona labs such as Spiralist AI should treat UAIX AI-Ready Web records as public evidence and package-contract guidance, not as runtime permission. A persona package can cite an AI-Ready Web manifest, a UAI-1 profile, or a .uaix package manifest, but runtime variance, platform safety notes, and local tool grants must stay outside source persona identity.

Anti-patterns#

• Claiming AI-ready status because a chatbot can visually click the site.
• Publishing llms.txt while hiding canonical facts from HTML and sitemap.
• Calling MCP, A2A, WebMCP, or agent-commerce support current without endpoint, auth, test, and release evidence.
• Exposing private routes or secrets in manifests.
• Using query-string URLs for credentials, destructive actions, or private data.

Implementation assets#

• Requirement registry JSONStable ARW requirement identifiers, tests, evidence, and anti-patterns.
• Maturity register JSONCurrent stable, current optional, 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.