Why bad bots matter after a WordPress malware cleanup
If your WordPress site has already been infected, blocking bad bots is one of the fastest ways to reduce reinfection risk.
Malicious crawlers, credential-stuffing scripts, and exploit scanners often return immediately after cleanup, looking for the same weak plugin, vulnerable endpoint, or exposed login page.
This article explains how to block bad bots after WordPress malware using practical server, plugin, and firewall controls that protect your site without breaking legitimate traffic.
What counts as a bad bot?
Bad bots are automated requests that consume resources, scrape content, probe vulnerabilities, or attempt unauthorized access.
Unlike search engine crawlers such as Googlebot or Bingbot, these bots usually ignore robots.txt, rotate IP addresses, and generate patterns that look abnormal in access logs.
- Exploit scanners that test known WordPress plugin and theme vulnerabilities
- Credential stuffing bots that try leaked username and password combinations
- Comment and form spam bots that abuse public forms
- Scrapers that copy content, product data, or email addresses
- Distributed bot traffic that amplifies load and hides source IPs
Why malware cleanup alone is not enough
Removing malicious files does not stop the same automation from returning.
If a bot discovered a vulnerable plugin, exposed XML-RPC endpoint, weak admin password, or infected upload path, it will often recheck the site within minutes or hours.
That is why cleanup should be followed by access control, rate limiting, and application-layer filtering.
In many cases, reinfection happens because the attacker still has a working path in through a bot-accessible route.
Blocking those routes reduces the chance of another compromise and lowers server load while you stabilize the site.
Start with a post-malware risk review
Before you block traffic broadly, identify what the malware used.
Review your security plugin logs, hosting firewall logs, and WordPress access logs for repeated requests to sensitive paths.
Focus on patterns rather than one-off hits.
Common paths to inspect
/wp-login.php/xmlrpc.php/wp-admin//wp-content/uploads/- Unknown PHP files in the uploads directory
- Deprecated plugin endpoints and AJAX actions
If you see repeated requests to these locations from the same IP ranges, user agents, or countries, those are strong candidates for blocking or rate limiting.
How to block bad bots after WordPress malware
1. Restrict access to the WordPress login page
The login page is one of the most attacked endpoints on any WordPress installation.
After a malware incident, protecting it becomes a priority because bots often try brute-force attacks before or after scanning the site.
- Use two-factor authentication for all administrator and editor accounts
- Limit login attempts through a security plugin or firewall
- Restrict
wp-login.phpby IP if your team uses fixed addresses - Add a CAPTCHA or Turnstile challenge for suspicious login attempts
For sites with small internal teams, IP allowlisting can be very effective.
For public-facing sites, rate limiting and bot challenges are usually safer than hard blocking most visitors.
2. Disable or secure XML-RPC if you do not need it
XML-RPC is a legacy WordPress feature used by some apps and remote publishing workflows.
It is also a frequent target for brute force and pingback abuse.
If you do not rely on it, disabling it can eliminate a common attack route.
If you must keep XML-RPC enabled, block abusive methods and apply rate limits at the firewall level.
Many managed WordPress hosts and web application firewalls can stop repeated XML-RPC requests before they reach WordPress.
3. Use a web application firewall
A web application firewall, or WAF, is one of the most effective tools for blocking bad bots after WordPress malware.
It can filter requests based on reputation, behavior, rate, and attack signatures before they consume PHP or database resources.
- Cloudflare offers bot management, rate limiting, and WAF rules at the edge
- Sucuri provides WordPress-focused firewall protection and malware cleanup support
- Wordfence offers endpoint protection, live traffic inspection, and login security
Use a WAF to block known malicious user agents, suspicious ASN ranges, countries that do not match your audience, and repeated hits to vulnerable endpoints.
Avoid relying on a single rule; layered rules work better than one broad block.
4. Block or challenge known abusive IPs and ranges
After malware cleanup, review your logs for IPs that repeatedly hit login pages, probe plugins, or request infected URLs.
Add those IPs to firewall deny rules, but be careful with shared networks and mobile carriers where legitimate users may appear on the same range.
When possible, block by behavior instead of a single address.
For example, if an IP makes dozens of POST requests to wp-login.php in a short period, that is stronger evidence than a single GET request from a crawler.
5. Harden uploads and executable paths
Many WordPress infections place backdoors in the uploads directory or exploit writable directories.
Bad bots often look for these files after a compromise, then try to re-execute them.
- Prevent PHP execution inside
/wp-content/uploads/ - Remove unknown PHP files from writable directories
- Audit file permissions and keep them as strict as your host allows
- Block direct access to backup archives, log files, and configuration copies
This step does not just reduce infection risk; it also makes scanning bots less useful because they cannot execute the files they discover.
6. Add rate limiting and request shaping
Rate limiting slows down automated traffic and prevents a single IP or botnet cluster from overwhelming your site.
It is especially useful for forms, login pages, search endpoints, and XML-RPC.
Typical controls include:
- Maximum login attempts per minute
- Throttling repeated requests to the same URL
- Blocking bursts from the same user agent
- Challenging suspicious traffic with a CAPTCHA
Rate limiting is often safer than hard blocking because it reduces malicious activity while allowing occasional edge-case traffic to pass.
7. Use robots.txt carefully, but do not depend on it
Robots.txt can reduce crawling by legitimate bots, but it will not stop malicious automation.
Bad bots usually ignore it.
Still, it can help you limit unnecessary crawling of low-value paths such as search results, staging URLs, or internal parameters.
Use robots.txt as a supplementary signal, not as a security control.
Real protection must happen at the firewall, web server, or application layer.
WordPress settings that help reduce bot exposure
Some WordPress settings make your site less attractive or less accessible to automated abuse.
These changes do not replace a firewall, but they do reduce noise and attack surface.
- Turn off public user registration unless it is required
- Remove unused themes and plugins
- Keep WordPress core, themes, and plugins updated
- Disable file editing from the dashboard
- Use unique admin usernames and strong passwords
If the malware came from a plugin vulnerability, removing unused plugins is especially important.
Every inactive plugin still represents code that may be scanned for a known exploit.
How to verify that your bot blocking is working
Once protections are in place, monitor your logs for changes in traffic patterns.
A successful setup should reduce repeated hits to login, XML-RPC, and suspicious plugin endpoints while keeping normal visitors unaffected.
What to monitor
- HTTP 401, 403, and 429 responses
- Repeated requests from the same IPs
- Spike patterns during off-hours
- Requests to nonexistent PHP files or old plugin paths
- Login failures across multiple accounts
Also check analytics and search console data to make sure legitimate indexing is still healthy.
If organic traffic drops sharply, your rules may be too aggressive.
Common mistakes to avoid
- Blocking entire countries without confirming your audience
- Relying only on plugins for security filtering
- Leaving XML-RPC open without rate limits
- Ignoring repeated requests to old plugin files
- Failing to change compromised passwords after cleanup
- Not reviewing server logs after a malware incident
Good bot blocking is specific, measured, and based on traffic evidence.
Broad blocks may stop some attacks, but they can also create false positives and hide useful diagnostics.
When to involve your host or a security specialist
If the malware keeps returning, the infection may involve server-level compromise, stolen credentials, or a hidden backdoor outside the WordPress database.
At that point, ask your host to inspect the environment, rotate credentials, and review server access logs beyond WordPress itself.
Sites with ecommerce, membership systems, or high traffic may also benefit from managed WAF rules and ongoing bot monitoring.
The more valuable your site is, the more likely it is to attract persistent automated attacks.