How to get your website ready for A2A in 2026

A growing share of the visitors to your site will be agents working for someone else. A founder asks Claude to shortlist content tools, and a buyer's assistant compares suppliers before anyone books a call. Neither of them scrolls your homepage. They read what your site serves to machines, and increasingly they talk to other agents to get the job done.

A2A is the standard for that second part. Search for how to prepare your website for it and you'll be told to drop a JSON file at your root and call it done. That file describes an agent. If you don't run one, it describes nothing, so the work starts somewhere else.

What A2A is, in plain terms

Google introduced the Agent2Agent protocol in April 2025. It defines how a client agent, which can be an app, a service, or another agent, delegates work to a remote agent that takes the request, runs the task, and reports back. The project now lives in the open under the a2aproject organisation on GitHub.

It grew up fast. Version 1.0 is the first stable specification, and at its one-year mark the Linux Foundation reported more than 150 supporting organisations, with support built into Google, Microsoft, and AWS platforms. In August 2026 it was accepted into the Agentic AI Foundation, the same home as the Model Context Protocol.

MCP is how one agent uses tools and data, and A2A is how agents find each other and split up the work. Picture MCP as the agent's toolbox and A2A as the switchboard between agents. Your website can plug into both, at different stages.

Start by working out which kind of site you run

Before you touch a file, put your site into one of three buckets.

• A content site, such as a blog, a portfolio, or a services brochure. Agents read it and act elsewhere, so you need the readable layer.
• A site with actions, like bookings, stock levels, quotes, or a checkout. Agents will want to do things here, so you need the readable layer plus a way to take those actions.
• A site with an agent behind it, whether that's a support assistant, a booking agent, or a research agent your customers already talk to. This is the bucket where A2A and the Agent Card come in.

Every bucket builds on the one before it. Skip ahead and you end up with an Agent Card pointing at a chatbot that can't take a task, which tells the agents reading it that your site is unreliable.

Step one: make every page readable by agents

Agents read text. Navigation, cookie banners, and client-side JavaScript all eat into the context window before your content shows up, and sometimes the content never shows up at all. While researching this post I tried to read a shared Gemini conversation with two different fetchers. Both came back with a sign-in link and nothing else, because the page builds its content in the browser. An agent sent to that page would have left with the same nothing.

Three fixes cover most of it.

Serve an llms.txt file. The llms.txt proposal puts a markdown file at your site root that gives agents a curated map of your site. The only required element is an H1 with the site's name, followed by a short blockquote summary and H2 sections listing your key URLs with a one-line note each. Note the spelling: it's llms.txt, plural, even though some AI summaries call it llm.txt.

Offer markdown versions of key pages. The same proposal recommends a clean markdown copy at the page's own URL with .md added. We do this on our own site: contengi.com/llms.txt maps the site, llms-full.txt holds the full product documentation in one file, and any page works as markdown with .md on the end.

Render content on the server. If your words only exist after JavaScript runs, any agent that doesn't run JavaScript never sees them, which is exactly what happened to both of my fetchers. Check the raw HTML of your top pages and make sure the copy is in it.

Step two: describe what you sell in structured data

Scraping a page for a price is guesswork. Structured data removes the guess. Add schema.org markup as JSON-LD for the things an agent will ask about, starting with your Organization, your Products and Offers with their prices, your Services, opening hours if you're a LocalBusiness, and your FAQs.

Two rules keep it useful. The markup has to match what's on the page, and the facts agents need, such as price, availability, and hours, should sit in plain text without a click or a login in the way. If an agent compares three suppliers and only two show a price, yours is the one it can't recommend.

Step three: expose the actions you want agents to take

If customers book, buy, or request quotes, their agents will want to do the same. That needs an interface built for machines: a documented API, or an MCP server that wraps it so any MCP-capable assistant can call it.

For a small team this is often the right stopping point. Contengi runs as an MCP server, and our users' own Claude calls our tools directly, with no A2A in the middle. A2A earns its place once your side of the conversation is an agent that plans, runs a task over minutes or hours, and reports back.

Step four: publish an Agent Card when there's an agent to describe

The Agent Card is how A2A discovery works. In the current specification a client fetches it from /.well-known/agent-card.json on your domain, reads what the agent can do and how to connect, then sends it a message. Older tutorials, including Google's own A2A codelab, still point to /.well-known/agent.json from earlier versions, so check which version a guide was written against before you copy it.

The card is a JSON document. It names the agent and its provider, gives a version and a description, lists its skills, declares capabilities such as streaming and push notifications, names the interfaces it speaks (version 1.0 defines JSON-RPC, gRPC, and HTTP+JSON bindings), and states the security schemes a client must use. Servers must reject requests with missing or invalid credentials, so declare your auth before you publish. Version 1.0 also adds signed Agent Cards, so a client can verify the card came from you.

A few habits save pain later:

• Write skills the way a customer would ask for them, with examples, because another agent matches on them.
• Switch on only the capabilities you've built and tested. Streaming can wait.
• Run the card through a validator before it goes live, then fetch it from outside your network to confirm it's public.

A readiness checklist for this quarter

• An llms.txt at your root, with an H1, a summary, and your key URLs
• Markdown versions of your most important pages
• Core copy present in the raw HTML
• JSON-LD for your organisation, products or services, and FAQs
• Prices, availability, and hours in plain text
• A documented API or an MCP server for any action a customer takes
• An Agent Card at /.well-known/agent-card.json, only if an agent sits behind it, with authentication declared

Where to start this week

Pick the first unchecked box and do that one, its the step every other step builds on. The readable layer pays off whether A2A traffic reaches you next month or next year, because every assistant already reading the web benefits from it today.

Then watch what changes. If you want to see whether ChatGPT, Claude, Gemini, Perplexity, and Grok mention you once agents can read your site properly, that is what LLM tracking is for, and our guide to AI visibility covers the content side in more depth.

FAQ

Is A2A still a thing in 2026?

Yes. Version 1.0 is the first stable specification, the Linux Foundation reported more than 150 supporting organisations in April 2026, and in August 2026 the project was accepted into the Agentic AI Foundation alongside MCP.

What is the difference between A2A and MCP?

MCP connects one agent to tools and data, such as an API, a database, or your files. A2A lets separate agents discover each other and hand work back and forth. A site can use both, with MCP to expose its actions and A2A once it runs an agent of its own.

Where does an A2A Agent Card go?

In the current specification, at /.well-known/agent-card.json on your domain, where a client agent can fetch it to learn what your agent does and how to connect. Older guides use /.well-known/agent.json from earlier versions.

Do I need an Agent Card if my website is just a blog or a brochure?

No. An Agent Card describes an agent that can take tasks. A content site gets more from an llms.txt file, markdown versions of its pages, server-rendered HTML, and accurate JSON-LD.

Is llms.txt part of the A2A protocol?

No. llms.txt is a separate proposal for giving agents a curated markdown map of your site. It helps any agent that reads your website, A2A or otherwise, which is why it's the first step.