WooCommerce works well until it doesn’t. And the telling part is that it doesn’t break all at once: it degrades. The shop keeps selling, nobody sees an error, and yet organic traffic stalls while the catalogue keeps growing.
There’s no magic number
The question we always get is how many products WooCommerce can handle. It doesn’t have a good answer, because the number isn’t what matters.
A shop with 5,000 products, no variations, no filters and flat categories can run perfectly well. One with 800 products, three variations each, six combinable filters and a badly configured search can be generating tens of thousands of URLs and choking on them.
What grows with the catalogue isn’t the products. It’s the URLs the catalogue generates around them.
Facets, again
This is problem number one and the one that takes longest to show.
Every filter you add multiplies the possible combinations. Colour, size, brand, price, material: five filters with five options each is thousands of URLs, almost all with practically identical content and none with search demand of their own.
WooCommerce generates them natively, and most filtering plugins generate them again with different parameters, so you end up with several URLs serving the exact same listing.
What happens when it isn’t controlled. Google allocates a crawl budget to each site. If it spends that budget working through filter combinations, your new products take weeks to get indexed. And if it also indexes those combinations, you have duplicate content at scale.
What to do. Decide which combinations have real demand and deserve indexing (the ones that answer a search somebody actually makes, like “women’s running shoes”) and block the rest. In practice that’s work on robots.txt, canonicals and the filtering plugin’s configuration, and it has to be done with the filter list in front of you, not in the abstract. We cover it in faceted navigation.
Listings are the expensive part
WordPress renders a category page by querying the database for every product it shows. With twenty products and a small catalogue, you don’t notice. With a large catalogue, filters applied and sorting on, that same page can fire hundreds of queries.
And listings are exactly where most people land from Google, because categories bring the bulk of transactional traffic.
The symptoms are recognisable: the home page is fine and so are the product pages, but categories are slow. And the more you filter, the worse it gets. On mobile it’s twice as noticeable.
What to do. Properly configured page caching, which comes first and pays off most. Cutting down what the listing loads (filtering widgets are usually the heaviest part). And on large catalogues, checking whether the queries can be optimised or whether a separate search index is needed.
This also underpins Core Web Vitals, which in ecommerce are paid for directly in conversion.
Internal search, the sale that leaks quietly
WordPress’s search does a simple text match. It doesn’t understand synonyms, it doesn’t tolerate typos and it doesn’t prioritise by commercial relevance.
On a blog that doesn’t matter. In a shop with two thousand references, someone searching for “trainer” when your products are titled “trainers” may find nothing at all. And whoever uses a shop’s search already knows what they want: it’s the traffic that converts best.
How to spot it. Look at internal searches in Analytics. If plenty come back with no results, those are lost sales that appear in no SEO report. And those searches also tell you which words your customers use, which aren’t always yours.
Out-of-stock products
On a large catalogue this stops being a one-off decision and becomes a process.
With fifty references, you decide case by case. With two thousand rotating by season, you need a rule: what happens when a product is temporarily out of stock, what happens when it leaves the catalogue for good, and who executes it.
Without that rule, in two years you have hundreds of dead product pages that Google keeps crawling and users landing on products they can’t buy.
Variations
A product with three sizes and four colours is twelve combinations. Multiplied across a large catalogue, that’s a lot of potential URLs.
The question is whether each variation deserves its own indexable page. Almost never: people don’t search for “blue t-shirt size M”, they search for “blue t-shirt”. The usual answer is a single product page with selectable variations, a clear canonical and structured data describing them without multiplying URLs.
Before you consider migrating
When a WooCommerce shop starts struggling, the same conversation always comes up: perhaps we should change platform.
Sometimes yes. If the catalogue is heading towards tens of thousands of references, if you need customer-segmented pricing, or if you have several markets with different logic, there are platforms that handle that better out of the box.
But almost everything in this article can be fixed without migrating, and migrating is one of the jobs where most traffic gets lost when it’s done badly. Changing platform over a configuration problem means trading a problem you know for one you don’t.
The honest conversation is about order: first you sort out what you have, you measure what improves, and if the platform genuinely turns out to be the ceiling, you plan the migration with data behind it. Not as a reflex.
Where to start
Three things you can check today without anyone’s help.
How many URLs Google has of your shop. A site search on Google, or Search Console. If the number is an odd multiple of your product count, you have facets indexed.
How long your largest category takes with two filters applied, on mobile. If it’s over three seconds, there’s work to do.
How many internal searches come back empty. It’s in Analytics and hardly anyone looks.
If you’d rather we looked at it, that’s how we work SEO for WooCommerce. Tell us about your case and we’ll tell you what we find.
Frequently asked questions
How many products can WooCommerce handle?
There’s no hard limit. We work with shops running several thousand references without trouble. What determines whether it will go well isn’t the product count, it’s how many URLs the catalogue generates around itself: variations, combinable filters and internal searches. A badly configured 800-product shop can cause more problems than a well-built 5,000-product one.
Why is my WooCommerce shop slow only on category pages?
Because listings are the most expensive thing to render: WordPress queries the database for every product it displays, and filtering widgets add weight on top. The home page and product pages usually run fine because they’re simpler. You tackle it with page caching, lightening the listing and reviewing the queries.
Should I index my shop’s filter pages?
Only the combinations that answer a real search, and there are few of those. The rest generates duplicates and eats crawl budget. The rule of thumb: if nobody searches that exact combination, don’t index it.
Should every product variation have its own URL?
Almost never. The usual approach is a single product page with selectable variations, a clear canonical and structured data describing them. Multiplying URLs by size and colour creates duplicates without capturing any new searches.
Is it worth migrating from WooCommerce to another platform?
Only if the platform genuinely is the ceiling, and that has to be demonstrated first. Most problems on a large WooCommerce shop are configuration issues that can be solved without migrating. A badly executed migration loses more traffic than any technical improvement gains.
