Can AI Agents Use Your Website? A Practical Acceptance Test
Check whether an assistant can read an offer, follow its links and complete a permitted task. Includes a test record and a way to separate access failures from missing capabilities.
An assistant asked to compare your service with another needs usable evidence: what you offer, who it serves, what the terms mean and where to go next. An assistant asked to book a demo also needs a working action. A page can supply the first and fail the second.
The useful question is specific: can the intended assistant complete the intended task on the public page? Our AI-search readiness guide addresses technical obstacles to discovery. This acceptance test extends that work to the person who wants an assistant to use the site.
Define a task with a verifiable result
Choose a task a real customer already performs. For a service business, a useful starting point is: “Find whether this service supports my location, identify the relevant service page and show me how to request a consultation.” Run the test against public information without submitting a form or changing customer data.
Write the expected answer before testing. Record the supported locations, the current service URL and the actual consultation action. This gives you a way to distinguish a convincing answer from a correct one.
Use a simple record:
| Task | Find the service available in a named location |
| Expected evidence | Service description, coverage statement, contact link |
| Observed result | Correct page found; contact action unavailable |
| Repair and owner | Replace the inactive contact control; web team |
| Verification | Repeat the task and record the resulting destination |
This is an illustrative record, not a customer result. Keep the assistant, test date and starting URL with the record so the next run can be compared fairly.
Separate access, reading and action
Start with what the assistant actually received. A login screen, consent interstitial or bot challenge may replace the page you see in your own browser. A successful status code alone cannot prove the service description was delivered. Save the observed response or a redacted screenshot and identify which intended content is missing.
Next, compare the visible offer with the content available to the assistant. Some tools retrieve text; others run a browser and inspect the page. Test the tool your customers use. Google describes browser agents that can inspect visual output, the DOM and the accessibility tree in its guidance on agentic experiences. A JavaScript page therefore needs an observed test, not a blanket declaration that every assistant can or cannot read it.
Finally, follow the action. A clearly named link should lead to the intended destination. A form should expose understandable labels and validation feedback. If a task needs authentication, payment or permission, record that boundary. A task that correctly stops for approval has behaved differently from one that loses the button or invents a confirmation.
Our JavaScript rendering guide is useful when the content a person sees and the content a retrieval tool receives diverge.
Choose access policies by purpose
Search retrieval, model training and user-directed activity have different controls. OpenAI documents independent settings for OAI-SearchBot and GPTBot: site owners can permit search while declining training. Its ChatGPT-User agent has a separate user-directed role. Use the provider's crawler documentation when deciding policy.
Anthropic likewise distinguishes Claude-SearchBot, ClaudeBot and Claude-User in its crawler guidance. Check the intended purpose, the site's policy and the observed access result together. A training opt-out is not, by itself, evidence that search access is broken.
Review hosting and CDN controls as well as robots.txt. Declaring permission in a file cannot make a blocked network request succeed. For legitimate traffic, verify the provider through its documented identification process before changing a rule. Copying a user-agent string into a request tests how that request is handled; it does not reproduce a verified provider request.
Make the next step discoverable
Keep important product facts on stable, linked pages. State capabilities in ordinary language and put qualifications beside the claim they limit. A page that says “integrates with your workflow” should link to documentation explaining the supported operation and its access requirements.
For sites that offer a public API or MCP integration, publish the supported interface and authentication requirements. SEOReport's agent integration lets compatible assistants request reports through the documented product interface. That is a separate capability from an assistant discovering SEOReport in a search answer.
A machine-readable navigation file can help a tool that explicitly consumes it. Verify that use before treating the file as part of your acceptance criteria. Working links and useful public documentation remain valuable to people as well.
Repeat the same task after the repair
Keep the original test record. Repeat it after the change using the same starting URL and task, then inspect the actual destination or answer evidence. Record any change in the assistant or its retrieval mode that limits the comparison.
Successful task completion establishes that this tested interaction worked. Search citations, referral visits and customer decisions need their own measurement. Together, those observations tell you whether the site became easier to discover, easier to use, or both.
See How Your Site Ranks
Get a free AI-powered SEO report with actionable findings and priority fixes for your website.
No signup required.