How to make your website AI-agent ready: a practical checklist

What does it mean for a website to be AI-agent ready?

For this checklist, an agent-ready website gives an automated visitor enough accurate information and reliable controls to complete a defined task within the user’s permissions. Readiness is specific to the page, task, and agent you tested.

AI search visibility is a related goal. Google says a page must be indexed and eligible for a search snippet to qualify as a supporting link in AI Overviews or AI Mode. It does not require special AI files or special schema, and eligibility does not guarantee inclusion. Google’s AI search guidance.

A browser agent has another problem to solve: using the website once it arrives. Depending on its tooling, it may work from screenshots, HTML, or the accessibility tree. That is why a search visibility check alone cannot establish that your booking form works for an agent. How agents perceive websites.

The AI-agent readiness checklist at a glance

Audit one important journey first: product comparison, appointment booking, or a demo request. Use the same journey throughout these checks so you finish with an actionable result.

Download the free audit worksheet (CSV). Record pass, fail, unknown, or not applicable, then attach evidence and assign the fix.

1. Check who can actually access your site

Open the target page in a signed-out browser. Then inspect its HTTP response and your robots.txt. A human seeing the page does not establish that an automated request receives the same content; a challenge screen can have a successful HTTP status.

Separate the decisions you are making about different crawlers:

• OAI-SearchBot: OpenAI’s crawler for ChatGPT search.
• GPTBot: OpenAI’s crawler for content that may be used in model training.
• ChatGPT-User: visits associated with certain user requests; it is not the automatic search crawler, and robots rules may not apply.

OpenAI documents these controls separately. Allowing search access does not require allowing GPTBot. Review its current crawler documentation and published IP ranges before changing network rules. OpenAI crawler reference.

For Google, Google-Extended controls certain training and grounding uses; Google says it does not affect inclusion or ranking in Google Search. Google-Extended documentation.

If access looks inconsistent, ask your hosting or CDN team to inspect the actual request logs. Check redirects, challenges, and denied requests on the URLs in your chosen journey. Changing a user-agent string in a local request does not prove a provider’s real crawler can reach you.

If Cloudflare is in the request path, use our OAI-SearchBot blocking diagnostic to connect the failed response to a security event and verify a scoped fix.

Evidence to keep: the intended crawler policy, the retrieved page response, and any relevant blocked-request record. Preserve authentication for private content: robots.txt is a crawl preference, not access control. How robots.txt works.

2. See what survives outside the visual page

Choose three facts the agent must get right: the product name, its price or pricing model, and a required integration. Find each in the initial HTML response, then compare it with the rendered page.

For a quick inspection on a public URL you control, save the response headers and body. Replace the example address:

curl --location --max-time 20 \
  --dump-header response-headers.txt \
  --output response-body.html \
  'https://example.com/pricing/'

This fetch does not execute JavaScript. If the returned document contains only an application shell, you have identified a dependency on rendering. Google can render JavaScript, but its documentation notes that not all bots can, and recommends server rendering or pre-rendering where appropriate. Google’s JavaScript SEO guide.

Put essential public facts into ordinary page text. A pricing graphic can supplement a table, but the table should carry the actual prices and conditions. Keep information consistent between the initial response and the interactive page.

For a repeatable comparison and a worked pricing-page repair, follow our guide to AI crawler JavaScript rendering and initial-HTML testing.

Evidence to keep: where each required fact appears in the raw response and rendered view. A failed raw-HTML check identifies a limitation for that access method; test your intended browser agent separately.

3. Give useful answers a stable, discoverable URL

An integration answer buried inside a temporary modal is difficult to revisit or cite. Give important product details, pricing explanations, and support policies durable URLs. Link to them from relevant pages using descriptive text.

Inspect navigation in the source. Google’s documented baseline is an <a> element with an href attribute; a click handler on a generic element is not an equivalent crawlable link. Crawlable link guidance.

For pages intended to appear in search, inspect the canonical URL, sitemap entry, and any noindex directive in HTML or HTTP headers. Google needs crawl access to see a noindex directive, so blocking crawling is not a substitute for controlling indexing. Use Search Console’s URL Inspection for Google’s view. Google’s noindex documentation.

Evidence to keep: an ordinary link to each important page, its final URL, and its index settings. These observations help diagnose discovery; they do not prove a particular AI service has indexed it.

4. Replace ambiguous claims with answerable facts

“Flexible pricing for growing teams” leaves a buyer with work to do. State the currency, billing period, unit, minimum commitment, and relevant limits. If prices require a quote, say what determines the quote and how to request one.

