Cloudflare Security Rules for WordPress: Free, SEO-Safe Firewall Setup

This guide shows how to protect a WordPress site with Cloudflare’s free firewall rules. The configuration focuses on real attack surfaces, avoids false positives, and keeps search engines and normal visitors fully unaffected.

If you have managed a WordPress site for any length of time, you have probably noticed that most attacks follow predictable patterns. They target the same endpoints, rely on the same automation tools, and rarely adapt to how a site is actually used.

Instead of responding with dozens of overlapping rules, this setup uses four carefully chosen Cloudflare security rules. Each rule has a clear purpose. Together, they form a balanced system that stays quiet during normal traffic and reacts only when something looks genuinely suspicious.

To avoid exposing sensitive information, all examples below use the placeholder [your custom login path]. When applying the rules in your own Cloudflare dashboard, replace it with your private WordPress login URL.

Rule 1 · Allow Hidden WordPress Login

Many site owners hide the default WordPress login page behind a custom path. That single change already removes a large amount of background noise. This rule makes sure Cloudflare never interferes with that private entry point.

By placing this rule at the top and skipping all other custom rules, you keep the administrator login smooth and predictable, even when stricter protections apply elsewhere.

Highest Priority Admin Safe SEO Neutral

(
  http.request.uri.path eq "[your custom login path]"
)

Action

Skip
→ Skip: All other custom rules

Rule 2 · Allow Verified Search Engines

Search engines should never feel the presence of a security layer. Cloudflare already verifies major crawlers such as Googlebot and Bingbot, which makes it safe to let them pass without friction.

This rule explicitly allows verified bots and direct access to /robots.txt. Indexing remains clean and consistent, with no unexpected challenges.

(
  cf.client.bot
  or http.request.uri.path eq "/robots.txt"
)

Action

Skip
→ Skip: All other custom rules

Rule 3 · Block Default WordPress Attack Surface

Even today, a large share of automated attacks still target /wp-login.php and /xmlrpc.php. If your site does not rely on XML-RPC, blocking these endpoints removes a major source of risk immediately.

This rule keeps things simple. It blocks the requests outright, without challenges or rate limits, and avoids unnecessary complexity.

(
  http.request.uri.path eq "/wp-login.php"
  or http.request.uri.path eq "/xmlrpc.php"
)

Action

Block

Rule 4 · Managed Challenge for Obvious Automation

Some traffic does not even try to look human. Tools like curl, wget, and common scraping frameworks tend to announce themselves clearly through their user agents.

This rule looks for that behavior only on administrative paths, including your custom login URL. Front-end readers never encounter a challenge, while automated tools meet an extra verification step.

not cf.client.bot
and (
  http.user_agent contains "curl"
  or http.user_agent contains "wget"
  or http.user_agent contains "python"
  or http.user_agent contains "go-http-client"
  or http.user_agent contains "scrapy"
)
and (
  starts_with(http.request.uri.path, "/wp-admin")
  or http.request.uri.path eq "/wp-login.php"
  or http.request.uri.path eq "[your custom login path]"
)

Action

Managed Challenge

What This Setup Achieves

With these four rules in place, WordPress stays fast, indexable, and significantly harder to abuse. The configuration fits entirely within Cloudflare’s free plan and leaves one extra rule available for future needs.

✔ Search engines crawl freely
✔ Custom admin login stays private
✔ Default attack endpoints disappear
✔ Automation receives challenges
✔ Front-end users remain unaffected
✔ SEO and caching remain intact