Visit Website →
← Back to blog

Block Bad Bots on Small WordPress Sites Without Locking Out Users

October 18, 2026
Block Bad Bots on Small WordPress Sites Without Locking Out Users

A reliable way to block bad bots on WordPress is to filter them at the edge with a WAF or CDN, add narrow rate limits on /wp-login.php and /xmlrpc.php, and run a behavior-based plugin such as Blackhole for visibility. Do not count on robots.txt to enforce anything. It only guides crawlers that choose to follow it.

TL;DR:

  • Use access logs to find repeated POST requests to login or XML remote procedure call endpoints, unusual bursts, and scanning patterns marked by 404 responses.
  • WordPress’s nginx example allows 10 login requests per minute with a burst of 20, but editors sharing an office network may need higher limits.
  • Disable the XML remote procedure call endpoint only when no integration needs it; otherwise, restrict access because Jetpack and mobile apps may depend on it.
  • Test rules on staging, allowlist your own address and trusted integrations, begin with reversible bans, and keep original logs plus a written rollback step.
  • Keep rules limited to abusive behavior and sensitive endpoints; verify claimed search crawlers through reverse and forward DNS before allowlisting them.
inSave Hosting
Host WordPress with confidence
InSave Hosting offers WordPress-specific hosting, managed security features, and free migration for small businesses and website owners.
Explore hosting

Table of Contents

Which defenses should you start with?

Not every site needs every layer on day one. Pick the first step based on how big the attack is and how much control you have over your hosting stack.

  • Edge, WAF or CDN filtering: best for large or distributed floods, because it stops requests before PHP ever runs on your server.
  • Server rules (nginx or Apache): a good fit when you control the web server and want to target specific endpoints such as the login form.
  • Plugins: useful for logs, visibility and low-volume enforcement when you have no CDN in front of the site.
  • Authentication hardening: two-factor authentication, passkeys and per-integration application passwords make stolen or guessed credentials far less useful.
  • Monitoring and a rollback plan: every block you add should be reversible, logged and tested before it reaches production.

If you are unsure where to begin, start with the edge, then add the login rate limit. Those two moves remove most of the noise on a typical small business site. The plugin comes after that, mainly so you can see what is still getting through.

If you want more background on host-level firewalls, our guide on which WAF to choose for WordPress walks through the options and the lockout risks to avoid.

How do you read your logs to spot abusive bots?

Before you block anything, look at what is actually hitting your site. Blocking on a hunch is how real customers get locked out. Your access logs record the request path, status code, User-Agent string, source address and timing for every request, and they are useful evidence for building narrow rules.

  1. Export a recent access log from your host's control panel or from your CDN's analytics dashboard.
  2. Sort requests by path and count hits on /wp-login.php, /xmlrpc.php and the REST API. Repeated POST requests to these paths are the classic sign of password guessing.
  3. Look for bursts: the same address or network range sending repeated requests in a short period, far above what a person could produce.
  4. Check for scanning behavior, which shows up as long runs of 404 responses for paths like /wp-admin/install.php, old plugin folders or backup file names.
  5. Group the suspicious traffic by User-Agent and source network, then record the request rate and the number of unique sources. A number you can measure tells you whether you need an edge rule or a single server rule.

Common automated abuse includes exploit probes and password guessing, and the Blackhole plugin documentation is a useful reminder that a bot block does not replace patching or account security.

Pro Tip: Save a copy of the raw log before you change any rule. If a block causes trouble, you can replay the evidence and see exactly which request pattern you matched.

Why should you block bots at the edge first?

Edge filtering sits between the internet and your server. A request that gets dropped there never wakes up PHP, never touches your database and never uses your hosting plan's CPU. That is why practitioners generally prefer edge or web-server controls for floods: a plugin still executes PHP for every request it inspects, so it cannot save you from sheer volume.

Managed bot protection from a WAF, CDN or your host usually gives you several useful controls:

  • IP reputation lists that drop traffic from addresses already known for abuse.
  • Bot management that scores clients by behavior and fingerprint rather than a single header.
  • Challenge pages such as CAPTCHA or JavaScript checks that real browsers pass and simple scripts fail.
  • Endpoint rate limits that cap how often one client can hit a specific URL.

Set your login thresholds from real data, not defaults. Check how many times a legitimate editor or customer logs in per hour, then set the limit comfortably above that. Be careful with anything that serves API clients, such as mobile apps or payment callbacks, because a blunt challenge page will break them. Application Passwords, which are separate and individually revocable credentials meant for API authentication, work best when HTTPS stays enabled and your bot rules leave authenticated API paths alone.