Here is an illustrative rewrite for a fictional scheduling product:

Add applicable structured data using values that agree with what the page shows. Do not invent ratings, availability, or an offer simply to fill a schema template. Google requires structured data to represent visible content and does not guarantee a rich result even for valid markup. Structured data policies.

For a concrete implementation, use our structured data and JSON-LD guide for AI agents. It shows how to model a public offer, compare it with visible terms, and distinguish schema validation from actual agent behavior.

Evidence to keep: a short answer sheet for the task, with each fact and its source URL. Compare the agent’s answer against this sheet during your final test.

5. Make every important control understandable

A row of identical “Select” buttons creates unnecessary ambiguity. Use names that identify the action and its object, such as “Select Team plan.” Keep the button close to the plan information in the document structure.

Start with native controls and explicit labels. For example, this basic form structure gives the name, requirement, and input purpose a clear relationship:

<label for="demo-email">Work email (required)</label>
<input id="demo-email" name="email" type="email"
       autocomplete="email" required>
<button type="submit">Request a product demo</button>

This is a markup example, not a complete form implementation. W3C’s accessibility guidance explains how to associate labels and controls; placeholder text should not carry the entire labeling job. W3C guidance on labeling controls.

Inspect the accessibility tree in browser developer tools. Check what names and roles appear for the actual controls. Then navigate with the keyboard and confirm that focus reaches the fields in a sensible sequence. Do this with the consent banner and validation errors visible too.

For a repeatable implementation check, follow our accessibility-tree inspection and testing guide. It covers computed names, hidden controls, changing states, and a runnable Playwright example.

Evidence to keep: the names and roles of the controls your journey uses. This is a focused interaction check; a complete accessibility audit covers more.

6. Make progress, errors, and success observable

After a click, the agent needs to know what happened. A silent delay invites another attempt. A green checkmark without text leaves the meaning uncertain. A message saying “Done” may conceal whether a request was saved, emailed, or merely validated.

For a demo form, design and test four distinct states:

• Ready: the required fields and next action are clear.
• Submitting: progress is visible and repeated submissions are controlled.
• Needs correction: the specific field and reason are identified, with entered values preserved.
• Confirmed: the page states what was accepted and what happens next, based on the server result.

Test an invalid email, a slow response, and a server error in a controlled environment. Check that the page announces status changes accessibly and remains usable after a failure. Keep key controls stable as banners, fonts, and validation messages load.

Evidence to keep: the exact result of each attempt, including the backend state where you can inspect it. A success-looking interface is insufficient evidence if the request never arrived.

7. Use WebMCP where it solves a specific interaction problem

WebMCP is a proposed browser API for exposing structured tools to agents. Its declarative approach describes actions through forms; its imperative approach supports JavaScript-based tools. Availability and API details are evolving, so check current support before implementing it. Chrome’s WebMCP introduction and the draft specification.

Start with one useful operation. For our scheduling example, a tool that returns current plan details could remove ambiguity from a comparison. A demo-request tool would need a separate, carefully defined write operation.

Write down the tool’s contract before coding:

• What user task does it support?
• What inputs does it accept, and what does the server validate?
• Does it retrieve information, prepare an action, or commit a change?
• What result or recoverable error does it return?

Chrome’s best practices recommend clear tool purposes, meaningful input types, validation in code, and testing. Tool names should distinguish starting a process from completing it. WebMCP implementation guidance.

For a repeatable release check, follow our guide to testing WebMCP tools with an inspector, fixtures, and agent evaluations.

Evidence to keep: the tool as discovered in a supporting browser, its actual result, and the resulting page state. A script tag or an MCP discovery endpoint alone does not establish that a browser WebMCP tool works.

8. Keep permission and confirmation inside the product

An agent’s ability to invoke a control should not grant extra authority. Apply the same server-side authentication, authorization, and input validation as you do to equivalent human actions.

For consequential actions, make the commitment explicit. A user asking an agent to research a plan has not necessarily asked it to buy the plan. Design the journey so the user can review what will be submitted or purchased before the system commits it. Chrome’s WebMCP tool-security guidance.

Our recommended test cases are concrete:

• A signed-out visitor attempts an account-only action.
• A user attempts an action on another account’s resource.
• An agent prepares a request but has no approval to submit it.
• A timeout causes the same write request to be retried.

Use test accounts and a sandbox for these checks. Where repeated writes could create duplicate bookings or charges, implement duplicate protection and verify it against the stored result. Keep secrets and privileged credentials on the server.

