E-Commerce Technical SEO
Technical SEO for stores is duplicates, canonicals, robots, sitemaps, JavaScript rendering and parameter URLs. Fix the catalog graph before you rewrite copy.
Technical SEO for e-commerce is making the catalog graph honest: one preferred URL per product and collection you care about, a crawl path that reaches them, and a sitemap that matches. Copy and keyword mapping still matter; they cannot rank URLs the engine never selects.
The conceptual loop is in How E-Commerce SEO Works. This article is the plumbing.
Duplicates: where they come from
Stores manufacture duplicates by default:
- HTTP vs HTTPS,
wwwvs apex, trailing slash vs none. - The same product at
/products/xand/collections/sale/products/x. - Variants as separate URLs with identical copy.
- Session IDs,
utmon internal links, sort parameters. - Printer-friendly and “quick view” URLs.
- Staging and the live host both reachable.
Pick a host and path convention and 301 everything else. Then pick a product URL pattern and canonical the rest to it. Shopify’s collection-product paths are a classic example—see Shopify SEO Fundamentals. WooCommerce permalinks and plugin extras are another—see WooCommerce SEO Fundamentals.
Canonicals
rel=canonical should point to the URL you put in the sitemap and in internal links.
Rules that stay out of trouble:
- Self-canonical on the preferred PDP and category page 1.
- Variant URLs you do not want indexed canonical to the parent (or use
noindexif they should not consolidate). - Filter URLs canonical to the clean category unless you intentionally index that facet (category page SEO).
- Do not canonical all products to the homepage. That is how you hide the catalog.
Canonicals do not replace redirects for URLs you have deleted. Use 301s when a SKU is gone for good.
Robots.txt and meta robots
Use robots.txt to keep crawlers out of:
- Cart, checkout, account, wishlist (unless you have a reason).
- Internal site-search result URLs (
/search?q=). - Facet systems you have decided are uncrawlable and that are not the only path to products.
Do not block CSS/JS the renderer needs if you expect modern crawlers to see the designed page. Do not block collection paths that are the only HTML links to new SKUs.
noindex is for URLs that may be crawled but should not appear in results (thank-you pages, pure sorts, thin duplicates). noindex in robots.txt is not the same as a meta robots noindex—crawlers that are disallowed never see the meta tag.
Sitemaps
An XML sitemap is a list of candidates, not a ranking switch. Include:
- Canonical product URLs in stock or that you still want found (policy choice for OOS).
- Canonical collection URLs (page 1).
- Guides and other indexable articles.
Exclude noindexed URLs, filtered faceted URLs, and cart. Lastmod should reflect real changes or omit it. Generate URL lists with care using something like the sitemap URL generator for small sets; large catalogs need an automated feed from the live canonicals.
Submit in Search Console and watch coverage: “Duplicate, Google chose different canonical than user” is a signal your hints and links disagree.
JavaScript rendering
Themes and headless storefronts often render product grids in the client. If the initial HTML is an empty <div id="root">, some crawlers will eventually render it—and some tools and some bots will not.
Verify:
- Product and collection links exist in view-source or a fetch-as-Google equivalent, not only after clicking “Load more.”
- Pagination or a crawlable “page 2” exists.
- Critical content (title, price, availability) is in the HTML or reliably rendered.
Headless commerce makes this your problem explicitly. Coupled platforms still fail it with app-laden themes.
Parameter URLs
Treat parameters as a list:
| Parameter | Usual handling |
|---|---|
sort, orderby | Canonical to clean URL; noindex if needed |
page | Index as a series or canonical policy—be consistent |
color / size if not unique pages | Canonical to parent PDP/category |
utm_* on internal links | Stop adding them internally; 301 or canonical if they leak |
Session / sid | Never index; fix the app that appends them |
Search Console URL Parameters (where available) is a last resort. Prefer not generating the URLs.
Page experience
Core Web Vitals for e-commerce is the catalog version: LCP on hero images, INP on filters, CLS on injected apps. Technical SEO includes not shipping three tag managers on the PDP.
Schema is adjacent: E-Commerce Schema Markup. It does not fix duplicates.
Hreflang, staging, and mixed signals
If you sell in multiple languages or domains, each locale needs a self-canonical and a coherent hreflang set. Do not hreflang a thin auto-translated collection to a rich original. Staging and preview hosts must be noindexed and not in the production sitemap.
Google Search Console “Duplicate without user-selected canonical” usually means internal links, ads, or the sitemap still point at the URL you thought you demoted. Fix the links; do not add a second canonical plugin.
HTTP status: soft 404s (200 on empty collections) waste crawl. Use 404 or 410 for gone SKUs you will not replace; 301 when there is a clear successor.
Pagination parameters must not create an indexable duplicate of page 1 with a different canonical. Be consistent: either ?page=2 is a series you want crawled, or it canonicals to page 1 (usually the wrong choice if products on page 2 are otherwise orphan).
Work in this order on a messy store: host/redirects → product URL canonicals → robots/sitemap agreement → renderability of grids → then copy. The e-commerce SEO guide sequences that with keyword and content work.
Key takeaways
- Most store SEO failures are duplicate and parameter URLs, not missing blog posts.
- Canonicals, robots, and sitemaps must tell the same story: which product and collection URLs are the ones to index.
- If important links exist only after JavaScript, assume some crawlers will not see them until you verify rendering.
- Core Web Vitals are part of page experience on catalog templates; apps and hero images are the usual budget.
Frequently asked questions
Should I block all filtered URLs in robots.txt?+−
Blocking in robots.txt means crawlers may never see product links that only appear on those URLs. Prefer canonicals or noindex on filter combinations, and keep category and product paths crawlable. Use robots.txt for true junk (cart, account, internal search results) after you confirm nothing important is only linked there.
How many URLs belong in the sitemap?+−
Canonical, indexable products and categories you want in the index, plus key guides. Not search result pages, not every sort order, not noindexed URLs. Split sitemaps if you exceed typical size limits.
Does a canonical tag force Google to drop duplicates?+−
No. It is a hint. If you still internally link to the duplicate as the main path, or the duplicate is the one in ads, the hint is weaker. Make the canonical URL the one humans and sitemaps use.
Related tools
- Robots.txt Generator
Build a conservative robots.txt with sitemap reference and optional disallows for carts and account paths.
- Sitemap URL Generator
Turn a list of paths or URLs into a sitemap-ready URL list with your domain prefixed.
- Meta Title Preview
Check title length, pixel-style width and a desktop SERP-style preview for e-commerce pages.
- Meta Description Preview
Draft a meta description, watch length, and preview how it may appear under a search title.
Related guides
- E-Commerce SEO Guide
A practical map of e-commerce SEO: information architecture, keyword research, product and category pages, technical indexation, schema, Core Web Vitals and measurement.
Related articles
- Core Web Vitals for E-Commerce
LCP, INP and CLS on catalog pages are usually hero images, apps and third-party scripts. How to think about those vitals for grids, filters and PDP media.
- How E-Commerce SEO Works
Catalog SEO is crawl, index, rank, then convert. Stores differ from blogs: thousands of URLs, filters, duplicates and thin product copy change the work.
- WooCommerce SEO Fundamentals
WooCommerce SEO starts with permalinks, plugin overlap, indexation and performance debt. WordPress control is real; so is the cost of a poorly hosted stack.