E-commerce SEO in the AI Era: Three Readers and Four Conflicts
How to redesign e-commerce SEO around three readers — people, Googlebot and AI crawlers. The foundations do not change, and there are four things to add. For the four places where SEO and AI pull in opposite directions — faceted URLs, lazy rendering, thin category pages and where reviews live — this guide sets out a rule for each. In our measurements, only about 25.1% of properties were ever named.
Key takeaways
- E-commerce SEO is now designed around three readers — people, Googlebot and AI crawlers. The largest divergence between them is how they handle JavaScript
- The foundations do not change. Index design, duplicate handling, internal linking and page speed all carry over. Nothing needs rebuilding, and there are four things to add
- In our measurements, only about 25.1% of properties in an area were ever named in AI recommendations. Before competing for position, there is a stage called getting on the list
E-commerce SEO now optimizes for three readers at once
Until recently, e-commerce SEO addressed two readers: people and Googlebot. A third has joined — AI crawlers.
All three look at the same page and read it differently. Design decisions became harder because their requirements sometimes conflict. Reviews rendered lazily for page speed look fast to people, are readable to Googlebot, and do not exist for AI crawlers.
People, Googlebot and AI crawlers read the same page differently
First, the differences.
| Reader | JavaScript | Unit of reading | What it evaluates | How it arrives |
|---|---|---|---|---|
| People | Executed | The screen — wherever the eye stops | Clarity, whether it looks trustworthy, whether buying is easy | Search results, ads, social, direct |
| Googlebot | Executed (it renders) | The whole page | Match to search intent, quality, links, speed | Crawling and indexing |
| AI crawlers | Not executed (raw HTML only) | The passage under a heading | Internal consistency, presence of sources, whether values are definite | Own crawlers, search indexes, product feeds |
The largest divergence is JavaScript. Googlebot renders, so it reads prices drawn by JavaScript. Major AI crawlers — GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot — do not execute JavaScript and read only the HTML that comes back. Google's own AI features are the exception, since they build on the Google Search index and can use rendered information.
That asymmetry produces the situation where a page ranking well in Google looks empty to ChatGPT. Our article on GEO for e-commerce covers it with measurements.
The foundations that do not change
Clear the worry first. Nothing needs rebuilding. Google states in its official guidance that existing SEO best practices remain effective.
Index design is unchanged. What you allow to be indexed and what you exclude still determines how the site is evaluated as a whole. Duplicate content handling is the same, and the standard practice of consolidating color, size and sort-order URLs with canonicals still applies.
Category structure and internal linking also carry over. Grouping related products and making them reachable from hub pages makes the relationships between items easier for AI to read, too. Page speed and mobile handling remain as important as ever, being tied directly to human experience.
Treat these as preconditions. New tactics built on a missing foundation do not work. Our overview of LLMO gives the full map.
Four things to add
Four additions sit on top of the foundation, each with a note on why the foundation alone is insufficient.
Put price, stock and main specifications in the initial HTML, because choosing lazy rendering as a speed tactic erases that information for AI crawlers
Pass definite values through structured data, because from body text alone AI infers whether a price includes tax and what stock means
Hand product data directly to Merchant Center and equivalents, because waiting for a crawl means price and stock changes take time to land
Comparison articles, review sites, press releases — because however well you prepare your own site, the grounds for a recommendation are frequently taken from outside evaluation
Implementation for the second is covered in our structured data guide, and the third in our product feed guide.
Where SEO and AI pull in opposite directions
This is where the practical difficulty lives. Four cases.
What to do with faceted URLs
The SEO orthodoxy is control. When filter combinations multiply URLs without limit, crawl budget drains and thin pages proliferate. noindex, canonicals and parameter handling were the standard answer.
But AI answers conditional questions — "a waterproof vacuum under 50,000 yen". A page collecting the products that match a set of conditions is a useful source. Suppressing all of them closes that route yourself.
The rule: keep the combinations with real demand as static listings and control the rest. Choose combinations of up to two axes that have search demand and build them as independent pages. Three or more axes, and combinations without demand, stay controlled as before. Setting a threshold keeps the judgment out of individual hands.
How much lazy rendering to allow
Rendering reviews and specification tables lazily for page speed is common practice. From an AI's point of view, whatever is rendered lazily does not exist.
The rule: decide the priority of what goes into the initial HTML. Price, stock, main specifications and a review summary belong in the initial HTML. Full review listings, related products and browsing history can be deferred. Draw the line at "would AI use this in an answer". If the things customers ask about are in the initial HTML, that is enough.
More category pages, or fewer
Mass-producing thin pages invites crawl suppression. We experienced this ourselves. In June 2026 our own indexed page count fell from roughly 1,000 to 787. The cause was not a technical fault but crawl suppression following a run of thin daily articles.
The rule: make "does it carry original information" the single criterion for creating a page. A page that merely reorders products carries none. If you can write the selection criteria, comparison axes and pitfalls specific to that category, build it; if you cannot, do not. A criterion like this survives a change of owner.
Collect reviews on your own site, or off it
Third-party evaluation carries weight in AI citations. At the same time, your own product pages need reviews to be informative. Which takes priority?
The rule: both — but manage them separately, because they behave differently. Structure your own reviews so they are machine-readable and use them as product page information. Treat external reviews as an acquisition program with its own target list and outreach. Handing both to one person as "the reviews project" means only one of them progresses.
Working with the major platforms
Take Shopify as the example. How much a theme renders in JavaScript varies substantially, so open a product page with JavaScript disabled first. Themes where the price disappears do exist.
Most stock themes emit Product and Offer JSON-LD, but GTIN, brand and priceValidUntil are frequently empty. Check what is actually emitted with the Rich Results Test and fill the gaps in the theme template.
URL structure is fixed at /products/ and /collections/ and cannot be changed. Accept the constraint and build the information relationships through collection design instead. Feed integration generally runs through an app.
The checks are the same on other platforms: how much depends on JavaScript, what schema ships by default, how feeds integrate, and how much freedom you have over URLs. Setting names and screens change between versions, so verify on the actual system when you start.
Priorities on a large catalogue
You cannot treat 100,000 products identically. Set a priority.
This is where results show up as revenue soonest. Fix the initial HTML and structured data for the top 20% first
Products that get compared with conditions attached. Choose categories with many axes — size, compatibility, use case
This is a freshness problem, so solve it through feed update frequency rather than per-page work
Many businesses are not even on the list
Before talking about position, look at the stage before it.
In our study of AI recommendations for accommodation in Hakone, 114 properties appeared across the recommendations. The town has 454, so the share ever named was about 25.1%. Three quarters were never named as candidates at all.
In the Okinawa study, the top five properties accounted for 44.2% of all recommendations — recommendations concentrating on a small set.
The same is likely happening in e-commerce. Before competing for position, there is a stage called getting onto the list. And the requirements for entering the candidate set are far more basic than those for improving a position: information readable in the initial HTML, no internal contradictions, a name present on third-party surfaces. Everything this article covers applies directly.
Designing the measurement
Add AI metrics to your existing SEO metrics.
The existing side — impressions, position, traffic, conversions — stays. What gets added is mention rate (how often you appear across your defined prompts), recommendation position (where you land when you do), and AI-referred traffic.
Two instruments. The generative AI performance report in Search Console separates AI Overviews and AI Mode impressions from ordinary organic search; only impressions are available for now. GA4 needs a channel configuration, without which AI referrals are absorbed into "direct".
To work through this as a process, see the ten steps for AI search; to work through it as an audit, use our 22-item checklist.
Frequently asked questions
No. Index design, duplicate handling, internal linking and page speed all continue to work. Google states officially that best practices remain effective.
Product pages. What AI cites is specific product information, while category pages get used in comparison contexts. Start with your best-selling product pages.
Not if key information is in the initial HTML. Emitting only price, stock and main specifications server-side is a partial fix that still works.
No. Choose combinations of up to two axes with search demand, build those as static listings, and control the rest as before.
Marketplace listings are managed by the marketplace, which limits what you can fix. When AI answers name the marketplace but not you, work on your own site is what changes it.
Clearing a technical fault can change answers within weeks once pages are re-fetched. Accumulating third-party evaluation takes months. Each layer runs on its own clock.
Summary
E-commerce SEO is now designed around three readers. The foundations hold, and four things get added: server-side output of key information, machine-readable product data, a product feed, and mentions on third-party surfaces.
Where the requirements conflict, set a rule. Facets up to two axes with real demand; lazy rendering drawn at "would AI use this in an answer"; category pages only where original information exists. With rules written down, the design survives a change of owner.
And there is a stage before competing for position. In our measurements, only about a quarter of properties were ever named. Getting onto the list comes first, and the requirements for that are the basic ones covered here. We offer a free AI visibility assessment for retail and e-commerce businesses.
