A marketplace is a search box in front of a very large number of nearly identical pages. That shape decides everything about how an agent uses it. The agent does not browse; it constructs a results URL from the term it was given, picks a listing out of the results, reads the price and availability from the listing's structured data, and looks for a way to buy without an account. Three checks cover that path: C6, on-site search; C5, commerce actionability; and B2, schema types for the site type. A fourth, B7, decides how badly pagination and filter URLs hurt you. The good news is that a marketplace has one listing template, so every fix below is made once and applies to every listing.
The path an agent takes
Four fetches, all of raw HTML. The homepage, to find the search form and the sitewide schema. A results page at a URL it built itself. One listing page, chosen from the results. Then the cart or checkout path, to find out whether a purchase is possible without logging in. A page that only fills in after JavaScript stops the path there.
Our crawler selects pages in a similar way. After the homepage it picks up to five more from the sitemap and the homepage's own links, preferring paths containing /product, /products, /shop or /collections, then /cart or /checkout.
Search by URL
C6 is 3 points, Medium effort. The scanner reads the raw HTML of the homepage only, finds the first form that looks like search, meaning one with an input type="search", an action or role containing search, or an input named search, query or q, and reads its method. One point for the form existing. Two more if the method is GET, or if the homepage carries a WebSite block with a SearchAction. The evidence fields are searchForm, usesGet, param and searchAction. On-site search by URL has the full table of outcomes.
On a marketplace this is the primary path, not a nicety. A shopper asks for "a second-hand road bike, 56cm, under a certain price", and the agent's first move is /search?q=road+bike+56cm. If that URL returns results in its HTML, the agent has a list to work from in one request. If search is a JavaScript widget or a POST form, there is no address, and the agent falls back to crawling categories, which on a large marketplace it will not finish.
Facets belong in the URL too. /search?q=road+bike&max_price=500&condition=used is an address the agent can build once it has seen the parameter names, and a filter panel made of GET forms and plain links is how it learns them. Advertise the primary template in the SearchAction so it does not have to read the form at all.
Listings within two clicks
C5 is 4 points, High effort, and runs only when the crawler typed the site as e-commerce. That typing comes from the homepage: Product, Offer or OnlineStore in its JSON-LD, or /cart, "add to cart", "add to bag", "shopify" or "woocommerce" in its HTML. A marketplace whose homepage is a search box and a hero, with no cart link and no schema, can be typed "other", in which case C5 is not applicable and its points are redistributed. If your listings carry offers, an OnlineStore node on the homepage is an accurate description and settles the classification; the siteType field on the report shows what was decided.
Once typed e-commerce, C5 awards four single points. A crawled page whose URL matches /product, /products, /shop, /collections or /item earns productPageFound. That page's HTML containing "@type": "Offer" earns offerSchema. A crawled page matching /cart, /checkout or /basket returning 200 earns cartReachable, and the cart page's HTML, or failing that the homepage's, mentioning Shop Pay, Apple Pay, Google Pay or guest checkout earns expressCheckout.
Two of those are marketplace-specific traps. Listing URLs like /l/8f3a2c or /listing/8f3a2c match none of the patterns; /item/8f3a2c does. And a cart that sends an anonymous visitor to a login page has closed the purchase path to an agent whatever status code it returns, which is the argument guest checkout is an agent feature makes at length. A marketplace with thousands of sellers has the strongest reason of any site type to let a buyer pay without an account first.
Schema at scale
B2 is 5 points, Medium effort. It collects every @type across all crawled pages, flattening @graph and nested objects, and awards two points if the set contains Organization or WebSite and three if, for an e-commerce site, it contains Product or Offer. The types are counted across the crawl, so the layout emits the sitewide nodes and the listing template emits Product and Offer.
That is the whole method for a site with thousands of listings. One template, one schema partial, every value read from the same field that renders the visible page. Structured data across templates describes the pattern; on a marketplace the listing partial looks like this.
{
"@type": "Product",
"name": "Road bike, 56cm, 2019",
"url": "https://example.com/item/8f3a2c",
"image": "https://example.com/img/8f3a2c.jpg",
"offers": {
"@type": "Offer",
"price": "480.00",
"priceCurrency": "USD",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/UsedCondition",
"seller": { "@type": "Organization", "name": "Seller display name" }
}
}
The Offer type carries seller, itemCondition and availability, and on a marketplace all three are load-bearing: the buyer's agent needs to know that the seller is not the site, that the item is used, and that it is still for sale.
Price and availability drift
The free scan tests only that an Offer is present on the listing page. It cannot prove that the price in the block equals the price beside the button. An agent can, and does, because it has both in the same response. On a marketplace the two drift for a reason a single-vendor shop does not have: the seller edits the listing. If the schema partial reads from a cached or denormalised copy of the listing while the visible page reads from the live record, a seller's price change opens a gap that persists until the cache expires.
The partial reads listing.price, the template reads listing.price, and there is no second field. When a listing sells, set availability to SoldOut or remove the offer rather than leaving InStock on a page whose button now says "sold"; a stale InStock is the specific error that makes an agent stop trusting the site's schema as a whole. Product and Offer schema that matches the page covers the fields and the ways they disagree.
Pagination and duplicates
B7 is 3 points, Low effort. For each crawled page the scanner reads rel="canonical", resolves it against the page URL, and compares the two pathnames with any trailing slash removed. Query strings are not compared. Two points if every crawled page is self-consistent by that test, one more if the www, non-www, http and https variants all resolve or redirect to one host.
For a marketplace that is more forgiving than it sounds. /search?q=bike&page=2 with a canonical of /search passes, because the pathnames agree; so does /listings?sort=price with a canonical of /listings. What fails is a path-based variant with a canonical pointing elsewhere: /bikes/road/ with a canonical of /bikes/, or a listing at /item/8f3a2c whose canonical still points at the seller's original /item/8f3a2c-old after a re-list. The crawler also de-duplicates its candidate pages by pathname, so a sitemap that lists every filter combination as a separate path both wastes the six-page budget and hands the scanner more canonicals to get wrong. Google's guidance on consolidating duplicate URLs is the reference for the mechanics.
The fixes, in order of effort
| Effort | Fix | Check |
|---|---|---|
| Minutes | method="get" on the search form, name="q" on the input |
C6 |
| An hour | A WebSite node with a SearchAction matching that form |
C6, B2 |
| An hour | Canonicals on results and filter pages that point at the same pathname | B7 |
| A morning | Product and Offer in the listing template, reading the live listing fields |
B2, C5 |
| A morning | An OnlineStore or Organization node in the layout, listing paths under /item or /products |
B2, C5 |
| A day | A cart and checkout path that returns 200 without login, with an express or guest option | C5 |
| Weeks | Server-rendered results and listing pages if they currently fill in client-side | A7 |
The first five are template edits; the last two are product decisions.
Check your own site
Run the free scan and read siteType, then the C6 and C5 evidence: usesGet, param, productPageFound, offerSchema and cartReachable tell you which step of the path broke. The definitions are under actionability and understanding on the methodology page, and the e-commerce leaderboard shows how other shops score on the same checks.