Most WordPress attacks don’t arrive out of nowhere. There’s almost always a build-up small, easy-to-miss signals in the days or weeks before things escalate into an actual breach or outage. The problem is that these signals look like background noise unless you know what you’re looking at. Here’s what to watch for, and what’s actually happening behind each one.
https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare
Sign 1: A Sudden Spike in Failed Login Attempts
If your WordPress login page is seeing dozens or hundreds of failed attempts in a short window, that’s not a fluke it’s almost always an automated brute-force attempt working through common username/password combinations. On its own, a modern password usually survives this. The danger is that brute-force attempts tend to escalate over time, and a login page with no rate limiting will keep letting the attacker try, indefinitely, for free.
What this looks like in your logs: repeated POST requests to /wp-login.php from a rotating set of IPs, often at a steady, mechanical interval rather than the irregular pattern of a human typing.
https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare
Sign 2: Unusual Activity on XML-RPC
xmlrpc.php is a WordPress file originally built to allow remote publishing and communication between sites but it’s also one of the most commonly abused entry points, because a single request to it can trigger hundreds of login attempts internally, effectively turning one request into a brute-force multiplier. If your server logs show repeated POST requests to this file, especially in bursts, that’s a strong early indicator someone is probing for weak credentials at scale.
https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare
Sign 3: Traffic That Doesn’t Behave Like Visitors
Real visitors browse unevenly they land on a page, pause, click around, sometimes bounce immediately. Bot traffic tends to look mechanically consistent: identical time-on-page across sessions, requests hitting the same handful of URLs in sequence, or traffic arriving in perfectly even intervals rather than natural clusters. A sudden increase in “visitors” that all behave identically is a sign you’re looking at bots, not people and bots probing a site are often reconnaissance for a later, more targeted move.
Sign 4: Requests to Endpoints That Shouldn’t Get Traffic
Watch for repeated requests to things like /wp-content/uploads/, old plugin folders, or admin-adjacent paths that aren’t part of your normal site navigation. Attackers frequently scan for known vulnerabilities in outdated plugins or themes by requesting specific file paths directly — if a request pattern looks like it’s checking for the existence of files rather than viewing your actual content, that’s scanning behavior, not browsing.
Sign 5: A Slow, Unexplained Increase in Server Load
Before a full DDoS event, there’s sometimes a quieter ramp-up server response times creeping up, resource usage climbing without a corresponding rise in legitimate traffic. This can be attackers testing capacity, running smaller probing waves before a larger attempt, or bots simply crawling more aggressively than your server can comfortably handle.
Why These Signs Usually Go Unnoticed
None of this shows up on a typical site owner’s radar because none of it looks dramatic in isolation a few failed logins here, a slightly higher bounce rate there. It only becomes obvious in hindsight, after the full attack, when someone finally looks back at the logs and realizes the warning signs were all there a week earlier.
What Armor Pro Catches Automatically
This is precisely the gap between hoping nothing happens and having something actively watching:
| Warning Sign | Armor Pro Response |
|---|---|
| Brute-force login spikes | Rate limiting on login endpoints, slowing or blocking repeated attempts |
| XML-RPC abuse | Custom WAF rules tuned to detect and block this specific abuse pattern |
| Bot traffic | Full managed WAF ruleset filtering automated, non-human traffic |
| Vulnerability scanning of old paths | Custom application-specific rules blocking known probing patterns |
| Rising server load from bad traffic | Cache tuning and Automatic Platform Optimization reducing load from illegitimate requests before they strain your server |
Every month, Armor Pro also includes a one-page security and traffic report — which means these patterns don’t just get blocked silently in the background, they get surfaced to you, so you actually see that something was attempted and stopped.
The Honest Comparison
A site running Armor Lite already has baseline protection against bad bots and login/XML-RPC abuse a solid floor. Armor Pro goes further: it’s tuned rate limiting, custom rules built around your specific application, and visibility into what’s actually being attempted against your site each month, rather than protection running invisibly with no reporting at all.
The alternative noticing these signs only after they’ve become an actual incident is exactly the scenario that leads to an emergency call and an Armor SOS cutover instead. Catching the warning signs early is simply the cheaper, calmer version of the same problem.
