WordPress runs a huge share of the web — which makes it the biggest target

There is nothing wrong with WordPress's security that careful configuration can't fix — but its success is also its liability. Because WordPress powers roughly 40% of all websites, it is the single most attractive target on the internet for automated attacks. Bots don't pick your site; they sweep the entire web for /wp-login.php, /xmlrpc.php, and known-vulnerable plugin paths, and run the same playbook against everything they find. Security vendors like Wordfence and Sucuri report billions of attacks blocked across WordPress sites every month.

The good news is that "predictable" cuts both ways. Because the attacks are automated and repetitive, a layered, mostly-automated defence stops the overwhelming majority of them with very little day-to-day effort. This guide walks through that defence in layers — login, attack surface, IP reputation, and bots — and, crucially, how to apply each without locking out the real customers you actually want.

TL;DR

• WordPress is attacked because of scale, not because it's uniquely weak. The attacks are automated, repetitive, and therefore very defendable.
• Defend in layers, not with one silver bullet: the login, software updates, your attack surface, file and server hardening, IP reputation, and bots — each closes a different door.
• Keep WordPress, plugins, and themes updated. Outdated, vulnerable plugins are the single most common way WordPress sites are actually compromised — far more than weak passwords.
• The strongest live signal is the visitor's origin IP. A login attempt or checkout from a data-center or open-proxy range is automation until proven otherwise.
• Don't block bluntly. Use a risk score, set ambiguous categories like VPN to "monitor" first, always allow-list your own IP, and keep verified search crawlers allowed.
• Watch your logs. Most break-in attempts are visible in failed-login and 404-scan patterns long before they succeed — monitoring turns security from reactive to proactive.
• Most of this can run on autopilot with a security plugin plus an IP-intelligence API — no need to babysit a blocklist.

The 2026 WordPress threat landscape

Five attack patterns account for almost all of the automated noise hitting a typical WordPress site:

• Login brute-force and credential stuffing. Bots try username/password combinations against wp-login.php — either guessing, or replaying credentials leaked from unrelated breaches. (We cover the mechanics in credential stuffing attacks: the complete guide.)
• User and author enumeration. Before guessing passwords, attackers harvest valid usernames via ?author=1 redirects and the REST API /wp-json/wp/v2/users endpoint — turning a password guess into a much easier targeted attack.
• XML-RPC abuse. The legacy xmlrpc.php endpoint allows hundreds of login attempts in a single request (system.multicall) and can be used for pingback-based DDoS amplification.
• Vulnerability scanning. Automated scanners probe for outdated plugins and themes with known CVEs, hitting paths like /wp-content/plugins/.../readme.txt at high speed.
• Bad bots, scrapers, and AI crawlers. Content scrapers, price bots, and AI training crawlers consume bandwidth and copy your content. Roughly half of all web traffic is now automated.

You don't fight these one plugin-vulnerability at a time. You build layers that neutralise whole categories at once.

Layer 1: Lock down the login

The login page is the front door, and brute-force is the most common knock. Two settings do most of the work:

1. Rate-limit and lock out failed logins. After a handful of failures, lock the source out — temporarily for ordinary visitors who mistype a password, permanently for high-risk IPs that have no business guessing. Splitting "clean" from "risky" IPs matters: a real customer should get a 30-minute timeout, while a Tor or data-center address probing your login deserves a permanent ban. (See login lockout thresholds.)
2. Add 2FA and strong passwords for every account with access. Two-factor authentication is the single highest-impact thing you can add to the login — even a correctly guessed or leaked password is useless without the second factor.

Two more login steps are worth taking: limit or block XML-RPC (see Layer 3), because it lets an attacker try hundreds of passwords in a single request and sidesteps simple login-page rate limits; and consider protecting or moving the default `/wp-login.php` URL so drive-by bots never reach a login form at all.

The combination is decisive: 2FA makes a correct guess useless, lockouts make guessing expensive, and IP screening (Layer 5) means a known-bad network never gets thousands of free attempts in the first place. Together they turn the login page from an open target into a dead end.

