Which Technical SEO Fixes Actually Move Ecommerce Rankings?

Last updated: 11 October 2026

Open the Page indexing report in Search Console for an online store with a few thousand products. On most stores we look at, Google has found far more URLs than the shop has products. Colour filters, size filters, sort orders, tracking parameters, internal search pages.

That gap is where most ecommerce technical SEO problems live.

The short answer: the fixes that move rankings now are the ones that stop Googlebot wasting time on junk URLs, keep product data identical across your pages and your Merchant Center feed, and make your product and category templates fast. Audit scores and piles of schema matter far less than people think.

Key facts

• Google’s faceted navigation guide, updated in December 2025, says crawlers typically access a very large number of faceted URLs and recommends blocking the ones you don’t need with robots.txt.
• Google’s ecommerce pagination guidance, updated in December 2025, says not to use the first page of a paginated series as the canonical, and confirms Google no longer uses rel="next" and rel="prev".
• Google’s product structured data documentation, updated in December 2025, says providing both on-page structured data and a Merchant Center feed maximises eligibility for shopping experiences.
• Google said in May 2025 that its Shopping Graph holds more than 50 billion product listings, with more than 2 billion of them refreshed every hour.
• web.dev sets the good Core Web Vitals thresholds at an LCP of 2.5 seconds, an INP of 200 milliseconds and a CLS of 0.1, measured at the 75th percentile of page loads.
• Google’s crawl budget guide for large sites, updated in July 2026, says soft 404 pages continue to be crawled and waste crawl budget.
• OpenAI’s commerce documentation lists nine required fields for a ChatGPT product discovery feed, including title, availability and price.

This article covers the eight technical areas we see making the biggest difference on ecommerce sites: faceted navigation, stock changes, product data and Merchant Center, Core Web Vitals on templates, JavaScript rendering, pagination and canonicals, internal search pages, and how the AI shopping tools in Google and ChatGPT read your product data.

Why is faceted navigation usually the biggest technical problem on an online store?

Because filters multiply URLs far faster than you add products, and Googlebot will crawl them. A category with five filters of ten values each can, if every combination gets its own URL, produce more than 160,000 pages. Most are thin or empty.

Google’s own guide to managing faceted navigation is unusually blunt about it. It says crawlers will typically access a very large number of faceted URLs, and its first recommendation is to disallow the ones you don’t need in robots.txt. It also suggests URL fragments for filters you never want indexed, and a 404 when a filter combination returns no products.

The decision we make with store owners is simple. Which filter pages have real search demand? “Women’s black running shoes” probably deserves an indexable, linked, properly written page. “Black, size 6.5, under 80, sorted by newest” does not. Keep the first kind crawlable with clean, consistently ordered parameters. Block the rest.

What surprises people is that a canonical tag alone rarely fixes this. Google’s guide lists canonicals and nofollow links as the weaker, longer-term option, and Googlebot still has to fetch each URL to see the tag.

What should you do with out-of-stock and discontinued products?

Keep temporarily out-of-stock pages live and say so clearly; only redirect or remove a product when it is gone for good. A product that is back next month has rankings, links and reviews you don’t want to throw away.

For temporary gaps, leave the page returning a normal 200, show the stock status and a back-in-stock alert, and update the availability value in your Product markup and your feed. Google’s product structured data documentation lists availability as one of the details it can show shoppers. A stale “InStock” on a page that says sold out is exactly the kind of mismatch to avoid.

For discontinued lines you have three honest options. Redirect with a 301 to a genuine replacement, such as the newer model. Keep the page as an archive if it still earns links or answers support questions. Or let it return a 404 or 410.

What we advise against is redirecting every dead product to the home page or a broad category. In our experience Google often treats those as soft 404s, and its crawl budget guide for large sites says soft 404 pages keep being crawled and waste budget. The same guide warns against long redirect chains, which pile up fast on stores that rename products every season.

How do product structured data and Merchant Center work together now?

They feed the same shopping results, so treat them as one job: price, availability and identifiers should match on the page, in the markup and in the feed. Google’s documentation says providing both structured data and a Merchant Center feed maximises your eligibility for shopping experiences, and that product snippets may use pricing from the feed when the page markup lacks it.

There are two kinds of Product markup worth knowing. Merchant listing markup is for pages where people can buy from you, and it supports shipping and returns detail. Product snippet markup is for pages that review products without selling them. Most stores need the first, plus return and shipping policies marked up at the organisation level.

The free side of Merchant Center is underused. Plenty of owners think Google Shopping only means paying for ads, but products from an approved feed can also appear in free listings. If you already run paid Shopping, your feed is half built. We cover the paid side on our Google Shopping page.