For large or distributed problems, a managed WAF or hosting-level bot protection is the right tool. Such controls can filter malicious IPs and apply endpoint-specific rate limits while adding challenge responses that protect your origin resources.

If your host offers managed WAF rules, ask them to enable and tune those before you sign up for a separate CDN. If your attack is large, persistent or changes sources constantly, a third-party CDN with a dedicated bot product is worth the extra setup.

WordPress guidance: rate-limiting /wp-login.php with nginx at rate=10r/m and burst=20 nodelay is the recommended example, and you should adapt the thresholds to your real users.

What do nginx and Apache rules look like for targeted blocking?

When you control the web server, you can add narrow rules for the endpoints bots love most. The official WordPress guidance on brute-force attacks gives an nginx example that rate-limits the login page, and it is a sensible starting point.

In nginx, you define a shared memory zone with limit_req_zone, then apply it to the login and XML-RPC locations with limit_req. The documented example uses a rate of 10 requests per minute with a burst of 20 and nodelay. Treat those numbers as a template, not a law. A site with a team of editors behind one office network may need a looser limit, while a site with a single admin can go stricter.

Rate limits separating normal and excessive requests

For Apache, .htaccess lets you match User-Agent substrings with a regular expression and return a 403. Use substring matching, case-insensitive, and build the list from agents you actually saw in your logs. Full-string matches miss variants, and copied lists from the internet tend to block real visitors.

Other server-level tools worth knowing:

  • IP allow and deny rules for the admin area when only a few known addresses should ever reach it.
  • BasicAuth as an extra password prompt in front of /wp-admin when you want a quick lock-down.
  • A narrow scope, always. Rules written for /wp-login.php and /xmlrpc.php rarely break anything. Site-wide blocks often break plugins, cron jobs and REST API clients.
  • Staging first. Test every snippet on a copy of the site and confirm that logins, checkout and form submissions still work.

If you plan to add more headers or rules in the same files, our copy-ready .htaccess and nginx snippets show how to keep your configuration tidy and reversible. Remember to reload nginx after changes and to keep a backup of the original file so a rollback takes seconds.

Which plugins and WordPress settings cut down bot noise?

Plugins give you something the edge often does not: a log you can read inside your dashboard and rules written around your own site's behavior. The official plugin directory has a whole category of block-bots plugins with behavior-based traps, User-Agent and IP controls, and logging.

Blackhole for Bad Bots is a clean example of the behavioral approach. It adds a hidden trap link to your pages and lists that link as disallowed in robots.txt. Well-behaved crawlers read robots.txt and stay away. A bot that ignores the file and follows the hidden link identifies itself and can be blocked. That makes it a low-risk way to catch non-compliant crawlers without guessing at User-Agents.

Keep the trade-offs in mind:

  • Plugins run in PHP, so they add visibility and granular rules but cannot absorb a flood. Use edge rules for volume and the plugin for insight.
  • Comment settings matter. WordPress has built-in options to require moderation, limit links and add moderation words, or to switch comments off where you do not need them.
  • Application Passwords let each integration have its own credential. Create one per app and revoke it when the integration is retired, instead of sharing your main password.
  • Layered hardening still applies. Bot blocking does not replace updates, strong authentication, HTTPS or monitoring, a point the WordPress hardening guide makes plainly.

Pro Tip: Run a new trap or deny rule in log-only or short-ban mode for a while. Review who it caught before you switch to permanent bans.

For a broader checklist that goes beyond bots, see our walkthrough on how to secure your WordPress site.

How do you protect wp-login.php and xmlrpc.php?

These two files attract most of the automated attacks aimed at WordPress, because they accept credentials and are present on nearly every install. The WordPress developer guidance recommends rate-limiting /wp-login.php and protecting or disabling XML-RPC when it is not needed. Here is a practical order of operations.

  1. Rate-limit the login page at the edge or in your web server, using the documented nginx example as a base and adjusting it to the number of real logins you see in your logs.
  2. Turn on two-factor authentication or passkeys for every administrator and editor account. Even a correct guessed password then fails. Our guide to setting up two-factor covers the steps without lockouts.
  3. Decide about XML-RPC. If nothing uses it, disable it. Our walkthrough on safely disabling XML-RPC at the server level shows ways to do it. Do not disable it blindly: Jetpack, mobile apps and some integrations may rely on it.
  4. If you need XML-RPC, restrict it to known origin addresses where you can and rate-limit it aggressively, as the same WordPress guidance advises.
  5. Document every integration that needs XML-RPC or the REST API, including the service name, the owner and the origin IPs. That list is what lets you whitelist safely and revoke later.
  6. Verify the configuration before production by testing a normal login, a failed login and an integration call, and confirm the responses match what you expect.

