Most WordPress owners still imagine DDoS as a bandwidth problem.
That mental model misses the attacks that cause the most operational confusion on normal sites.
Layer 7 attacks are quieter. They look like real requests. They hit pages, search endpoints, login paths, XML-RPC, account routes, and dynamic URLs that force the application to do work. The site may stay online the whole time and still feel terrible.
That is why application-layer DDoS is often misdiagnosed as "hosting issues," "slow PHP," or "some plugin acting weird."
The traffic is the problem. The stack is just carrying it.
Layer 7 attacks win by being expensive, not by being huge
You do not need enormous bandwidth to hurt WordPress.
You just need requests that are expensive enough often enough.
A cached page hit is cheap. A search request is not. A WooCommerce account request is not. An XML-RPC call is not. A login request that wakes sessions, database reads, and plugin hooks is definitely not.
I have seen sites absorb a lot of traffic calmly when most of it was cacheable, then stumble badly under much lower request volume because the traffic shifted onto expensive paths. That difference matters more than the raw request count.
This is why "requests per second" by itself is not a sufficient security metric. Ten bad requests against the wrong path can cost more than a hundred good requests against a cached page.
Why WordPress is easy to stress at the application layer
WordPress is not uniquely broken. It is just easy to make work.
Common pressure points include:
wp-login.php/xmlrpc.php- search
- preview routes
- WooCommerce account and checkout paths
- uncached pages with heavy plugins
Once you add themes, plugins, API calls, personalization, carts, and tracking logic, the cost per request goes up fast.
That is why application-layer attacks are so annoying on WordPress. The attacker does not need to break the site. They just need to keep choosing the paths that make it work hardest.
Why origin-side mitigation is always late
A lot of WordPress security advice still starts inside the application.
Install a plugin. Add a CAPTCHA. Add some rate limiting. Tighten Nginx. Tune PHP-FPM.
All of that can help. None of it changes the core problem if the traffic is still reaching origin in volume.
Once the request has made it that far, the expensive part has already started. The web server saw it. PHP may see it. Sessions may open. The database may get touched. Even a rejected request can be too expensive if enough of them arrive.
That is why I care much more about where the request is handled than about which local plugin rejects it.
Why these attacks are easy to underestimate
Layer 7 pressure often builds sideways.
The site does not always fall over. Instead you see:
- admin pages timing out
- login flows feeling inconsistent
- API calls slowing down
- checkout lag on stores
- uptime still technically green while users complain
That is one reason operators underestimate it. They wait for a full outage signal. The damage has already been happening for a while.
One pattern I see often is a site owner saying, "We are not under attack, the site is just slower from some countries." Then you check the paths taking traffic and the story becomes obvious. It is not random geography. It is cached versus uncached pressure, different edges serving stale responses, or hostile traffic hitting dynamic routes from distributed networks.
Why caching helps and still does not solve the whole thing
Good caching is one of the best ways to make WordPress harder to hurt.
But only for the parts of WordPress that should be cached.
That distinction matters more than people admit.
If an attack hits:
- login
- search
- checkout
- cart
- XML-RPC
- dynamic account routes
cache alone will not save you. Those are exactly the paths that are often uncached or should be uncached.
So yes, caching reduces pressure. No, it is not a complete answer to application-layer DDoS.
I would rather describe it this way: caching removes cheap attack opportunities. You still need another layer for the expensive ones.
Why path-aware filtering matters more than blanket rules
The mature answer to Layer 7 pressure is not "block more traffic."
It is "treat different request classes differently."
A brochure page can tolerate one policy. Search deserves another. Login deserves another. WooCommerce deserves another again.
This is where a lot of generic DDoS messaging falls apart. It talks about floods without talking about path economics. On WordPress, path economics are the whole game.
Requests to dynamic routes should face stricter handling because they cost more.
That means being more opinionated about:
- rate limits
- repeated request patterns
- suspicious headers or agents
- challenge decisions
- bot posture on sensitive endpoints
This is also where the FirePhage DDoS Protection positioning fits naturally. The real value is not just absorbing traffic. It is making sure the wrong traffic never becomes expensive WordPress work in the first place.
Why hard blocking is not always the smartest first move
There is a temptation to swing hard once you recognize hostile traffic.
Sometimes that is correct. Sometimes it creates its own mess.
Real users do weird things. They refresh. They search badly. They sign in from mobile networks. Agencies test from VPNs. Payment plugins make bursts. Monitoring tools can look repetitive. If your rule set is too blunt, you swap attack noise for support noise.
Challenge logic and graduated response usually age better than all-or-nothing blocking.
This is especially true during an ongoing event. You want room to tighten fast without locking out everyone who behaves imperfectly.
What I would check on a WordPress site taking Layer 7 pressure
If I had to review a site quickly, these are the first questions I would ask.
Which paths are expensive and still reachable without friction?
That list is almost always longer than the team thinks.
Are cached and uncached traffic patterns visible separately?
If not, you cannot tell whether the site is slow because volume is high or because the wrong endpoints are getting hit.
Is the origin doing too much defensive work?
If the answer is yes, the control point is too late.
Is XML-RPC still exposed for no real reason?
I would remove that surface first on most sites.
Are there emergency controls ready before a real event?
The worst time to invent a stricter posture is in the middle of the attack.
Why "under attack mode" exists for a reason
Application-layer events often do not justify a permanent hard posture.
They do justify a fast one.
The useful operational move is not to pretend the site should always run in emergency mode. It is to have a stricter mode ready when traffic turns hostile and to know exactly what that mode changes.
That usually means stronger challenge decisions, tighter request tolerance on sensitive routes, and less patience for automation that looked borderline five minutes earlier.
The sites that handle these events best are not always the ones with the biggest infrastructure. They are the ones that can change posture quickly without improvising.
The better question to ask
Do not ask, "How much traffic can my host take?"
Ask, "How much expensive application traffic am I willing to let reach WordPress?"
That question leads to better defenses.
It pushes you toward:
- caching where it is safe
- strict handling where it is not
- edge-side filtering before origin
- better visibility into path-specific pressure
- a faster emergency posture when traffic changes shape
Layer 7 DDoS is not dangerous because it looks dramatic. It is dangerous because it looks normal just long enough for WordPress to waste real resources on the wrong visitors.