A marketplace SEO audit has to cover everything a single-store audit covers, then a second list that exists only because more than one person uploads to your catalog. That second list is not a niche concern: Euromonitor reports that online marketplaces achieved 62% of global retail e-commerce sales, reaching USD 2.4 trillion.
The second list is also the one that gets missed, for a specific reason. None of it breaks. Seller URLs do not suddenly change pattern, category trees do not collapse and rating schema does not stop validating. Each item drifts instead, a little at a time, as vendors and listings and integrations accumulate across months. A launch checklist cannot catch any of that, because on the day you run it everything is still correct.
This article covers the second list. For the first one, the standard technical checks that apply to any ecommerce audit have a checklist of their own, and everything below assumes that ground is already covered.
TL;DR
- A marketplace needs everything a standard ecommerce audit checks, plus a second list that exists only because independent sellers publish to the same domain.
- The marketplace-specific problems drift rather than break. They arrive gradually with new vendors, new categories and new integrations, which is why a launch checklist cannot catch them and a recurring one can.
- Google has not documented a preference between a seller subdomain and a seller subdirectory. What costs you is running both at once because two onboarding cohorts were set up differently.
- Duplicate listings are a canonicalization event rather than a penalty. Google documents that it picks a canonical and consolidates signals, and that canonical hints are not even required.
- The review schema risk inverts on a marketplace. Pooling star ratings from several sellers of one product is precisely the aggregation Google’s review guidelines rule out.
Quick Scan: Signs Your Marketplace Has One of These Problems
Before the detail, a fast read. If any row below describes something you have actually seen on your own platform, the section that follows it is the one to start with.
| What You Might Have Noticed | Why It Matters |
|---|---|
| Some seller pages sit on a subdomain and others on a path, and nobody remembers deciding that | Each host builds its own crawl history, so the newer cohort starts from close to nothing |
| Your category count has grown faster than your category traffic | Vendors are creating near-duplicate categories, splitting one intent across pages that each rank for nothing |
| Filter URLs outnumber real listings by an order of magnitude | Crawl that should be reaching new listings is being spent on states nobody searches for |
| New listings take weeks to get indexed, and it used to take days | Crawl demand is going somewhere else, usually parameters, internal search or deleted listings |
| The same product description appears under six sellers, word for word | Google picks one version and consolidates the rest, so five of those pages earn nothing on their own |
| Star ratings vanished from a template nobody touched | Pooled multi-seller ratings can run afoul of the aggregation rule in Google’s review guidelines |
| Your returns page still describes the policy you wrote for your first ten sellers | Trust is the component Google calls most important in E-E-A-T, and a stale policy page works against it |
Why This Audit Differs From a Standard Ecommerce Audit
Everything in a normal technical audit still applies. Crawlability, canonicalization, schema basics, hreflang, page speed and internal linking do not become optional because the catalog has many authors. A marketplace needs all of it, and it needs the marketplace list on top.
What changes is the shape of the work rather than its content. A single-brand catalog changes when your team decides it should, on a release cycle you control, so an audit finding has a natural end state: you fix it, and it stays fixed until somebody deliberately changes it again. A marketplace catalog changes when a vendor decides it should. Hundreds of people outside your organization add listings, pick categories, write titles and upload images on a schedule nobody owns.
That turns almost every audit item into something with a half-life. The question stops being whether the setup is correct and becomes how far it has moved since the last time anyone looked.
Each row has a trigger that moves it and a lagging indicator that eventually reveals it. The audit exists to replace the third column.
Seller URL Consistency: Is Drift Creeping Into How New Vendors Get Added?
Here is a decision a single-vendor ecommerce site never has to make. Does each seller get a seller storefront at seller.marketplace.com, at marketplace.com/seller/, or no seller-level URL at all?
Start with what Google actually says, because this question attracts more confident advice than evidence. Google has not documented a preference between the two. The only official page that compares them does so purely as URL options for geotargeting, with a neutral table of pros and cons and no ranking claim attached to either. What Google has said on the record is narrower and more useful: in an August 2024 SEO office hours session, Martin Splitt answered a question about regional subdomains by noting that having regional subdomains or subfolders does not by itself make content unique or surface it for specific markets. The URL shape is not doing the work you might hope it is doing.
So the audit question is not which pattern is better. It is whether you are still using the one you chose.
A pattern that fragments by onboarding era rather than by decision. Each cohort is internally consistent and the platform is not.
This is how it usually happens. The first two hundred sellers were onboarded by hand under a path. A replatform or a new integration arrived, and the sellers that came with it landed on subdomains because that was simpler for the vendor supplying them. Later, a feed pipeline started ingesting listings with no seller page at all. Nobody chose a new architecture. Three cohorts simply accumulated.
The cost is concrete. A subdomain is a separate host as far as crawling and history are concerned, which is why Google treats a move from a.example.com to b.example.com as a site move with URL changes rather than an internal reorganization. A seller who lands on a fresh subdomain starts with no crawl history, which is the cold start problem applied to a page that should have inherited the platform’s standing instead. Whatever you call the accumulated strength of the main domain, domain authority in the loose industry sense rather than any metric Google publishes, a separate host does not inherit it on the day it goes live.
One adjacent check belongs in the same pass. Marketplaces frequently run a seller sandbox or a staging environment, often on a subdomain, and those have a habit of getting indexed. Blocking them in robots.txt does not solve it: Google’s own documentation states that a page disallowed in robots.txt can still be indexed if other sites link to it. Password protection is what Google recommends, and John Mueller described it in a office hours session as “a common and a recommended practice”. Note too that noindex in robots.txt is not supported, and that a noindex rule only works if the crawler can reach the page to read it.
The practical audit step takes ten minutes. Pull a sample of sellers from each onboarding era, not a random sample, and check which pattern each one landed in. Drift shows up by cohort, which means a random sample can easily miss it entirely.
Taxonomy and Facet Drift as the Catalog Grows
Category trees and filter rules are set early, usually by someone who no longer owns them, and then left alone while dozens of vendors add listings underneath. Three things drift here, and they drift independently.
Category Trees That Vendors Quietly Reshape
Vendors do not pick the right category. They pick the closest one that gets their listing live, and they do it a few hundred times a quarter. Over a year that produces categories holding four products, categories that duplicate each other under different names and categories that no longer describe what is in them.
The SEO consequence is thin content and split intent. Two near-identical categories divide the internal links, the external links and the query coverage that should have concentrated on one page, so neither ranks. Check category indexation against listing count per category rather than looking at the tree in isolation, since the tree always looks reasonable on a diagram.
Facet Rules Set Once and Never Rechecked
Facet drift works by multiplication. Each new attribute that joins the filter UI multiplies across every attribute already there, so the crawlable surface grows much faster than the catalog does. Google is direct about the cost in its guidance on managing faceted navigation: because the URLs look novel, “the crawlers will typically access a very large number of faceted navigation URLs before the crawlers’ processes determine the URLs are in fact useless”, and “if crawling is spent on useless URLs, the crawlers have less time to spend on new, useful URLs”. On a marketplace that means your newest vendor’s listings are competing with filter states for the same attention.
The mechanics of fixing this are a topic in their own right, and we covered them in how to audit, prioritize and fix faceted navigation issues. For the audit, the number that matters is the ratio: facet and filter URL count against real listing count, tracked over time rather than read once.
Internal Search Results, Which Drift the Same Way
Internal site search result pages accumulate URL variants exactly as filters do, and they are easier to forget because nobody designed them as pages. Every query a user or a bot has ever submitted can become a crawlable URL with a thin, duplicated result set behind it. Check them on the same cadence and with the same ratio.
All three are measurable from a crawl and log file analysis together, and they are worth reading alongside a full crawl budget optimization playbook, since facet sprawl is one case of a broader allocation problem.
See Facet URLs vs. Real Listings
Vendor Onboarding Compliance: Catching Duplicate Content From Every New Seller
Duplicate content on a marketplace is not a setup problem you solve once. It renews with every vendor you onboard, because the behavior that causes it is rational for the vendor. Manufacturer copy is already written, already approved and already accurate, so sellers reuse it. Feeds and API integrations make this worse by shipping templated boilerplate across every listing in a batch.
Be precise about what this costs, because the usual framing overstates it. Google’s guidance on duplicate URLs treats duplication as a canonicalization question: when you do not specify a canonical, “Google will identify which version of the URL is objectively the best version to show to users in Search”, and the point of a canonical is to consolidate signals into a single preferred URL. The same page says the canonicalization methods are optional and that “your site will likely do just fine without specifying a canonical preference.” The word penalty does not appear on the page at all.
The real cost is simpler and still expensive. One version gets chosen, the others get consolidated into it and the crawl spent discovering them bought you nothing. Where it does become a policy question is further along: Google’s spam policies name “republishing content from other sites without adding any original content or value” and scraping feeds to generate many pages with little value for users. A catalog built entirely from unmodified supplier feeds drifts toward that description one onboarding batch at a time.
Enforcement works better than remediation, and it belongs in the feed specification rather than in a quarterly cleanup. These four requirements catch most of it:
| Feed Requirement | Why It Matters | How to Check It at Onboarding |
|---|---|---|
| A unique title at listing level | Identical titles across sellers are the clearest duplicate signal you can send, and the easiest to prevent | Reject the batch when title uniqueness across the feed falls below your threshold |
| A minimum description length | Very short descriptions produce thin pages that compete with nothing, including your own category page | Set a character floor in the feed schema and fail validation below it |
| No unmodified manufacturer copy | This is the single most common source of cross-seller duplication, and it arrives pre-formatted | Compare incoming descriptions against known manufacturer text and against listings already live |
| Unique alt text per listing image | Alt text is the one field vendors skip most often, and it is also the cheapest to generate from structured attributes | Require the field, or generate it from the listing attributes when a vendor leaves it empty |
That last row has more behind it than a checkbox, and we went into the mechanics in how to optimize images for ecommerce, from alt text onward. On a marketplace the difference is that you cannot go and fix the images yourself, so the control has to sit at ingest.
Finding what is already live needs a comparison across the whole catalog rather than within one vendor’s inventory, since the pattern only appears when every seller offering the same item is compared on the same crawled domain.
Review and Rating Schema Compliance as UGC Accumulates
One rule gets repeated wrong in both directions, so it is worth stating carefully. On a single-brand product page, reviews are not disqualified merely for belonging to the brand. Google’s review snippet guidelines point the self-serving restriction at specific types: “if the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature”. Product pages are not named in that sentence.
A marketplace runs into the opposite risk. The same guidelines rule out ratings aggregated from other sources and reviews not based on genuine experience, and pooling star ratings across every seller offering one product into a single AggregateRating is aggregation by design. A buyer reading four stars on a listing may be reading an average across six sellers with different condition grading, different handling and different delivery records.
Three rating strategies are defensible, and the audit is about confirming you are still running the one you chose:
- Rating per listing, with the AggregateRating sourced from verified purchases of that listing, which keeps the rating and the thing being rated aligned
- Rating per seller, marked up on the seller entity rather than on the product, which rates the merchant and says so
- A clearly sourced aggregate, where the product-level rating is explicitly product-level and seller performance is rated separately
Drift happens here because volume accumulates. New product and seller combinations keep appearing, each inheriting whatever the template does, so a decision made when the platform had two hundred products is still running when it has two hundred thousand. By the time ratings disappear from a template, thousands of reviews are already sitting under the wrong structure, and restructuring them is a migration rather than a fix.
Verify what is actually live rather than what the template is supposed to emit, because those stop matching the moment a seller-supplied field enters the markup.
Trust and Safety Pages: Still Accurate as You Scale
A marketplace introduces buyers to sellers they have never heard of, which creates a question a single-brand store never has to answer: why should anyone trust a transaction with a stranger on your platform? That is a conversion problem and a quality signal at the same time.
Google’s position here is more specific than the shorthand suggests. Its guidance on creating helpful content states that “while E-E-A-T itself isn’t a specific ranking factor, using a mix of factors that can identify content with good E-E-A-T is useful”, and then singles one out: “of these aspects, trust is most important. The others contribute to trust, but content doesn’t necessarily have to demonstrate all of them.” The Search Quality Rater Guidelines put it more bluntly still, defining trust as “the extent to which the page is accurate, honest, safe, and reliable” and noting that untrustworthy pages have low E-E-A-T however expert they otherwise appear.
The pages that carry this on a marketplace are the ones nobody reviews. Buyer protection and dispute resolution. Returns and refunds when the seller is not you. Seller verification and what it actually checks. Payment security. A contact route that reaches a human.
All of them go stale in the same way: they were written for the marketplace you had, and the marketplace grew past them. A returns page written when every seller shipped from one country does not survive your first international cohort. A buyer protection promise written for ten vetted sellers reads differently with ten thousand self-serve ones, and if the product changed while the page did not, the page is now inaccurate rather than merely dated.
Audit these against how the platform works today rather than against a style guide. The test is whether a buyer following the page would get the outcome it describes.
Why This Audit Belongs on a Recurring Calendar, Not Just a Launch Checklist
A recurring audit beats a thorough one here, and the reason is in every section above. Every item degrades gradually. Seller URL patterns fragment by cohort, category trees sprawl, facet rules multiply, duplicate listings arrive with each feed and rating schema outlives the strategy it was built for. None of it fails on a date you can point at, which is exactly why a launch checklist signs it all off and never catches any of it.
Cadence tied to triggers rather than to the calendar. A release moves things faster than a month does.
That leaves the question an SEO lead actually has to answer after each run, which is how to show the audit is working. Three numbers do it, and all three are reportable to someone who does not care about canonical tags:
- The share of new listings indexed within one to two weeks of a major release, which tells you whether discovery is keeping up with the catalog
- The share of crawl budget going to facet and internal search URLs versus real product and category pages, which tells you where the attention is actually going
- Organic sessions landing on vendor and category pages specifically, which tells you whether the pages you decided should rank are the ones doing the work
Those three move slowly and they move together, which makes them a decent scorecard across quarters. Set the audit cadence against your release and onboarding rhythm, and keep the XML sitemap in the same review, since a sitemap that still lists last year’s category tree is quietly teaching crawlers the wrong shape of your site. For a sense of what the upside looks like when the foundations get fixed, a multi-vertical marketplace group grew Googlebot visits by 350% after working through crawl and log data, alongside a 700% rise in SERP impressions.
A marketplace SEO audit run once is a snapshot of a platform that will not look like that in six months. Run on a schedule tied to your release and onboarding cadence, the same work becomes a scorecard that tells you when something shipped.
A scheduled crawl on a recurring cadence is what turns this from a launch checklist into an ongoing measurement. JetOctopus keeps crawl, log and Search Console data in one place, and the trial runs for seven days with no credit card.
Technical SEO to dominate AI and Google search.
FAQ
If new vendors join through an automated feed pipeline rather than manual onboarding, does this audit still catch drift and duplicate content?
The audit catches it, and a feed pipeline needs its own check in addition. A crawl shows you what went live, which is the outcome. Validation at ingest stops the batch before it becomes 4,000 near-identical listings, which is cheaper by a wide margin. Treat the feed specification as the enforcement point and the crawl as the verification that the specification is being applied.
Do individual sellers need their own Organization schema, or is one marketplace-wide Organization entity enough?
Google does not document this case, and it is worth saying so rather than inventing a rule. Its Organization structured data guidance describes site-level markup for one organization, recommending you place it “on your home page, or a single page that describes your organization”, and it says nothing about representing many sellers as many Organizations on one domain. The defensible reading is one Organization for the platform operator, with seller entities described through the markup that fits what they are on your site.
If a vendor’s product description already lives on their own website, does that count as duplicate content against the marketplace listing?
It is duplication, and it is the ordinary kind Google resolves by choosing a canonical and consolidating signals rather than by penalizing anyone. The practical question is which version wins, and on a strong marketplace domain it is often yours. That still leaves the vendor competing with themselves, which is a conversation worth having at onboarding, and it leaves you with a page that adds nothing a search engine has not already seen.
If seller URL drift already exists across older and newer vendors, is it worth fixing retroactively?
Weigh it by traffic rather than by tidiness. Consolidating cohorts means a site move for every seller you relocate, with the redirect work and the temporary volatility that implies, so it only pays where the affected cohort earns meaningful organic traffic. Where it does not, enforce the rule going forward and leave the old cohort alone. A mixed estate that nobody adds to is a smaller problem than a migration nobody has resourced.
Does this audit require a full site crawl, or can it be done from Search Console data alone?
Search Console cannot answer most of it, and Google documents why. Its help on Search Console data states that “most Search Console reports only cover a representative sample of URLs” rather than a comprehensive listing, and that tables “can show a maximum of 1,000 rows”. The Page Indexing report is explicit that its example URLs are “limited to 1,000 items” and are not guaranteed to show every URL in a status. On a catalog with hundreds of thousands of listings, a thousand examples cannot tell you which cohort drifted.
If the quick scan turns up more than one of these problems at once, which should get fixed first?
Order them by what is still getting worse. Vendor onboarding compliance comes first, because every day it runs unenforced adds more to clean up later. Facet and internal search sprawl comes second, for the same reason and because it is taking crawl from listings right now. Rating schema is third, since the cost compounds with review volume. Seller URL drift and trust pages are both real and neither accelerates, so they can wait for a quarter with room in it. That ordering is the whole value of running a marketplace SEO audit on a schedule: you fix what is compounding before you fix what is merely wrong.
