How I prepared my website for AI agents

1. Three AI models, three incomplete pictures

I gave GPT, Gemini and Claude the same task: check what a website needs to be ready for AI.

• GPT gave a good framework: AI that searches and an agent that performs tasks need different things. But it did not mention MCP at all, nor Bing, multilingual setup or GDPR for the server.
• Gemini listed outdated bot names, mistook the Google-Extended token for a crawler, and confused agents with an in-house chatbot backed by a vector database. It did not mention GDPR.
• Claude was the most concrete on MCP and the catalogue, but its first plan left out the basics: favicon, Search Console, Bing, x-default and translations of the privacy policy. It also suggested the wrong schema for the questions.

It took several days to settle the right structure, content sections and required files. During implementation many more errors and gaps turned up, which I fixed and filled in as I went. Of course I recorded every path and decision, so next time will be easier. The new standards (MCP Server Card, Content Signals, markdown for agents) only showed up through Cloudflare’s scanner isitagentready.com. None of the models mentioned them.

Key point: an AI model is a good helper, but it is still far from being a check on the work, let alone an implementation partner. I am glad that even the standards for a simple website are changing so fast with AI that people will be needed to build proper websites for a while yet, never mind more complex software. Without AI models, though, everything is considerably harder and slower.

2. What I had to prepare before I started

Content

• Questions from real conversations with customers, not from keywords. Every answer is a real answer to a customer. This matters because Google and AI search engines favour content that adds something new.
• Prices as ranges, with the factors the price depends on. Without published prices, AI cannot answer a pricing question with your data.
• Translations into EN, DE and HR, reviewed before publication. The translations were machine-made, and confabulated errors or misinterpretations often slip in, even when the translation is done in context in the same conversation with the model.
• A list of terms that must never appear anywhere, such as client names.

Legal details

• Data from the business register for the legal notice and structured data.
• Terms of use and a privacy policy for the MCP server.

Access

• DNS, server, code repository.
• A Google Cloud project with the Calendar and Gmail APIs for bookings.
• Google Search Console, Bing Webmaster Tools, identity verification with OpenAI.

Decisions

• Are crawlers that train models welcome? In my case, yes.
• Where do the links for bots go? Bots don’t care, so I put them in the footer, not the menu.
• What is logged, and for how long?

Key point: visibility still depends on how human the content is. Formalising before implementing is Operative Intelligence’s motto anyway.

3. What the site has now, layer by layer

• Questions and answers: each question has its own page in four languages, with a date. The first sentence is a direct answer.
• Catalogue (catalog.json): one source for services, prices, questions and booking. Everything else is generated from it, so an agent never gets different data than a person.
• Structured data: the company, the author and each question as a separate entity.
• llms.txt: an overview of the site for language models.
• MCP server: an assistant (Claude, ChatGPT, Gemini) can ask directly about services, prices and answers. The server has no model of its own and returns only what is published.
• Booking through an assistant: the assistant shows free slots and requests a booking, but only with the user’s explicit consent. The booking is valid only once the user confirms it by e-mail.
• Agent Card and MCP Server Card: descriptions for other agents of what the server can do.
• Content Signals and markdown: the site states what AI may do with the content and returns an easier-to-read version to agents.
• Search engines: a sitemap covering all languages, Search Console and Bing.

Key point: one data source, many outputs. Without it, the site, the catalogue and the MCP server drift apart sooner or later.

4. What an MCP server in the EU needs

1. Separate terms of use and privacy policy for the MCP server, in every language of the site.
2. A controller with name, address and registration number.
3. Data minimisation: the server does not receive the conversation and does not store the search query.
4. Logs without IP addresses, with limited retention.
5. A stated legal basis, processor and hosting location.
6. For actions (e.g. a booking), explicit consent and confirmation by a person.
7. A clear boundary: the assistant’s provider is responsible for the conversation, not you.
8. A statement that answers are not an offer and that the content of the site prevails.

In my assessment, the AI Act does not apply directly to a server like this, because it has no model and is not an AI system. GDPR does apply.

Key point: keep the public part read-only, and every action subject to consent and human confirmation.

5. What is hype and what is not

• There is no button that guarantees AI will recommend you.
• llms.txt does not help with Google. It is cheap, but don’t sell it as a solution.
• The new standards are still rare: according to Cloudflare’s analysis in April 2026, fewer than 15 sites had an MCP Server Card; by the end of May, another source counted around 122 domains. The early-adopter advantage is real, but small.
• What works: good indexing, concrete answers, mentions on other sites and presence in MCP server directories.
• What not to do: hidden instructions for AI on the page, or mass-generated subpages.

Key point: the standards need constant monitoring, because they are changing a lot right now. That makes the basics all the more important.

6. What a company must prepare if someone else does this for them

1. Customer questions, problems and suggestions from e-mail or sales, and a person who approves the answers.
2. A valid price list or ranges, and rules on what may be published.
3. Legal details and a person for legal review.
4. Access: DNS, hosting, CMS or repository, calendar, Search Console and Bing.
5. A decision on what an agent may do: only read, book, or submit an enquiry.

Key point: what you put in is what you get out, to put it politely. A site is still only as good as its content. A good web developer knows what to ask the client for; a poor one works with whatever they get, and the result shows it.

7. Two levels: AI-ready and agent-ready

• AI-ready: AI finds you, understands you and cites you. This is content, structured data and indexing.
• Agent-ready: an agent gets something done with you, e.g. checks a price or books a slot. This is the catalogue, the MCP server and the rules for actions.

Most companies need the first level first. The second makes sense once you have an action a customer actually wants to complete through an assistant.

Key point: everything is moving towards automation with agents, so it makes sense to prepare your site for what is coming, level by level. My next step is content plugins for every model that supports them.