The website becomes the infrastructure

If your commerce architecture assumes the customer starts on the homepage, it has a very specific idea of how the internet works.

Search. Social. A marketplace. A link from a friend. An AI assistant answering a question about a jacket. None of those starting points owes you a trip through the navigation.

My take is that the website becomes one interface among many, while the commerce capabilities behind it become more important. That is an architectural direction, not a claim that every retailer has the same channel mix or that websites are about to disappear.

We have declared the death of the website enough times. I would rather talk about what it has to do next.

What becomes infrastructure, exactly?

The website is not the inventory system. The product page is not necessarily the product master. A shipping paragraph in a CMS should not become the authority for calculating a customer’s delivery charge.

When I say the website becomes infrastructure, I mean the capabilities historically assembled behind it need to serve other experiences too: product information, pricing, availability, eligibility, delivery, returns, and a safe path to transact.

Those facts may belong to a PIM, commerce engine, OMS, ERP, or another system. A new channel needs a usable contract with those capabilities. It should not have to scrape the storefront and reconstruct the business from whatever the page happened to display.

This is broader than replacing a frontend. A headless commerce decision can separate presentation from a platform and still leave business rules scattered everywhere.

Three answers to one shipping question

An audit of my Après Studio demo on September 5, 2026 found a small, very teachable problem. The homepage and cart advertised a $150 free-shipping threshold. The shipping policy said $50. Juniper, the shopping assistant, initially answered from that policy.

Which number was right?

The visible test could establish the disagreement. It could not establish the intended commercial rule. The assistant had a source. The shopper had a different source. Better prose would not resolve the contradiction.

This is a demo defect, not a customer conversion study. But it shows exactly what happens when we make an assistant responsible for explaining a business whose surfaces disagree.

I would fix the ownership first. Decide which policy applies, in which market, to which basket. Make the operational rule authoritative. Then reconcile the banner, cart, policy content, and assistant answer with it. If the assistant cannot establish the applicable rule, it should say so.

Adding another channel before doing that gives the disagreement another place to live.

Separate the rule, the explanation, and the channel

These are three different jobs:

• The rule determines eligibility, price, availability, and the permitted transaction.
• The explanation makes that result understandable to the customer.
• The channel determines how the explanation and action are presented.

A promotion should not change because the shopper switched from the website to an assistant. Its explanation may get shorter. Its eligibility must still come from the same governed logic, evaluated for the relevant customer and cart.

That does not require one enormous enterprise API or a platform replacement. Start with a bounded capability that is currently duplicated. Shipping eligibility is a good candidate. So is a product’s sellable variant.

Name the owner. Define the inputs. Return both the result and enough context to explain it. Decide what happens when the answer is unavailable or stale. Then replace the duplicate interpretations one at a time.

What do search engines and agents need from product data?

They need distinctions a human might infer from the page: the product family versus the purchasable variant, color versus marketing name, current offer versus old campaign copy. An image of a black jacket does not establish that black in medium is available.

For search, Google’s product-variant guidance uses ProductGroup and related Product entries to express the relationship between a product and its variants. That is useful machine-readable context. It is not a reservation or permission to charge the customer.

Discovery data and transactional truth have different freshness requirements. A searchable description may change infrequently. The final price and stock position need validation at the point where the system makes the relevant commitment.

Do the same work for policy. Put the scope, exclusions, currency, and effective rule where they can be found and maintained. A beautifully written returns page is of limited use if nobody can tell whether it applies to the item in the bag.

Follow one promise across the stack

I would not begin this work with a channel transformation program. Pick one product and one customer promise.

Follow the variant, price, stock state, shipping charge, and return conditions from search or an external link through the product page, assistant, cart, and order handoff. Record every disagreement. Find the owner of each answer. Fix the most consequential one before broadening the exercise.

The OMS is part of that customer experience, even if the customer never sees its name.

The homepage can still be beautiful. It just cannot be the only place the business makes sense.