How to stop bot traffic to WoodMart product filters with Cloudflare

A WoodMart case study on reducing server load from WooCommerce faceted-navigation URLs with Cloudflare.

On our own WoodMart demo sites, we found automated crawlers repeatedly opening product-filter, sorting, and layout URLs. The sites do not process real customer traffic, but these requests still reached WordPress and triggered product archive queries.

We added a narrowly scoped Cloudflare Managed Challenge rule. During the next seven-day period, it matched 1.31 million requests—3.5% of all site traffic. Only 1.6% passed the challenge, so 98.4% of the matching traffic was stopped at Cloudflare.

Before enabling the rule, we could see CPU usage climbing to almost 100% in the terminal during peaks of bot activity. After Cloudflare started challenging these filter requests, those crawler-related load spikes disappeared from our demo servers. We are not assigning a percentage to the CPU reduction, but the practical difference was immediately visible.

What the crawlers were requesting

WoodMart and WooCommerce filters create query-string URLs. A crawler can combine attributes, categories, prices, stock status, sorting, and display options into a large number of distinct archives. Typical anonymized examples look like this:

/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
/shop/?filter_color=black&per_page=96&shop_view=list

A page-cache plugin remains important for normal pages—see our WoodMart performance optimization guide. It cannot eliminate every cold request when bots continuously generate new filter combinations. Google describes the same underlying problem in its documentation on faceted-navigation URLs.

The Cloudflare rule we tested

Create a custom rule under Cloudflare → Security → Security rules → Create rule → Custom rules, paste the expression below, and select Managed Challenge:

(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=")

The contains "filter_" condition is intentionally simple and broad. It catches parameters such as filter_color, filter_size, filter_category, and filter_product_brand wherever they appear in the query string. That simplicity also creates some false-positive risk, so review Cloudflare Security Events after deployment and narrow the rule if another feature uses the same text.

These are standard parameters from our WoodMart/WooCommerce setup, not a universal list for every store. Open the browser Network panel, apply each shop control, and confirm the parameters used by the actual site.

For WoodMart setup details, see Create a product filters form, Add a filters area to a custom shop layout, and the Product Archive Builder.

Test WoodMart AJAX Shop before rollout

Cloudflare Challenge Pages are not fully compatible with AJAX/XHR. In our WoodMart tests, the first filter request opened as a regular page and displayed the challenge. After it was passed, the page loaded correctly and subsequent AJAX filtering worked normally.

Test the rule on staging or in a clean private browser session before rollout. Check the first filter request, several subsequent filters, and both desktop and mobile. If filtering becomes stuck or the product grid displays challenge content, do not deploy the rule unchanged. Cloudflare explains this limitation in its AJAX/XHR compatibility documentation.

SEO and crawl management

The Cloudflare rule protects the server but does not manage indexation. Use robots.txt, canonical URLs, and the store’s SEO settings to control unnecessary faceted-navigation URLs. For example:

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

Extend this list only after an SEO review. Abusive bots can ignore robots.txt, so it cannot replace the Cloudflare rule.

Should Googlebot bypass the rule?

Cloudflare’s cf.client.bot field can identify verified crawlers. Allowing them to bypass the rule preserves crawl access but sends more requests to the server; challenging them reduces load but may affect the site’s SEO strategy. If you use Cloudflare’s verified-bot rule example, be careful with Skip all remaining custom rules: it also bypasses other lower-priority custom rules. Review the complete WAF ruleset first.

When you should not use this rule unchanged

Do not copy this rule directly when:

• Filter combinations are intentional, indexable SEO landing pages.
• Feeds, monitoring, mobile apps, or partner integrations use these query parameters.
• The first filter interaction must remain AJAX-only with no full-page challenge.
• The same parameter names are used by legitimate workflows outside the shop.

In those cases, narrow the rule by hostname or shop path, exclude trusted traffic, or use rate limiting instead of challenging every match.

Conclusion

On our WoodMart demo sites, crawler traffic to product-filter URLs was not harmless background activity. It generated 1.31 million requests in seven days and coincided with server-load spikes that reached almost 100% CPU. After enabling the Cloudflare rule, 98.4% of matching requests were stopped and those spikes disappeared.

For stores seeing the same pattern, this rule is a practical starting point. Check which parameters the store actually uses, review Cloudflare Security Events for false positives, and keep crawl and indexation decisions aligned with the site’s SEO strategy.