What Happens When Bots Hit Protected Content
Every public WordPress site gets bot traffic. Scrapers, AI crawlers, vulnerability scanners—they constantly probe your site looking for accessible files. That’s not new.
What’s changed is the volume.
And when your media protection relies on PHP to handle every request, that traffic becomes expensive very quickly.
The Hidden Cost of “Protection”
Most WordPress media protection plugins work by routing file requests through PHP.
When a request comes in, the system:
- Boots WordPress
- Checks permissions
- Either serves or denies the file
That works fine for legitimate users.
But the same process runs for unauthorized requests too. Every bot request still triggers the full stack—just to say “no.”
👉 You’re spending server resources to deny traffic that should never have reached your server in the first place.
Why This Breaks Under Load
Let’s make this concrete.
- Your hosting plan allows 10 PHP workers
- A bot swarm sends 50 concurrent requests
Each request:
- Consumes a PHP worker
- Takes ~100–500ms to process
Result:
- All workers are busy denying bots
- Legitimate users are queued
- Pages slow down or fail entirely
The system works—access is denied—but your site still becomes unavailable.
How to Tell If This Is Happening
Look for these signals:
- High request volume to protected media paths
- Many 403/404 responses for media files
- PHP workers consistently maxed out
If most of those requests are being denied, you’re burning resources on traffic that provides zero value.
Your Options
Option 1: Upgrade Your Hosting
More CPU, more PHP workers.
What it does: Gives you more headroom What it doesn’t do: Fix the root problem
You’re still paying to process bad traffic.
Option 2: Add Bot Mitigation
Tools like Cloudflare or Wordfence can block some traffic.
What it does: Reduces volume What it doesn’t do: Eliminate the problem
Some traffic always gets through.
Option 3: Move Protection to the Edge
Instead of handling requests in PHP, handle them before they reach your server.
- Authorized requests pass through
- Unauthorized requests are blocked at the edge
No PHP. No WordPress. No database.
Your server never sees the request.
What This Looks Like in Practice
We tested a simple scenario: what happens when a bot swarm hits a protected file.
Origin-based protection (PHP handler per request):
- Throughput: ~89 requests/second
- Average response time: ~507ms
- PHP workers: fully saturated
Edge-based protection (XYZ Protect):
- Throughput: ~1,208 requests/second
- Average response time: ~38ms
- PHP workers: zero
Both systems denied every request.
The difference is where the work happened.
Why This Matters
Under normal conditions, both approaches can work.
The difference shows up under load.
When bots hit your protected content:
- Origin-based protection consumes your server resources
- Edge-based protection isolates that traffic completely
Legitimate users don’t compete with bots for resources.
The Bigger Shift
Bot traffic is increasing.
AI crawlers are accelerating that trend.
Architectures that process every request at the origin will continue to feel pressure.
This isn’t a configuration issue—it’s where the work happens.
Is This Relevant to You?
If your site is slow due to:
- Login attacks
- Poor plugins
- Database issues
This isn’t your fix.
But if your bottleneck is protected media under bot traffic:
This is the difference between scaling and constantly upgrading hosting.
What This Means for Your Hosting Costs
When your server is busy processing bot traffic, you have two choices:
- Upgrade your hosting to handle the load
- Reduce the load hitting your server
Most site owners follow the first path. More CPU. More memory. More PHP workers.
But the underlying problem doesn’t change—you’re still spending resources on requests that deliver zero value. That means each upgrade only buys you time until traffic increases again.
If you’ve dealt with bot traffic at scale, you’ve probably seen this firsthand. The typical solutions involve adding layers—IP intelligence services, advanced bot filtering, or higher-tier CDN plans. Those tools can work, but they come at a cost. And they still operate on the assumption that your infrastructure needs to absorb and process incoming traffic.
At some point, it becomes cheaper to stop bad traffic than to keep scaling systems to handle it.
With edge-based protection, the equation changes.
- Bot traffic is handled before it reaches your server
- PHP workers are reserved for real users
- Your existing hosting plan continues to perform
Instead of scaling your infrastructure to absorb bad traffic, you prevent that traffic from consuming resources in the first place.
In practice, this often means:
- Avoiding a move from shared hosting to a VPS
- Delaying or eliminating the need for higher-tier plans
- Keeping hosting costs predictable as traffic grows
Final Thought
The question isn’t whether access is denied. It’s how much work your server does to deny it.
If protected media delivery is where your server is getting overwhelmed, XYZ Protect moves that load off your origin entirely.