From product pages to product protocols

A product page is a conversation with a person who is already looking at your store. A protocol is a promise to anyone, including a machine, about how to ask questions and what shape the answers will take. Commerce is moving from the first to the second.

What a page assumes

A page assumes a human with a browser, patience, and context. It assumes they will scroll to find shipping information, hover to see a size chart and click through a cookie banner. None of that is written down anywhere. It is simply what everyone expects from a shop.

What a protocol states

A protocol writes the expectations down. It says: here is how you ask what this item costs, here is how you ask whether it is available in a given size, here is how you start an order and here is what a completed order looks like. The details can vary. The predictability is the point.

We have seen this pattern before. Search engines pushed merchants toward structured markup. Payments settled on a few standard flows. Each time, the merchants who adopted the shared shape early got reach they did not have to negotiate for.

What gets written down

It helps to be specific about what a protocol contains. Four things, in plain terms.

Questions. The set of things an agent may ask: the price of an item, whether a size is in stock, the delivery estimate to a given place, the return terms.

Answers. The shape each answer takes, so that a price always arrives as a number with a currency and not as a sentence.

Actions. The few steps that change state: add to cart, start an order, confirm it.

Errors. What the store says when it cannot do something, so that a failure is a message and not a silence.

What stays a page

Pages do not go away. A person still wants to look at a product, read the details and decide. A protocol sits beside the page and says the same things in a form a machine can use.

That is also why the two must agree. If the page says a jacket costs one price and the structured data says another, the agent has two answers and no way to pick. Keeping the two in step is the unglamorous core of the work.

A first step that costs little

For a store that has done none of this, the smallest useful step is to publish structured product data that matches the page, and to check that match regularly. It does not require a new platform. It is also the step that measurement can see, since an agent either reads the right price or does not.

An illustration

Here is the same question asked two ways. This is an illustration of the idea, not a real store.

As a page. An agent opens the product page, finds the word "Delivery", scrolls to a paragraph, and tries to work out whether "3 to 5 working days" starts at the order or at dispatch.

As a protocol. The agent asks for the delivery estimate to a given postcode and gets a date range, with the starting point stated.

The second is faster, and it is also checkable. If the date is wrong, the store can see it, and so can an agent's builder. With a page, a wrong guess is invisible.

A gradual shift

Nobody has to rebuild their store. The practical path is incremental: publish structured product data alongside every page, keep it correct, and expose the few actions an agent needs. Then measure whether an agent can use it.

Why measurement comes with it

A protocol that nobody tests drifts. Prices update in one place and not another, a field gets renamed, a checkout step is added. Conformance tooling and public benchmarks exist to catch that drift. They turn a vague claim of agent-friendly into a result a merchant can check.