WooCommerce bot traffic causing high CPU usage – how to identify and stop it

WooCommerce websites can see sudden spikes in CPU usage even when there's been no obvious increase in real visitors. One of the most common causes we see is automated bots and scrapers repeatedly crawling WooCommerce product filters, categories and catalogue pages.

The requests usually look something like this:

/product-category/surgical/?filter_category=clamps,scissors,cataract
/catalogue/?filter_category=equipment,tools,dry-eye
/product-category/equipment/?orderby=price&filter_category=furniture

One request like this isn't a problem. Thousands of them, each with a different combination of filters, force WooCommerce, PHP and MySQL to build an expensive product query from scratch every time. During a busy scraping run this can cause:

• Very high CPU usage, and your account reaching its CloudLinux resource limits
• A slow website and WordPress dashboard
• 503 Service Unavailable errors
• Higher MySQL load
• Real customers getting slow page loads, and search engines receiving errors

This guide explains why it happens, how to spot it, and what you can do to stop it.

Why bots love WooCommerce filters

Product filters can create an almost unlimited number of URLs. Every filter, and every combination of filters, is a new page as far as a crawler is concerned:

?filter_category=chairs
?filter_category=chairs,tables
?filter_category=chairs,tables,equipment
?filter_category=chairs,tables,equipment,dry-eye

Add sorting and display options and the numbers multiply again:

orderby=price
orderby=rating
per_page=24
filter_product_brand=123
shop_view=grid

This is called faceted navigation. A crawler can keep finding new combinations forever, which can mean thousands or even millions of unique URLs.

Some of these bots are search engines. Others are scraping product catalogues and prices, building commercial or AI datasets, running SEO tools, doing competitor research, or are simply badly written scraping scripts. The bot operator usually isn't trying to take your site offline, but the effect can look just like a denial-of-service attack.

Why they're hard to block

They use many IP addresses. Modern scrapers send requests through large proxy networks. Instead of thousands of requests from one address, you see hundreds or thousands of different addresses, each making only one or two requests:

181.x.x.x
83.x.x.x
201.x.x.x
160.x.x.x
189.x.x.x

Blocking them one at a time is endless. The bot just sends its next request through a different proxy.

They pretend to be normal browsers. Bots often send a User-Agent that claims to be an ordinary browser, for example:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36

That says "Chrome on a Mac", but there's no real person or Mac involved. This is called User-Agent spoofing.

So rather than blocking IP addresses, the effective approach is to block the behaviour: expensive filter URLs, combined with signs that the visitor isn't a real shopper.

How to tell if this is happening to your site

