Ecommerce SEO
Most online shops do not have a traffic problem so much as a URL problem. A catalogue of products presents a search engine with many times that number of pages, and most of them are filters, sort orders, variants and sold-out listings nobody meant to publish. Ecommerce SEO makes the shop legible first, then makes the pages that earn money worth ranking.
What is included
- A crawl of the shop's real URL space, including filters, sort orders, variants and pagination
- A category and product page architecture with each page's search target stated
- Rules for faceted navigation: what is indexed, blocked, consolidated or returned as not found
- Product and Offer structured data checked against what is visible on the page
- A stock-state policy for out-of-stock, back-order and discontinued products
On this page
- What is ecommerce SEO, and how is it different from ordinary SEO?
- How should category and product pages be structured?
- How do you handle faceted navigation without creating duplicate content?
- Which filter and parameter URLs should be indexed, blocked or consolidated?
- What does a product page need to rank, and what does product schema need to say?
- What should a product page do when the product is out of stock or discontinued?
- How do product feeds fit with ecommerce SEO?
- How should internal linking work in an online shop?
- Which ecommerce migrations put rankings at risk?
- How does ecommerce SEO fit with the ecommerce build, and does the platform matter?
- What does an ecommerce SEO audit cover?
- How do you judge an ecommerce SEO agency, consultant or specialist?
- When is ecommerce SEO the wrong first step, and what drives the cost?
What is ecommerce SEO, and how is it different from ordinary SEO?
Ecommerce SEO is the work of getting an online shop's category, product and guide pages crawled, indexed and ranked for the searches that lead to a purchase. It differs from ordinary SEO because a shop generates its own pages at scale: filters, sort orders, variants and sold-out products all create URLs that nobody wrote and nobody reviewed.
A service business has a few dozen pages that each have to be good. A shop has a handful of templates, each repeated across the whole catalogue, so one mistake in the category template is a mistake on every category. That is why most of this work is architecture and rules rather than copywriting, and why the fix usually has to be made in the platform. It is the specialist end of our wider SEO work, and it assumes the basics are already covered.
It is for retailers whose catalogue is big enough that filters, variants and stock changes are creating pages faster than anyone is checking them. It is not for a shop with a few products and one page for each, where ordinary on-page work is enough. And it does not make a shop sell: it gets the right pages in front of people who are already looking.
How should category and product pages be structured?
Build the shop around the category, because that is where most buying searches land. A category page should target one clear search, sit no deeper than it needs to, link down to its subcategories and products, and carry enough genuine content to be worth ranking. Product pages support the category rather than competing with it.
Most people search for the kind of thing, not the SKU: “leather sofas”, not a model number. The category page is therefore the page that matches the search, and it is also where the commercial value sits, because one category can feed many products. Yet in most stores the category is a heading above a grid of thumbnails, with the real work left to the product pages. Giving each category a stated search target, a short introduction above the products, helpful buying guidance below them, and links to the subcategories that matter changes what the page can rank for, and it stops two categories chasing the same phrase.
Structure should be planned before it is built, which is why this belongs inside the store build itself wherever the shop is being created or rebuilt. Google generally works out how a site is organised from its links rather than from its URLs, so the useful question is not what the URL looks like but whether a visitor, and a crawler, can get from the menu to a category to a subcategory to every product by ordinary links. Keep the hierarchy shallow, keep naming consistent, and decide which pages exist on purpose. The wider job of producing category and buying-guide content follows once the structure is settled.
The point
Structure should be planned before it is built, which is why this belongs inside the store build itself wherever the shop is being created or rebuilt.
Which filter and parameter URLs should be indexed, blocked or consolidated?
Index only the filtered pages that match a real search and can carry their own title and copy. Block or consolidate everything else: sort orders, price ranges, tracking parameters, internal search results and long filter chains. The table sets out the treatment we start from, before testing it against your catalogue.
| URL type | Usual treatment | Why |
|---|---|---|
| A single filter that matches a real search, such as colour plus product type | Indexable, with its own title, heading and short copy, included in the sitemap and linked from the category | People do search this way, and a filtered page with its own content can answer the search better than the generic category. |
| Sort orders such as price low to high or newest first | Not indexed; crawling discouraged through robots.txt or noindex | The same products in a different order add nothing a search engine needs, and every sort multiplies every category. |
| Price sliders and numeric ranges | Blocked from crawling | The number of possible values is effectively unlimited, so the URL space is too. |
| Three or more filters stacked together | Blocked or canonicalised to the nearest useful page | Few people search for such specific combinations, and they are the main source of near-duplicate pages. |
| A filter combination with no products | Returns a genuine not-found response at that URL | A page that says “no results” but returns a normal response invites a search engine to keep crawling nothing. |
| Internal site-search results | Not indexed and not crawled | Crawlers do not submit searches, and the results are unbounded, thin and duplicated by the category pages. |
| Pagination, such as page two of a category | Each page has its own URL and its own canonical, linked with ordinary anchors | Google no longer uses the previous and next link tags, and canonicalising every page to page one hides the products on the later ones. |
| Tracking and session parameters | Canonical to the clean URL; stripped from internal links | They create copies of pages that already exist, and internal links should never point at them. |
What does a product page need to rank, and what does product schema need to say?
A product page needs a unique title and description, accurate specifications, clear images, a visible price and stock state, and Product structured data that matches what is on the page. The markup should describe the page honestly: if a value is not visible to the shopper, it should not be in the schema.
- Unique copy. Manufacturer descriptions are used by every other retailer of the same product, so a page that repeats them has nothing of its own to rank on. Even a short, specific description that answers the questions buyers ask is a better page. How much to rewrite depends on how much of the catalogue earns its revenue from search.
- Required fields. For Google's merchant listing experiences the Product needs a name, an image and an Offer, and the Offer needs a price above zero and a currency as a three-letter code. Availability is recommended, and the listing may not show if a stated price validity date has passed.
- One seller only. Merchant listing markup describes an Offer made by the merchant selling the product, not an aggregate across several sellers, and it only applies to pages where a shopper can actually buy. A comparison or review page should not carry it.
- Match the page. Price, currency and availability in the markup have to agree with what the shopper sees and with what the checkout charges. When the template pulls them from the same data source as the page, this stays true automatically. When markup is hand-maintained, it drifts.
- Shipping and returns. Standard shipping and returns information is better stated once at organisation level than repeated on every product, with product-level values only where a product differs. If your policy is complicated, the first job is to state it clearly on the site.
- Variants. Sizes and colours need a deliberate decision: one URL with a selector, or a URL per variant. Either can work. What does not work is a URL per variant with identical content and no canonical logic, which is how a few hundred products become many thousands of near-copies.
- Reviews. Mark up only genuine reviews that are visible on the page, from real customers. Reviews written by the shop about itself, or imported from elsewhere without being shown, do not belong in the schema.
- Validation. Test the template, not one page. Check a product with several variants, a product on sale, and a product that is out of stock, because those are the cases where markup is most often wrong.
What should a product page do when the product is out of stock or discontinued?
Keep the page live and marked as out of stock when the product is coming back. Redirect to the closest equivalent when it has been discontinued and a genuine alternative exists. Return a proper not-found only when nothing relevant remains. Deleting pages that earned links, with no plan, throws that value away.
| Situation | What the page does | What the markup and feed say |
|---|---|---|
| Temporarily out of stock, restock expected | Stays live and indexable. Shows the stock state plainly, offers alternatives and a back-in-stock notification where one exists. | Availability set to out of stock, matching the page. The feed agrees. |
| Available to order but not yet in hand | Stays live. States clearly that it is on back-order or pre-order, and what that means for delivery. | Availability set to the back-order or pre-order value, not to in stock. |
| One variant sold out, others available | Stays live. The sold-out variant is shown as unavailable; the page does not become out of stock as a whole. | Each variant carries its own availability, so the feed does not advertise a size you cannot send. |
| Seasonal product, off sale for part of the year | Stays live with its links and history intact, with a clear note and a route to related products. | Out of stock while off sale, returning to in stock when it returns. |
| Discontinued, with a close successor | A 301 redirect to the successor, or the page stays with a clear pointer to the replacement while it still earns visits. | Removed from the feed. No offer is stated for a product you do not sell. |
| Discontinued, with no genuine equivalent | Redirect to the most relevant category if the intent matches; otherwise a genuine not-found response. | Removed from the feed and the sitemap. |
| Whole range or brand withdrawn | A planned decision, not a bulk delete: redirect to the category that now serves that intent, and keep any guide content that still ranks. | Removed from the feed and the sitemap in the same release as the redirects. |
How do product feeds fit with ecommerce SEO?
A product feed and your product pages describe the same products to Google, so they have to agree. When price or availability in the feed does not match the page, listings can be disapproved and shoppers see numbers that are wrong. The fix is to generate both from one source of truth.
A feed is a structured file sent to Google Merchant Center, and it can also help Google discover products on a large catalogue, alongside a sitemap. The on-page Product markup is a second description of the same thing. Problems arise when they come from different places: a feed exported nightly from the stock system, markup hard-coded into a theme, and a visible price edited by hand in the admin. Each can be right on its own and wrong together. Making them all read from the same product record is dull and effective, and it is easier to do while the store is being built than to retrofit.
Be clear about the line between this and paid work. Keeping the data accurate, complete and consistent is part of ecommerce SEO. Running campaigns on top of the feed, deciding bids and structuring them is a separate discipline, covered under Google Shopping management. The two share a data source, so we plan them together, but we do not sell one as the other.
The point
Keeping the data accurate, complete and consistent is part of ecommerce SEO.
How should internal linking work in an online shop?
Every product you want found should be reachable through ordinary HTML links from a category, and every category from the menu or a parent. Use breadcrumbs, related-product links and editorial links to pass authority to the pages that earn money, and do not make any product depend on a search box.
- Menus link to categories. The main navigation should point to the categories you most want to rank, as crawlable links, not to a script that builds the menu on demand.
- Categories link down. A category links to its subcategories, and a subcategory links to its products. Google's own ecommerce guidance describes this chain. Products reachable only through site search may never be found, because crawlers do not submit searches.
- Breadcrumbs reinforce the hierarchy. They give every product a consistent route back to its category and, with matching breadcrumb markup, show the structure explicitly.
- Related products link sideways. Links between genuinely related products and categories keep a crawler moving and help a shopper compare, but a block of fifty arbitrary links dilutes everything on the page.
- Best sellers earn prominent links. Linking to the products and categories you most want to rank from the homepage and from editorial content tells a search engine they matter. More internal links generally signal greater importance.
- Guides link into categories. A buying guide that never links to the category it helps with is wasted. The anchor should describe the category in the words a buyer would use.
- Orphans get fixed or removed. Products in the sitemap but linked from nowhere should either be linked properly or deliberately retired. Load-more buttons and infinite scroll need a crawlable link to each page of results behind them, because crawlers do not click.
- Links serve conversion as well. A category that is easy to move around is also easier to buy from, and conversion work on the shop tends to touch the same templates.
Which ecommerce migrations put rankings at risk?
Any change that alters URLs, templates or hosting can put rankings at risk: a replatform, a category restructure, a domain change, a redesign, a move to a JavaScript-rendered storefront, or adding a country version. The risk is rarely the new shop. It is the old URLs that stop resolving to anything.
| Change | What puts rankings at risk | What to do before launch |
|---|---|---|
| Replatforming to a new ecommerce platform | Platforms use different URL patterns by default, so every product and category can change address at once. | Map every old URL to its new equivalent, redirect all of them with a 301, and compare indexation before and after. Planning the migration for search comes before the build, not after. |
| Restructuring or renaming categories | Merged or renamed categories change URLs and can leave old pages with inbound links and nowhere to go. | Decide which category inherits the history of each old one, redirect accordingly, and update internal links so they do not rely on the redirects. |
| Changing domain | Everything the old domain earned depends on the redirect from the old to the new. | Redirect page to page, not everything to the homepage, and keep the old domain and its redirects live. |
| A redesign on the same platform | Templates change, and with them headings, copy, internal links and markup, often removing text that was earning the ranking. | Audit what ranks now, carry the performing copy and structured data across, and check the new templates before launch. |
| Moving to a headless or JavaScript-rendered storefront | Content drawn by script may not be in the HTML a crawler receives, so pages that ranked can appear empty. | Check what a non-rendering fetch of a category and a product page returns before committing to the architecture. |
| Adding a country or language version | Duplicated content across versions, wrong-version results and missing alternate signals. | Treat it as a separate planning job. International SEO covers URL structure and hreflang. |
How does ecommerce SEO fit with the ecommerce build, and does the platform matter?
It fits best before the build, because category architecture, filter handling, product markup and redirects are build decisions. Retrofitting them to a live shop costs more and risks more. The platform matters less than the quality of its configuration: WooCommerce, Shopify and custom builds can all be made to behave, and all can be set up badly.
Each platform has its own habits. WooCommerce commonly produces parameter URLs for sorting and layered filters, plus archive pages for product tags, all of which need a decision. Shopify commonly exposes the same product under more than one path, which canonical tags are meant to resolve, and its themes control much of the markup. A custom build has no habits but also no defaults, so every rule has to be written. None of this is a reason to choose one platform over another; choosing between Shopify, WooCommerce and a custom build turns on the business, not on SEO.
If your shop is on Shopify, our Shopify agency page covers the platform side. If it is being planned from scratch, the sensible order is to settle the category structure and URL rules first and then build to them, which is how the ecommerce development service is run. If it is already live, we start with the audit and change the templates.
The point
If it is already live, we start with the audit and change the templates.
What does an ecommerce SEO audit cover?
An ecommerce SEO audit reviews how a shop is crawled, indexed and presented, then ranks what it finds by cost. It covers the URL space, indexation, category and product templates, structured data, feeds, internal links, redirects and speed. The test of a good one is that each finding carries a fix a developer can build.
- The real URL space. A crawl that follows filters, sort orders, pagination and variants, to see how many pages the shop actually presents to a search engine compared with how many it means to.
- Indexation against intent. What Google has indexed compared with what you want indexed, using Search Console, so unwanted filter pages are found and wanted categories that are missing are found too.
- Category templates. Titles, headings, introduction and supporting copy, subcategory links and pagination behaviour, checked on the templates rather than one category at a time.
- Product templates. Titles, descriptions, variant handling, canonical logic, breadcrumbs and Product markup, tested on awkward cases such as a variant product, a product on sale and a product out of stock.
- Feeds and markup. A comparison of what the feed, the structured data and the visible page each say about price and availability.
- Stock-state handling. What actually happens, today, to a product when it sells out or is retired, found by looking at examples rather than asking.
- Redirects and errors. Chains, loops, old URLs that still earn links, and pages returning errors that should return something else.
- Speed on real devices. Category and product page performance on a mobile connection, since shop templates are weighed down by apps, tracking scripts and images.
- Next steps. A written report ranked by impact, plus the specifications. For the wider picture, our ecommerce SEO audit checklist sets out every check in the order we run it.
How do you judge an ecommerce SEO agency, consultant or specialist?
Judge them on specifics: who changes the templates, how they choose which filtered pages to index, what they do with discontinued products, and how they protect rankings during a migration. Ask each of these, and ask to see the written output, not a case-study slide.
- Who implements? If the answer is “your developers”, ask who writes the specification and who checks the result. A consultant who diagnoses and an agency that also builds are both legitimate, but you should know which you are hiring.
- How do you decide which filters are indexable? A good answer starts from how people search and ends with a rule per filter. A bad answer is “we block all of them” or “we index everything”.
- What happens to a product when it sells out or is discontinued? You want a policy for each case, not a general preference for redirects.
- How do you protect a migration? Look for a URL map before the build, redirects for every old URL, and a check of indexation afterwards.
- What will you refuse to do? Stuffing category pages with keyword text, generating thousands of thin filter pages, and buying links should be on that list.
- Can you show me the output? A sample audit, a redirect map or a template specification, with client details removed, is more informative than a promise. Our own record is international rather than UK-based, and the work we have built is shown as built sites, not as ranking claims.
- Is the arrangement right for the size of the job? Whether to use a freelancer, an agency or a hire is a real question, and the guide to choosing a partner for ecommerce SEO and the broader advisory SEO consultancy route both bear on it.
When is ecommerce SEO the wrong first step, and what drives the cost?
It is the wrong first step when the problem is not search: an uncompetitive range, margins that cannot support the cost of acquiring customers, a checkout that loses buyers, or a platform that cannot be changed. Cost follows the work: catalogue size, how many URLs the platform generates, how competitive the categories are, and whether templates need developer changes.
Organic traffic delivered to a shop that cannot convert it is wasted, so we look at the shop before we sell anything. If people already visit and leave, the first spend should go on the pages they land on. If you need sales sooner than organic search can supply them, paid search is a faster test, and whether SEO or paid search suits you first is worth settling before committing to either. For the wider picture of how a retailer should think about marketing, see our ecommerce retail sector page.
We do not publish prices, and cost depends on what the audit finds. Catalogue size, platform behaviour, the amount of category content needed, whether a migration is involved and who does the implementing are what move it. If you want to talk it through, tell us about the shop and we will say whether ecommerce SEO is the right thing to buy now.
The point
We do not publish prices, and cost depends on what the audit finds.
What Ecommerce SEO covers
Not a menu to pick from. Most projects use some of this and ignore the rest, and the scope conversation is mostly about working out which half you actually need.
Category and product architecture
Which pages exist, what each one targets, how deep they sit and how they link, planned so that the category pages that earn money are the strongest pages in the shop.
Faceted navigation control
Deciding which filter combinations deserve a page of their own and which are blocked, consolidated or returned as not found, so the catalogue stops generating duplicate URLs.
Product structured data
Product and Offer markup that matches the visible page: name, image, price, currency, availability, and shipping and returns information where it applies.
Feeds and stock states
Product feeds and on-page markup that agree with each other, and a defined treatment for out-of-stock, back-order, seasonal and discontinued products.
Internal linking and breadcrumbs
Menus, category and subcategory links, breadcrumbs and related-product links built as crawlable HTML links, so no product depends on a search box to be found.
Pagination and crawl management
Paginated listings with their own URLs and crawlable links, infinite-scroll patterns made crawlable, and robots rules written to the shop's real URL patterns.
Migration protection
A full URL map, redirect plan and before-and-after checks for replatforms, restructures and domain changes, so what the old shop earned is not discarded.
Category and buying-guide content
Copy for category pages and guides that answers what a buyer is deciding, written to sit alongside the products rather than push them off the screen.
Ecommerce SEO audit
A written, prioritised review of how a shop is crawled, indexed and presented, with specifications a developer can act on.
Why this is worth doing properly
Fixes happen in the platform, not in a PDF
Most shop SEO problems are template problems. Because we build stores as well as optimise them, a finding becomes a change to the template rather than a recommendation to somebody else's developer.
Fewer pages, better pages
The aim is not to get more URLs indexed. It is to get the right ones indexed, so authority is concentrated on the category pages that earn money instead of spread across filter permutations.
Stock changes stop costing you rankings
A defined policy for sold-out and discontinued products means a page that earned links is not deleted, and a page that no longer sells does not mislead anyone.
Migrations that keep what the old shop earned
The URL map and redirect plan are written before anything moves, so the question after launch is how fast the new shop is re-crawled, not what was lost.
Honest about what search cannot fix
If the range, the margin or the checkout is the real problem, we say so before you spend on organic traffic that arrives at a shop that cannot convert it.
What you are handed, and who this suits
Deliverables
- A category and product page architecture, with each page's search target and parent
- A faceted navigation rule set covering indexed, blocked, consolidated and not-found URLs
- Product and Offer structured data for your templates, validated against the visible page
- A stock-state policy and the template changes that implement it
- An internal linking and breadcrumb plan, with orphaned products identified
- A prioritised audit report with a technical specification for each fix
- A URL map and redirect plan where a migration or restructure is involved
- Re-crawl and indexation checks against the baseline after implementation
Everything on that list is yours on final payment, in your own company's accounts — the handover is written into the contract, not offered as a favour at the end.
Usually a fit for
- Shops whose filters, sort orders or variants have generated far more URLs than they have products
- Retailers whose category pages have little more than a grid of products and a heading
- Stores planning a replatform, a category restructure or a domain change
- Shops with a product feed and on-page data that disagree about price or stock
- Businesses holding an ecommerce audit from elsewhere that nobody has implemented
- Stores on WooCommerce, Shopify or a custom build where the fix means changing templates
Built with
- Google Search Console
- Google Analytics 4
- Schema.org Product and Offer markup
- JSON-LD structured data
- Google Merchant Center product feeds
- XML sitemaps
- robots.txt
- rel=canonical
- 301 redirect mapping
- Core Web Vitals
Chosen per project, not per fashion. If your team already runs something else and can maintain it, that usually wins.
Ask what this would involve for youFour gates, and you sign off at each one
Every stage ends with something you can read and approve — crawl and catalogue review, architecture and url rules, implement and validate, measure and extend. Nothing moves to the next stage until you say so.
- 01
Crawl and catalogue review
We crawl the shop as a search engine would, compare what is indexed with what should be, and read the templates, feeds and Search Console data. The output is a written finding for each template, ranked by what it costs you.
- 02
Architecture and URL rules
We agree the category structure, which filters earn a page, how pagination behaves, what happens to sold-out products, and how product data is marked up. These rules are written down before anything is changed.
- 03
Implement and validate
Our developers make the template, redirect, markup and linking changes on staging, check them against the rules, and deploy with your approval. Where your own team builds, we write the specification and review what ships.
- 04
Measure and extend
Indexation, crawling and enquiries or orders are checked against the baseline. What is working is extended to more categories, and what is not is changed, with the reasons recorded.
Explore Related Services
Frequently Asked Questions
What do ecommerce SEO services include?
They cover the problems specific to shops: category and product page architecture, faceted navigation and duplicate content, product structured data, product feeds and stock states, internal linking and migration safety. Content for category pages and guides sits alongside. The work is implemented in your templates, not left as a list of recommendations.
How is ecommerce SEO different from normal SEO?
A shop generates pages at scale, so one template error repeats across the whole catalogue. Filters, sort orders, variants and sold-out products all create URLs nobody wrote. Normal SEO concentrates on a few dozen pages being good; ecommerce SEO concentrates on rules that keep thousands of generated pages from competing with each other.
How do I choose an ecommerce SEO agency?
Ask who will change the templates, how they decide which filtered pages get indexed, what happens to discontinued products, and how they protect rankings during a migration. Specific answers matter more than a portfolio. Our guide to choosing an ecommerce SEO agency sets out the full list of questions.
Do I need an ecommerce SEO consultant or an agency?
A consultant suits a team that already has developers and only needs a diagnosis and a plan. An agency suits a shop that needs the template changes made as well. The deciding question is who implements. Our SEO consultancy page covers the advisory route, and we can work either way.
Do you do SEO for WooCommerce and Shopify stores?
Yes. We build on both, so we know where each platform generates duplicate URLs, how its templates output product markup, and which fixes need a developer. The principles are the same on a custom build. Platform-specific Shopify work is covered on our Shopify agency page.
What is an ecommerce SEO audit and what does it find?
It is a written review of how a shop is crawled, indexed and presented. It usually finds filter and parameter URLs being indexed, thin or missing category content, product markup that disagrees with the page, orphaned products and redirect chains. A good one ranks findings by what they cost you and specifies the fix.
Should faceted navigation URLs be blocked from search engines?
Most should, but not all. Filter combinations nobody searches for should be blocked or consolidated. A combination that matches a real search, such as a colour and a product type, may deserve its own indexable page with its own title and copy. The rule is decided per filter, from how people actually search.
What happens to SEO when a product goes out of stock?
It depends on whether the product is coming back. A temporary stock-out should keep the page live, marked as out of stock, with alternatives shown. A permanently discontinued product should redirect to its closest equivalent, or return a not-found response if none exists. Deleting pages that earned links, without a plan, loses that value.
What decides the cost of ecommerce SEO services?
Catalogue size and how many URLs the platform generates, how competitive the categories are, whether templates need developer changes, whether a migration is involved, and how much category content must be written. We scope it after looking at the shop. What SEO costs per month in the UK explains the pattern.
Can ecommerce SEO fail if the shop itself is the problem?
Yes. Organic traffic to a shop with an uncompetitive range, poor margins or a checkout that loses buyers produces visits, not revenue. We would say so before you pay for it. Sometimes paid search against organic is the faster test, or the checkout needs work first.
Let's Build Something That Matters.
Tell us what you're trying to achieve and we'll help you find the right solution.