What’s overrated is adding every schema type a plugin offers. Rich results depend on complete, accurate data that matches the visible page, not on the amount of markup.

Do Core Web Vitals really affect ecommerce rankings?

A little for rankings, a lot for revenue, and you should measure them per template rather than per page. Google’s thresholds, set out on web.dev, are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less, judged at the 75th percentile of real visits. INP replaced First Input Delay as a Core Web Vital in 2024.

On a store, a handful of templates serve almost every page: home, category, product, basket and checkout. Fix the product template once and you’ve fixed 20,000 pages. That’s why we read the Core Web Vitals report in Search Console grouped by URL pattern, not a single homepage score from a lab test.

The usual culprits on product pages are oversized hero images, carousels that load every slide up front, review and chat widgets that block the main thread, and late banners that push the Add to basket button down. That last one hurts CLS and conversions at the same time.

Our honest view: a fast site with weak products and thin content will not outrank a slower site with better ones. Speed is a tie-breaker and a conversion lever. Treat it that way and you’ll prioritise better.

Is JavaScript stopping Google from seeing your products?

It can, especially on headless and app-style storefronts where prices, stock and even product links only appear after scripts run. Google’s JavaScript SEO basics page explains that pages go through crawling, rendering and indexing, and that a page may wait in the rendering queue for a few seconds or longer. It still calls server-side rendering or pre-rendering a great idea because it makes sites faster for users and crawlers.

Two checks catch most problems. First, look at the raw HTML of a category page and a product page, not the rendered version. Are product names, prices and links to products there? Second, make sure product grids use real a href links rather than click handlers.

Google is no longer the only reader, either. Google’s own page notes that not all bots can run JavaScript, so content that only exists after rendering may be invisible to some of the crawlers feeding AI answers.

How should category pagination and canonicals be set up?

Give every paginated page its own self-referencing canonical and link the pages with normal crawlable links. Google’s pagination guidance for ecommerce says not to use the first page of a series as the canonical for the rest, and confirms Google no longer uses rel=”next” and rel=”prev”.

Pointing pages 2, 3 and 4 back to page 1 is still one of the most common mistakes we find. It tells Google those pages don’t matter, and products listed only on deeper pages lose a path in.

Infinite scroll and Load more buttons need a crawlable fallback, because the same guidance says Google’s crawlers don’t click buttons. Real paginated URLs behind the scenes, plus a product sitemap, cover it.

Variants need the same thinking. If each colour has its own URL, decide whether each variant deserves to rank or one main URL should carry them all, then make the markup, the feed and your internal links agree. We wrote more on this in our post on handling duplicate content on ecommerce websites.

Should internal site search pages be indexed?

Almost never. Internal search result pages are endless: any string a visitor or a bot types creates a new URL, and spammers sometimes link to search URLs with their own phrase in the query to get it indexed on your domain.

Block the search path in robots.txt. If search pages are already indexed, add noindex first, let Google recrawl them, and only then block. Do both at once and Google can’t see the noindex.

The useful part of site search is the data. Your search logs show what shoppers expect you to sell and can’t find. When the same query turns up hundreds of times, that’s a case for a proper category or landing page built on purpose, not an indexed search page.

How do AI shopping features in Google and ChatGPT read your product data?

Mostly from structured product data, not from clever copy. Google said in May 2025 that its Shopping Graph, which sits behind shopping in AI Mode, has more than 50 billion product listings, with more than 2 billion refreshed every hour. If your feed and your pages disagree on price or stock, you are handing that system conflicting facts.

OpenAI has gone the same way. Its commerce documentation describes product feeds for discovery in ChatGPT, with nine required fields including title, brand, availability and price. It tells merchants to update the feed when a sale starts or ends and when items sell out or come back.

Here the evidence is thin, and we’d rather say so. Nobody outside these companies knows exactly how products get picked. What is clear is that both prefer clean, current, structured data: accurate titles, GTINs where you have them, prices, stock, shipping and returns. Those basics help in classic search too.

Be wary of anyone promising your products will appear in AI answers. Nobody can promise that. What you can do is remove the reasons to leave you out, which is the focus of our AI SEO work.

If you only do three things this quarter, do these. Find out how many URLs Google is crawling compared with how many products you sell. Check that price and stock match across your pages, your markup and your feed. Then test your product template, not your homepage, for speed.

Most stores we audit have at least one of those wrong, and fixing it does more than any new plugin. If you’d like a second pair of eyes on your store, SEOValley’s ecommerce SEO service starts with exactly these checks, and our technical SEO service handles the fixes.

About the author

Shabir MS leads SEOValley Solutions and has worked in search since 2005. These days most of his time goes on how brands show up in AI answers, and on separating what the data actually shows from what gets said at conferences. Read more from Shabir MS.

Frequently asked questions