Notice that none of these steps blocks all crawlers site-wide. The recommended approach is to rate-limit the endpoints bots abuse most while leaving normal page crawling alone.

Can robots.txt or User-Agent lists stop bad bots?

Not on their own. A robots.txt file is a cooperation signal: it guides reputable crawlers but cannot enforce anything against a client that ignores it. A disallow line does not prove who a crawler is, and it does not stop a hostile client from requesting the URL. Enforcement has to come from server rules, a WAF or a plugin.

User-Agent deny lists have their own limits, since they are coarse and spoofable and tend to produce false positives. Still, they have a place when handled carefully:

  • Match distinctive substrings, case-insensitively, and start from agents that actually appear in your logs, then review false positives before widening the list.
  • Use robots.txt as bait. A Blackhole-style honeypot lists a trap path as disallowed, then enforces a ban on anything that visits it anyway.
  • Test your file. A free robots.txt validator helps confirm your rules say what you think they say.
  • Skip blanket blocks. Broad User-Agent or country blocks are only worth it if you accept that you may turn away legitimate visitors.

What is a safe way to monitor, test and roll back?

A good block that locks out your own team is a bad block. Use this short checklist for every change.

  1. Test on a staging copy first. Add your own IP address and admin User-Agent to an allow list before you turn anything on.
  2. Enforce for a short window, and make initial bans time-limited and reversible.
  3. After each change, watch failed logins, response codes and origin traffic. A drop in login attempts with no rise in 403 or 5xx errors for real users is what success looks like.
  4. Keep the logs from before and after, so you can show what changed and reverse it quickly.
  5. If the attack keeps growing or your rules are not holding, escalate to your host's support team or switch on managed WAF rules.

Pro Tip: Write the rollback command next to the change itself, in the same ticket or note. Under pressure, nobody wants to remember how to undo something.

How do you configure Wordfence and Sucuri to block bad bots?

Both plugins sit in front of WordPress and give you a dashboard for blocking, but they work at different points. Wordfence runs inside WordPress as a firewall and scanner. Sucuri offers a plugin for hardening and monitoring plus a separate cloud firewall that works at the edge. Exact menu names change between versions, so check each plugin's own documentation for the current screens.

For Wordfence:

  1. Install it, then put the firewall into learning mode for a few days so it can observe normal traffic before it starts blocking.
  2. Switch the firewall to enabled and protecting, then review the rate-limiting options. Set limits for crawlers and for people who view too many pages or too many 404s, and choose throttling before blocking while you tune.
  3. Turn on brute-force protection for logins, with a lockout after a small number of failed attempts, and enable two-factor authentication for admin users.
  4. Add your own IP address to the allowlist, then review the live traffic view to find the patterns from your log triage.

For Sucuri:

  1. Install the plugin and generate an API key to enable its audit log and security notifications.
  2. Use its hardening tools to review permissions and protect sensitive directories.
  3. If you subscribe to its cloud firewall, point your DNS through it so bad traffic is filtered before it reaches your server. This is the edge step, and it is where Sucuri's bot filtering helps most.

Run only one full firewall plugin at a time. Two of them inspecting the same requests can conflict and slow the site.

How do you combine bot defenses into layers?

No single control stops every bot. Layering works because each layer catches what the one before it missed, and because a failure in one does not take down the whole defense.

A sensible order from outside to inside looks like this:

  • Edge first. A WAF or CDN absorbs volume, drops known bad addresses and challenges suspicious clients.
  • Web server second. Narrow rate limits on /wp-login.php and /xmlrpc.php catch what slips through, using thresholds taken from your own logs.
  • Application third. A behavioral plugin such as Blackhole and a firewall plugin give you logs, traps and per-site rules.
  • Accounts last. Two-factor authentication, passkeys and application passwords mean that even a successful guess does not become a breach.

Some practical rules keep layers from fighting each other. Give every layer the same allowlist, covering your office IPs, your monitoring service and your trusted integrations. Avoid duplicating the same rule in two places, because when something breaks you will not know which one caused it. Review the logs weekly so you can retire rules that no longer catch anything. And change one layer at a time, so a spike in complaints points to a single cause.

