Buyers ask an AI 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, because 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 never read a page at all, only your product feed. 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 a translation layer, not a ranking trick. 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. An implication does not survive extraction. "Fits Bosch GLM series" is usable; "perfect for your favorite 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 summarize 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 recognized 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 no system has a reason to quote you over 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, not 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.

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, 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. Attribute mapping is the detail that gets missed. A shade belongs in Schema.org's color field and a capacity in additionalProperty, because a crawler reads the field name, not your label for it. 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. 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. For most stores, then, blocking is the weaker position: it gives up presence and wins back nothing. Allow the crawlers that identify themselves, write the choice down, and revisit it as the terms change, because nothing about this is settled.

• 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 modeling, 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.