We don't run WordPress. It was attacked 286,000 times

When we sorted every request our five websites received between 2 and 16 October 2026, one group dwarfed everything else: requests for WordPress. Login pages, admin screens, and above all a file called xmlrpc.php.

We don't run WordPress anywhere. Not one of these requests could ever have worked. They came anyway, from thousands of different addresses, around the clock.

What the bots asked for

Our five sites, 2–16 Oct 2026. The 286,061 count includes every path containing xmlrpc.php or wp-.

Why a Django site gets WordPress attacks

Because checking is cheaper than knowing. WordPress runs a large share of the web, so attack tools don't bother finding out what a site runs. They send the same list of paths to every address and domain they can find, and keep whatever answers. Four of our sites each received between 35,000 and 45,000 xmlrpc.php requests. The fifth, our newest domain, got 3 in the eight days we measured it: most likely it simply isn't on many attack lists yet.

xmlrpc.php is the favourite for a reason. On a WordPress site it accepts a system.multicall request, so one request can try hundreds of username and password pairs, slipping past limits that count login attempts. It can also be used to make a site send "pingbacks" to someone else, turning it into a weapon in a flood attack.

Why you've never seen this in Google Analytics

Analytics only counts visits that run its JavaScript tag. Attack tools don't run JavaScript: they send one request, read the status code and move on. So these were 74% of everything our servers answered, and analytics showed zero of it.

That matters even when every attempt fails:

• Your server still does the work. Each request goes through your web server, and often your application, to produce a "not found" page.
• Real holes get found. One forgotten .env file or exposed .git folder is all it takes, and they're among the first things checked.
• Spikes hide real problems. On 7 October alone, xmlrpc.php requests hit 27,907. If your logs are mostly noise, real errors are hard to see.

What to do if you don't run WordPress

Refuse these paths as early and cheaply as possible, before they reach your application. With nginx:

# Not a WordPress site: drop WordPress probes and secret hunting without a response
location ~* ^/(xmlrpc\.php|wp-login\.php|wp-admin/|wp-content/|wp-includes/) { return 444; }
location ~ /\.(env|git) { return 444; }

On Cloudflare, a custom WAF rule does the same at the edge, so the request never reaches your server at all: block when the URI path contains /xmlrpc.php, /wp-login.php, /wp-admin/, /.env or /.git.

What to do if you do run WordPress

• Turn off XML-RPC unless something needs it (some mobile apps and plugins do). Many security plugins have a switch, or block the path as above.
• Protect the login. Two-factor sign-in, no "admin" username, and a limit on attempts per address.
• Keep plugins updated, and remove the ones you don't use. Old plugins are what /wp-content/plugins/… probes are looking for.

For everyone

• Never put .env files or the .git folder anywhere your web server can serve them. Request https://yoursite.com/.env and https://yoursite.com/.git/config yourself: you want a 403 or 404.
• Watch for sudden changes. A jump in failed logins can mean someone is stuffing stolen passwords into your form; a jump in errors after a deploy means something broke.

Humansift does this watching for you. It flags attack paths in your logs, alerts you when attacks or login failures spike, and keeps them out of the visitor numbers you report.

How we measured

Every number here comes from the server logs of our own five websites (a pet guide, an education site, a small-business tool, a crafts marketplace and a fashion blog), from 2 to 16 October 2026: 400,425 page and API requests. Images, styles and scripts were counted separately and are left out. Each request was sorted by Humansift: named bots by their user agent, Googlebot, Bingbot, GPTBot, ChatGPT and Perplexity checked against the address ranges their owners publish, attack paths by pattern, and data-centre traffic by network. A "visitor" is one address and browser on one day. Five small sites are a small sample, so read these as one honest data point, not an industry average.