WordPress runs a large share of the web, which makes it the default target for automated attacks. It is also unusually easy to overload: a single uncached request can trigger dozens of database queries, so a flood that a static site would shrug off can take a WordPress origin down with a few hundred requests per second.
The Three Endpoints That Get Hit
- xmlrpc.php — the legacy remote publishing interface. It supports request batching, which makes it an amplifier: one HTTP request can carry many operations.
- wp-login.php — the login form, targeted both for credential stuffing and as a cheap way to force uncached, database-heavy requests.
- Search and filtered archive URLs — every unique query string bypasses the page cache and reaches PHP and the database.
Why caching alone is not protection
A page cache only helps when the attacker requests cacheable URLs. Adding a random query string to every request defeats it, which is exactly what automated floods do.
Layers That Matter, In Order
Start at the edge and work inward. Filtering in front of the origin is the only layer that keeps flood traffic off the server entirely; everything after it is damage control on traffic that already arrived.
- Edge filtering with a browser challenge, so automated clients never reach PHP during an attack.
- Per-address rate limits that are strict on login and search, and loose on static assets.
- Disable xmlrpc.php if you do not use it, or restrict it to the addresses that need it.
- A full page cache with a sane policy for query strings, so cache-busting parameters do not become a free path to the database.
- A tuned PHP worker pool: enough workers to use the machine, few enough that memory exhaustion does not take the whole host down.
Hide the Origin
The most common reason edge protection fails on WordPress is that the origin address is still public. It leaks through old DNS records, mail headers sent by the site, and subdomains that were never moved behind the proxy. Once traffic is routed through a proxy, the origin should accept connections only from the proxy addresses — a firewall rule, not a plugin setting.
What to Skip
Security plugins that block addresses from inside PHP are, during a flood, simply another database write per malicious request. They are useful against slow credential attacks and useless against volume. The same applies to anything that logs every blocked request to the same database the site is trying to serve from.