Most WordPress DDoS advice is useless.
It focuses on IP blocking, firewalls, or bandwidth graphs, while real WordPress sites go down for a much simpler reason: expensive application paths get hit concurrently.
You do not need botnets, spoofed IPs, or illegal tools to test this.
You need to understand what to protect, why it matters, and how to prove your assumptions are actually true.
This article shows you how to test a WordPress site safely from a single MacBook and, critically, how to confirm that your CDN is actually protecting you rather than just sitting in front of an exposed origin.
The First Principle: What Actually Dies First in WordPress
WordPress does not fail because your network link is saturated.
It fails when one of these resources is exhausted:
- PHP FPM workers
- Database connections
- CPU consumed by uncached PHP execution
- Memory consumed by concurrent requests
- Cache bypass paths being abused
Your goal is not to block IP addresses.
Your goal is to ensure these resources are never reachable by anonymous traffic at scale.
The Assets You Must Protect (In Order)
PHP Execution
Every request that reaches PHP consumes CPU, memory, and a worker slot.
If anonymous traffic can repeatedly execute PHP, denial is inevitable.
Database Connections
Most WordPress attacks are asymmetric.
A cheap HTTP request for the attacker triggers an expensive database query.
A few hundred concurrent database connections is enough to stall the site.
Cache Bypass Paths
Attackers deliberately choose paths that skip cache:
- Search
- Login
- Admin AJAX
- Query parameters
- RSS feeds
Origin Exposure
If attackers can reach your origin directly, your CDN and WAF are ornamental.
High Risk WordPress Endpoints
/wp-login.php/wp-admin/admin-ajax.php/xmlrpc.php/?s=anything/feed/- Any uncached page with query parameters
Preconditions Before You Test
You should already have:
- A CDN in front of WordPress
- Full page caching enabled
- Origin firewalled to CDN IP ranges only
- XML RPC disabled or restricted
- Low PHP worker limits
Philosophy of Safe Testing
All testing:
- Runs from one MacBook
- Uses valid HTTP
- Does not spoof IPs
- Does not amplify traffic
Tooling Setup on macOS
Install Homebrew if required.
Install curl, siege, hey, and optionally k6.
How to Test if Your CDN Is Bypassable
Identify the origin IP from hosting dashboards or historical records.
Test direct origin access by forcing the Host header.
If WordPress content loads, your CDN is bypassable.
Test high risk endpoints directly against the origin.
Compare headers from CDN versus origin.
If origin responds normally, isolation is broken.
Safe Application Level Tests
Test anonymous page access for cache behaviour.
Test admin-ajax abuse.
Test login rate limiting.
Test search cache bypass.
Test concurrency with hey.
Metrics That Matter
- PHP worker queues
- Database connections
- CPU and memory
- Cache hit ratios
- Time to first byte
Hard Rule
Anonymous users must never reach PHP.
How to Harden WordPress
- Enforce origin isolation at the firewall
- Make WordPress static for anonymous users
- Lock down admin-ajax
- Disable or restrict XML RPC
- Rate limit by behaviour, not IP
- Fail fast at the origin
Final Reality Check
If your CDN can be bypassed, all other protection is cosmetic.
Real protection means the origin is unreachable except through the CDN.