Mercur

Marketplace SEO: How to Maintain Pages That Carry Many Offers

Storefront and buyer experience~15 min
Marketplace SEO: How to Maintain Pages That Carry Many Offers

Marketplace SEO is the work of getting pages indexed and ranked when one address carries several sellers' offers, several authors' text, and a price that changes whenever the winning offer does.

Search visibility is the one layer of the storefront where a decision taken in the first week of the project keeps costing you for the life of the platform. Page addresses stay. And the three things that decide it are decided in your data schema.

This article breaks down:

  • What does a search engine see on a page with 5 offers?
  • One address per product, or one per offer?
  • Why does one new facet multiply your addresses?
  • What happens when the last offer goes dark?

Key insights

  • A search engine sees one page where you have five offers, five authors, and a price that changes whenever the winning offer does.
  • Keep one address per product wherever several sellers list the same thing, so your own pages stop competing with each other.
  • One new facet multiplies your addresses because facets combine, so you have to decide which combinations may enter the index at all.
  • When the last offer goes dark, the page keeps its traffic and its promise, so decide in advance whether it stays with an honest state and an alternative, redirects, or goes.

What does a search engine see on a page with 5 offers?

A first-party store has one author and one address per product. One company wrote the description, one company sets the price, and one company decides what happens to the address when the goods run out.

A marketplace has none of those three things. It has as many versions of the description as it has sellers, as many addresses as the catalog model allowed, and a price that is not a number but a range.

The search engine does not see that fragmentation and does not want to see it. It sees an address, the content under it, and whether anything there can be bought.

From that follows a conclusion that changes who owns the subject. Marketplace visibility is not an optimization problem.

It is a consequence of decisions taken in the data schema. A specialist brought in after launch works with whatever you left them: if the same product has three addresses with the same description on your site, no amount of tuning will merge them.

And nobody will configure this for you. In this class of solutions, the storefront sits on the operator's side: one vendor does not ship one at all, and another withdrew the one it had.

Addresses and markup are not a feature you buy. They are your own design.

One address per product or one per offer: which do you index?

Comparison of three catalog models for 3,000 products with three sellers each: one address per product (3,000 addresses, no dead addresses), an address per offer (9,000 addresses, 3,000 dead after one seller leaves), and an address per offer pointing at the product page.

Take 3,000 repeatable products and an average of three sellers per product, so 9,000 offers. The shared page model gives you 3,000 addresses with 9,000 offers under them.

The listing model gives you 9,000 addresses, including 3,000 triplets of near-identical content. The description comes from the same manufacturer in all three.

In the second variant, those addresses do not add up. They compete.

The public guidelines of the largest search engine say it plainly: where several addresses carry the same content, one of them is picked as the version shown to users, and the signals of the rest are consolidated into it. You are therefore not deciding whether one of three near-identical addresses stays visible, only whether the choice is yours.

A canonical pointer is a declaration and not an order, but without one the machine picks.

The third variant is a compromise: offers get addresses of their own, and each one points at the product page as the main version. The signals come back to a single place. What stays is nine thousand addresses to maintain and to translate.

How do you rank a page carrying the manufacturer's description?

A seller does not write the description for you. They paste in the manufacturer's file or an export from their warehouse system, the same one they use to feed every other channel.

So the same text sits under twenty other addresses on the internet. In the implementations we know, practically every product page comes from a seller's hands, and the description is the part several channels have in common rather than the sum of what they all ask for: the minimum, in other words.

The first answer lives in what you can enforce on content. Generate the description from attributes: the structure you enforce anyway assembles sentences in a voice nobody else has.

The second answer matters more, because it is about content the competition cannot have. A page with three offers has three prices, three delivery dates, three stock levels, and three sellers: twelve pieces of data that sit under no other address on the internet.

Add the real questions buyers ask and a comparison of variants. This is the only content layer in which a marketplace is unique by definition, and usually the last one to reach the page source, because nobody ordered it.

Why does one new facet multiply your addresses?

One category with four filters — 41 brands, 13 colors, 9 sizes, 7 price bands — produces 33,578 non-empty addresses, 134,312 with four sort orders, and over 235,000 once a fifth filter with six values is added, against a catalog of 3,000 products.

Take one category with four filters: 40 brands, 12 colors, 8 sizes, 6 price bands. The number of non-empty combinations is the product 41 × 13 × 9 × 7 minus one, so 33,578 addresses.

