All ResourcesFree Consultation
WordPress Security · Part 7 of 10

Protecting WordPress from Spam & Bots.

Not every bot is malicious and not every unwanted request should be treated the same. The goal is to reduce abuse while keeping real visitors, search engines and business systems working.

Steve Kenneth · 360 Web FirmUpdated September 202614–18 minute readIntermediate
What you'll learn: common bot types, why form spam happens, how edge and application controls complement each other, where Turnstile/rate limiting fit, and how to distinguish blocked noise from a real problem.

First, identify the kind of bot problem

Form spamAutomated submissions advertising products, phishing, junk links or nonsense.
Credential botsRepeated login attempts using guessed or leaked credentials.
Vulnerability scannersRequests for plugins, files and endpoints looking for known weaknesses.
Resource abuseHigh-frequency requests that consume CPU, bandwidth or application resources.
ScrapersAutomated collection of content; behaviour and impact vary widely.
Legitimate crawlersSearch engines, uptime monitors and other useful automated services should not be lumped in with hostile bots.

A practical anti-bot request flow

I prefer to stop obvious abuse as early as practical, then let deeper layers make decisions that require more context.

Visitor / Bot
→
Cloudflare
→
Form / WordPress
→
Validation + Anti-Spam

Cloudflare can challenge or block traffic patterns at the edge. Turnstile can help distinguish automated form interactions without forcing every visitor through an old-style puzzle. Server-side validation verifies that required fields and security tokens are valid. WordPress or anti-spam tools can apply application-specific checks.

Protect forms at more than one layer

A hidden field alone is not enough. JavaScript alone is not enough. Client-side required attributes are not enough because a bot can send an HTTP request without using your visible form at all.

✓ Validate and sanitize submissions on the server.
✓ Use CSRF protection where appropriate.
✓ Use Turnstile or another suitable anti-automation check.
✓ Add a honeypot or timing check as an additional signal when useful.
✓ Rate-limit repeated submissions by a sensible combination of signals.
✓ Do not reveal detailed validation internals to an attacker unnecessarily.
✓ Log enough information to troubleshoot without collecting more personal data than needed.

Use Cloudflare for the traffic it can see

Cloudflare is well placed to reduce scanners, abusive request rates and clearly unwanted paths before they consume WordPress resources. Part 4 covers the firewall strategy in detail.

But remember Part 3: an edge firewall protects only traffic that passes through the edge. If the origin accepts direct traffic, investigate whether that route can be restricted.

Real-world case study: I encountered exactly this while troubleshooting suspicious traffic across sites I manage. Read Stopping Cloudflare Origin Bypass for the full investigation and solution—not just the short version in this series.

What WordPress security tools add

Application-level security can see details Cloudflare may not: WordPress usernames, failed authentication, plugin files, changes and application events. Tools such as Wordfence can therefore complement edge protection. Dedicated anti-spam services can evaluate form/comment submissions using their own signals.

Avoid installing several overlapping security plugins that all attempt to control the same login, firewall and file-monitoring features. Overlap can make troubleshooting harder and may add unnecessary load.

Rate limiting needs realistic thresholds

A human visitor may load many assets quickly, a checkout can make several background requests, and an administrator can trigger bursts of AJAX. Rate limiting should focus on meaningful endpoints and abusive patterns rather than “more than X requests means bot.”

Start conservatively, review events and adjust. If you immediately choose a low threshold and a long block period, you may discover your best customer is the first person you block.

Do not break legitimate search crawling

User-agent strings can be forged, so do not blindly allow anything calling itself Googlebot. Where your edge provider supplies verified-bot signals, use them appropriately. Also keep robots.txt separate in your mind: robots directives tell cooperative crawlers what you prefer; they do not function as an access-control firewall.

How to read the noise

Seeing thousands of blocked requests can look alarming. Often it means the controls are working. Focus on outcomes: Is CPU still being consumed? Are spam messages still arriving? Are legitimate forms failing? Are suspicious requests reaching WordPress despite an edge rule? Did an administrator login succeed unexpectedly?

Steve's Tip: Don't spend all day chasing individual bot IPs. They change. Look for the behaviour you want to stop—repeated requests, impossible paths, abusive submissions—and build a layer around the behaviour.

Common questions

Can I eliminate all spam?

Probably not without also creating friction for legitimate visitors. The practical goal is to reduce spam to a manageable level while preserving usability.

Do I need both Cloudflare and an anti-spam plugin?

They solve different parts of the problem. Cloudflare acts before the origin for traffic routed through it; application anti-spam can evaluate the submission itself.

Is every cloud-hosted IP malicious?

No. Major cloud providers host countless legitimate services. Judge the request behaviour and context rather than assuming the infrastructure owner is the attacker.

Important: Bot controls can block real visitors and integrations. Test forms and critical workflows after every significant change and maintain a rollback path.

Next: make sure WordPress email actually arrives

Part 8 follows another business-critical path: what happens after WordPress needs to send a password reset, contact-form notification or order email.

View the Complete 10-Part Series← Part 6Part 8: Secure Email →