Most merchant websites are built for humans, and to some extent for Google. Pretty product pages, plenty of marketing content. An AI crawler doesn’t care about any of that. To a machine deciding whether it can stake a recommendation on your catalogue, most of it is noise.
So what does the destination look like — a store that AI engines can read, trust and cite? Here’s the anatomy, piece by piece. Use it as a checklist.
Discovery files at the root — mostly already there
This part of the anatomy has changed, and it changed in the merchant’s favour. Shopify now serves llms.txt, llms-full.txt and agents.md at the root of production stores by default, with agents.md declaring itself the canonical agent-facing file and the other two mirroring it. The platform settled the protocol argument; you are unlikely to be creating these files.
Which leaves two jobs that are actually yours.
- robots.txt — advertise the sitemap so any crawler hitting the root knows where to start, and allow the citation bots you actually want reading you. Blocking the wrong agent here quietly removes you from the answer.
- agents.md — fill it. The default template is byte-identical across stores, with only the shop name and domain substituted in: no product authority, no brand voice, no curated answers. A clothing brand, a supplements brand and a homewares brand all ship the same file on day one.
Whatever your platform serves, these files must agree with each other and with the visible site. A discovery layer that contradicts itself is worse than none. And note what they are: signposts to your real pages. They are not a place to publish a second version of your catalogue.
A catalogue feed on your own domain
Mirroring the XML sitemap: stable, predictable URLs listing every product with last-updated timestamps. Machines reward predictability; a feed that lives on your own domain keeps the authority yours.
Products that answer at every depth of intent
Shoppers ask at three depths — broad (“I need a new pair of slip-ons”), mid (“waterproof leather slip-ons for travel”) and ultra-specific (“premium slip-ons, vegan-leather upper, arch support”). A GEO-optimised product page carries content for each depth: an overview paragraph, structured attributes, honest pricing and availability, usage guidance, FAQs, breadcrumbs, and the full JSON-LD an engine needs to ground a citation. Those depths are blocks on the product page, not destinations of their own. One page, answering the question however precisely it’s asked.
Not a parallel set of pages
It is worth saying plainly what is not in the anatomy, because an earlier version of this post recommended it.
A separate machine-readable surface — a /llm/{product}.md mirror of every product, or a set of AI-facing intent pages sitting alongside the real ones — looks efficient and is not. It splits your catalogue into two versions that immediately begin to disagree, it moves content away from the URL that carries your links, reviews and trust signals, and it asks a model to cite a page no human ever sees. That is the doorway pattern, and it does not hold.
Everything else in this anatomy lands on the canonical product page. One page, engineered so a machine can read it — not a second site built for machines.
Enriched schema on the human-facing page itself
Most platforms emit some structured data by default. The GEO-optimised version extends it — correct offers data, review and rating markup where it exists, FAQ blocks, discovery attributes — and, critically, keeps it identical to what the visible page says. A crawler arriving directly at the product URL must get the same picture as one that came in via llms.txt. Schema that drifts from the page is a trust-destroyer.
Collection pages that mirror it all at category level
Where products share intent, the collection page you already publish carries the same kind of structured data and grounding content at group level — so an engine asked “what’s the best vegan ketchup in the UK?” can land on a coherent category surface, not just one product.
A monitoring layer over the top
None of this is set-and-forget. Catalogues drift: prices change, products retire, a rewrite quietly contradicts a spec sheet. The final piece is high-frequency checking — findings with severity, tied to the specific page or element that triggered them, rolled into a coherence score with history so you can watch it move. Plus external tracking: querying the major AI engines on a schedule against the prompts that matter for your brand, recording whether you’re cited, whether competitors are cited instead, and where the content gaps sit.
The point
That’s the destination. What your platform lets you ship determines the path — Shopify and WooCommerce each have their own routes — but it doesn’t change what the picture looks like. Every piece serves the same goal: when an AI reads your store, it finds one consistent, structured, checkable story about what you sell and who it’s for.
Building and maintaining all of this by hand is possible. Doing it across a full catalogue, and keeping it in sync as the catalogue changes, is what Geoffy is for. Optimise — the engineering layer — is generally available today on Shopify and WordPress / WooCommerce; Monitor and Influence are in early access.
See which pieces your store already has — and which are missing: get your free GEO Score.