Ecommerce technical seo is a different discipline from technical SEO on a 40-page brochure site. The problems aren’t subtle tag errors — they’re arithmetic. One filter set on one category quietly generates fifty thousand URLs, and by the time anyone notices, Googlebot is spending its crawl allowance on color-plus-size combinations nobody searches for.
What follows is the work in the order it pays off on a real store. Technical seo for ecommerce rewards fixing the crawl and index layer first; the on-page refinements are worth more once crawlers can find and prioritize your money pages.
Crawl budget is a real constraint above ~10,000 URLs
On small sites, crawl budget is a non-issue and anyone who tells you otherwise is selling something. On a catalog with 50,000 products and faceted navigation, it’s the primary constraint. Google allocates a finite crawl rate per host, and every request spent on a parameter permutation is a request not spent on the new product you launched this morning.
Diagnose it from server logs, not guesswork. Pull a month of Googlebot hits and group by URL pattern. The typical finding on an unmanaged store is that 60 to 80 percent of crawl goes to filtered, sorted, or paginated URLs, and category pages get crawled weekly while new products wait a month for discovery.
Fixing crawl allocation is usually the single highest-leverage technical change available, and it costs nothing but decisions.
Faceted navigation: the biggest risk on any store
Filters multiply. Five facets with six options each is 46,000 combinations per category, before sort order and pagination. Left crawlable and indexable, that’s an infinite URL space, index bloat, and duplicate content all from one feature.
There is no single correct setting — there’s a policy applied per facet:
- Canonicalize filtered views back to the clean category URL when the facet has no independent search demand. Color and size usually fall here.
- Block parameter paths in robots.txt for anything that should never be crawled: sort order, view toggles, session IDs, tracking parameters. Blocking saves crawl budget; it does not remove already-indexed URLs.
- noindex, follow where a page must stay crawlable for discovery but has no business in the index. Note that robots.txt and noindex are mutually exclusive — a blocked URL is never crawled, so its noindex is never read.
- Static URLs only for facets with real search demand. “Waterproof hiking boots” earns a proper page with its own title, H1, and intro. “Blue, size 9, price ascending” does not.
Also make filter links non-crawlable where you’ve decided they shouldn’t be followed — rendering them as buttons with JavaScript-driven state rather than anchor tags stops the URL space from existing in the first place. That’s cleaner than generating millions of URLs and then trying to suppress them.
Canonicals, and the ways stores get them wrong
Canonical tags are hints, not directives, and Google ignores them when the signal contradicts everything else on the page. Three failure patterns account for most damage:
- Everything canonicalized to the homepage. Usually a plugin default. It effectively tells Google your catalog doesn’t exist.
- Paginated pages canonicalized to page one. Products on pages two onward lose their crawl path and drop out of the index.
- Cross-domain or mixed-protocol canonicals left over from a migration, pointing at a staging host or an http:// version.
Products reachable through multiple categories are the other classic. If the same SKU lives at three category paths, pick one canonical product URL and use it everywhere — or better, serve products from a flat /products/sku-name/ path independent of category entirely. That removes the problem instead of patching it.
Pagination without rel=next and rel=prev
Google announced years ago that it no longer uses rel=”next” and rel=”prev” for indexing. A large share of ecommerce SEO advice still recommends them. They’re harmless and pointless.
The current approach: keep paginated pages crawlable, self-canonicalize each page to itself, and link between pages with real anchor tags rather than infinite scroll alone. Infinite scroll is fine for users if you back it with paginated URLs that load directly. Keep descriptive category copy on page one only — repeating it across every page creates duplication you didn’t need.
If your category has 800 products across 40 pages, the deep pages are effectively invisible regardless of markup. That’s a taxonomy problem, not a pagination problem: build subcategories so no listing runs longer than a handful of pages.
Structured data, stock status, and rich results
Product schema drives price, availability, and review snippets. Those don’t lift rankings directly but they lift click-through, which on a competitive SERP is worth as much as a position.
Mark up name, image, description, brand, SKU or GTIN, and offers with price, priceCurrency, and availability. Accuracy is the rule that matters most: schema claiming InStock on a sold-out page invites a manual action against your rich results. Review markup carries its own constraint — it must not be self-serving. Genuine customer ratings on the product page are legitimate; ratings you wrote about your own products, or store-level ratings smuggled into Product markup, are not.
Add BreadcrumbList markup while you’re there. It’s cheap, it renders in the SERP, and it reinforces the site structure you worked to get right.
Out-of-stock, discontinued, and URL lifecycle
Products die constantly and most platforms handle it by deleting. That destroys pages that took years to rank. Write the policy down and implement it in code:
- Temporarily out of stock: keep live and indexed, availability OutOfStock, show restock timing and related in-stock products. No redirect.
- Discontinued with a successor: 301 to the nearest equivalent product. Redirecting to the homepage or a top-level category is treated as a soft 404.
- Discontinued, no equivalent, no links, no traffic: 410 Gone for a clean exit.
- Seasonal: keep the URL permanently rather than rebuilding it each year.
Audit your redirect chains at the same time. Migrations layer 301s on top of 301s, and a four-hop chain wastes crawl and leaks equity. Flatten them to a single hop.
Speed, rendering, and finding all of this at scale
Core Web Vitals matter more on ecommerce than most verticals because the same fixes move conversion. On product and category pages the wins are unexciting: correctly sized and compressed images, lazy loading below the fold, removing dead third-party tags, and reserving space for elements that load late so the layout stops shifting. Judge by field data from real users, not a lab score on a fast desktop.
Rendering is the other trap. If products only appear after JavaScript executes, discovery gets slower and less reliable. Server-render category listings and product content where you can.
None of this is findable by hand at catalog scale, which is where crawling tooling comes in. SEO Rocket runs an instant quick scan of about 25 pages and deep full-site crawls verified at 900+ pages, giving concrete evidence per issue — the actual duplicate titles, the actual URLs, the actual H1 text — alongside PageSpeed and Core Web Vitals with real-user field data. Its keyword research and content gap analysis handle the other half of the job: deciding which categories and products deserve pages at all. It does not manage product feeds, Merchant Center, or inventory; those remain in your platform.
Expect technical fixes to take four to twelve weeks to show up, because Google has to recrawl before anything changes. Watch indexed page counts and crawl distribution in your logs as the early indicators, and remember that two or three positions of daily movement is noise, not a result.
