Most of search engine optimization for ecommerce is just search engine optimization. Titles, headings, internal links, speed, a page that answers the query. If that were all of it there would be no reason for this article to exist and you would be better served by a general guide.
The reason a catalog needs its own treatment is a short list of problems that only appear when you sell things. Filters that manufacture URLs faster than anything can crawl them. The same product at four addresses because it comes in four colors. Descriptions that arrived in a supplier feed and are already on two hundred other sites. Products that stop existing. And a conversion that happens three steps after the page that earned the visit.
This covers those. We sell audits and retainers, so treat it as interested testimony and check it. Google publishes documentation specifically for ecommerce sites and for faceted navigation, so the rules below are quoted from those pages with the URL and the date they were read rather than summarized from a vendor’s blog.
What makes search engine optimization for ecommerce a different job
The work goes by three names. Ecommerce SEO, online store SEO and search engine optimization for ecommerce all describe the same job, and nothing below turns on which of them you searched for.
Three neighbors to this article exist and it is worth saying what each one is before you read further, because all four get described with the same words.
Our breakdown of what SEO pricing packages really run prices this work and explains why a catalog costs more than a service site. That one prices it and this one performs it. Our walkthrough of an ecommerce site audit is the one-off inspection that tells you which of the problems below you actually have, where this is the ongoing work of keeping a catalog findable once you know. And our comparison of ecommerce platforms judged on SEO merit answers which cart to build on, so anything platform-specific, WooCommerce settings and plugin choices included, belongs with that one rather than here. Everything below is true of a catalog whatever software runs it.
The structural difference is scale of a particular kind. A service site has perhaps forty pages, each one written on purpose by a person. A shop has a few hundred products and several million possible URLs, almost none of which anybody decided to create. They were generated by a filter, a sort order, a variant picker or a tracking parameter, and they exist whether or not anyone wanted them.
That changes what the work is. On a service site you are mostly improving pages. On a shop you are mostly deciding which pages should exist at all, and then making sure the ones that should are the ones being found. Every section below is a version of that decision.
Faceted navigation, where a shop manufactures its own URLs
Start here, because it is the largest problem, the one most shops have, and the one Google has written a dedicated page about.
Faceted navigation is the set of filters down the side of a listing page. Google describes it as a common and useful feature whose most common implementation, based on URL parameters, “can generate infinite URL spaces which harms the website in a couple ways” (developers.google.com/crawling/docs/faceted-navigation, read 16 September 2026).
The two harms are named on the same page and both are about wasted attention rather than penalty. On overcrawling, Google says “the crawlers will typically access a very large number of faceted navigation URLs before the crawlers’ processes determine the URLs are in fact useless”. The second harm follows from the first, which is slower discovery of the pages that do matter, because crawling spent on useless URLs is crawling not spent on new ones.
Google is blunt about the arithmetic too, noting that “crawling faceted URLs tends to cost sites large amounts of computing resources due to the sheer amount of URLs and operations needed to render those pages”. That cost lands on your server, not on Google’s, which is why a catalog with open filters is often also a catalog that is slow at exactly the wrong moments.
Three filters with ten values each is a thousand combinations before anybody sorts by price. Add sorting and pagination to each and the number stops being worth calculating. Nobody made those pages. Your platform did, the moment somebody added a third filter.
Deciding which filtered URLs a search engine should see at all
Google splits this into one question asked first, which is whether you want any of those filtered pages indexed. Almost every shop answers no and then behaves as though it had answered yes.
If the answer is no, the documentation is direct about it. “Oftentimes there’s no good reason to allow crawling of filtered items, as it consumes server resources for no or negligible benefit”, and the recommended shape is to “allow crawling of just the individual items’ pages along with a dedicated listing page that shows all products without filters applied”. That is a robots.txt job, disallowing the parameter patterns and allowing the unfiltered listing.
There is a second method that most teams have never considered, which is to stop putting filters in the URL at all. Google states that “Google Search generally doesn’t support URL fragments in crawling and indexing”, so a filtering mechanism built on fragments after a hash has no crawling impact in either direction. If you are rebuilding the front end anyway, that decision removes the problem rather than managing it.
The two methods people reach for first are ranked below both. Google notes that canonical and nofollow signals are “generally less effective in the long term than the previously mentioned methods”, and adds a condition on nofollow that quietly kills most implementations, which is that every anchor pointing at a given URL has to carry the attribute for it to work. One forgotten link in a footer undoes the whole thing.
If you do want some filtered pages indexed, because a filter combination is genuinely a thing people search for, one rule matters more than the rest. Google says to “Return an HTTP 404 status code when a filter combination doesn’t return results”, and to serve a real empty-results page rather than redirecting to a generic error. An indexable filter that sometimes has nothing in it is a page that sometimes has nothing in it.
Variants, and when two colors are one page
The same shirt in four colors is either one page or four, and the decision has consequences in both directions.
If your variant picker uses a fragment, the decision has already been made for you. Google’s ecommerce URL documentation gives the example directly, that “/product/t-shirt#black and /product/t-shirt#white are considered to be the same page by Google” (developers.google.com/search/docs/specialty/ecommerce/designing-a-url-structure-for-ecommerce-sites, read 16 September 2026). One page, whatever the picker looks like.
The opposite failure is more expensive and harder to see. The same page reachable at two real addresses gets crawled twice for one result, and Google is explicit that it cannot always tell. Its example is that “/product/black-t-shirt and /product?sku=1234 may return the same product page, but Google cannot determine this by looking at the URL alone”. That is the internal search results link, the feed link and the old category path all arriving at one product by different roads.
So decide deliberately. One page per product with variants selected on it is the right answer when the variants share a description, a price and a use. Separate pages are right when people search for the variant by name and would be disappointed to land on a generic parent. The wrong answer is the accidental one, which is four indexable pages carrying the same words because that is what the platform emitted.
While you are in the URL structure, take the free improvement. Google’s instruction is to “Add descriptive words in URL paths”, with its own contrast between a readable product path and a bare numeric one. Most platforms will do this and most shops have never switched it on.
Descriptions that arrived with the supplier feed
If you resell rather than manufacture, this is the finding that decides whether the catalog can rank at all, and no amount of technical work substitutes for it.
A supplier feed gives every stockist the same paragraph. Two hundred shops publish it, the manufacturer publishes it, and a search engine choosing which of those to show has nothing in the text to choose on, so it falls back on everything else it knows about the sites. That is a competition you lose by default against whoever is larger, and you lose it on every product simultaneously.
The fix is unglamorous and it is writing. Not all of it, though. Rank your products by revenue and by search demand, take the overlap, and rewrite those first. On most catalogs a small minority of products carries the great majority of the money, and rewriting that minority properly beats rewriting everything badly or running the text through a generator and publishing a different kind of sameness.
What to write is the part the feed structurally cannot give you. Who the thing is for and who it is not for, what it is like in the hand, what people ask before buying it, what it does not do, and what it replaces. The supplier knows the specification. You know the returns, the support questions and the objections, and none of that is in anybody else’s copy.
Leave the specification table exactly as supplied. It is the same everywhere because it is factual, and rewriting it introduces errors without adding anything.
Products that sell out, and products that stop existing
Every catalog has a policy on this even if nobody wrote one, and the default policy is usually the worst available.
Separate the two cases first, because they need opposite treatment. A product that is temporarily out of stock is still the right answer to the query that found it, so the page should stay, stay indexable, say plainly that it is unavailable, and offer a way to be told when it returns. Deleting it throws away whatever ranking it earned and you will have to earn it again when the stock arrives.
A product that is discontinued is a different question, and the test is whether a visitor arriving from a search would be better served by something else you sell. If there is a genuine successor, redirect to it. If there is a category that answers the same need, redirect there. If there is nothing, let the URL go and return the honest status code rather than bouncing everybody to the homepage, which tells the visitor nothing and tells a crawler that the page still exists.
The same logic runs upward to categories that empty out. Google’s guidance for ecommerce sites is to avoid indexing pages without useful content and that “If a category has no items, use a noindex robots meta tag”, with a 404 as the option where the site has removed the category from browsing entirely. A seasonal category sitting empty for nine months of the year is a page inviting people in to find nothing.
Write the policy down and attach it to whoever manages stock, because this is a merchandising decision that happens daily and an SEO decision that happens once.
Category pages do most of the ranking and nobody writes them
Ask a shop which pages it has optimized and it will say the products. Look at what actually earns non-brand visits and it is usually the categories.
The reason is what people type. Searches for a specific product by exact model number are low in volume and usually late in the decision, and often the manufacturer wins them anyway. Searches that describe a kind of thing, with the qualities and the use attached, are where the volume and the undecided buyers both are, and the page that answers those is a category or a filtered view, not an individual item.
So treat category pages as pages rather than as containers. They need a real title, copy that says what belongs in this category and how to choose between the items in it, and internal links out to the sub-categories and guides that help somebody narrow down. A grid of thumbnails with a heading above it is not a page, it is a menu, and it competes with every other menu.
Put the copy where it helps rather than where it is traditional. A wall of text above the products pushes the products off the screen on a phone, and a wall of text below them is read by nobody. A short orienting paragraph at the top and the fuller guidance underneath is the compromise that works on both counts.
Pagination, load more, and infinite scroll
Long listings have to be broken up somehow, and the three ways of doing it are not equivalent as far as a crawler is concerned.
The decisive fact is how discovery works. Google states that “When crawling a site to find pages to index, Google generally crawls URLs found in the href attribute of <a> elements”, and that its crawlers do not click buttons or trigger the JavaScript behind them (developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading, read 16 September 2026). A load-more button or an infinite scroll with no real links behind it means everything past the first screen may never be found.
You can keep either pattern for people, as long as there are genuine links underneath for crawlers. What you cannot do is rely on the button.
Where teams get the detail wrong is canonicals. Google’s instruction is plain, that you should “Don’t use the first page of a paginated sequence as the canonical page. Instead, give each page its own canonical URL.” Pointing every page of a listing at page one is a common default and it tells a search engine that pages two onward are duplicates of page one, which removes them from consideration along with everything only reachable through them.
Google also says, on its ecommerce URL page, that “We see the most URL mistakes in pagination URL structures.” That is worth reading as a hint about where to look first when something large is missing from the index.
Structured data, and what it does not buy you
Product markup is worth having and it is routinely sold as something it is not, so set the expectation before the work.
What it does is make your price, availability and review information legible to a machine, which makes you eligible for the richer presentations in results and in shopping surfaces. Eligible is the operative word. It is a description of your page in a format that can be parsed, not an argument that your page deserves to be higher.
What it is not is a ranking mechanism, and the tell that somebody is selling it as one is a proposal where markup is the deliverable and nothing changes on the pages themselves. Markup on a product with a supplier description is a well-labeled copy of everybody else’s page.
The rule that matters in practice is that the markup has to agree with the page. A price in the markup that differs from the price on screen, or availability that says in stock while the page says otherwise, is worse than no markup, because it is a machine-readable contradiction on a commercial page. Keep it generated from the same data the page renders from, never maintained separately, and it stays true by construction.
Watching the crawl on a catalog, and seeing waste
Everything above is a hypothesis until you look at what is actually being fetched, and on a shop that is the single most informative thing you can read.
Pull the crawl statistics for your own site and read them by URL shape rather than by total. You are asking one question, which is what proportion of fetching is being spent on addresses you would not have chosen to publish. Parameters, sort orders, session identifiers, filter combinations and internal search results are the usual answer, and on an untreated catalog they are frequently the majority.
Then compare that against what is missing. A shop where new products take weeks to appear in results, while filtered listings are fetched constantly, has a distribution problem rather than a quality problem, and no amount of rewriting product copy will fix it until the distribution is corrected.
Our walkthrough of SEO performance step by step covers reading indexation and crawl reports in order, which is the same discipline applied to a site that is not a catalog. This is also the measurement that tells you whether the faceted navigation work landed. Make the robots.txt change, wait, and read the same report again. The proportions should move, and if they do not, the rules are not matching the URLs your platform actually emits, which is the most common reason this work fails quietly.
Measuring it when checkout is the only conversion that counts
A service site measures inquiries and can argue about quality afterward. A shop has a number that settles arguments, which is an advantage right up until it is used badly.
The trap is attributing revenue to the page that received the order. That is almost always the checkout, or the product page, and almost never the page that earned the visit. A buying decision on a catalog routinely starts on a category page or a guide, wanders through three products and completes days later, and a report crediting the last page teaches you to stop doing the thing that works.
So look at entry pages for sessions that eventually bought, not at the page the purchase happened on. That single change usually reverses which pages look valuable, and it is the argument for the category work two sections up.
Two other things belong in the same report. Movement on non-brand queries, because brand searches would have found you anyway and mixing them in flatters everything, and our explanation of SEO visibility covers how to read that pattern without fooling yourself. And where people leave, since a catalog earning more visits and converting fewer of them has a conversion problem rather than a search one. Getting a report to credit the page that started a purchase days earlier is a measurement setup job before it is an analysis one, and our explanation of SEO analytics covers building it that way.
What we would do first, and what to ask us
Given an unfamiliar catalog and a week, we would spend the first day counting rather than improving anything.
How many URLs does the site actually expose, against how many products it sells. What share of crawling goes to addresses nobody chose to publish. How many product descriptions are the supplier’s, word for word. Which categories earn non-brand visits and which have never earned one. Those four numbers decide the order of everything else, and on most shops at least one of them is a surprise to the person who runs it.
Then the filters, because that is usually the largest single lever and it is configuration rather than content. Then the descriptions on the products that carry the revenue. Then the categories. Our work on ecommerce website design covers the build side where a filter decision is cheaper to make than to undo, our guide to retail SEO takes the same work from the retailer’s angle, and our explanation of links for ecommerce sites covers the part product pages are worst at.
Now point that at us, because we sell this work and the article is an argument for buying it. The test it sets is that every rule above is quoted to a published page with a date, that the order of work is justified by dependency rather than by what is easiest to sell, and that nothing here promises a ranking in exchange for markup. Ask whoever pitches you what share of your crawling is being wasted and how they intend to measure whether it improved, and that applies to us as much as to anybody.
The first move costs nothing. Open your own crawl statistics and read them by URL shape. If you would rather have the four numbers counted for you, our free website audit is where we would start on a catalog we have not seen.
