How to Make Your Website Agent-Ready (Before AI Buys Without You)

Picture a customer who never sees your homepage. They never read your reviews, never notice your hero video, never click a single CTA you spent three weeks refining. They tell an assistant "find me a rugged 15-inch laptop backpack under ₹6,000 that ships in two days," and something else does the shopping — searching, comparing, checking stock, and in a growing number of cases, completing the purchase outright.

That customer is already real. In 2026, agent-driven buying stopped being a demo and started producing revenue. Which means the first entity evaluating your business is increasingly not a person but software acting on a person's behalf. If your product data, pricing and checkout are not machine-readable and machine-callable, you are not losing the comparison — you are not in it.

This post covers what changed at the protocol layer, the four things that actually make a site agent-ready, and the work most teams get wrong.

The protocol stack you need to understand

Three standards emerged in quick succession, and they are not competitors. They stack.

UCP (Universal Commerce Protocol) answers what you sell and how a cart gets built. It was co-developed by Google and Shopify and announced in January 2026 at the National Retail Federation show, with Etsy, Wayfair, Target and Walmart among the co-developers and more than twenty companies endorsing it at launch. It is designed as a full commerce standard covering discovery through post-purchase, modelled loosely on TCP/IP layering, and it is protocol-agnostic — it supports REST, MCP, A2A and AP2.

ACP (Agentic Commerce Protocol) answers how the transaction executes inside an AI surface. Maintained by OpenAI and Stripe, it powers ChatGPT's Instant Checkout: the agent queries your ACP endpoint, and if there is a match, a buy action appears directly in the conversation. The consumer never leaves the assistant.

AP2 (Agent Payments Protocol) answers who authorised this spend. Google's protocol represents every agent purchase as three digitally signed mandates — an Intent Mandate for what the user asked for, a Cart Mandate for what the agent assembled, and a Payment Mandate for what actually gets charged. That signature chain is what makes the transaction disputable and auditable later.

A complete agentic purchase typically uses one protocol to transact and another to prove authorisation. The card networks have already built for that reality: Visa shipped a protocol-agnostic on-ramp in April 2026 that accepts agents across multiple standards simultaneously, and Mastercard runs its own agent acceptance framework. Adyen launched a modular agentic API suite in June 2026.

The practical read for a business owner: you do not need to bet on one protocol winning. The acceptance layer is converging. What you do need is the underlying data and endpoints that all of them require, because none of them can rescue a site with messy product data.

Step 1: Fix your product data before you touch any protocol

Every agentic standard assumes a clean, complete, structured feed. This is the least glamorous work and the highest leverage.

An agent cannot infer that "Blk / M" means black in medium. It cannot guess your delivery window from a shipping page written in prose. It will not click through three variant selectors to find out whether the item is in stock in Punjab.

What a machine-readable catalogue actually requires:

• Canonical identifiers on every SKU — GTIN, MPN or an internal ID that never changes across a re-platform
• Explicit variant attributes as separate fields, not concatenated strings
• Real-time inventory exposed per location, not a binary in-stock flag updated nightly
• Total landed price including tax and shipping, resolvable before checkout
• Return and delivery terms as structured data, because agents weight these heavily when ranking options If you sell services rather than products, the same logic applies to your offerings, pricing tiers and availability. The unit changes; the requirement does not.

Step 2: Publish a discovery surface

Agents need to find out that you speak their language. The emerging convention is a well-known path — UCP-capable merchants publish a profile at /.well-known/ucp, in the same spirit as A2A agents publishing capabilities at /.well-known/agent-card.json.

This is cheap to implement and it is the difference between being discoverable and being invisible to an entire class of buyer.

While you are in that layer, audit robots.txt. We have reviewed sites that spent heavily on content and were silently blocking the crawlers that feed AI assistants. Decide deliberately which agents you allow, then verify the decision matches the file.

One caution worth stating plainly, because a lot of budget is being wasted on it: Google published its first dedicated generative AI search guide in May 2026, and it explicitly listed llms.txt files and content chunking among the tactics it considers unnecessary. Structured data is not a requirement for AI Overviews. Publish structured data because it makes your catalogue usable by agents and shopping surfaces — not because a vendor told you it is an AI ranking factor.

Step 3: Make checkout callable, not just clickable

This is where most engineering effort lands, and where a full-stack team earns its fee.

Your checkout was built for a browser session: cookies, a rendered cart page, a form, a redirect. An agent has none of that context. It needs an API it can call, with idempotency, and a payment leg that produces provable authorisation.

The good news is the on-ramp is genuinely short if your stack is modern. ACP's specification is payment-processor flexible, and because Stripe was a founding partner, businesses already on Stripe can reach agentic checkout with far less integration work than a ground-up build. PayPal auto-enrolled millions of existing merchants for AI-surface acceptance in early 2026 with no technical lift required from the merchant.

What still needs deliberate work on your side:

1. Cart creation as an API operation — create, update, price, and validate without a session
2. Idempotency keys on every mutating call, because agents retry
3. Spending and scope limits enforced server-side, never trusted from the caller
4. Order lifecycle webhooks so the agent can report status back to the user
5. Event logging that captures the mandate chain, which is your evidence if a purchase is disputed That last point deserves emphasis. Delegated authority changes your liability picture. When a purchase was initiated by software, "the customer clicked buy" is no longer a defence you can produce. The signed mandate is. Log it, retain it, and make sure your dispute process can retrieve it.

Step 4: Decide what you expose beyond commerce

Agentic patterns are not limited to retail. Any business with a bookable, quotable or queryable service can expose an MCP server that lets an assistant check availability, retrieve a quote or file a request on a user's behalf. For a B2B software product, this is fast becoming a competitive requirement rather than a novelty — being callable inside the assistant your customer already lives in is distribution.

The engineering discipline is identical to the commerce case: a narrow, well-documented tool surface, hard server-side authorisation, and full audit logging.

What this costs you if you wait

The honest answer is that early adopters are not winning on volume yet. They are winning on positioning. Agent-initiated purchasing is compounding month over month, and the merchants with clean feeds and callable endpoints are the ones already appearing in those answers. The ones with a beautiful React site and a catalogue that only makes sense to a human are being skipped without ever knowing it happened.

There is no dashboard that reports "you lost this sale because an agent could not parse your inventory." That is precisely why the gap widens quietly.

The short version

Agentic commerce turned real in 2026, and the standards layer — UCP for the catalogue and cart, ACP for the transaction, AP2 for provable consent — is converging fast enough that you can build against it without picking a winner. The work that matters is unglamorous: clean structured product data, a discovery endpoint at a well-known path, a checkout that is callable via API with idempotency and server-side limits, and logging that preserves the authorisation chain. Skip the tactics vendors are selling that the platforms have publicly called unnecessary.

If you want to know how much of this your current stack already supports, we run a fixed-scope agent-readiness audit that maps your product data, endpoints and checkout against the current protocol requirements and returns a prioritised build plan.