Blog · By industry

AEO for marketplaces and aggregators, when the inventory is not yours

Published 21 September 2026 · Updated 8 October 2026 · 8 min read

AEO for marketplaces and aggregators, when the inventory is not yours
Photograph: Catherine Zaidova / unsplash

The short answer: AEO for a marketplace or an aggregator is mostly a question of identity and scale, not writing. The engines need to work out who is actually selling the thing on your page, and they need to reach the handful of pages worth reading out of the millions you generate. Get the seller identity wrong and your richest markup is ineligible. Get the crawl shape wrong and your best listings are never fetched at all.

None of this is about tone of voice. In the marketplace audits we have run, a clean feed and a sane URL space have mattered more to whether a page gets cited than the quality of the prose on it. That is a pattern from a small number of engagements, not a measured law.

Two businesses sharing one word

A marketplace takes the order. Money moves through it, the buyer checks out on it, and the seller is a third party operating inside it. An aggregator does not take the order. It compares, it ranks, it sends the buyer somewhere else to transact. Price comparison sites, travel metasearch, lender panels and job boards all live here.

The distinction sounds like legal trivia. It decides which structured data you are allowed to claim, which is the biggest technical fork in this work. It is also why the generic advice in AEO by industry: where the work differs stops being generic the moment a third party owns the inventory.

The eligibility line that governs your markup

Google separates two product experiences. Merchant listings are for pages where the visitor can actually buy. Product snippets are the lighter treatment for pages that discuss a product without selling it. The documented difference in markup is small and consequential: a merchant listing requires an Offer, because the page is expected to be the seller, while a product snippet will also accept an AggregateOffer.

So an aggregator that renders fourteen merchant prices and links out to all fourteen is not a merchant listing page. Marking it up as one does not make it eligible. The honest markup is AggregateOffer, which exists for exactly this case: lowPrice, highPrice, offerCount and a set of nested offers, defined by schema.org as a subtype of Offer for when one product carries several sellers.

Marketplaces sit on the other side of that line, and usually qualify, but with a catch worth naming. The required Offer fields are price and priceCurrency in ISO 4217 form, and the price has to be above zero for the merchant treatment. A listing page that renders "Price on request", or that shows a seller-set price only after a size is chosen, fails quietly. Nothing on the page itself says so, and nothing in your own analytics will; the place the problem surfaces is Google's own rich result reporting, if someone is reading it.

Run the check on your worst pages, not your best ones. The homepage of a marketplace is rarely where this breaks.

Feeds know the difference even when your site does not

The shopping surfaces are fed by product feeds, and the feed specs have grown fields specifically for the three-party case. OpenAI's commerce feed requires nine fields on every row: item_id, title, description, url, brand, seller_name, image_url, availability and price. Titles cap at 150 characters and descriptions at 5,000.

The marketplace-relevant field is marketplace_seller, which names the marketplace an offer is being sold through, kept deliberately separate from seller_name, the party actually supplying the offer. Two fields, two different entities, one row. Feeds that collapse both into the marketplace brand describe a world where the marketplace manufactures and sells everything it lists, and the engine has no way to tell that is false.

That collapse is the defect we have hit most often on the marketplace feeds we have audited. We have not kept a count across engagements, so read that as an impression from a handful of audits rather than a measured rate. What follows from it is inference, not observation: if every row names the same seller, the feed offers no per-seller entity to attach a reputation to, so corroboration about a specific seller has nothing in the feed to attach to. We cannot see inside an engine's entity resolution, so that is the mechanism the two-field split implies, not a behaviour we have watched happen.

Crawl budget is the constraint nobody budgets for

Marketplace URL spaces are generated, not authored. Filters, sorts, pagination, locale variants and session parameters multiply against each other, and the result is a URL count with no upper bound. Google's own guidance on faceted navigation is unusually blunt about the consequence: crawlers treat each faceted URL as novel, so they fetch an enormous number of them, and crawling spent on useless URLs is crawling not spent discovering useful ones.

Their recommended default is to disallow faceted URLs in robots.txt unless you genuinely need them indexed, and to serve a 404 for filter combinations that do not exist rather than an empty results page. Fragment-based filtering is noted as crawl-neutral, since a fragment never produces a request. The rel="nofollow" route is described as weak, because it only works if every anchor to that URL carries the attribute, which on a large site is a promise nobody can keep.