Four sort orders multiply that to 134,312. Your catalog holds 3,000 products.

One category has produced more than eleven times as many addresses as your entire assortment.

Here is the warning of this article, and it runs against budget intuition: the new filter marketing asks for does not add six addresses. A fifth filter with six values multiplies the whole grid by seven (from 33,578 to more than 235 thousand).

Your supply grows linearly, your address space grows exponentially, and between those two growth rates there is no threshold anybody would notice.

Search engines say this openly: a crawler does not judge in advance whether a faceted address is useful, so it visits a great many of them, and time spent on the useless ones is time it will not spend on new ones. The public guidelines give two thresholds above which managing crawl budget stops being theory: a million addresses, or ten thousand addresses whose content changes very quickly.

A marketplace hits the second one with a modest catalog, because prices and stock levels change daily.

The decision is binary, and it has to be yours: a combination is either a page or a view. A page has an address, a title, and text of its own.

A view filters the list without producing an address to index. Three conditions qualify a combination at once: people search that way, there are enough buyable offers behind it, and the content differs from the parent page.

Do the arithmetic on our category. There are 48 sensible candidates: 40 brands plus 8 sizes, which is just under 0.15% of the combinations.

After a threshold of "at least ten buyable offers," you are left with 31 pages, and 17 go back to being views. This is an assortment decision rather than a technical one, so no plugin and no template behavior will settle it.

One caveat: the guidelines point out that if category pages do not link directly to every product, the crawler may never find them. When you close combinations off, you take on an address map or a feed as an obligation rather than an option.

What happens to a page when its last offer goes dark?

At 3,000 products and 12% of pages with no active offer: 360 dead addresses, 14,400 monthly views, €216,000 of turnover not booked and €25,920 of marketplace revenue lost, plus lost rich results and soft-404 risk.

After a year some product pages have no active offer at all: the seller left, the stock ran out, the product went out of the assortment. At 3,000 products and 12% of pages in that state, that is 360 addresses promising something that is not there.

They are addresses with history, so they carry traffic. At 40 views a month per address, that is 14,400 views landing on pages with nothing to sell.

What that is worth can only be estimated, and this is an assumption rather than a measurement: at a 1.5% conversion rate and a €1,000 cart it is 216 orders, so €216,000 of turnover a month. At a 12% commission, that leaves €25,920 of your revenue, and the seller receives €880 out of every thousand.

An address with no offer generates neither of those two numbers, while you keep paying the cost of maintaining it.

Two more effects land on the visibility side. The richest store presentation formats are available only for pages where the buyer can buy the product, so you lose the format along with the sale.

And a page that looks like a product and has nothing to sell is a candidate for a soft missing page: an address like that still gets visited and still eats budget that new products will not get.

The conclusion belongs to the system rather than to the content team: what happens to an address when the last offer goes dark has to be a rule.

What does structured data commit you to on a multi-offer page?

9,000 offers generating 18,000 daily price and stock updates against markup regenerated once a day leaves 900 pages showing a price that is not in the cart, with three reasons a mismatch is worse than no markup at all.

The data description standard search engines read has a separate type for a product offered by many sellers. It requires the lowest price and the currency, and it recommends the highest price and the number of offers.

Those are exactly the numbers that change most often on your platform.

The maintenance arithmetic: 9,000 offers, with every seller updating price and stock twice a day, comes to 18,000 events daily. If the markup is generated once a day, and even 5% of those events change the lowest price on a page, 900 pages show the search engine a price that is not in the cart.

A mismatch is worse than no markup at all, for three independent reasons. The guidelines say not to mark up content that is not visible on the page, and misleading markup costs you the right to enriched presentation.

Rank itself is untouched, so you see the penalty as the price vanishing from the result rather than as a drop. A price validity tag with a date in the past can switch the presentation off by itself.

And a buyer who clicked a price and did not find it in the cart costs you more than one who never clicked.

Two things to settle before anybody promises the board anything. A many-offer aggregate qualifies for a narrower set of formats than a single-seller page, because the richest store formats assume the owner of the site sells the goods.

And the price in the markup has to follow the same rule as the price on the page (showing the price) and come from the same series you use to calculate a discount message (price history and discount messages). Three different numbers for the same offer is not a data error.

It is three owners of one rule.

What does marketplace SEO change about the rest of your build?

1. Three decisions are architectural and belong at the gate before the build

One address per product or per offer, which filter combinations are pages, and where the content nobody else has comes from. They are taken in the routing and in the schema.