Layer 2: Keep everything updated

Here is the uncomfortable truth most WordPress security advice buries: the most common way WordPress sites are actually compromised is not a weak password — it's an outdated plugin or theme with a known, published vulnerability. Vulnerability trackers like Patchstack and WPScan catalogue thousands of new plugin and theme CVEs every year, and automated scanners weaponise them within days of disclosure.

The defence is unglamorous but decisive:

• Turn on automatic updates for WordPress core, and for plugins and themes you trust. The small risk of an update breaking something is far outweighed by the risk of running known-vulnerable code.
• Delete what you don't use. Every deactivated-but-installed plugin or theme still sits on disk and remains a potential entry point. Inactive is not the same as removed.
• Only install from reputable sources. Nulled or pirated "premium" plugins are a classic backdoor-delivery vehicle.
• Vet before you install: a plugin not updated in over a year, or carrying an open unpatched advisory, is a liability no matter how useful it looks.

No firewall fully compensates for running vulnerable code — patching is the foundation every other layer sits on.

Layer 3: Shrink your attack surface

Every piece of information your site leaks for free makes an attacker's job easier. Hardening removes that free intelligence:

• Block user/author enumeration. Stop ?author=N probes and lock down the REST /wp/v2/users endpoint so logged-out visitors can't harvest your usernames. This single change breaks the first step of most targeted brute-force attacks.
• Harden or disable XML-RPC. Unless you actively use it (some older mobile apps and Jetpack features do), block the amplification methods or disable xmlrpc.php entirely — it removes a favourite brute-force and DDoS vector.
• Hide your WordPress version. Remove the version number from your HTML source and feeds so scanners can't trivially match you to a list of version-specific exploits.

These are set-and-forget toggles with essentially no downside for a normal site. (Our WordPress hardening guide walks through each one.) Pair them with a real Web Application Firewall, which inspects request *content* for injection and exploit patterns — hardening shrinks the surface, the WAF guards what's left. For a deep dive on exactly how these three techniques work and how Predax Security stops them, see Stop WordPress Brute-Force Attacks: Login Floods, User Enumeration, and XML-RPC Amplification in 2026.

Layer 4: Harden your files and server

A handful of server-level settings shut doors that plugins alone can't:

• Disable the built-in file editor. Add define('DISALLOW_FILE_EDIT', true); to wp-config.php so that even if an admin account is compromised, an attacker can't rewrite your theme and plugin code straight from the dashboard.
• Set correct file permissions. Directories at 755, files at 644, and wp-config.php locked down to 600 or 640. Never use 777 on anything.
• Force HTTPS everywhere and enable HSTS so browsers refuse to fall back to plain HTTP — this protects logins and session cookies from interception.
• Add security headers — X-Content-Type-Options: nosniff, X-Frame-Options (to prevent clickjacking), and a sensible Referrer-Policy. They cost nothing and close off whole classes of browser-side attack; OWASP documents what each one does.
• Disable directory listing so a misconfigured folder doesn't hand your file structure to anyone who guesses the path.

A good security plugin (Predax included) can apply the headers for you, but the wp-config.php and permission changes are worth doing once at the server level and forgetting.

Layer 5: Screen visitors by IP reputation

Layers 1 and 2 protect specific endpoints. IP reputation protects everything at once, because it judges the visitor before the request even matters. The question shifts from "is this request malicious?" to "should this network be hitting my site at all?"

The signals, roughly in descending order of confidence:

• Data-center / hosting IPs. A real reader browses from a residential ISP or mobile carrier, not from AWS or a hosting provider. A login or checkout from a data-center range is automation until proven otherwise.
• Open proxies and Tor. Almost no legitimate customer reaches a small-business WordPress site through an open proxy or a Tor exit node. These are safe to block outright for most sites.
• VPNs. Trickier — lots of real people use them — so treat VPN as a *monitor-first* signal rather than an automatic block. (How VPN detection works.)
• High risk score / repeat velocity. Fold every signal into a single 0–100 score and act on the score, not any one flag. (IP risk scoring explained.)