Evidence to keep: which requests were permitted, which were rejected, and whether a retry produced one intended change. A refusal can be the correct outcome of a successful test.

9. Test the whole task and keep the evidence

Give your chosen agent a customer goal without prescribing every click. Define the correct outcome first, then inspect the steps, facts, and final state. Repeat the task in fresh sessions and after relevant site changes.

Chrome’s June 2026 toolkit announcement describes Lighthouse’s Agentic Browsing category, available from M150, with checks for accessibility, stability, and WebMCP. At that announcement it was informational and unbenchmarked. Use the reported findings alongside your task tests, and check the current tooling documentation for availability. Chrome’s agent-ready developer toolkit.

Keep these measurements separate:

• Technical findings: which public or browser checks passed, failed, or remained unknown.
• Task completion: whether the correct permitted outcome occurred.
• Search visibility: whether a defined search or prompt surfaced your page.
• Business outcome: whether a visit led to a useful signup, enquiry, or sale.

A browser run proves something about that run. Record the browser, agent, date, login state, and input so you can reproduce a failure. Avoid turning a handful of successful attempts into a general reliability claim.

Evidence to keep: a trace or recording, the expected answer, the observed result, and the first point where the task diverged.

A worked example: audit the request behind the visit

Return to our fictional scheduling product. Its Team plan costs €19 per user per month, billed annually, with a ten-user minimum and VAT excluded. The plan includes a Salesforce integration. These are invented test fixtures, not Adapt My Page pricing or measured customer results.

Give the agent this task in a test environment:

Find the plan that supports Salesforce for ten users. Tell me the annual cost before tax and any setup requirement. Prepare a demo request using the supplied test contact details. Stop before submitting it.

Your acceptance criteria are specific:

1. It identifies the Team plan and links to the supporting information.
2. It reports €2,280 per year before VAT: €19 × 10 users × 12 months.
3. It includes the annual billing condition and Salesforce administrator requirement.
4. It fills the intended form fields with the supplied test details.
5. It stops before submission, and no demo request exists in the backend.

Suppose the agent gets the price right but cannot identify the email field. The next fix is in the form. If it submits despite the stopping condition, investigate the approval boundary. If it never reaches the pricing page, inspect discovery and access. This method ties each change to an observed obstacle.

Once the preparation test works, run a separate submission test with explicit authorization and a sandbox destination. Check the stored request and confirmation. Do not send real customer messages just to establish a benchmark.

Turn the checklist into a working backlog

Download the audit worksheet and add an owner, evidence, and retest result for each finding. Fix blocked access and incorrect facts first, then broken controls and unsafe writes. Add optional tooling where the task test shows a reason to use it.

If you audit multiple sites, the Agent Readiness API returns public findings as JSON for your workflow. Preserve unknown and not-applicable results rather than treating every missing signal as a failure. Our guide to automating agent readiness audits shows a paced batch script, an n8n schedule, and a GitHub Actions check built on that API.

For teams exploring browser actions, the experimental Agent Tag pilot is a separate implementation path. Public discovery checks and live interaction work answer different questions; plan the browser verification as part of the implementation.

Frequently asked questions

Do I need llms.txt to make my website agent-ready?

It depends on the clients and workflow you support. The llms.txt proposal describes a Markdown resource that can guide agents to useful information. Version 2, updated in August 2026, also describes scoped files such as /docs/llms.txt. It can be useful documentation infrastructure. Its presence does not demonstrate that an agent completed a task or that a search engine will cite you.

Will this checklist get my website into ChatGPT or Google AI answers?

It can help uncover access, content, and interaction problems. It cannot guarantee selection, rankings, or clicks. For Google’s AI search features, ordinary SEO fundamentals still apply. Track actual visibility and visits separately from your technical audit. Google’s eligibility and measurement guidance.

Does every website need WebMCP?

No universal requirement follows from this checklist. A documentation site may mainly need accurate, retrievable answers. A booking application has more interaction work to test. Evaluate WebMCP against a specific journey, the agents you expect, and current browser support.

What is a good AI-agent readiness score?

Ask what the score measures and which checks were possible. A public scan and a browser audit observe different things. Review the individual evidence, then run the customer task. There is no score in this guide that certifies universal agent compatibility.

How often should I repeat the audit?

Retest the affected journey after changes to pricing, navigation, forms, consent flows, authentication, or tools. Also rerun it when your target agent or browser changes. Keep the old result so you can distinguish a regression from a problem that was never tested.