Screenshots and vision
The model interprets visual hierarchy, text, icons and control positions. Overlays, transparent components and layout shifts can make the intended action ambiguous.
Open sourceGuides
Is your website ready for AI agents? How to make pages, forms and checkout usable
Assistants no longer just read and summarise pages. They can search for a service, compare alternatives, fill in forms and attempt to complete a task. A website may be perfectly indexable yet remain unusable when an agent is navigating it.
The short answer
A website is ready for AI agents when information is discoverable, its structure is understandable, actions have explicit names and states, and sensitive operations remain controlled. It needs semantic HTML, a stable layout, labelled forms, verifiable feedback, performance and security. There is no need to chase every new protocol: WebMCP is a possible extension, not the foundation or a guarantee of use.
Gian Luca Partengo
Web developer since 1995 · bespoke websites · Updated on
“Agent-ready” is not a badge: it is a chain that has to work
Quality is not measured by asking a chatbot whether it likes the website. It is verified across four levels, in order.
- 01Discoverable: public pages, stable URLs, links and content can be reached.
- 02Understandable: headings, regions, controls, data and relationships have explicit meaning.
- 03Actionable: buttons, links, fields and flows work with reliable input and observable states.
- 04Controlled: authorisation, confirmation, validation and logs limit mistakes and abuse.
An agent may see screenshots, the DOM and the accessibility tree
There is no single navigation mode. Modern systems may combine the visual appearance of a page with its technical structure.
HTML and page structure
Elements, attributes, text and relationships distinguish navigation, content and controls. A clickable div remains far less explicit than a genuine button.
Open sourceAccessibility tree
Browsers and assistive technologies expose names, roles, values and states. That same structure can give agents more stable signals than visual appearance alone.
Open sourceThe practical consequence
Designing only for the human eye or only for a crawler is insufficient. The interface, HTML and accessibility tree should describe the same action.
Appearing in AI answers does not mean agents can use the website
SEO, GEO and agentic usability overlap, but they answer different questions.
Discoverable
Content is reachable through URLs, links and sitemaps; it is not hidden behind fragile interactions or areas the system cannot open.
Understandable
The page answers clearly, presents relationships and conditions, and uses consistent data. This supports search, citation and decision-making.
Actionable
The system can identify a control, enter data, continue and verify whether the action succeeded or needs correction.
Governed
The agent does not receive more power than necessary; irreversible steps require confirmation and the server remains the final authority.
Semantic HTML is already an interface for people, browsers and agents
Before adding manifests or APIs, describe what already exists on the page correctly.
Technical principle
Use the native element that represents the action
A link leads to a resource; a button starts an action; a field collects a value; headings and landmarks define hierarchy. These differences are information, not styling.
ARIA can supplement complex components, but it does not automatically fix a poorly built element. Name, role, value and state must remain consistent with what really happens.
Real, descriptive links
Every navigation uses a valid href and a name that describes the destination, avoiding dozens of indistinguishable “click here” links.
Genuine buttons
Submit, open, add and confirm actions use button elements, work from the keyboard and communicate disabled or busy states.
Hierarchy and landmarks
One h1, orderly headings and regions such as header, nav, main and footer help define content and functions.
Names, roles and states
Visible labels and accessible names match; menus, tabs, dialogs and toggles expose whether they are open, selected and their current value.
A predictable layout stops agents acting on the wrong target
Stability is not just a Core Web Vitals concern: it preserves continuity between what a system observes and what it attempts to use.
Consistent navigation
Menus, breadcrumbs and primary actions stay recognisable across pages, with names and positions that do not change without reason.
Visible controls
The target has text or an explicit name, an adequate size and is not covered by overlays, banners or invisible elements.
Stable interface
Images, fonts and dynamic content reserve space. The button does not move while the agent is deciding where to act.
Governable dialogs
Modals and panels have a title, correct focus, an understandable close action and never hide content without a clear exit.
A completable form explains what it asks for, in what format and why
Placeholder text and visual position are not enough. Every field must retain its identity before, during and after completion.
Design rule
The field should be interpretable without guessing
An associated label identifies the control; fieldset and legend group related choices; type, autocomplete and instructions make format and purpose explicit.
Browser validation improves the experience, but the server must validate every value. An agent can make mistakes or be manipulated just like a user and must not bypass application rules.
Persistent labels
Every input has a visible, correctly associated label. The placeholder remains an example, not the field’s only name.
Format and autofill
Data type, units, constraints and autocomplete help distinguish email, telephone, address, quantity and payment details.
Groups and dependencies
Radio buttons, checkboxes and conditional fields explain their relationship. When a choice opens more fields, the change is announced and predictable.
Unambiguous submission
The button states its actual effect — send enquiry, save draft, continue to payment — and prevents duplicate submissions while processing.
Without observable states, errors and confirmations, an agent cannot know it is finished
A colour change or a message that disappears too quickly may be invisible to the system and unclear to a person as well.
Loading
The interface communicates that the operation is in progress, blocks duplicates and keeps the state associated with the request.
Specific error
The problem is linked to the correct field or step, explains how to fix it and does not discard data that is already valid.
Verifiable outcome
Persistent confirmation, a reference number or a new state distinguishes success from a visual animation.
Next step
The page says what happened, what will happen and which action remains available without forcing the user to infer it.
Avoid false success
The HTTP response, application state and visible message should describe the same reality. A green notification does not prove that the server recorded the operation.
Basket and checkout are an end-to-end test, not a collection of buttons
An agent must move through prices, variants, availability, identity, shipping, payment and confirmation without encountering contradictory data.
-
01
Product and variant
Name, identifier, price, currency, availability and selected option remain consistent from the product page to the basket.
-
02
Authoritative basket
Quantity, discounts, tax and subtotals are recalculated by the server; edits and removals produce a new observable state.
-
03
Costs before commitment
Shipping, fees, renewals and essential terms appear before the user confirms or provides payment details.
-
04
Identity and address
Fields, autocomplete, countries, regions and validation handle real data without trapping the user in generic errors.
-
05
Explicit confirmation
The irreversible action presents its amount and consequences. An agent should not purchase merely because it found an available button.
-
06
Order and recovery
The outcome provides an identifier, summary and instructions; timeouts and retries must not create duplicate orders or charges.
Accessibility and agent compatibility share foundations, not equivalence
The same semantics that help a person using assistive technology may make an interface easier for an agent to read. The goals are not identical, however.
Necessary distinction
An agent-ready website is not automatically WCAG conformant
Native HTML, accessible names, visible focus, keyboard support, instructions and clear errors improve both areas. They are sound foundations, not certification.
Conformance requires criteria, level, representative pages, content, manual testing and assistive technologies defined against the project and applicable rules.
Keyboard
Actions and focus order work without a pointer, without traps and with an indicator that is always visible.
Accessible name
Controls and informative images communicate meaningful purpose even when the visual element is not interpreted.
Programmatic state
Expanded, selected, invalid, busy and disabled states are exposed in code and updated with the interface.
Understandable content
Headings, instructions and messages are direct and consistent and do not rely only on colour, shape or position.
For duties, exemptions, WCAG and the review service, read the complete guide to website accessibility.
The more an agent can do, the more the website must limit what can go wrong
Page content, responses from external tools and even apparently legitimate instructions may try to divert the agent from its goal.
Least privilege
Every function sees and changes only the data it needs. An agent checking availability does not receive permission to change prices or users.
Confirm consequences
Purchases, submissions, publishing, deletion and irreversible changes show the object, amount and effect before execution.
Server-side validation
Roles, quantities, prices, destinations and inputs are verified by the server. The DOM and client are not an authoritative source.
Idempotency and limits
Idempotency tokens, rate limits and replay protections stop retries and loops producing duplication or abuse.
Untrusted output
Text, pages, files and tool responses are treated as data, not as instructions to execute automatically.
Logs and interruption
Operations, errors, authorisation and identity are traceable; the system can stop, cancel or recover an abnormal flow.
The practical rule
Do not design on the assumption that the agent will “behave well”. Design for mistakes, hostile input, diverted goals and repeated attempts.
For patching, infrastructure, application security and monitoring, explore website security.
Speed and stability reduce timeouts, retries and ambiguity
A slow website costs people attention and agents operational cycles. Useful speed comes from a simpler system, not an isolated score.
HTML available immediately
Essential content, navigation and actions arrive in the initial response where possible, without relying on fragile JavaScript chains.
Contained dependencies
Scripts, tags, fonts and external components are reduced and governed. Fewer third parties mean fewer blocks, variations and failure surfaces.
State preserved
Reloads, errors and back navigation do not needlessly discard a basket or valid data; sessions and expiry are explained and recoverable.
Reliable responses
Timeouts, HTTP errors and retries are handled consistently, distinguishing temporary problems from final outcomes.
WebMCP can expose structured tools, but it remains an emerging technology
The idea is to let a page declare functions that an agent can discover and call without reconstructing them only from the visual interface.
Actions with a schema
Name, description, parameters and result turn a website function into a more explicit tool for an agent.
Open sourceDeclarative or imperative
The proposals describe enhanced forms as well as JavaScript tools for complex flows while retaining the human interface.
Open sourceDraft, not a stable standard
The document is a Draft Community Group Report, not a W3C Recommendation. APIs, availability and behaviour may still change.
Open sourceProgressive enhancement
The accessible, secure website must work first. WebMCP can then be considered for repeatable, high-value tasks, with a complete human alternative and no promise of universal compatibility.
Agent-ready audit: 20 checks before discussing integrations
The test should use real pages and tasks, not a demonstration built specifically to succeed.
Discovery and understanding
- Important pages have public URLs, canonicals and internal links.
- Title, h1 and content explain purpose, audience and conditions.
- Menus, breadcrumbs and main content are recognisable in the DOM.
- Visible and structured data describe the same reality.
- Essential content does not depend on fragile interactions or scripts.
Controls and forms
- Links and buttons use native elements and unique names.
- Every field has a label, type, format and useful instructions.
- Focus, keyboard, dialogs and menus work without a pointer.
- Errors are specific, associated and correctable.
- Submission, loading and success produce observable states.
Flow and reliability
- Prices, availability and summaries remain consistent.
- The server validates data, role and consequences.
- Refreshes, back navigation and timeouts preserve valid data.
- Retries do not duplicate submissions, orders or payments.
- The final outcome has a persistent identifier and instructions.
Security and governance
- Sensitive actions require explicit confirmation.
- Permissions and data follow least privilege.
- External output does not become trusted instructions.
- Rate limits, idempotency and logs cover operations.
- There is a way to stop, cancel and recover.
The GLP method: robust foundations before agentic features
Preparation starts with the real website and the value of the task. I do not add emerging technology merely to name it in a quote.
-
01
Define the tasks
Identify what a person or agent should find, compare, complete or finish and which steps have consequences.
-
02
Audit the foundation
Review HTML, structural accessibility, content, forms, states, performance and security on published pages.
-
03
Correct the flows
Make controls, errors, summaries and confirmations understandable without building a second AI-only interface.
-
04
Manual end-to-end testing
Run real tasks from the keyboard, with relevant assistive technologies and with error, recovery and double-submission scenarios.
-
05
Assess the integration
Only when useful, compare WebMCP, APIs or other tools against cost, compatibility, security, maintenance and the human alternative.
-
06
Monitoring and maintenance
Track errors and changes to the website or standards, because an operational flow can deteriorate without changing its URL.
| Level | Scope | Status | Price |
|---|---|---|---|
| Custom website | Semantics, keyboard, focus, labelled forms, performance, security and light/dark theme | Foundations included in website packages | Included |
| Accessibility preferences | Basic panel and reduced-motion support, which can be disabled together with the theme | Included, not certification | Included |
| WCAG conformance | Scope, remediation, automated and manual tests, assistive technologies, report and 12 months | Optional documented package | From €1,800 |
| WebMCP, APIs or agents | Analysis, design, security, development, testing and maintenance of the agreed integration | Separate advanced development | Quoted separately |
No solution is automatic certification, a guarantee of legal conformance or a promise that an agent will use or complete the website. Price depends on pages, functions, risks and the agreed scope.
Explore how to appear on ChatGPT and AI search, how to prepare ecommerce for AI shopping or review custom website services and pricing.
Verified primary sources
Agent capabilities and WebMCP proposals evolve quickly. These sources distinguish established foundations, product guidance and specifications that are still drafts.
-
web.dev — Build agent-friendly websitesOpen source
Screenshots, DOM, accessibility tree, semantic controls, stable layouts and predictable interfaces.
-
Google Search Central — Generative AI optimisationOpen source
SEO foundations, crawling, text, page experience, structured data and emerging agent technologies.
-
web.dev — The accessibility treeOpen source
How browsers and assistive technologies derive roles, names, states and properties from the DOM.
-
W3C WAI — Labeling controlsOpen source
Explicit labels, label-for association, accessible names and form controls.
-
W3C WAI — User notificationsOpen source
Feedback, errors, success and notifications that remain perceivable and associated with their context.
-
W3C — Web Content Accessibility Guidelines 2.2Open source
Testable criteria for perceivable, operable, understandable and robust web content.
-
Chrome for Developers — WebMCPOpen source
Overview of the proposal, declarative and imperative tools and browser experimentation.
-
Web Machine Learning CG — WebMCP draftOpen source
Technical specification and Draft Community Group Report status, not a W3C Recommendation.
-
Chrome for Developers — Agent securityOpen source
Risks of actions in authenticated sessions, hostile instructions, permissions and user protection.
-
OWASP GenAI — Agentic AI securityOpen source
Goal hijacking, tool misuse, excessive privilege, indirect prompt injection and defensive controls.
Sources checked on 28 July 2026. WebMCP is an evolving proposal: verify status, browser support, risks and specifications before implementation.
Frequently asked questions
Direct answers that separate concrete foundations, emerging technologies and promises that cannot currently be made.
What does “agent-ready website” actually mean?
It means content and functions are discoverable, understandable and actionable through explicit structures, while authorisation, confirmation and validation govern consequences. It is not an official mark or certification.
Is a website that ranks well on Google already agent-ready?
Not necessarily. SEO and GEO support discovery and understanding, but an agent can still fail on non-semantic controls, unlabelled forms, invisible errors or inconsistent flows.
Do I need WebMCP to make a website usable by agents?
No. Semantic HTML, structural accessibility, clear forms, observable states, performance and security are the foundation. WebMCP may become an extension for defined tasks, but on 28 July 2026 it remains an evolving proposal.
Does agent-ready mean WCAG conformant?
No. The two qualities share many foundations, but WCAG conformance requires a specific scope and testing. Good agent compatibility does not replace an accessibility audit.
Can I simply add ARIA to divs and custom components?
No. Native HTML should be preferred. ARIA adds names, roles, properties or states when necessary, but does not automatically recreate correct keyboard, focus and behaviour.
Can an agent complete any form?
No. It depends on the system, permissions and form quality. Labels, types, autocomplete, instructions, errors and confirmation increase reliability but do not guarantee completion.
Can I let an agent complete a purchase without confirmation?
That is a high-risk choice. The amount, item and consequence should be shown before the irreversible action; the server must verify authorisation, price and idempotency.
Does structured data make a website actionable?
No. It makes entities and properties more explicit to systems that use it, but does not replace controls, forms, application states, APIs or security.
Is a hand-coded website automatically better for agents?
No. The advantage comes from control over the result: clean HTML, contained dependencies, semantics, performance and testable flows. Bespoke code still has to be designed and tested well.
How much does it cost to make a website agent-ready?
It depends on pages, forms, checkout, authentication, risk and integrations. Structural foundations are included in new custom sites; the WCAG package starts at €1,800, while WebMCP, APIs and agentic features are quoted separately.
Can you guarantee that ChatGPT or another agent will use the website?
No. I can improve compatibility, clarity, security and testability, but site selection, tool availability and completion depend on the agent, browser and services involved.
Where should an existing website start?
Start with three real high-value tasks: find information, submit a form and complete the main commercial flow. Review DOM, keyboard, states, errors, performance and security before adding new protocols.
Next step
Do you want to know whether your website is genuinely usable, not merely visible?
Start with the tasks that matter: I will analyse structure, forms, states, performance and security and tell you what to fix before investing in agentic integrations.