The key configuration insight that trips people up: screening normal page visitors is usually off by default — most plugins only check login and registration unless you explicitly turn on full visitor screening. If you want to block a bad IP that's simply browsing or scraping, you have to enable that. (We wrote a whole guide on why blocking sometimes "doesn't work", and on choosing what to protect and detection modes.) For the deeper VPN/proxy/Tor angle specifically, see how to block VPNs, proxies and Tor on WordPress.

Layer 6: Block bad bots and AI scrapers

Not every unwanted visitor is trying to break in — some are just taking. Content scrapers republish your articles, price bots monitor your shop, and AI crawlers like GPTBot and ClaudeBot ingest your content for training. The defence overlaps neatly with the layers above: most abusive bots egress from data-center and proxy ranges, so IP-reputation screening catches them as a side effect. Add user-agent rules and verified-bot checks (reverse-DNS confirmation that "Googlebot" is really Google) and you allow the crawlers you want while stopping the impostors. When a single network is the source, ASN-based blocking can shut down a whole hosting provider's range at once.

Don't over-block: the risk-based approach

The fastest way to undermine your own security is to block so aggressively that you lose real customers — or yourself. Three rules keep you safe:

In practice: always add your own IP to the allow-list so a misconfiguration can never lock you out of your own admin; set ambiguous categories like VPN to monitor before you block; and if real visitors ever get caught, loosen the risk threshold rather than turning protection off. Start in monitor mode, watch the logs for a few days, then enforce — you'll tune out false positives before they ever reach a customer.

Monitor, and know what to do if you're breached

Security isn't a switch you flip once — it's something you watch, and the signals that matter are mostly already in your logs:

• Failed-login spikes, from one IP or many — the signature of a brute-force or credential-stuffing run.
• 404 floods — vulnerability scanners probe hundreds of non-existent plugin paths a minute, so a burst of 404s is usually reconnaissance.
• Blocked-threat trends — a sudden rise tells you you're being targeted, and it's worth reviewing what's getting through.

A good plugin surfaces these in a threat log and can email you when a high-risk visitor is blocked, so you're not parsing raw server logs by hand. The goal is to catch the *attempt* pattern before it becomes a *successful* breach.

And if the worst happens, work in order: take the site into maintenance mode; change every password (WordPress admins, database, hosting, FTP) and rotate your security keys; update everything; scan for and remove injected files or unknown admin accounts; then restore from a known-clean backup. Vendors like Sucuri publish detailed cleanup guides — and this is exactly why off-site, automated backups are non-negotiable: they are your fastest route back to a known-good state.

Wire it up: checking an IP from WordPress

If you want to build the IP layer yourself, it's a single API call. Here's the core of it in PHP, the kind of check you'd run on a login or checkout hook:

$ip = $_SERVER['REMOTE_ADDR'];

// The endpoint is POST-only — a GET returns 405.
$response = wp_remote_post( 'https://predax.io/api/v1/check/ip', array(
    'headers' => array(
        'X-API-Key'    => 'prdx_live_YOUR_KEY',
        'Content-Type' => 'application/json',
    ),
    'body'    => wp_json_encode( array( 'ip' => $ip ) ),
    'timeout' => 3, // fail open: never block real users if the API is slow
) );

if ( ! is_wp_error( $response ) ) {
    $data = json_decode( wp_remote_retrieve_body( $response ), true );

    // The signals live under 'classification'. Reading them at the top level
    // returns null silently — we shipped that exact bug three times in our
    // own plugins, so read the nested shape.
    $c = isset( $data['classification'] ) ? $data['classification'] : array();

    // Block automation; let privacy-conscious humans through.
    if ( ( $c['risk_score'] ?? 0 ) >= 70 || ! empty( $c['is_proxy'] ) || ! empty( $c['is_tor'] ) ) {
        wp_die( 'Access denied.', 'Blocked', array( 'response' => 403 ) );
    }
}

Two details matter for production: keep the timeout short and fail open (never block a real customer because the API was briefly slow), and cache the result per IP for an hour so you're not calling the API on every page view. A good plugin does both of these for you automatically.

