Ecommerce technical SEO is the work that lets search engines crawl, render and index the right URLs of an online store, and understand what each product page sells. It covers crawl control, JavaScript rendering, index rules per page type, site architecture, pagination, XML sitemaps, structured data and page speed. On a ten-page brochure site most of this takes care of itself. On a catalog it does not, because every product, variant, filter, sort order, page number and language multiplies the number of URLs a crawler can find.
This guide is for stores that already did the basics. If you need a first pass, start with the ecommerce SEO audit, and for filters read the faceted navigation SEO guide. Here we go one level deeper: how to measure what Googlebot actually does on your store, and how to set rules per template that hold when the catalog doubles.
The URL inventory: count what a crawler could find before you fix anything
Most technical SEO problems on stores are arithmetic. Before you change a single tag, write down how many URLs each template can produce. Take an outdoor gear store as the running example:
- 4,200 products, of which 1,300 have variants, for 11,000 variant SKUs in total.
- 180 categories, each with 5 filters, 4 sort orders and 24 products per page.
- 3 languages (English, Dutch, German) in subfolders.
- Variant selection through a ?variant= parameter, internal search at /search?q=.
The products alone give 12,600 product URLs across three languages. Variant parameters add up to 33,000 more if they are linked. Categories with an average of 3 pages give 1,620 listing URLs, and the 4 sort orders multiply that to 6,480 before a single filter is clicked. Combine two filters and you reach six figures. The store wants about 14,200 URLs in the index: products, categories and their pagination, in three languages.
Crawlable URLs vs the URLs the store wants indexed
Illustrative example| Category | URLs |
|---|---|
| Product URLs, 3 languages | 12,600 |
| Variant parameter URLs, if linked | 33,000 |
| Category listing URLs | 1,620 |
| Listing URLs with 4 sort orders | 6,480 |
| URLs wanted in the index | 14,200 |
That gap between possible and wanted URLs is the whole job. Every rule in the rest of this guide either keeps unwanted URLs from being found, tells Google which version to index, or makes the wanted URLs easier to reach and understand.
Server logs show what Googlebot actually requests
A crawler like Screaming Frog shows what can be found from the home page. Your server logs show what Googlebot really fetched, how often and with what response. On a catalog these are rarely the same thing. Ask your host or platform for raw access logs covering at least 30 days, filter on the Googlebot user agent and drop hits that fail a reverse DNS check, because many scrapers fake that user agent.
Then group every request by template, using URL patterns you already know (/products/, /collections/, ?sort=, ?page=, /search). The useful questions are simple:
- Share of requests per template. If sort and filter URLs take 40% of Googlebot hits while products take 25%, crawl activity is going to the wrong place.
- Days since last crawl per product. Products Googlebot has not requested in 30 days will show stale prices and stock in search.
- Status codes per template. A pile of 301s on product URLs usually means internal links still point to old URLs.
- Never crawled products. Products in your catalog export that do not appear in 30 days of logs are effectively invisible.
If you cannot get logs, the Crawl Stats report in Search Console is the next best source. It breaks requests down by response code, file type, Googlebot type and purpose, where discovery means a URL Google never crawled before and refresh means a recrawl of a known page. A store that launches 300 new products a week and sees almost no discovery requests has a discovery problem, usually in sitemaps or internal links.
Crawl waste on a catalog: soft 404s, redirect chains and noindex
Google's crawl budget guide is written for sites with 1 million or more unique pages that change about weekly, or 10,000 or more pages that change daily. A store with 4,200 products is below both lines, but filter and sort combinations can push the crawlable URL count far above them, and price or stock changes make product pages change daily. So treat crawl efficiency as a real constraint once your logs show Googlebot spending most of its time outside your wanted URLs.
The same guide lists what wastes crawling on stores:
- Soft 404s. A sold-out product page that says "no longer available" with a 200 status keeps getting crawled. Return a real 404 or 410 for products that are gone, or redirect them to a close successor.
- Long redirect chains. A product renamed three times can sit behind three hops. Point internal links and sitemap entries straight at the final URL.
- noindex as a crawl saver. Google still requests a noindexed page and then drops it, so noindex does not save crawling. Use robots.txt for URL patterns you never want crawled, such as sort orders and internal search.
- Missing lastmod. Google reads sitemaps regularly. An accurate <lastmod> on changed products helps it pick what to recrawl.
- No 304 support. Servers that answer 304 Not Modified for unchanged pages let Google reuse its copy, which matters when thousands of product pages did not change since the last visit.
Server health counts too. When the store answers with 5xx errors or 429 rate limits, Google slows down crawling and only speeds up again gradually. A slow category template during a sale can cost you recrawls of the very products you just repriced.
Rendering: what Googlebot sees before and after JavaScript
Google processes JavaScript sites in three phases: crawling, rendering and indexing. According to Google's JavaScript SEO basics, every page with a 200 status goes into a render queue, where it can wait a few seconds or longer. Two consequences matter for stores. First, Google only discovers links that are <a> elements with an href, so a "related products" carousel built from click handlers passes no links. Second, anything that only exists after rendering arrives later than what is in the HTML.
That second point is critical for product data. Google states that dynamically generated Product markup can make Shopping crawls less frequent and less reliable, which is a problem for fast-changing content like price and availability. If your theme or headless front end injects Product JSON-LD with JavaScript after a client-side API call, move it into the server-rendered HTML.
A quick test per template: open the page source (not the inspector) and search for the product name, the price, the GTIN and the first two category links. Then run URL Inspection in Search Console and compare with the rendered HTML. Anything missing from the source but present after rendering depends on the render queue.
- Must be in the server HTML: title tag, canonical, robots meta, H1, price, availability, Product JSON-LD, breadcrumb links, links to products on category pages, pagination links.
- Fine to render client side: review widgets below the fold, recently viewed items, personalized recommendations, chat.
Index rules per template, written once for the whole catalog
Per-URL decisions do not scale. Write one rule per template and enforce it in the theme or platform settings. For the outdoor store it looks like this:
Index rules per template for the outdoor store
| Product page | Index | Self-referencing | Yes |
|---|---|---|---|
| Variant URL (?variant=) | Index separately only when each variant has its own content and demand | The product URL if variants share one page | |
| Category page 1 | Index | Self-referencing | Yes |
| Category page 2 and later | Index | Self-referencing | No |
| Sort order URLs | Blocked in robots.txt, never linked as plain links | ||
| Filter URLs | Only whitelisted combinations get a static URL and index; the rest follow your faceted navigation rules | ||
| Internal search results | Blocked in robots.txt | ||
| Out-of-stock product | Stays indexed with availability set to OutOfStock | ||
| Discontinued product | 301 to a successor or the closest category if one exists, otherwise 404 or 410 | ||
| Cart, account, checkout, compare | Blocked in robots.txt | Never |
Field-level rules such as titles, descriptions and images per product page are covered in the product page SEO guide. Platform-specific settings live in the Shopify SEO checklist and the Magento SEO guide.
Site architecture for large catalogs: depth, hubs and orphan products
Architecture decides how quickly a crawler reaches a product and how much internal link weight it gets. On a catalog, the menu links to categories, categories link to products, and products link sideways to related products and back up through breadcrumbs. Three checks keep that structure healthy as the catalog grows:
- Click depth. Crawl from the home page and count clicks to each product. If listing pages only link to the next page, a product on page 6 of a 140-product category sits 7 clicks from the home page. Splitting that category into four subcategories of 35 products brings it back to 4.
- Category size. A category with 1,200 products and 24 per page has 50 pages, and the products on the last pages get crawled least. Subcategories based on real attributes (insulation type, fill weight) shorten that tail and give you landing pages for real queries.
- Orphans. Compare the URLs in your product export with the URLs a crawler reached. Products in the export but not in the crawl have no internal links: often items assigned to no category, or listed only in a category that is hidden from the menu.
Orphans are usually a product data problem, not a theme problem. A product with an empty category field never appears on a listing page. Fix the category assignment in your catalog first, then check that the template prints the link as a crawlable <a href>.
Page numbers, load more buttons and infinite scroll
Google's pagination guidance for ecommerce is short and specific. Give each page its own URL, for example ?page=2. Do not set page 1 as the canonical for the whole series, because that tells Google pages 2 and later are duplicates and the products on them lose a path to discovery. Link pages to each other with normal <a href> links. Google no longer uses rel="next" and rel="prev", although other search engines may.
Load more buttons and infinite scroll need care. Google's crawlers do not click buttons and generally do not trigger JavaScript that needs a user action. If your category uses infinite scroll, keep a paginated version with real links behind it, and make sure every product is also in your XML sitemap or a Merchant Center feed so it can be found without the listing.
Two catalog-specific tips: choose a page size that keeps most categories under five pages, and never put page numbers behind a # fragment, because Google ignores fragment identifiers.
XML sitemaps generated from product data
A sitemap is a list of the URLs you want in search. On a store it should be generated from the catalog, not from a crawl. Google's sitemap documentation sets the limits and rules:
- Each sitemap holds at most 50,000 URLs or 50 MB uncompressed. Use a sitemap index to combine several files.
- Use absolute URLs and list only canonical URLs, the version you want shown in results.
- Google ignores <priority> and <changefreq>, so do not spend time on them.
- Google uses <lastmod> only when it is consistently accurate. Change it for meaningful updates to main content, structured data or links, not for a new copyright year.
Split sitemaps by template and language, for example products-en.xml, products-nl.xml and categories-en.xml. Search Console then reports indexing per file, so you can see that 96% of English products are indexed while only 61% of German ones are. Leave out redirected, noindexed, canonicalized and deleted URLs. And drive <lastmod> from the product record: a price change updates the Offer markup, so it counts as a structured data change.
Structured data at scale: generate it from the catalog, not the theme
Most stores output Product markup from a theme template, which works until the data behind it is incomplete or the variants get complicated. At catalog scale, treat structured data as an export of your product data and check it the way you check a feed.
For variants, Google supports ProductGroup markup. The parent carries a productGroupID (the parent SKU), variesBy names the dimensions that change, and hasVariant lists each variant as a Product. Supported variesBy values are color, size, suggestedAge, suggestedGender, material and pattern. There are two setups:
- Single page: all variants live on one page, with one canonical URL for the group. Each variant still needs a distinct URL that preselects it, usually a query parameter.
- Multi page: each variant has its own page with full, self-contained markup. There is no single canonical for the group.
Take a down jacket sold in 3 colors and 5 sizes: 15 variants, each with its own GTIN, price and stock. If the template reads color and size from the parent, all 15 variant objects report the same values and Google sees duplicates. If 4 of the 15 GTINs are empty, those variants go out without an identifier. Neither problem shows up in a theme preview, and both are fixed in the data, not the markup.
Practical checks at scale: validate one URL per template with the Rich Results Test, then watch the Merchant listings and Product snippets reports in Search Console for errors spread across many URLs. Count empty GTIN, brand, color and size values per category in your catalog before you blame the template. For a reference example to compare your output with, use the product schema generator.
LCP images, layout shift and app scripts on catalog templates
Speed problems on stores repeat per template, so measure one product page and one category page per template type on a mid-range phone, then fix the template. The product image is usually the Largest Contentful Paint element. Never lazy-load it, make it discoverable in the HTML source instead of injecting it with JavaScript, and give it fetchpriority="high". Break slow LCP down into its parts (server response, load delay, load time and render delay) before you buy a faster host, because the delay is often a script that runs before the image is requested.
Layout shift on catalog pages often comes from data: images without width and height, swatches that load after the price, a "low stock" badge that pushes the add-to-cart button down. Store image dimensions with the image record so the template can reserve space. Interaction delays usually come from filter scripts and third-party apps, so list every script on a category page with the app that loads it and remove what nobody uses.
A quarterly technical SEO routine for a growing catalog
Quarterly technical SEO routine
Several of these checks start in the catalog rather than in the code. WISEPIM's sitemap coverage analytics matches your sitemap URLs to product records, and internal link analysis lists orphan products next to their Search Console data. Because WISEPIM keeps GTINs, categories and variant attributes complete before they are pushed to your store, the structured data and sitemaps built from that data stay correct as the catalog grows.