None of this is documented for AI crawlers specifically. Google's guidance above is Google's, and we have not found an AI crawler that publishes a fetch budget. What we can say is what we have seen in the server logs clients have shared with us: AI user agents fetch far fewer distinct URLs per day on a given site than Googlebot does, and on marketplaces a large share of those fetches land on parameterised URLs. A marketplace spending that smaller allowance on ?sort=price_asc&page=47 is spending it on pages unlikely to be worth citing.

The thin-page trap, and why it is sharper here

Aggregators generate pages at the intersection of entities: product by city, role by seniority, lender by loan size. Most of those intersections have no real content behind them. Google's spam policies, last updated in August 2026, now name scaled content abuse directly: many pages generated chiefly to manipulate rankings, including pages stitched together from feeds with little coherence. The same page names site reputation abuse, which covers hosting third-party content mainly to borrow the host's accumulated signals.

Neither policy was written about marketplaces specifically. Both describe exactly what an unsupervised template generator produces. The defensible version is simple to state and tedious to do: publish the intersection page only when you hold data that makes it worth reading, and let the rest 404 or redirect. Regulated verticals learned this earlier than most, which is why AEO for fintech reads like a compliance document in places.

Checks you can run this week

Five of them, in the order we run them.

Pull a week of server logs and count fetches by AI user agent, grouped by URL pattern. If more than half the requests land on parameterised URLs, your crawl budget is being spent on nothing. Fix the robots rules before you touch anything else.

Take ten listing pages at random from the long tail, fetch them with JavaScript disabled, and check whether the price and the availability are present in the HTML. Sellers often sit behind a client-side call.

Grep your feed for rows where seller_name equals your own brand. On a marketplace, that number should be small and explainable.

Ask five engines a buying question in your category, with the brand name omitted, and record whether you are named, whether a seller inside you is named instead, and which page got cited. A seller outranking its own marketplace is a normal, healthy result, and it is also a signal about which identity the engine has resolved.

Then check the claim. Mention without accuracy is not a win, a point the self-check walks through in more detail.

Honest limits

The eligibility and crawl guidance above is Google's documentation, and we have not found an equivalent published rule for ChatGPT, Perplexity, Claude, Copilot or Gemini; do not assume it transfers. The feed argument rests on what the specification separates, not on engine behaviour we have observed, because we cannot see inside an engine's entity resolution from the outside. Our crawl and feed observations come from client logs and feeds across a small number of marketplace engagements, not from a sample anyone could call representative, and we have not kept counts that would let an auditor reproduce them. We also cannot yet tell whether an engine treats a marketplace listing page and the seller's own storefront as one entity or two. And attribution stays poor: these surfaces rarely pass a referrer, so a marketplace can see traffic move without being able to prove which answer moved it.

The naming debate around AEO vs GEO vs SEO: what the three terms actually mean matters far less here than a settled answer to a duller question, which is who owns AEO inside a company when the fix lives in the catalogue team's backlog and the symptom lands on marketing's dashboard.

FAQ

Should an aggregator use merchant listing markup? Only if the buyer completes the purchase on your page. If you link out to the seller to transact, the eligible path is a product snippet with AggregateOffer, which carries lowPrice, highPrice and offerCount. Claiming the richer type does not create eligibility.

Our seller pages are not being cited. Where do we look first? Server logs, before content. Count AI crawler fetches by URL pattern. On the marketplace logs we have reviewed, a large share landed on filtered and sorted variants, which leaves seller pages competing for whatever fetch budget is left over. Run the count on your own logs rather than assuming ours generalise.

Does blocking faceted URLs in robots.txt hurt us? It removes pages that were unlikely to be cited anyway and returns the fetch allowance to pages that might be. Keep the unfiltered category URL crawlable, disallow the parameter patterns, and serve a 404 for filter combinations with no inventory.

How many thin intersection pages are too many? There is no published threshold, and anyone quoting one is guessing. The usable test is whether a page holds information a reader could not assemble in ten seconds from the pages above it. If it does not, it is a candidate for removal.

Sources

Related reading

AEO by industry: where the work differsAEO for fintechAEO vs GEO vs SEO: what the three terms actually meanWho owns AEO inside a companyAEO for publishers losing clicksAEO when every claim needs approval