Your WordPress security checklist

A quick, scannable version of everything above:

• Strong passwords + 2FA on every account with dashboard access.
• Login lockouts — temporary for clean IPs, permanent for high-risk ones.
• Automatic updates for core, plugins, and themes; delete anything unused.
• Block user/author enumeration and harden or disable XML-RPC.
• Hide the WordPress version and disable the dashboard file editor.
• Force HTTPS + HSTS and add the core security headers.
• Screen visitors by IP reputation — block data-center, proxy, and Tor; monitor VPNs.
• Turn on full visitor screening if you want browsing visitors checked, not just logins.
• Allow-list your own IP so you can never lock yourself out.
• Block bad bots and AI scrapers; verify real search crawlers by reverse DNS.
• Watch the threat log for failed-login and 404 spikes; alert on high-risk blocks.
• Keep off-site automated backups, tested at least once.

Work top to bottom and you've closed the doors that account for the overwhelming majority of WordPress compromises.

How Predax helps

Predax is an IP-intelligence API that classifies VPNs, proxies, Tor, data-center IPs, and bots in real time and returns a 0–100 risk score with full geolocation. The Predax Security plugin for WordPress wraps every layer in this guide — login lockouts, hardening, IP-reputation screening, bot blocking, and a WAF — into toggles you can switch on in a few minutes, with the per-IP caching and fail-open behaviour already handled.

If you're starting from scratch, the install & connect guide gets you live with a sensible preset; from there the WordPress Security help section covers each setting in plain language. The free tier — 5,000 IP checks a month, capped at 1,000 in any single day — is enough to test it against your own traffic before you commit to anything.

Frequently asked questions

Why is WordPress targeted so much more than other platforms? It's a numbers game — WordPress powers roughly 40% of the web, so automated attackers build their tooling for it first. The attacks aren't personal; bots sweep the whole internet for WordPress paths and run the same playbook everywhere, which also makes them predictable and defendable.

Isn't a strong password enough to stop brute-force attacks? A strong password defeats the guess but not the attempt — and thousands of attempts an hour drain resources and are often reconnaissance for credential stuffing. Combine strong passwords and 2FA with rate-limiting, lockouts, and IP screening so the traffic never gets free guesses.

Will blocking VPNs and proxies block my real visitors? Only if you do it bluntly. Treat VPN as one signal among many, block the higher-confidence categories (open proxy, Tor, data-center) outright, set VPN to monitor first, and always allow-list your own IP and verified crawlers.

Do I need a Web Application Firewall as well? Yes — a WAF inspects request *content* for exploits, while IP-reputation screening judges *who* is making the request. The first asks "is this request dangerous?", the second "should this visitor be here at all?" Run both.

What's the difference between blocking by country and blocking by IP reputation? Country blocking is a blunt geographic filter, useful only when a whole region is irrelevant to your business. IP-reputation screening judges each visitor on whether their network is a proxy, VPN, Tor, or data-center source — a better primary defence, since most fraud is anonymised through networks rather than tied to a country.

How are most WordPress sites actually hacked? Far more often through an outdated, vulnerable plugin or theme than through a guessed password. Automated scanners hunt for known plugin and theme CVEs and exploit them within days of disclosure, which is why keeping everything updated — and deleting what you don't use — is the single highest-leverage habit. No firewall fully makes up for running vulnerable code.

Do I need a security plugin, or can I harden WordPress manually? You can do most of it manually: wp-config.php flags, file permissions, security headers, disabling XML-RPC. The catch is the live layer — login lockouts, IP-reputation screening, and bot detection have to run on every request, stay current against new threats, and be tuned over time. A plugin packages that into toggles and keeps the threat data fresh, which is where the manual route falls down.

Will all this security slow down my site? Done right, the impact is negligible. The login, update, and hardening layers add no per-page cost. IP-reputation screening adds a lookup, which is exactly why caching the result per IP (usually for an hour) and failing open on a slow response matter — a well-built plugin does both, so the typical visitor never waits on it.