166,000 Visits in One Day and Not a Single Sale

High traffic is usually good news for an online store. But when a site suddenly starts slowing down at the exact same time analytics show a huge spike in visits, the story can be very different.

I recently came across exactly that situation on a client’s WooCommerce store. The site would load normally one moment, then slow down the next. At the same time, the traffic reports showed more than 166,000 visits in a single day, an unusually high number for what was normally a fairly quiet online store.

At first glance, that looks like a fantastic day for the business, but it wasn’t. Those visits weren’t coming from potential customers, they were coming from bots crawling product filters and generating a massive number of requests to the server.

In this article, I’ll walk through how we found the source of the load, what WooCommerce filters had to do with it, and how one Cloudflare rule changed the situation completely.

What Was Actually Happening

If you run a WooCommerce store (in this case, one using the WoodMart theme), filters for color, size, price, availability, sorting, and similar options generate URLs with query parameters like these:

/shop/?filter_color=black
/shop/?filter_size=large&query_type_size=or
/shop/?min_price=50&max_price=100&orderby=price
/shop/?filter_category=lighting&stock_status=instock

For a real customer, these are just a few clicks. For a bot, they’re a playground.

Combine several colors, a couple of sizes, a price range, and a sorting option, and suddenly you have tens of thousands of unique URLs. Each one looks like a separate page.

These URLs are also hard to cache effectively. Your caching plugin may store regular pages, but every new filter combination is essentially a cold request. Once it loads, it might get cached, but there may never be another request for that exact combination.

Google describes this problem as faceted navigation, and it’s a well-known issue.

In short, it looked like traffic. In reality, it was more like an attack, just the polite version.

What It Looked Like on the Server

Now let’s look at the server side. The total script and database processing time was reaching around 5,000 to 6,000 minutes per day. That isn’t a CPU percentage. It’s the total amount of processing time spent handling requests.

There were no major errors in the logs and no broken plugin causing the issue. CPU usage was hitting 100%, memory was maxing out, and the common factor was requests containing ?filter_ parameters in the URL.

The Cloudflare Rule That Fixed It

I recently came across an article on the WoodMart blog where their team explains this exact problem and suggests a possible solution. I tested it on a real case, and it worked well, so I’m sharing what we did from first-hand experience.

In Cloudflare, go to Security → Security rules → Create rule → Custom rules. Then apply a Managed Challenge to requests containing filter-related query parameters:

(http.request.uri.query contains "filter_") or
(http.request.uri.query contains "per_page=") or
(http.request.uri.query contains "per_row=") or
(http.request.uri.query contains "shop_view=") or
(http.request.uri.query contains "stock_status=") or
(http.request.uri.query contains "min_price=") or
(http.request.uri.query contains "max_price=") or
(http.request.uri.query contains "orderby=")

What does that do? Whenever a request contains one of those filter parameters, Cloudflare serves a Managed Challenge before the request reaches the server. A real visitor completes the check once and continues browsing the site. Most bots don’t get past it.

The result was pretty dramatic. Out of more than 184,000 requests, over 179,000 were blocked. The CPU usage spikes we had been seeing disappeared, and most importantly, the site stopped slowing down.

Be Careful Before Applying It

Before copying the rule exactly as it is, there are a few things worth knowing.

Managed Challenge and AJAX Don’t Always Play Nicely

WoodMart filters work through AJAX, while Cloudflare challenge pages don’t always behave perfectly with XHR requests. In practice, the first filtered request may open as a regular page with the challenge. Once the visitor passes it, AJAX filtering usually continues normally.

That’s why testing matters. Try the first filter, then several more, on both desktop and mobile. If challenge content starts appearing inside the filtering interface, don’t leave the rule enabled in that form.

filter_ Is Broad on Purpose

The rule catches parameters such as filter_color, filter_size, filter_category, and anything else beginning with filter_. That makes it convenient, but it also means that if the same string is used elsewhere on your site, legitimate requests could be affected.

After enabling the rule, keep an eye on Security Events in Cloudflare for a few days and adjust the conditions if needed.

The Rule Protects the Store, but It Doesn’t Handle SEO for You

This rule reduces server load. It doesn’t manage search engine indexing. That’s what robots.txt, canonical URLs, and your store’s SEO configuration are for. For example:

User-agent: *
Disallow: /*?*filter_
Disallow: /*?*min_price=
Disallow: /*?*max_price=
Disallow: /*?*orderby=

And because malicious bots are perfectly happy to ignore robots.txt, it’s not a replacement for the Cloudflare rule. The two serve different purposes and work best together.

Googlebot Is a Separate Conversation

Cloudflare can identify verified bots through cf.client.bot. You can let Googlebot bypass the challenge so you don’t interfere with crawling, but that also means sending more requests to the server. Or you can restrict it and reduce server load, while keeping a close eye on indexing.

Which option makes sense depends on the SEO strategy of the specific store. There isn’t one universal answer.

The Takeaway

Not every traffic spike is good news. Sometimes 166,000 “visits” mean a server under heavy load and exactly zero additional sales.

The good news is that in this specific scenario, with WooCommerce and WoodMart product filters being aggressively crawled by bots, the fix can be relatively simple with the right Cloudflare rule. For more ways to protect your store, take a look at our web hosting security best practices, and if you’re choosing where to host your shop, our comparison of the best hosting for WooCommerce is a good place to start.