Technical SEO for an online store is a different job than technical SEO for a blog or a company website. A blog has a few hundred URLs that a human created on purpose. A store with 800 products can have 40,000 URLs, most of them generated by the platform: filter combinations, sort orders, variant pages, paginated categories, tag archives, cart actions. Nobody decided those pages should exist, and Google has to deal with all of them.
That is why ecommerce technical SEO is less about clever optimizations and more about control: deciding which URLs deserve to exist, making sure Google can reach and render them, and keeping the platform from quietly undoing the work. Most of the problems are invisible in the browser. The store looks fine to a shopper while Google is spending its crawl on parameter URLs and indexing a product’s size variant instead of the product.
If you have not yet run a full check of the store, start with our ecommerce SEO audit checklist, which covers content, links, and structured data alongside the technical layer. This article goes deeper on that technical layer alone: the ten things that most often go wrong on stores, how to check each one, and the order in which to fix them so that the early work is not wasted.
What technical SEO covers on a store
Technical SEO is everything that decides whether a page can be crawled, indexed, rendered, and served quickly, before anyone judges the content on it. On a store, that breaks down into ten areas:
- Indexation control: which URLs are allowed into Google’s index and which are kept out
- XML sitemaps that reflect the catalog rather than a stale snapshot of it
- URL structure for categories, filters, and products
- Canonicalization across variants, parameters, and protocol or hostname duplicates
- Pagination on category pages
- JavaScript rendering, especially on app-heavy themes and headless builds
- Core Web Vitals on the templates that matter
- Hosting and server response times
- Out-of-stock, variant, and discontinued product handling
- Structured data, which we cover separately and leave out here
None of this creates demand. Technical work removes the obstacles between an existing page and the searches it should be ranking for, so it pays off only when those pages target terms people use. If the category and page structure was never mapped to real searches, do the ecommerce keyword research first, then come back here.
Fix 1: Take control of what gets indexed
Open the Pages report in Search Console and compare the indexed count to the number of URLs you actually want in Google: products, categories, subcategories, and content pages. On most stores the indexed figure is either several times higher (index bloat) or well below (indexing failures), and both point at the same underlying problem, a lack of rules about which URLs may be indexed.
Write those rules down before touching any settings. Product pages, category pages, and content: indexable. Sort and view parameters, internal search results, cart and wishlist actions, tag archives, and filter combinations without search demand: not indexable. Then implement each rule with the right tool. A noindex tag for pages that must stay crawlable (so links on them still pass through), a robots.txt disallow for URL patterns that produce nothing worth crawling at all, and a canonical tag for true duplicates of an indexable page.
Check click depth in the same pass. In a crawler, look at how many clicks each product sits from the homepage. Products at depth four or more are crawled less often and rank worse, and the fix lives in navigation and category structure, which we covered in detail in our guide to ecommerce site architecture. Everything after this step assumes that the URLs you want indexed are reachable in three clicks and the ones you do not want are blocked or canonicalized.
Fix 2: Make the XML sitemap match the catalog
A store’s sitemap should contain every indexable, canonical URL and nothing else. In practice it usually contains out-of-stock products that now redirect, variant URLs that canonicalize elsewhere, pages marked noindex, and a lastmod date that updates every night whether anything changed or not. Each of those sends Google a signal that contradicts the page itself, and Google resolves the contradiction by trusting the sitemap less.
Google’s sitemap documentation limits a single file to 50,000 URLs or 50 MB uncompressed, and recommends a sitemap index file when you need more than one. For stores, splitting by page type (products, categories, content) is the useful version of that rule, because the Sitemaps report in Search Console then shows indexing coverage per type, and a drop in indexed product URLs stands out immediately instead of disappearing into an aggregate number.
Three checks catch most sitemap problems: crawl the sitemap URLs and confirm every one returns 200 with a self-referencing canonical, confirm that no URL in the sitemap carries a noindex tag, and confirm that lastmod changes only when the page content changes. If the platform cannot do the last one, drop lastmod entirely rather than lying with it.
Fix 3: Clean up the URL structure
URL structure on a store is mostly about parameters, because parameters are how platforms build filters, sorting, and tracking. Google’s URL structure guidance for ecommerce sites is specific here: keep the same parameter order and the same encoding everywhere, express multiple values of one filter as a single parameter (type=candy,sweet rather than type=candy&type=sweet), and avoid linking internally to temporary parameters such as session IDs, tracking codes, or user-relative values. Every inconsistency creates another URL Google has to crawl and reconcile.
For the URLs you want to rank, the rules are simpler and older: readable words instead of IDs, hyphens between words, one consistent case, and a category path that reflects the hierarchy shoppers see in the navigation. Whether product URLs include the category folder matters less than people argue about; what matters is picking one convention and never changing it without redirects.
One store-specific trap is content served through fragment identifiers, the part of a URL after a hash. Google generally does not process fragments as separate pages, so a filter or a tab that changes content only after the hash is invisible to search. That is fine for filters you never wanted indexed and a problem for anything else.
Fix 4: Canonicals and the duplicates the platform creates
Every store produces duplicates by design: the same product under several category paths, size and color variants on separate URLs, parameterized copies of every category, http and https versions, www and non-www, trailing slash and no trailing slash, upper and lower case. Canonical tags are how you tell Google which copy counts, and on most stores they are either missing where they matter or pointing at the wrong place.
Google’s guide to consolidating duplicate URLs draws two lines worth repeating. Do not use robots.txt for canonicalization; a blocked URL cannot pass its signals anywhere. And do not use noindex to choose between duplicates within your own site, because noindex removes the page from search entirely rather than consolidating it. Canonicals, redirects, and consistent internal linking are the tools; robots and noindex are for different jobs.
Audit canonicals per template rather than per URL. Load one product, one variant, one category, one filtered category, one paginated category, and one blog post, and check that each canonical points where your indexation rules say it should. Then confirm the canonical URL is the one your internal links use. A canonical that disagrees with every internal link on the site is a hint Google will happily ignore.
Fix 5: Pagination on category pages
Paginated categories are where stores hide most of their products from Google, usually by canonicalizing page 2 onward to page 1 in the belief that this “consolidates” the category. It does not. Google’s pagination guidance says plainly not to use the first page of a sequence as the canonical for the others. Each paginated page should have its own URL and its own self-referencing canonical, and the products on page 4 should be reachable through ordinary links.
The same document warns against putting page numbers in URL fragments, and against “load more” or infinite scroll implementations that only fetch products with JavaScript. If a shopper can reach page 3 only by scrolling, Google can only reach it if a real, linked URL for page 3 also exists. The fix is to keep paginated URLs in the HTML (a hidden but linked page list is enough) even when the visible experience is infinite scroll.
Check the sequence in a crawler by filtering to URLs containing your page parameter and comparing indexability. If pages 2 onward all report “canonicalized” or “noindex”, the products on them are effectively orphaned, and it explains a lot of “product pages never rank” complaints on large catalogs.
Fix 6: JavaScript rendering
Google processes JavaScript-heavy pages in three phases: crawling, rendering, and indexing, and it queues pages for rendering rather than rendering them on first fetch. Content that only exists after JavaScript runs is therefore indexed later, and sometimes not at all if rendering fails or times out. Google’s JavaScript SEO basics also spells out the two rules stores break most often: Google can only follow links that are real anchor elements with an href attribute, and single-page apps must return proper 404 status codes rather than showing a “not found” message on a 200 page.
For a typical themed store, the risk is narrower than on a full web app. Themes load product descriptions, reviews, related products, and sometimes the entire filter navigation with JavaScript, and apps inject content of their own. Use the URL Inspection tool in Search Console to view the rendered HTML for one URL per template and compare it to what a shopper sees. Anything missing from the rendered version is not being indexed.
The fixes, in order of preference: render critical content on the server, make sure product and category links are plain anchor tags, and reserve JavaScript-only loading for things that never needed to be indexed anyway, like personalized recommendations.
Fix 7: Headless and app-heavy storefronts
Headless architectures move the rendering problem to the center of the project, because a headless front end renders in the browser by default unless the build includes server-side rendering or static generation. Stores that migrate to headless for speed and flexibility then discover that category pages are empty shells in Google’s rendered view, or that thousands of URLs are stuck in “Discovered, currently not indexed” because the rendering queue cannot keep up. The trade-offs are covered in our comparison of headless commerce and traditional platforms; the technical SEO requirement is simple to state and hard to skip: every indexable page must arrive as complete HTML, with its title, canonical, product content, and links present before any JavaScript runs.
App-heavy stores on traditional platforms face a milder version of the same thing. Each installed app adds scripts, and uninstalling an app often leaves its script in the theme. Review the theme’s script list quarterly and remove anything that no longer has a reason to load.
Fix 8: Core Web Vitals on the templates that matter
Core Web Vitals are Google’s real-user measurements of loading, interactivity, and visual stability. The thresholds published on web.dev are a Largest Contentful Paint within 2.5 seconds, an Interaction to Next Paint of 200 milliseconds or less, and a Cumulative Layout Shift of 0.1 or less, each measured at the 75th percentile of page loads. A store does not need to pass on every URL; it needs to pass on the product template, the category template, and the homepage, because those account for nearly all organic landings.
Use the Core Web Vitals report in Search Console, which groups URLs by pattern, to see which template fails and on which metric, then diagnose with PageSpeed Insights on one URL from that template. The recurring causes on stores:
- The main product image as LCP: oversized, not preloaded, or lazy-loaded even though it is above the fold
- Third-party scripts from review widgets, chat, heatmaps, and pixels running before the page is interactive
- Layout shift from promo bars, cookie banners, and image sliders that load without reserved space
- Theme CSS and JavaScript shipped for features the store never enabled
Judge progress with field data from Search Console, not the lab score. A page can score 95 in a lab test and still fail for real shoppers on mid-range phones over mobile networks.
Fix 9: Hosting and server response time
Everything in the previous step sits on top of the server’s response time. If the HTML itself takes 1.5 seconds to arrive, the largest image cannot paint in 2.5 seconds no matter how well it is optimized, and Googlebot’s crawl rate drops with it, because Google slows down when a server responds slowly. Check time to first byte on the product and category templates from a location close to your customers, at a busy hour, not from your office at midnight.
Shared hosting, an undersized single server, or no full-page caching are the usual explanations on WooCommerce and Magento stores, and the fix is almost always at the infrastructure level rather than in the theme. Our guide to cloud computing for ecommerce covers the options and what they cost; for the technical SEO checklist, the target is a server response under 500 milliseconds on cached category and product pages, and a CDN in front of images and static files.
Fix 10: Out-of-stock products, variants, and discontinued URLs
Stores change constantly, and each change creates URLs that need a decision. Out-of-stock products that will return should stay live, indexable, and honest about availability, with alternatives shown. Discontinued products with links or rankings should redirect to the closest parent category or replacement product. Discontinued products with neither can 404, and a 404 is a perfectly good status code when nothing worth keeping is lost.
Variants need the same discipline. A product in six colors on six URLs with identical descriptions should canonicalize to the main product unless a specific variant has its own search demand, in which case it earns unique content and a self-referencing canonical. Many of the deeper reasons these pages fail are content problems rather than technical ones, and we went through them in why most ecommerce product pages never rank; on the technical side, the checklist is short:
- Status codes: no soft 404s, no product pages returning 200 with an empty template
- Redirects: one hop, no chains, and never a mass redirect of discontinued items to the homepage
- Variants: canonicalized or unique, never both indexable and identical
- Availability: what the page says, what the structured data says, and what the feed says should agree
The order to do it in
The sequence matters because later fixes depend on earlier ones. Indexation rules come first, because there is no point speeding up or canonicalizing pages that should not exist. Sitemaps and URL structure come next, so that Google’s picture of the catalog matches yours. Canonicals and pagination follow, since they decide which of the remaining URLs carry the signals. Rendering comes after that, because you cannot diagnose rendering problems on URLs that are still being blocked, duplicated, or orphaned. Speed and hosting come last, once the set of pages worth making fast is settled.
Do the whole sequence once, properly, then put a lighter version on a quarterly schedule: a crawl compared against the previous one, the Search Console Pages and Core Web Vitals reports, and a check of the theme’s scripts. Stores change faster than anyone plans for, and technical SEO on a store is less a project than maintenance on a machine that keeps generating new URLs.
About the Author
Matija Konjić is the founder of Link Inbound, a link building and content marketing agency working with B2B and B2C brands. He has built campaigns across 40+ industries and obsesses over the data behind what actually moves rankings.