Best ecommerce platform for SEO: the criteria that actually decide it

There is no best ecommerce platform for SEO, and any article that names one is answering a different question than the one you asked.

Every serious platform can rank. What differs is how much of the technical groundwork you get by default, how much you have to configure, and — critically — how much the platform will actively fight you on. Those differences are real and they are worth choosing on. They are just not visible on a feature comparison, because every vendor writes "SEO friendly" and none of them define it.

This page defines it. Nine properties that decide whether a store can rank, how to test any platform against each in an hour, and an honest note about where self-built stores fail — which is the part we have the most direct evidence for.

The nine properties that matter

1. Server-rendered HTML with the content in it

The single most important one, and the one most likely to be quietly broken.

When a crawler requests a product page, the response has to contain the product name, description, price and availability as text. If the response is an empty shell that fills in via JavaScript, you are relying on the crawler executing your code — which it may do, later, inconsistently, and with no guarantee for every page on a large catalogue.

How to test: view source on a product page — actual source, not the inspector, which shows the rendered result. Search for the product description. If it is not in there, the page is client-rendered.

2. Real URLs, one per page

Each product, category and content page needs its own crawlable path. /products/blue-widget, not a fragment or a query parameter that a crawler treats as the same page.

How to test: navigate to three different products and watch the address bar. If the part after a # is what changes, those are not separate URLs to a search engine — fragments were dropped as a crawling mechanism a decade ago.

3. Canonical control

Ecommerce generates duplicates by nature: the same product under two categories, filtered and sorted variants of a listing, pagination, tracking parameters. Canonical tags tell a crawler which version counts.

How to test: apply a filter to a category page and check whether the canonical still points at the unfiltered category. Then check that a product reachable from two categories declares one canonical URL, not two.

4. Control over titles, descriptions and headings

Per page, editable, with sensible templating for the thousand products you will not write manually. The heading structure has to be real — one h1 per page, describing that page.

5. Structured data for products

Product schema carrying price, availability, brand and reviews. This is what produces the rich result in search — the price and stars under your link — and it directly affects click-through.

How to test: run a product URL through a structured-data validator. It either has valid Product markup or it does not.

6. Page speed under a real catalogue

Demo stores are fast because they have twelve products. Ask how the category pages perform with your actual catalogue size and image count, and check whether images are served in modern formats at appropriate sizes without you doing it manually.

7. Redirect management

You will rename products, discontinue lines and restructure categories. Every one of those is a URL that needs to redirect rather than 404, and you need to be able to create those redirects yourself without a developer.

How to test: find the redirect management screen. If there is not one, every future catalogue change costs you accumulated ranking.

8. A sitemap that updates itself

Generated automatically, including new products, excluding out-of-stock or unpublished ones according to a rule you control, and submitted without manual work.

9. Not being locked out of your own head tag

Analytics, verification tags, schema you add yourself. Some platforms restrict this on lower tiers, and it is worth knowing before rather than after.

Testing a platform in an hour

Set up a trial, add one product with a description, then work down the list:

1. View source, search for the description text.
2. Visit three products, watch the URL structure.
3. Filter a category, check the canonical.
4. Edit a product's title and meta description — confirm it is possible per product.
5. Validate the product page's structured data.
6. Find the redirect manager.
7. Find /sitemap.xml and confirm your product is in it.
8. Add a snippet to the head.

A platform that passes those eight will not hold your SEO back. One that fails the first two cannot be fixed with plugins, because the failure is architectural.

Hosted, open source, or custom — how each behaves for SEO

The three routes fail and succeed in different places, and knowing which trade you are making is more useful than a ranking. SEO is one axis of that choice — choosing an ecommerce platform covers the rest, starting with the six different store shapes that need genuinely different software, and B2B ecommerce platform covers the shape furthest from what these products are built for.

Hosted platforms give you most of the nine by default. Server rendering, real URLs, sitemaps and canonicals are handled, and you inherit their performance work. What you give up is control at the edges: head-tag access is sometimes tier-gated, URL structures are often fixed (you may be stuck with /products/ whether you like it or not), and if the platform makes an architectural change you inherit it. For most small businesses this is the correct trade and the SEO ceiling is high enough that you will never touch it.

An open source ecommerce platform gives you complete control and hands you the responsibility. The mature projects are server-rendered by default and generally sound on all nine properties — but performance under a real catalogue is now your problem, as are upgrades, and the plugin ecosystem is where SEO regressions creep in. A plugin that changes how category pages paginate can quietly duplicate your catalogue. The advantage is that nothing is gated: every tag, every redirect, every URL rule is yours.

Custom gives you exactly what you specify and nothing else — which, as the next section covers, is usually the problem rather than the benefit. The upside is real for stores whose structure does not match the products: unusual catalogue hierarchies, content-and-commerce hybrids, or a business where the product page is not the main landing surface.