An address is a contract between the catalog, the storefront, and seller integrations into a template.

2. The execution belongs to specialists

Titles, internal linking, address maps, page speed, and rank monitoring are the work of visibility people, done on your data. Your responsibility comes earlier: making sure they have something to work on.

3. A new category stops being a switch you flip

Practitioners describe the same sequence: the tree, the required attributes, a visibility analysis, an update to the terms, a notice to sellers. Only then does the category open. A calendar of categories is a calendar of visibility.

How do you check marketplace SEO on your own catalog?

  1. How many addresses does one product sold by four sellers have, and can the main address be pointed at without a code change?
  2. Show me the aggregate markup in the page source on a product page with four offers. Then change the price of the cheapest one and tell me how long it takes the markup to show it.
  3. Which filter combinations have addresses of their own, and who decides that? You, or the default behavior of the template?
  4. Where do the title and the text of a filtered page come from? From a template, or from a field that somebody fills in?
  5. What does the address of a product with no buyable offer return? A message with a replacement, a redirect, or a page that still looks like a product?
  6. What is in the address map? Products, offers, filter combinations? And who generates it?
  7. A measurement before you sign a contract: count the filter combinations in your three largest categories and compare that with your number of products. If there are more combinations, you have a decision to make rather than a task to hand out.

Which mistakes do operators make about marketplace SEO?

1. "We will deal with visibility after launch"

Consequence: an address per offer is already in the routing, and changing it means an address migration with redirects to maintain for years.

2. Facets indexed because that is how the template behaved

Consequence: the crawler tours a hundred and thirty thousand near-identical addresses instead of your new products.

3. Aggregate markup generated once, at implementation

Consequence: the price in the result does not match the cart. You lose the buyer's trust and the right to the format that showed the price in the first place.

4. The manufacturer's description as the whole content of the page

Consequence: a page identical to twenty others, at the full cost of curating it.

5. No rule for the moment the last offer goes dark

Consequence: hundreds of addresses carrying traffic and a promise, with nothing to buy behind them.

What do you still have to settle with a search specialist?

This chapter does not settle optimization techniques or tactics, and leaves them to specialists deliberately. Keyword selection, internal linking, titles, and monitoring are not settled in a committee meeting, and an article that pretends to be a technical guide here does damage to both sides.

The neighbouring decisions are led elsewhere:

  • redirects after duplicate pages are merged, in duplicates and merging
  • the ladder of winding down and de-indexing
  • internal search and facets as a tool for the buyer
  • addresses per language, description quality, and price presentation
  • the information duty toward the buyer, and the labeling of positions that rank higher because somebody paid for them, in price history and discount messages and the rules on decisions about sellers

If filtered pages are going to be monetized, that is the right order to read them in.

Nor does it settle how much traffic any one variant will bring you. That depends on the category, on the competition and on the age of the domain, and anybody who hands you a number here is selling you a conviction. The most important number you can count yourself in a single day: how many filter combinations your largest category produces, and how many of them you want as pages.

Our claim is narrower and independent of those answers: a platform that cannot say how many addresses one product has, and which of them it wants to show, does not have a visibility strategy. It has a template.

Summary: What does marketplace SEO come down to?

Deciding what deserves an address, and what each address promises. One product with five offers is one page to a search engine, so the addressing model – a page per product or a page per offer – sets how many of your own pages compete with each other before anyone else does.

Facets sit on top of that and multiply rather than add, which is why the rule about what enters the index belongs in the design and not in a template's default. And the part everyone meets late: a page whose last offer went dark still ranks, still gets clicked, and still promises something you no longer sell.

Count how many indexable addresses your filters can generate in one category, then count how many you meant to have. Building a marketplace where the addressing model is a decision rather than a side effect?

Talk to us about the build.

Frequently asked questions on marketplace SEO

What is marketplace SEO?

Marketplace SEO is getting pages found and ranked when one address carries several sellers' offers rather than one shop's product. The differences are structural: several authors on one page, a price that moves with the winning offer, facets that generate addresses, and pages that outlive the offers on them.

Should a marketplace index products or offers?

A marketplace should index products, in almost every catalog where several sellers list the same thing. One address per product concentrates the signals; one per offer splits them between pages that differ only by seller and compete with each other. The exception is assortments where every item is one of a kind.

Ready to build?

If you want to count how many addresses your catalog model will produce before they reach the index, let's talk.