1. Log in to cPanel from your service page under Services → My Services (https://www.hooplahosting.co.nz/client/clientarea.php?action=services).
2. Open Visitors (type it in the cPanel search bar) and click the magnifying glass next to your domain. This shows the most recent requests to your site.
3. For a longer history, open Raw Access and download your domain's access log.

Look for lots of requests to pages like /catalogue/, /shop/, /product-category/ or /brand/ that include parameters such as:

filter_category=
filter_product_brand=
filter_ (any other filter_ attribute)
orderby=
per_page=
shop_view=

Signs that it's bot traffic rather than real customers:

• Hundreds of different IP addresses requesting similar URLs
• The same pages with endless different filter combinations, often three, four or more values at once
• The same or very similar User-Agent on most requests
• No referring page (the referrer column is empty or shows -)
• Large numbers of requests within a few minutes
• Your CPU usage hitting the account limit at the same time. You can check this in cPanel under Resource Usage. See What are resource limits?

You may also see named crawlers such as GPTBot, SemrushBot, PetalBot, meta-externalagent, bingbot or Googlebot. Not all crawlers are bad. Googlebot and Bingbot are legitimate search engines. The bigger problem is usually anonymous crawlers pretending to be ordinary Chrome, Safari or Edge visitors.

Emergency fix: block bot-style filter requests with .htaccess

If your site is being overloaded right now, a few lines in your .htaccess file can stop most of this traffic. Because the request is rejected before WordPress loads, it costs your account almost nothing.

The rules below don't stop real customers using your filters. They block two patterns that real shoppers rarely produce:

• Rule 1: a filter URL with no referring page. A shopper clicking a filter on your site always comes from one of your pages. A bot jumping straight to the URL usually doesn't send a referrer.
• Rule 2: a filter with three or more values combined, such as filter_category=a,b,c. Real shoppers rarely tick that many options at once, but scrapers generate these combinations constantly.

To add them:

1. In cPanel, open File Manager and go to your site's folder (usually public_html). Click Settings and tick Show Hidden Files if you can't see .htaccess.
2. Right-click .htaccess and choose Download, so you have a copy to restore if needed.
3. Right-click it again, choose Edit, and paste the following at the very top, above the # BEGIN WordPress line:

<IfModule mod_rewrite.c>
RewriteEngine On

# Block WooCommerce filter requests with no referring page (direct bot hits)
RewriteCond %{QUERY_STRING} (^|&)filter_ [NC]
RewriteCond %{HTTP_REFERER} ^$
RewriteRule ^ - [F,L]

# Block filter requests combining 3 or more values (bot-generated combinations)
RewriteCond %{QUERY_STRING} (^|&)filter_[^=]+=[^&]*(,|%2C)[^&]*(,|%2C) [NC]
RewriteRule ^ - [F,L]
</IfModule>

4. Click Save Changes, then check your shop still loads and that clicking a filter on your site still works.

Matching requests now get a 403 Forbidden response instead of a full WooCommerce page. CPU usage should start dropping within a few minutes, as requests already in progress finish.

A few things to know:

• If your filters use a different parameter name (for example pa_colour= or yith_wcan=), change filter_ to match what you see in your logs.
• Some privacy tools strip the referrer, so a small number of real visitors opening a filtered link directly (for example from a bookmark) may see a 403. Clicking through from your shop page works normally.
• If customers regularly choose three or more filter values at once, leave out Rule 2.

Blocking one specific bot pattern

If you've identified a single bot by its User-Agent, you can block exactly that pattern. This example blocks filter requests that claim to be Chrome on a Mac, aimed at catalogue, category and brand pages:

<IfModule mod_rewrite.c>
RewriteEngine On

# TEMPORARY: block Mac Chrome WooCommerce filter crawler
RewriteCond %{HTTP_USER_AGENT} "Macintosh; Intel Mac OS X" [NC]
RewriteCond %{HTTP_USER_AGENT} "Chrome/[0-9]+" [NC]
RewriteCond %{QUERY_STRING} (^|&)filter_category= [NC]
RewriteCond %{REQUEST_URI} ^/(catalogue|product-category|brand)/ [NC]
RewriteRule ^ - [F,L]
</IfModule>

Use this only as a short-term fix. Real Mac users with Chrome will also be blocked from filter pages, and as soon as the bot switches to a Windows Chrome or Edge User-Agent, the rule stops matching. Keep checking your logs after adding it.

Block crawlers you don't need

If you don't want certain commercial or AI crawlers on your site at all, you can block them by name:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (GPTBot|SemrushBot|PetalBot) [NC]
RewriteRule ^ - [F,L]
</IfModule>

Be careful with this. Blocking Googlebot or Bingbot will hurt your search rankings, and some social media crawlers (such as Facebook's) are what create link previews when your pages are shared.

Tell search engines not to crawl filter pages

Filtered pages are rarely worth having in Google anyway, because they're near-duplicates of your category pages. Add these lines to your site's robots.txt file (in public_html; create it if it doesn't exist, or use your SEO plugin's robots.txt editor):

User-agent: *
Disallow: /*?*filter_
Disallow: /*?*orderby=
Disallow: /*?*per_page=
Disallow: /*?*shop_view=

This cuts load from Google, Bing and other well-behaved crawlers. But robots.txt is a request, not a block. Abusive scrapers ignore it, which is why the server-side rules above matter.

Use Cloudflare for stronger protection

If your site uses Cloudflare (the free plan is enough), you can stop this traffic before it ever reaches our servers. In Cloudflare, go to Security → WAF → Custom rules and create a rule:

• Expression: (http.request.uri.query contains "filter_" and not cf.client.bot)
• Action: Managed Challenge

Real shoppers pass the challenge, usually without noticing, while most scrapers can't. Cloudflare's Bot Fight Mode and rate limiting can add further protection. Our servers also run Imunify360, which blocks a lot of malicious traffic automatically. See Imunify360 blocked my page or shows a challenge.

Use page caching

Our servers run LiteSpeed, so WordPress sites can use the free LiteSpeed Cache plugin. Caching stops WordPress rebuilding the same pages over and over, which reduces CPU usage for normal traffic. See WordPress LiteSpeed Cache plugin setup.

On its own, caching won't solve this problem. When every bot request uses a new filter combination, there's nothing in the cache to serve, so each one still hits PHP and MySQL. Use caching alongside the blocking steps above.

Don't block all filters permanently

It's tempting to block every URL containing filter_, but real customers use your filters to find products. A blanket block will break your shop. The best long-term setup combines:

• Targeted blocking of bot behaviour (the .htaccess rules above)
• Cloudflare or another WAF with bot protection
• robots.txt rules for filter pages
• Page caching
• Checking your Resource Usage and logs from time to time

Check it's working

After making changes:

• Watch Resource Usage in cPanel. CPU should start to drop within a few minutes.
• Look at Visitors again. Bot filter requests should now show a 403 status instead of 200.
• Browse your shop and use the filters yourself, to make sure real visitors aren't affected.

If your whole site shows a 500 error after editing .htaccess, there's a typo. Restore the copy you downloaded and try again. See Find and read your website error logs.

On a VPS or dedicated server with root access, you can watch filter requests in real time from the domain's access log, for example:

tail -f /usr/local/apache/domlogs/example.co.nz-ssl_log | grep --line-buffered 'filter_'

Summary

The typical pattern looks like this:

Hundreds of IP addresses
        ↓
Normal-looking browser User-Agents
        ↓
Thousands of WooCommerce filter combinations
        ↓
WordPress + WooCommerce + MySQL build every page from scratch
        ↓
High CPU usage and 503 errors

Blocking individual IP addresses rarely works. Instead, identify the expensive request pattern and stop it before WordPress has to process it. The .htaccess rules give you immediate relief, and Cloudflare, robots.txt, caching and regular monitoring keep it under control long term.

Need help?

If your WordPress or WooCommerce site suddenly has high CPU usage or 503 errors, open a support ticket. Let us know roughly when the problem started, so we can match your resource usage against the traffic reaching your site at that time. We can check your access logs, CloudLinux resource usage, PHP and MySQL activity, Imunify360 logs and bot traffic, and help you put the right blocks in place.