Think of the edge as the lock on the front gate, the server rules as the lock on the office door and the plugin as the camera inside. You want all three, and you want to know which one made the noise.

How do you let legitimate crawlers through without hurting SEO?

Blocking search engines by accident is one of the costliest mistakes in bot control. The safest approach is to scope your rules so they target abusive behavior rather than whole categories of visitors, which is also why WordPress guidance favors rate-limiting login and XML-RPC endpoints over blocking every crawler site-wide. Normal page crawling stays untouched.

Practical steps:

  • Verify before you trust. A User-Agent that claims to be a major search engine is not proof. Confirm genuine crawlers with a reverse DNS lookup on the source address, then a forward lookup to check it matches. Most reputable search engines document this method.
  • Allowlist verified crawlers in your WAF or CDN bot settings rather than relying on a User-Agent string alone, since those can be spoofed.
  • Keep your robots.txt accurate so you are guiding crawlers on purpose, not by accident.
  • Check Search Console for crawl errors and spikes in blocked requests after any new rule.
  • Think about AI crawlers separately. Blocking them by User-Agent can reduce your visibility in AI tools, so read this guide on blocking AI crawlers without losing AI discovery before you add any broad deny list.

If rankings or crawl stats dip after a change, roll back the newest rule first and compare the logs.

What if bots rotate IPs or use headless browsers?

Some sophisticated bots run real browser engines that execute JavaScript, spread requests across many addresses, and copy normal User-Agent strings. Simple IP and User-Agent lists will not stop them, so you need to shift from identity to behavior.

  • Rate-limit by behavior, not just by address. Limits on login attempts per account, failed logins per hour and requests to sensitive paths hold up even when the source address changes.
  • Use managed bot management at the edge. Scoring based on browser fingerprints, timing and interaction patterns catches headless browsers that pass a basic challenge.
  • Add challenge pages on sensitive actions. Put a CAPTCHA or similar check on login, registration and checkout rather than on the whole site.
  • Lean on trap-based detection. A hidden link that no human would click catches automation no matter which address it comes from.
  • Make stolen credentials useless. Two-factor authentication and passkeys defeat credential stuffing even when the bot gets past every other layer.
  • Watch for slow attacks. A low, steady trickle of requests from many sources will not trip a per-address limit, so look at aggregate failed-login counts too.

When an attack outgrows your rules, escalate. Ask your host to turn on stronger managed WAF rules rather than writing an ever-longer list yourself.

My take: pragmatic defaults for small WordPress sites

My default plan for a small or mid-sized site is simple. Start with a WAF or CDN from your host so the heavy traffic never reaches your server. Add rate limits on the login endpoints, and only reach for site-wide server blocks when logs prove you need them, because broad rules cause more support tickets than they prevent. Run Blackhole or a similar trap plugin for visibility, but treat it as a sensor, not a shield, and let the edge rules carry you through a big attack. Above all, back up and stage every change. Most bot problems I see described are made worse by a rushed rule that locks out a real admin at the worst moment.

— Ihor

How can we help you block bots on WordPress?

If you would rather not tune firewalls and rate limits yourself, we built our WordPress hosting to take that work off your plate. Our WordPress hosting plans include managed security features, free migration and staging tools, so you can test a new rule before it touches your live site. Our team of SRE and DevOps engineers handles server-level protections, and we are happy to help with rate limits and whitelisting.

inSave Hosting

Before you try an aggressive block, contact our support team. When you are ready, check our WordPress hosting page, pick a plan and let us move your site with the protections already in place.

FAQ

Is robots.txt enough to stop bad bots?

No. Robots.txt only guides crawlers that choose to follow it, and it does not prevent a hostile client from requesting a URL. Enforcement must come from server rules, a WAF or a plugin.

Should I disable XML-RPC on my WordPress site?

Disable it if nothing uses it. If Jetpack, a mobile app or another integration depends on it, restrict it to known sources and rate-limit it aggressively instead, as WordPress guidance recommends.

Will blocking bots hurt my search rankings?

It can if the rules are too broad. Target abusive endpoints and behavior instead of whole crawler categories, verify genuine search engine crawlers by reverse DNS, and watch Search Console after every change.

Where should I block bots first: plugin, server or edge?

Start at the edge, because it stops floods before PHP runs. Add narrow server rules for login endpoints next, then use a plugin for logs and selective bans.

How do I avoid locking myself out?

Test on staging, allowlist your own IP address first and use short, time-limited bans at the start. Keep a written rollback step and a backup of the original configuration.

Sources