A lot of the load on a typical WordPress site does not come from visitors. It comes from automated traffic hitting the same few files: the XML-RPC interface, the login page, and the cart and wishlist links that SEO tool crawlers follow. If your domain runs through Cloudflare, three simple firewall rules stop most of that traffic before it reaches our servers. This article covers what each rule does, what to check before you add it, and how to tell it is working.
Why the edge is the right place for these blocks
A security plugin such as Wordfence can block brute force logins and bad bots, but it does so from inside WordPress. By the time it refuses a request, the server has already started PHP and loaded part of the site to make that decision. Thousands of refused requests still cost CPU. A Cloudflare rule refuses the request at Cloudflare’s network, so it never arrives at the hosting account and never uses your resources.
These rules only run if the domain is on Cloudflare with the website’s DNS record proxied (the orange cloud). They live in your Cloudflare account, not on our server. In the dashboard they are under Security, then WAF, as custom rules (older accounts called them firewall rules).
Rule 1: block XML-RPC
xmlrpc.php is an old remote publishing interface built into WordPress. It is a well-known attack target: bots use it to guess passwords and probe for vulnerabilities, and enough traffic to it can consume so much CPU that it takes a site down. Many security plugins disable it. Blocking it at Cloudflare is simpler and cheaper for the server.
- Match: URI Path contains
xmlrpc.php - Action: Block
Check first: Jetpack and some older publishing tools connect through XML-RPC. If you use them, test after adding the rule, or leave this one out.
Rule 2: block SEO tool crawlers
The crawlers used by Semrush, Ahrefs and Moz (Open Site Explorer and Dotbot) are aggressive. On WooCommerce stores they follow add to cart and wishlist links several times a second, which the server experiences as several shoppers working on carts at once. On shared or entry-level hosting that is a significant load for traffic that brings you nothing.
- Match: User Agent contains each crawler name, joined with “or”. You only need part of the user agent string, not all of it.
- Action: Block
Cloudflare’s “contains” match is case-sensitive, so use the exact spelling each crawler sends (for example SemrushBot, AhrefsBot, DotBot), or wrap the field as lower(http.user_agent) in the expression editor and match lowercase names. After deploying, check Security Events to confirm the rule is matching.
One trade-off: if you or your marketing agency pay for any of these tools, their site audit of your own website will stop working while the rule is active. Pause the rule when you need an audit.
Rule 3: challenge the login page from outside your country
wp-login.php is bombarded by brute force password guessing. The video mentions sites receiving 1,000 to 10,000 attempts a day when the rule was first applied, each one making PHP work. This rule shows Cloudflare’s challenge page to anyone outside your country before they can reach the login form.
- Match: URI Path contains
wp-login.phpand Country does not equal your country (Australia in the video) - Action: a challenge (captcha), not a block, so a staff member travelling overseas can still get in
On WooCommerce sites, use this one with caution. Customers logging in to their account could be challenged, which is unwelcome if you sell to other countries.
Checking the results
The rules take effect as soon as you deploy them. Come back a day later and each rule shows how many requests it acted on. In the video’s 24-hour snapshot the XML-RPC rule blocked 5 requests, the crawler rule 32 and the login rule challenged 12, with a CSR (challenge solve rate) of zero, meaning none of them were genuine users. The video also notes that once the rules have been in place for a week or two, much of this junk traffic stops arriving altogether.
All three fit within Cloudflare’s free plan, which allowed five rules at the time the video was made.
When to contact us
If your site is still hitting resource limits or slowing down at certain times after these rules are live, open a ticket from the client area with the domain, the times you noticed the problem and whether the domain is proxied through Cloudflare. Our support team can check the server access logs to see what is actually requesting pages at those times, which shows whether another rule is needed or the cause is elsewhere.