Buyers ask an assistant before they ever reach your store

The change is not that people stopped searching. It is that more questions get resolved before anyone lands on a page: a system reads several sources, forms a summary, and presents a short list. Your store is either one of the sources that summary was built from, or it is not. Nothing in that process rewards clever copy. These systems look for facts they can state without hedging — what the product is, what it fits, what it costs, whether it is in stock, how returns work. A page written purely to persuade a human, with the specifics scattered across tabs, images and a downloadable PDF, gives a machine very little to work with. A page that also states its facts plainly gives it a lot, and costs you nothing with human readers.

Treat every AI surface as a reader with limited patience and no hands. Some crawl and render pages much like a search engine, some rely on an index built by someone else, and some consume product feeds rather than pages at all. What they consistently struggle with is anything that exists only after interaction: a spec table behind an accordion that fetches on click, a size chart in a modal, a variant price that appears only after two dropdowns are set, review text loaded on scroll. If a fact matters to the buying decision, it should exist in the HTML that arrives with the page, not only in the interface. That is one of the quieter arguments for a server-rendered storefront: what a person sees and what a machine reads are the same document.

• In the HTML on load: names, specs, price, stock and policies
• In structured data: the same facts, stated machine-readably
• In your product feed: the version shopping surfaces actually read
• Usually invisible: anything that appears only after a click

Structured data is not a ranking trick, it is a translation layer. Schema.org's Product vocabulary, and the fields Google documents for product structured data, let you state price, currency, availability, GTIN or MPN, brand, shipping and return details in a form that needs no interpretation. Beyond the required fields, the ones that decide real purchases are the boring ones: dimensions, material, wattage, thread size, what the item is compatible with, how the sizing actually runs. Write those as explicit statements rather than implications. "Fits Bosch GLM series" is usable; "perfect for your favourite tools" is not. The same discipline improves conventional organic search, which is the more measurable half of the benefit and the reason this work pays for itself even if assistants never send you a single visitor.

Contradiction is the fastest way to be left out of an answer. If your site calls it a "Model 4 Pro Cordless", the feed says "4-Pro Cordless Drill", a marketplace listing says something else again, and the price differs across all three, a system trying to summarise your product has no way to tell which record is authoritative. It will either pick one at random or prefer a source it trusts more than you. Identifiers exist precisely to solve this: a stable GTIN or MPN, one brand string, one title pattern, so separate records can be recognised as the same object. Google Merchant Center's product data specification is a reasonable template for which fields to keep aligned, even for a store that never runs shopping ads.

• Same title pattern on the site, in the feed and on marketplaces
• Stable identifiers: GTIN or MPN, one brand string, one SKU scheme
• Prices and availability that agree across every published source
• One canonical URL per product, not a maze of variant pages

If your description is the manufacturer's paragraph, so is everyone else's, and there is no reason for any system to quote you rather than the other forty stores carrying the same SKU. Your differentiator is knowledge the manufacturer never wrote down: which of the two versions people usually order, what it explicitly does not fit, what arrives in the box, what first-time buyers get wrong. Put those answers on the product page in plain language, near the point where the question arises rather than in a support article three clicks away. Real customer questions make good headings. A page that answers "will this fit a 2018 model" in a sentence a machine can lift is more useful than a page that answers it inside a chat widget — and it serves the human reading your product page just as well.

None of this requires leaving WooCommerce. Products, stock, prices, variations, coupons, orders, tax and shipping rules, payment gateways and the plugins your team depends on stay exactly where they are, and WordPress remains the place where someone edits a spec or corrects a price. What changes is the layer in front of it: how the storefront renders those facts into HTML, what structured data each template emits, how WooCommerce attributes map onto schema fields, whether variant data is present on load, and whether the feed is generated from the same source of truth instead of maintained by hand in a spreadsheet. In practice the work is mostly attribute hygiene inside WooCommerce plus a storefront that publishes those attributes faithfully — one record, several honest outputs.

You do have control over access. OpenAI documents its GPTBot user agent, Google publishes the Google-Extended token, and other operators publish their own; robots.txt directives are how you allow or refuse each one. The trade-off deserves a clear head rather than a strong opinion. Allowing them means your products can appear in answers, and some of those answers will satisfy the shopper without a visit: visibility without a click. Blocking them means you get neither the visibility nor the click, and a competitor's data fills the space instead. Blocking also does nothing about content already copied or republished elsewhere. Most stores settle on allowing crawlers that identify themselves, documenting the choice, and revisiting it as terms change rather than treating it as permanent.

• Decide per crawler, using user agents the operators actually publish
• Allowing: possible presence in answers, plus sessions that never click
• Blocking: no presence, no click, no effect on copies already made
• Write the decision down and review it; the terms keep moving

Nobody can sell you a ranking inside an AI answer. There is no submission form, no verified placement, no reliable lever, and any agency quoting a guaranteed position in an assistant's response is selling something it does not control — treat that claim as a reason to walk away. Measurement demands the same honesty: referral data from these surfaces is patchy, often arriving as direct traffic or an unhelpful referrer, so a report showing precise "AI-sourced revenue" is modelling, not measuring. Judge the work instead by what is verifiable — valid structured data, feed and site agreement, questions answered on the page, and conventional organic performance. This is also the wrong project if your records are already clean and the real problem is a slow site, thin traffic or a price nobody wants; in that case spend the budget elsewhere first.