A note on the small-business case specifically: if you are searching for the best ecommerce platform for small business or for beginners, the honest answer is that the SEO differences between the major hosted platforms will not be what decides your outcome. Your product pages, your content and your photography will. Choose on how quickly you can operate it, and treat the nine properties as a qualification check rather than a ranking.

Where custom-built stores fail — with evidence

This is the part worth reading if you are considering building rather than buying, and we have direct evidence rather than opinion.

A coding agent will build you a fast, attractive store. It will also, by default, build a single-page application that renders entirely in the browser, routes by URL fragment, ships no canonical tags, no structured data, no sitemap and no robots file — and every one of those failures is invisible in the browser. The store works perfectly. It is simply not indexable.

We watched exactly this happen on one of our own projects recently: a research site built by a capable agent, launched with the content rendering flawlessly, and a raw HTML response of about a kilobyte containing nothing but the site name. Every route was a URL fragment. Requesting the real paths returned 404. No canonical, no sitemap, no robots. It took several rounds to fix, and the fix was architectural — server-rendered paths, a URL taxonomy, redirects from the old fragments, structured data and a generated sitemap. Not a plugin.

The reason this happens is worth understanding: nothing in a normal build brief mentions crawlers. The agent is asked for a store that works, and it delivers one. Rendering strategy is invisible to every test a person runs by clicking around, so it survives all the way to launch.

If you build, these five must be in the specification before a line is written, because retrofitting each is a rewrite rather than an addition:

1. Server-side rendering or prerendering for every page a customer could land on.
2. Path-based routing, never fragments.
3. Canonical tags with an explicit rule for filtered and paginated views.
4. A generated sitemap plus a robots file — and check the robots file at launch, because a Disallow: / left over from staging is the single most common way a correct site stays invisible.
5. Product structured data emitted from the same source as the page content, so they cannot drift.

The three ecommerce SEO problems no platform solves for you

Choosing well removes the technical obstacles. It does not do the work, and three problems are yours regardless of which ecommerce platform you land on.

Duplicate and thin product pages. If you sell manufacturer-supplied products you are shipping the same description as every other retailer, on pages that differ only by a price. No platform fixes that. The fix is your own copy, your own photography, and — where it applies — your own specifications and use cases. This is the single largest determinant of whether a small store ranks, and it is entirely manual.

Faceted navigation. Filters generate near-infinite URL combinations: colour, size, price band, brand, sorted four ways. Left alone, a crawler will spend its time on ?colour=blue&sort=price-desc and never reach half your catalogue. Every good platform gives you canonical and indexing controls for this. None of them decide for you which facets deserve their own indexable page — and some do, because "blue widgets" is a real search and worth a landing page.

Out-of-stock and discontinued products. A product that sells out has ranking you should not throw away. Deleting the page loses it and creates a 404; leaving it up unchanged frustrates people. The options are keeping the page with clear availability and alternatives, or redirecting to the closest equivalent. Whichever you choose, it needs to be a rule you apply consistently rather than a decision made per product by whoever noticed.

Those three are where ecommerce SEO is actually won or lost. The nine properties above simply determine whether you are allowed to compete.

What the store itself has to do

SEO decides whether people arrive. These decide whether they buy. From our hand-counted inventory of 90 real online stores:

Capability	Found in
Product variants — size and colour with per-variant SKU, price and stock	49 of 90 (54%)
Customer accounts — profiles and address book	48 of 90 (53%)
Order management — admin order list and detail	47 of 90 (52%)
Checkout creating a durable order record	44 of 90 (49%)
Payment gateway integration	42 of 90 (47%)
Search, filter and sort on the storefront	42 of 90 (47%)
Shipping and fulfilment — flat rate, local delivery, pickup	40 of 90 (44%)
Inventory tracking with movement rows, rechecked at order creation	39 of 90 (43%)
Reviews and ratings	35 of 90 (39%)

Two of those interact directly with search.

Product variants at 54% is the most common capability in the set, and it is also an SEO decision: whether each variant gets its own URL or they share one determines how many pages you have and whether they compete with each other. Decide deliberately.

Reviews at 39% are the lowest-ranked capability here, and worth the position — they are frequently built early because they are visible, when they only matter once you have traffic. They do feed structured data, which is their real SEO value.

The counted note on inventory is the one to hold on to if you build: stock must be rechecked at order creation, not just displayed on the product page. That has nothing to do with SEO and everything to do with not selling things you do not have.

---

If you are weighing self-hosted options, most of the same architecture questions apply — and if you are building, the Online Store planner is the specification we hand our own coding agents, including the rendering and URL requirements above, so an agent cannot hand you a beautiful storefront that no crawler can read.