.htaccess changes can cause outages, block legitimate visitors, interfere with third-party services or make a website inaccessible if they are configured incorrectly. The examples here describe what worked in my environment and may not be appropriate for yours. Back up your configuration first, make changes only to systems you own or are authorized to administer, test carefully, keep a working recovery method available, and consult your hosting provider or a qualified professional if you are unsure. You are responsible for any changes you choose to make based on this article.It started with traffic that didn't make sense
For several days I was troubleshooting suspicious traffic affecting websites I manage. The sites were behind Cloudflare and had security rules in place, yet I was still seeing requests in Wordfence and hosting activity that seemed to be consuming resources.
A pattern that caught my attention involved reverse hostnames ending in bc.googleusercontent.com. That name is associated with Google Cloud infrastructure, and it is important not to jump to the conclusion that “Google is attacking the site.” Cloud platforms host countless legitimate and illegitimate workloads. An attacker can rent cloud infrastructure just like a legitimate business can.
The useful clue was not the hostname by itself. It was what the requests revealed: some traffic appeared to be reaching the hosting environment without taking the Cloudflare path I expected.
The assumption I had to challenge
It is easy to think that once the DNS record is orange-cloud proxied, every HTTP request must go through Cloudflare. In normal use, that is the path. But if somebody discovers a reachable origin address and the origin accepts requests directly, they may attempt this:
On that second route, Cloudflare custom rules, bot controls and rate limiting cannot inspect a request they never receive. Wordfence may still see the request later, but by then the hosting server and WordPress are already involved.
What I tried first
My first instinct was the obvious one: allow Cloudflare's proxy networks and reject everything else. That is a sound architecture in environments where you control the network firewall and can maintain the allowlist correctly.
In my particular shared/managed hosting environment, however, the IP-based approaches I tested were not giving me the result I wanted. I spent several days working through allowlists and web-server restrictions and continued to see behaviour that made me uncomfortable.
Rather than pretending that one technique works everywhere, I changed the question: could the origin require a marker that a direct visitor would not have, but my Cloudflare path would add?
The solution: require a private request header
The design I settled on was simple in concept:
In the original implementation I used a Cloudflare Worker on the site's route to add the header, then an Apache .htaccess rule at the origin to reject requests that did not contain the matching value.
Cloudflare's current platform also has Request Header Transform Rules that can modify headers sent to an origin. Whether that is the better implementation depends on the features available to your account and the exact hosting design. The important architecture is the same: the trusted Cloudflare path adds a private marker; the origin requires it.
Worker example—with a placeholder, never a real secret
A Worker running on a route in front of an existing origin can clone/modify the incoming request, set a private header and then continue the request to the origin. A simplified educational example looks like this:
Do not use the placeholder above as a secret. Generate a long random value and keep it private. The previously published version of this article contained an example value; I intentionally do not repeat or reuse it here.
For an existing external origin, Cloudflare Workers Routes are the relevant routing model: the hostname must be proxied and the Worker runs in front of that application server. Cloudflare also supports Custom Domains for cases where the Worker itself is the origin, which is a different architecture.
The origin rule
On an Apache environment where .htaccess is the appropriate control point, the concept is to reject a request when the expected header does not match. A deliberately generic example is:
The header name and secret must match what the trusted edge path sends. This is not a universal copy-and-paste recipe. Apache configuration, reverse proxies, caching, health checks, control panels and hosting restrictions can change how the rule should be implemented.
The test that gave me confidence
I wanted two results: the public website should work normally through Cloudflare, and a request deliberately sent to the origin while preserving the hostname should be rejected.
1. Test the normal Cloudflare route
You are looking for the normal successful response appropriate to the site.
2. Test the origin directly
Replace the example hostname and origin address with values you are authorized to test. With the protection working as designed in my environment, the direct-origin request returned 403 Forbidden while the normal Cloudflare path continued to work.
This distinction matters. Testing only the public URL proves the website works; it does not prove the origin is unreachable through another path.
What I did about the Google Cloud traffic
After fixing the direct-origin issue, suspicious traffic could still legitimately arrive through Cloudflare. That is a different problem, and now Cloudflare could actually evaluate it.
The original article used an ASN-based Managed Challenge for traffic from Google's ASN while excluding Cloudflare-known good bots. I would not blindly republish the old expression because Cloudflare's Rules language has evolved. As of September 2026, Cloudflare documents ip.src.asnum as the current ASN field, while cf.client.bot remains available to identify known good crawlers on all customer plans. Some Bot Management fields require higher-tier subscriptions.
More importantly, I would not challenge an entire major cloud ASN merely because one reverse hostname appeared in a log. Build a rule from the behaviour you actually observe, scope it as narrowly as practical, preserve verified bots where appropriate and review Security Events for false positives.
Why I prefer a challenge while tuning
When a traffic source may contain both automated abuse and legitimate users, Managed Challenge gives Cloudflare a chance to evaluate the visitor instead of immediately denying everyone. Once you have evidence and understand the impact, a narrower block may make sense for requests that can never be legitimate.
My backup plan before enabling the origin rule
.htaccess or server configuration.If the whole site suddenly returns 403
Check whether the Worker or request-header rule is still active, whether the route covers the hostname you are testing, and whether the origin expects the same header/value the edge is sending. If necessary, temporarily remove the origin restriction through your hosting/file access, restore service, then troubleshoot without the site locked behind a failing rule.
A single typo can cause an outage. That is why I treat this as controlled server work, not a five-minute WordPress tweak.
What changed after the fix
For my environment, the important result was architectural: direct requests without the private marker were rejected, while normal requests through Cloudflare continued to reach the website. That meant Cloudflare once again had the opportunity to apply the security controls I had configured before traffic reached WordPress.
What began as “why am I seeing this strange bot traffic?” turned into a much more useful question: is every web request actually travelling through the security layer I think it is?
How this relates to the 10-part WordPress Security Guide
This case study stands on its own. If you want the broader educational version, Part 3 explains origin-server protection, Part 4 covers Cloudflare firewall strategy, and Part 7 covers spam and bots.
Read the Complete WordPress Security Hardening Guide