One line that matters: you can make Cloudflare’s Managed Challenge only fire on /search requests when the query string contains an ampersand. If you run a faceted search or any expensive endpoint, this spares normal '?q=term' searches while slowing down aggressive crawlers hitting multiple params.
The rule expression:
(http.request.uri.path wildcard r"/search/*" and http.request.uri.query contains "&")
Why this works: '&' usually means multiple query parameters (facets, pagination, filters). Many scrapers enumerate combinations; simple human searches often pass a single 'q'. This is a cheap, specific heuristic that cuts friction for regular users.
Trade-offs and constraints:
- It’s a heuristic, not security. Bots can adapt by avoiding multiple params or spacing requests.
- Some legit users will include multiple params (e.g., sort, page). They’ll get a challenge—likely acceptable if your goal is to protect costly queries, but measure it.
- Apply it only where it makes sense (e.g., your search path), and keep rate limiting and logs in place.
Interesting side note: the author tried Cloudflare MCP with Claude Code to edit the rule and hit capability gaps; the practical path was falling back to the Cloudflare API. My read: MCP provider coverage for vendor-specific admin surfaces is still spotty. Keep your API playbook handy and design automations that can drop to raw API calls when tools can’t.
What I’d watch:
- Challenge rates vs. successful searches in analytics after rollout.
- If crawlers adjust (e.g., single-param crawling), consider layering: header reputation, method/path allowlists, and smarter rate limits.
Short, practical takeaway: this expression is a low-effort way to stop hassling normal searches while still checking the costly ones. Read the original for the quick story and caveats.