When your server logs show the same IP address hammering your login page hundreds of times an hour, or a scraper bot churning through your site at midnight, the fastest remedy is a direct block. Brute force attacks, comment spam, and aggressive crawlers often come from a small pool of repeat offenders — cut off those addresses and the noise drops immediately.
WordPress has no built-in IP blocking tool, but there are three practical options: a security plugin, your server’s access-control config, or your hosting control panel. Which one fits depends on how many IPs you need to block, and where the attack is actually coming from.
Finding the IPs Worth Blocking
Before blocking anything, you need to know what you’re blocking. Security plugin reports are the most direct source — Wordfence and similar plugins log failed login attempts and blocked requests with the originating IP visible under Wordfence → Firewall → Blocked Attacks. Server access logs work too: cPanel users can check Metrics → Visitors or Logs → Access Log for high-frequency requests from a single IP in a short window. And your comment spam queue often shows the same IP behind multiple spam entries.
Before blocking anything, run a quick lookup on a tool like ipinfo.io to confirm it isn’t a shared hosting address, a legitimate search engine crawler, or a known CDN node — blocking a Googlebot IP by mistake costs you indexing, not attackers.
Blocking With Wordfence
Wordfence is the most widely used WordPress security plugin and includes IP blocking in its free firewall — get it at wordpress.org/plugins/wordfence. Install and activate it, go to Wordfence → Firewall → Blocking, select IP Address from the block type dropdown, enter the address, optionally note a reason for your own records, and click Block. It takes effect immediately, returning a 403 Forbidden to any request from that address.
If attacks come from multiple IPs in the same subnet, block the whole range with CIDR notation — 192.168.1.0/24 covers all 256 addresses in that block — which Wordfence’s blocking interface accepts directly. Worth doing whenever a cluster of IPs shares the same first two or three octets.
Blocking at the Server Level
Blocking without a plugin works at the server level, before WordPress even loads, which makes it slightly faster for high-volume situations — but the correct syntax depends on your server software, and this is where a lot of copied tutorials cause real problems.
If your host runs Apache 2.4 or later — the current version on virtually all modern hosting — the old Order Allow,Deny / Deny from syntax is deprecated. It still works on hosts that keep mod_access_compat enabled for backward compatibility, but the correct current syntax uses Require:
<RequireAll>
Require all granted
Require not ip 192.168.1.100
Require not ip 10.0.0.50
</RequireAll>Add this to your site’s root .htaccess file (accessible via FTP or your host’s file manager) before the WordPress rewrite rules, replacing the example IPs with the ones you’re blocking, or a partial address like Require not ip 192.168.1 to block a whole range. Save it and the block applies immediately, no restart needed.
If your host is running LiteSpeed (a common Apache-compatible setup on shared hosting), the same .htaccess syntax generally works. If your host runs Nginx instead, .htaccess does nothing at all — Nginx has no per-directory override file, and blocking an IP means adding a deny 192.168.1.100; line to the server block config directly, which usually means asking your host to make the change or using whatever IP-blocking tool their control panel provides instead. Check which server software your host actually runs before assuming either syntax applies.
Blocking Through Your Host’s Control Panel
Most shared and managed hosting providers include an IP blocking tool in their control panel — in cPanel it’s under Security → IP Blocker. Enter an IP or range and the host applies the block at the server level, ahead of your WordPress install and any .htaccess rule entirely. This is the best option under a high-volume attack that’s already loading the server, since blocking at the application layer — WordPress or even .htaccess — still costs some server processing per request, whereas a hosting-level block stops the traffic earlier. It’s also the right tool if you manage multiple WordPress installs on one hosting account and want the block applied across all of them at once.
Keeping Blocks Useful Instead of a Liability
Keep a simple record — a text file, a note — of what you’ve blocked, when, and why; revisiting a security setup months later without one means starting from scratch. Check before blocking shared IPs: corporate networks, mobile carriers, and some ISPs route many users through one address, and an ipinfo.io lookup will flag this before you accidentally lock out real visitors. Review blocks periodically too — IPs get reassigned, and a block that was necessary six months ago may now sit on someone else entirely. And combine blocking with broader WordPress hardening — IP blocks deal with known offenders, but hardening closes the vulnerabilities those offenders were actually trying to exploit in the first place.
Mistakes Worth Avoiding
Blocking your own IP — it sounds obvious, but it happens; check with a quick “what is my IP” search before blocking any address. Blocking without investigating — one IP rarely means the attack stops, since most bots rotate through multiple addresses, so use the logs to look for a pattern rather than reacting to a single hit. Treating IP blocking as a substitute for a firewall — a good WordPress firewall does the same job automatically and far more besides; if you find yourself manually blocking IPs on a regular basis, that’s the signal a firewall plugin or hosting-level WAF is the better long-term fix.
What IP Blocking Can’t Do
IP blocking is effective against persistent, known bad actors hitting the same site from the same address — someone hammering a login page, a scraper you’ve identified, a source generating repeated 404s against known vulnerable paths. It’s far less effective against a distributed attack coming from thousands of addresses at once, where a CDN with DDoS protection or a cloud-based WAF is the right tool; against comment and form spam, where bots cycle through addresses fast enough that a CAPTCHA or honeypot handles it better than any block list; or against genuinely new, unidentified threats, where a firewall analysing behaviour patterns catches an attacker before you’ve even seen their IP.
Blocking a problem IP takes under two minutes in Wordfence or via a modern .htaccess rule — and it works for what it’s designed for. Use it for targeted, reactive situations, combine it with a firewall for ongoing protection, and keep a record of what you’ve blocked so you can review it later. If you’re building a WordPress site from scratch and working through your security setup, the step-by-step guide to building a WordPress website covers the security groundwork in the right order.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.