A practical way to prepare your site for assistants that read, recommend and sometimes act on a customer’s behalf.
A customer asks an AI assistant to find a suitable provider. The assistant reads five websites, compares the offers and gives the customer a shortlist. Your page may have influenced that answer even if nobody clicked through. If the customer does visit, they arrive with a sharper question than “what do you do?”
What should your website do in that journey? An AI agent-ready website needs three things: facts an assistant can find, evidence that keeps those facts accurate, and a clear boundary before any customer action. A new file or a chatbot widget is not the foundation. A trustworthy public website is.
The site is still the source. The assistant is another way people reach it.
More AI traffic does not mean more customers
The phrase “AI traffic” hides several different events. A training crawler may fetch a page. A search crawler may index it. An assistant may retrieve it because a person asked a question. A human may click a citation. Only later might that person enquire or buy.
Cloudflare’s 2025 traffic analysis found that AI bots accounted for an average 4.2% of HTML requests across its customer network. Googlebot alone accounted for 4.5%. Those are requests, not a count of interested buyers. Cloudflare also reported that traffic from its “user action” crawler category rose more than 21-fold from January to early December 2025. That rise makes the distinction between a crawler and a customer more valuable, not less.
The visitor side is changing too. Pew Research Center analysed 68,879 Google searches made by 900 US adults in March 2025. People clicked a traditional result on 8% of visits with an AI summary, compared with 15% without one. They clicked a link inside the summary on 1% of visits where it appeared. The study describes US search behaviour, not a forecast for an Australian service business, but it shows why citations, visits and sales cannot be treated as one metric.
Ask a better question than “How many AI bots visited?” Ask which customer decision your page helped make, and whether the next step worked when a person took it.
Know which kind of assistant is at your door
OpenAI’s crawler documentation makes a useful distinction: OAI-SearchBot supports search discovery, GPTBot relates to model training, and ChatGPT-User can fetch a page following certain user requests. One block or allow rule does not mean the same thing for all three. Google’s AI Search guidance is different again: eligibility for AI Overviews and AI Mode uses the ordinary Google Search requirements, including indexing and snippet eligibility. Google says there is no special AI schema or AI text file required.
Grok Bot, Muse and dots change the visitor, not the source of truth
The new personal agents make this distinction more concrete. Their product names are not crawler identities. They can work through a computer, browser or connected app to carry out a person’s task. That is a different job from indexing pages for future answers.
- Grok Bot is xAI’s team of always-on agents. xAI says its Bots have a cloud computer and can work across websites and apps, including ones without a dedicated API.
- Muse is Meta’s personal agent. Meta says it runs in a secure virtual computer with its own browser and works across apps on a person’s behalf.
- dots are OpenAI’s always-on agents. OpenAI says a dot has its own cloud computer and browser and can use connected apps under the person’s permissions and approval rules.
Suppose one of them is asked to compare ERP consultants and start an enquiry. It may read your service page to assess fit, then reach the contact form through a browser-like session. A training-bot rule tells you little about whether that journey succeeds. The useful test is whether the page explains the offer and the form accepts a properly authorised, validated request.
Cloudflare now separates Search, Agent and Training activity. Its Agent category covers real-time work on a person’s behalf, including browser-use agents. Review edge rules and logs by behaviour and outcome; do not assume a product called Grok Bot will arrive under a user-agent string called GrokBot, or that a dot will arrive as OAI-SearchBot.
That is why a single “agent-friendly” switch is a poor brief for a developer. Decide the desired outcome first:
- Be discoverable: ensure valuable pages can be crawled, indexed and reached through real internal links.
- Be understandable: publish current service scope, locations, process, evidence and contact routes as visible text.
- Be actionable: if an assistant can initiate an enquiry or transaction, require the same validation, permission and confirmation as any other client.
Notice the last line. A model reading “appointments available” from a six-month-old page cannot know that Tuesday is still free. A citation is an information event. A booking is a live business commitment.
The useful framework is read, verify, act
Imagine a consultancy page saying it serves Melbourne businesses and offers ERP selection advice. An assistant can safely extract that public description. It may also see an old “projects start within two weeks” sentence. If capacity has changed, the assistant can repeat an outdated promise with perfect fluency. If it then attempts to submit an enquiry, the site must know who authorised that action and what was actually sent.
This produces a simple three-layer design for an AI agent-ready website:
| Layer | Examples | Site responsibility | What can go wrong |
|---|---|---|---|
| Read | Service descriptions, coverage, articles, FAQs | Publish clear, crawlable, internally linked facts | The assistant misses or misstates the offer |
| Verify | Price, availability, eligibility, current terms | Give a current source, owner and review trigger | An old claim becomes a new promise |
| Act | Enquiry, booking, purchase, account change | Require user consent, server validation and confirmation | A request becomes an unauthorised action |
The first two layers are primarily publishing problems. The third is a workflow and security problem. Confusing them creates expensive projects: teams buy an “agentic” integration to fix a service page that simply lacks a clear answer, or they let an assistant infer permission from a page visit.
Readable content can earn consideration. Only a confirmed action can create an order.
Make one important page a reliable source of truth
Start with a page that influences an enquiry, not the whole website. A service page is often ideal because the customer needs to judge fit before contacting you. Read it as if you are an assistant with no background knowledge of the business.
Can you answer these questions using only the visible page?
- Who is the service for, and what is outside its scope?
- Which locations, industries or platforms does it actually cover?
- What does the engagement include, and what happens first?
- Which claims can change, and who maintains them?
- What is the correct next action for a customer who is ready?
If the answer lives only in a sales deck, an image, a hover state or a private conversation, the website is a weak source. Put the essential fact in the page text. Link to deeper evidence where the decision needs it. Use structured data where it accurately describes the visible content, but do not expect markup to rescue a vague page. Google’s published guidance explicitly calls for important content in textual form and structured data that matches what users see.
This is also a publishing governance task. An offer can be correct when written and wrong after a staffing, pricing or policy change. Give each changeable claim an owner and a trigger for review. If a business cannot answer who updates a public promise, no amount of AI-specific markup will make that promise dependable.
Velacore’s own site illustrates the architectural point. Marketing pages and WordPress articles can have separate publishing systems while sharing one public domain and clear internal links. The assistant does not care which editor created a page; the visitor cares whether the facts agree and the next step works. The same principle applies if your business uses a headless CMS, a static site or a conventional CMS.
Should you build an API for AI agents?
Usually, a business should improve the public page before building an agent-specific API. A small service firm with an enquiry form gains more from accurate service scope, accessible page text, working contact paths and current evidence than from exposing a new machine interface nobody has asked to use.
An API becomes useful when a third party needs live, structured data or an authorised transaction that a static page cannot safely supply. Think of real-time inventory, appointment slots or order status. Even then, define what a caller can read, what requires identity, what requires customer approval, how duplicates are prevented and how the business confirms the result. The API is an extension of the business system, not a substitute for the page that helps a customer decide.
If a vendor promises “AI agent readiness” through a file, tag or bot alone, ask what customer task it improves and what evidence will show that improvement. Google’s guidance says a new machine-readable file is not required to appear in its AI Search features. OpenAI describes separate bot controls for search and training. Those facts do not rule out useful specialist integrations; they rule out treating a fashionable file as the strategy.
Measure the hand-offs, not one blended AI number
The measurement plan should follow the journey. These signals answer different questions:
- Access: can search crawlers and user-requested fetches reach the intended pages, or are robots and CDN rules blocking them?
- Discovery: are important pages indexed, visible for relevant queries or cited where the platform provides that data?
- Human response: do referred visitors read the right page, enquire and become qualified opportunities?
- Action quality: if an assistant can submit a request, was it authorised, validated, deduplicated and confirmed?
Do not turn a bot spike into a conversion report. Search Console, analytics, server logs and the customer relationship system each see only part of the journey. Some platforms may expose citations without a click; others may pass a referral that analytics can record. A later direct visit can still be influenced by an earlier answer without giving you a clean attribution label. If you need a deeper measurement method, our AI assistant traffic guide explains how to keep visibility, visits and qualified leads on separate lines.
For a first pass, pick one high-value page and record its present state: indexed or not; clear service answer or not; current claims with an owner or not; working enquiry flow or not. Improve those facts, then watch the signals over time. The point is to learn which hand-off breaks, not to manufacture an “AI visibility score”.
The next useful move is a one-page audit
You do not need to rebuild a website because an assistant can read it. Choose one page tied to a real customer decision and apply the read, verify, act test. Make the offer and scope unmistakable, check the changeable promises against a named source, and run the contact path as a customer would. Then look at access, discovery and enquiries separately.
If the page cannot explain the offer to a human, it will not become reliable merely because a machine can parse it.
Velacore can help connect SEO and AI search with the website content and conversion path behind it. If you want a review of a specific page and its hand-offs, contact the team.
Questions business owners ask next
Will AI agents replace business websites?
They can change how customers discover and compare businesses. The website still provides the public facts, evidence and customer-facing action path. A useful strategy improves those foundations and treats assistants as another route into them.
Do I need an llms.txt file to appear in Google AI Overviews?
No. Google’s AI Search documentation says ordinary Search eligibility applies and no additional AI text file or special schema is required. A curated file can be useful for other purposes, but it is not a Google inclusion requirement.
Should I allow every AI crawler?
Decide by purpose. OpenAI, for example, separates search discovery from training and user-requested visits in its bot documentation. Review your goals, robots rules, CDN controls and server logs before applying a blanket rule.
Can an assistant submit my contact form?
It can only be treated as a valid customer request if the user authorised the action and your form or backend accepts it under normal validation, consent, anti-abuse and confirmation rules. A page fetch or generated answer is not an enquiry.