
WordPress spam protection is one of those jobs that looks trivial until you inherit a site that has been neglected for two years: 40,000 spam comments in the moderation queue, a contact inbox where real enquiries drown between casino links and “SEO offers”, and a user table full of accounts called things like bettyhorton1987 with Russian mail addresses. I have cleaned up dozens of sites like that over 12+ years and 500+ WordPress projects, and the pattern is always the same – nobody set up defences at launch, the flood arrived quietly, and by the time anyone noticed, real customer messages had been lost in the noise.
Spam is not just an annoyance. It buries genuine leads, it makes Google crawl and sometimes index junk on your domain, it bloats your database, and a comment section full of pharmacy links tells every visitor that nobody is looking after this site. The good news: with the right layers, spam on a typical business site can be near-zero without a single visitor ever solving an image puzzle. This guide covers the whole surface – comments, contact and quote forms, user registration, and a short look at fake WooCommerce orders – with honest recommendations on Akismet vs Antispam Bee, Turnstile vs reCAPTCHA, and when the right answer is simply switching a feature off.
Table of contents
- Why spam exists and why it actually hurts
- Comment spam: the native settings that already help
- Akismet vs Antispam Bee – an honest comparison
- When the right answer is closing comments
- Form spam: build a layered defence
- Honeypot, Turnstile, reCAPTCHA or nothing at all
- Registration spam and fake users
- Fake orders and card testing in WooCommerce
- Trackbacks, pingbacks and cleaning existing spam safely
- Measuring success and the maintenance routine
- Frequently asked questions
Why spam exists and why it actually hurts
Understanding the motive helps you pick the right defence, because different spam waves have different goals:
- Link schemes. The classic. Bots post comments and profile links pointing at gambling, pharma or “essay writing” sites, hoping some of them get published and pass link value. Even nofollow links have residual value in bulk, so the bots never stop trying.
- Phishing seeds. Spam messages plant URLs that later redirect to phishing or malware pages. A published spam comment on your domain lends the link your reputation – and if Google flags the destination, your page sits next to it.
- Harvesting and probing. Many “spam” submissions are reconnaissance: bots testing whether your forms echo input back unescaped, whether registration is open, whether your site runs a vulnerable plugin. The junk message is a side effect of the probe.
- Card testing. On WooCommerce stores, bots run stolen card numbers through your checkout in small amounts to find out which cards are still alive. That one costs you real money – more on it below.
And the damage is concrete, not cosmetic. A client’s agency site I took over had 14 genuine project enquiries sitting unread in a Contact Form 7 inbox tab because the owner had stopped checking – 300 spam mails a week had trained him to ignore the address. Comment spam that slips through gets crawled, wastes crawl budget and occasionally gets indexed, so your domain starts ranking for casino terms in the worst case. Tens of thousands of spam rows in wp_comments and wp_commentmeta slow admin queries and inflate backups. And under GDPR you are storing personal data (names, mails, IPs) you never wanted – junk data is still data you are responsible for, a point I cover in the GDPR compliance guide.
Comment spam: the native settings that already help
Before you install anything, WordPress ships with settings under Settings > Discussion that stop a surprising share of comment spam. On maintenance takeovers I configure these first, because they cost nothing and never block a real person:
- Hold comments with links. “Hold a comment in the queue if it contains 2 or more links” – change that number to 1. Almost no genuine comment on a business blog contains a link; almost every spam comment does. This single change moves the bulk of spam into moderation instead of publishing it.
- Manual approval, at least for first-timers. Enable “Comment author must have a previously approved comment”. Regulars flow through, strangers wait. On low-traffic blogs I go further and enable “Comment must be manually approved” – moderating two real comments a week is cheaper than cleaning published spam.
- Disallowed comment keys. The built-in blocklist field sends any comment containing your listed words, URLs or IPs straight to the bin. Seed it with the terms you actually see: casino, viagra, crypto signals, loan offer, plus recurring spam domains. Ten minutes of curation kills whole campaigns.
- Require name and email. Trivial for humans, one more field for cheap bots to get wrong.
- Close comments on old posts. “Automatically close comments on posts older than 60 days” – most comment spam targets old posts found via search. If your posts do not generate long-tail discussion, closing them after a few weeks removes most of the attack surface.
- Disable comments on media pages. Attachment pages have comment forms too, and bots find them. Most SEO plugins redirect attachment pages anyway; make sure yours does.
These settings do not need a plugin, do not send data anywhere, and on a typical brochure site they cut published spam to zero on their own. What remains is queue noise – which is what the next section deals with.
Akismet vs Antispam Bee – an honest comparison
If your blog gets real comment volume, moderating manually stops scaling and you want an automatic filter. The two names that matter are Akismet and Antispam Bee, and the honest comparison is less about catch rate than about data protection and licensing.
Akismet is the Automattic service that ships half-installed with WordPress. Every comment – author name, email, IP address, content – is sent to Akismet’s servers, scored against a global database, and returned as ham or spam. The catch rate is excellent, easily the best in the market, because it sees spam across millions of sites. The two catches: it is a paid product for commercial sites (the free tier is for personal blogs; a business site should be on a paid plan, from roughly USD 10-15 per month), and it is a data transfer to a US company that must appear in your privacy policy and records of processing. That is workable under GDPR with proper disclosure, but many of my German clients simply do not want a US transfer for something as mundane as comment filtering.
Antispam Bee, from the German pluginkollektiv team, is free and built for exactly that concern. Its core checks run locally – trust for previously approved authors, honeypot, regular-expression patterns, a local spam database – and the options that would contact external services are clearly marked and off by default. Configured sensibly it catches the vast majority of comment spam. It will miss some cleverly written human spam that Akismet would catch, and its public-antispam-database option should stay off for privacy, but for a typical European business blog it is the right default.
| Akismet | Antispam Bee | |
|---|---|---|
| Catch rate | Excellent (global cloud database) | Very good (local rules and lists) |
| Cost | Paid for commercial sites | Free, no upsell |
| Data flow | All comment data to US servers | Local by default, no third party |
| GDPR effort | Privacy policy entry, US transfer basis | Minimal – nothing leaves the site |
| Best for | High-volume blogs, forums, global sites | EU business sites, typical blogs |
| Scope | Comments plus some form integrations | Comments and trackbacks only |
My default: Antispam Bee for EU clients and any site where comments are a minor feature; Akismet on a paid plan where comment volume is genuinely high and the filter earns its subscription. Running both at once brings nothing – pick one.
When the right answer is closing comments
Here is the recommendation nobody selling an anti-spam plugin will give you: most business websites should not have comments at all. Look at your last twenty posts. If the genuine comment count is zero – and on agency sites, consultancies, local services and most company blogs it is – then the comment form is pure attack surface with no upside. Closing it is not an admission of failure; it is removing a door nobody legitimate ever walks through.
Closing comments properly takes three steps, because the Discussion settings only affect future posts. First, untick “Allow people to submit comments on new posts” in Settings > Discussion. Second, close comments on existing content: select all posts in the post list (raise “Number of items per page” in Screen Options first), use Bulk actions > Edit, and set Comments to “Do not allow” – repeat per screen, or use WP-CLI on large sites. Third, check the front end: a well-built theme now shows no form anywhere, but some themes still render “Comments are closed” or leave the form on custom post types. If your theme lacks a clean way to suppress the markup, that is a five-minute template fix, not a reason for yet another plugin.
Keep comments where they genuinely work: tutorial blogs where readers report solutions, communities, sites where discussion is the product. Even then, pair the native settings with a filter and a moderation habit. And if you are on the fence, close them for three months and watch what happens – in my experience nobody has ever asked a small business where its comment box went.
Form spam: build a layered defence
Contact and quote forms are where spam does real damage, because this inbox is where money arrives. The mistake I see most is jumping straight to the heaviest tool – a checkbox CAPTCHA on every form – which punishes every legitimate visitor for the sins of bots. The professional approach is layered: several cheap, invisible checks that each catch a different class of bot, so the visible friction stays at zero for humans.
- Layer 1 – honeypot. An extra field, hidden from humans with CSS but visible in the markup, for example <input type=”text” name=”website_url”>. Humans leave it empty; dumb bots fill everything they find, and any submission with content there is dropped silently. Most form plugins (WPForms, Fluent Forms, Gravity Forms) have this built in; Contact Form 7 – which attracts more spam than any other form plugin simply because it is everywhere – gets it via a small add-on. Cost to humans: zero.
- Layer 2 – time check. Humans need at least a few seconds to read and fill a form; scripted bots submit in under two. Rejecting submissions faster than three seconds after page render, or carrying a signed timestamp token, filters the fastest bots. Built into Antispam Bee for comments and into several form plugins. Cost to humans: zero.
- Layer 3 – content rules. Blocklists for the patterns your real audience never uses: Cyrillic text on a German-market site, more than one URL in the message body, known spam phrases, typical crypto and “SEO service” vocabulary. Every serious form plugin supports keyword filtering; keep the list short and specific to avoid false positives.
- Layer 4 – email quality. Reject disposable-mail domains (mailinator-style throwaways) on quote and signup forms. There are maintained open lists of disposable domains; a small validation hook checks against them. Do not block role addresses like info@ – real businesses write from them.
- Layer 5 – a challenge, only if needed. If spam still gets through the invisible layers, add Turnstile or a similar low-friction challenge – the next section compares the options. On most of my client sites, layers 1-4 alone take form spam from dozens per day to one or two per month, and the challenge layer is never needed.
Two operational points. First, always log submissions in the database as well as sending mail (Flamingo for Contact Form 7, built-in entries in most other plugins) – then an overzealous filter or a broken mail server never silently costs you a lead. Second, rate-limit at the server or firewall level if a bot hammers one endpoint; a single IP posting your form forty times a minute is a firewall problem, not a form problem. I go deeper on form architecture, deliverability and consent in the WordPress forms guide.

Honeypot, Turnstile, reCAPTCHA or nothing at all
“Just add a CAPTCHA” is the most common spam advice and the least examined. The options differ enormously in what they cost your visitors – in friction, in accessibility and in privacy – and picking the heaviest one first is how sites lose enquiries they never know about.
| Friction for humans | Privacy / GDPR | Stops | |
|---|---|---|---|
| Honeypot + time check | None – completely invisible | Perfect – nothing leaves your server | Dumb, scripted bots (the majority) |
| Cloudflare Turnstile | Near zero – usually no interaction | Good – minimal data, no ad business, still a third party to disclose | Most automated bots incl. headless browsers |
| reCAPTCHA v3 | Invisible, but opaque scoring silently rejects some humans | Poor – Google scripts and cookies on every page, hard to justify under GDPR | Most bots, with false positives you cannot see |
| reCAPTCHA v2 | High – checkbox plus traffic-light puzzles | Poor – same Google data flow | Most bots, and a measurable share of humans |
| Nothing | None | Perfect | Nothing – fine only behind other layers |
Some detail behind the table. reCAPTCHA v2’s image puzzles are a genuine accessibility failure: screen-reader users get an audio challenge that is often harder than the images, people with cognitive or motor impairments give up, and everyone on a slow connection waits. Studies and my own clients’ analytics agree that a visible CAPTCHA loses real conversions – on one quote form, replacing reCAPTCHA v2 with honeypot-plus-Turnstile increased submissions by roughly a fifth with no rise in spam. reCAPTCHA v3 removes the puzzle but scores users invisibly with Google cookies and behavioural signals, which several European data-protection authorities have criticised; and when it wrongly scores a human as a bot, that person simply cannot contact you and you will never know.
Cloudflare Turnstile is my current recommendation when a visible challenge layer is justified: free, no image puzzles ever (it runs browser checks and shows at most a brief “verifying” widget), markedly less data collection than Google, and official or well-maintained integrations for every major form plugin and WooCommerce. It is still a third-party service that belongs in your privacy policy, but it is the option I can defend to a German client’s data-protection officer. The decision tree I use: start with honeypot plus time check on every form; add content and email rules if spam persists; add Turnstile only on the forms still being hit; and treat reCAPTCHA as legacy – I remove it more often than I install it.

Registration spam and fake users
Fake user registrations puzzle site owners more than any other spam: why would a bot want a subscriber account on a small business site? Several reasons, all worth taking seriously. Registered accounts can post comments that skip first-timer moderation. Some themes and plugins give every user a public profile page – a free backlink. Membership and forum plugins open more posting surfaces. And most importantly, a registered account is a foothold: if a plugin vulnerability later allows privilege escalation from subscriber to admin – a class of exploit that appears several times a year – the bots that registered months ago are already inside. A user table with 3,000 fake subscribers is not cosmetic debt; it is a waiting room for an attack.
The fix starts with a question: does this site need open registration at all? For most business sites the answer is no – and the “Anyone can register” checkbox in Settings > General should be off. That is the whole fix: no registration form, no registration spam. If you do need accounts (a store, a members’ area, a course), harden the pipeline:
- Default role: Subscriber. Never anything higher. What each role can actually do – and why it matters – is covered in the user roles and permissions guide.
- Protect the form like any other form: honeypot and time check on the registration page, Turnstile if it is actively attacked. The default wp-login.php?action=register endpoint is a known target; a custom registration page with proper protection is harder to script.
- Require email activation. An account that never confirms its address never becomes active. Combined with disposable-domain blocking this kills the bulk of bot signups.
- For WooCommerce, register at checkout. Let accounts be created during purchase rather than through a free-standing form – a registration that requires a paid order is not worth a spammer’s time.
- Review the user list monthly. Sort by registration date; a burst of accounts with pattern names and no orders or content is a bot wave. Investigate what form they came through before deleting.
Fake orders and card testing in WooCommerce
Stores get two extra flavours of spam, and one of them costs real money. Fake orders are bots completing checkout with junk data – usually cash-on-delivery or bank transfer, since no valid card is needed. They pollute your order list and your revenue reports, and each one fires the full email chain. Card testing is worse: fraudsters use your checkout to test batches of stolen card numbers with small purchases. You pay a gateway fee for every attempt, including declines; your dispute rate climbs; and if it goes on, Stripe or PayPal will restrict or close your account for fraud exposure that is not your fault.
The basics that stop most of it: turn on your gateway’s own fraud tooling first (Stripe Radar rules, for example blocking payments when the CVC check fails, are more effective than anything WordPress-side); put Turnstile on checkout and registration; rate-limit checkout attempts per IP and session so a script cannot run 200 cards through in an hour; and disable cash-on-delivery or other no-validation payment methods if you see fake-order waves and do not genuinely need them. Watch for the tell-tale pattern – bursts of small orders, many declines, mismatched countries – and treat it as an incident, not an annoyance: pause the affected payment method, block the source, refund anything that slipped through before it becomes a chargeback. Store fraud deserves its own full guide and this is deliberately the short version – but do not launch a store with a naked checkout. If you are setting one up, get the fraud settings in before the first marketing campaign, not after the first incident.
Trackbacks, pingbacks and cleaning existing spam safely
Two cleanup jobs remain on almost every site I take over. The first is quick: switch off trackbacks and pingbacks. These are a 2005-era mechanism for blogs to notify each other about links, and today their traffic is effectively 100% spam – automated notifications from junk sites hoping to appear in your comment area. In Settings > Discussion, untick “Attempt to notify any blogs linked to from the post” and “Allow link notifications from other blogs (pingbacks and trackbacks) on new posts”. Like comment settings, this only covers new posts, so apply it to existing content with the same bulk-edit pass you used for comments (the Pings field sits next to Comments). Nothing of value is lost; I have disabled this on hundreds of sites and never once heard a complaint.
The second job is clearing the backlog, and at scale it needs a little care. A few hundred spam comments can go through the dashboard: Comments > Spam > Empty Spam. Tens of thousands will time out in the browser, so use WP-CLI in batches – for example wp comment delete $(wp comment list --status=spam --format=ids --number=500) --force, repeated until the queue is empty. Three safety rules. Always take a database backup first – a fat-fingered status flag deletes approved comments just as happily. Skim before you delete: filters make mistakes, and I regularly find one or two real messages, sometimes customer enquiries, sitting in a spam queue. And clean up after the purge – orphaned rows in wp_commentmeta can outnumber the comments themselves, so run a database optimisation afterwards to reclaim the space in your tables and backups.
Fake users need more caution than comments, because deleting a user asks what to do with their content. Filter subscribers registered in the bot wave’s date range, spot-check a sample (no orders, no comments, no posts, disposable or pattern email addresses), and delete in batches with content attributed to no one or reassigned. On a WooCommerce site, never bulk-delete by role alone – customers are users too, and deleting one deletes the link to their order history. When a cleanup involves thousands of users on a live store, I stage it: export the candidate list, verify against orders, then delete in verified batches.
Measuring success and the maintenance routine
The target for spam protection is easy to state and rarely stated: spam near zero, false positives at zero. Half a job is blocking bots; the other half is making sure no real person is blocked, and that second half is invisible unless you measure it. A contact form that silently rejects 5% of humans looks identical to a quiet week – which is why “we get less spam now” is not a success metric on its own.
- Check the spam folders on a schedule. Comment spam queue and form-entry logs, skimmed weekly at first, then monthly once the filters are tuned. You are looking for real names and real questions caught by an aggressive rule – each one found is a rule to loosen.
- Watch form conversion, not just spam counts. If submissions per hundred visitors drop after you add a challenge, humans are paying for your filter. This is how the damage of reCAPTCHA v2 usually shows up – and why I measure before and after every change to a money form.
- Keep the entry log as ground truth. Database-logged submissions mean a mail-delivery failure or filter mistake loses nothing permanently. On takeovers, the log is also how I prove to a sceptical owner what the old CAPTCHA was costing.
- Test as a stranger quarterly. Submit each important form from a private browser window, a phone on mobile data, and ideally once with a screen reader or keyboard only. If any of those journeys fails, your defence is overtuned.
The routine that keeps it working is small: monthly, empty the spam queues, skim for false positives, review new user registrations, check that the anti-spam and form plugins are updated, and glance at form conversion in analytics. Quarterly, do the stranger test and prune blocklist rules that no longer match anything. This slots naturally into a maintenance plan alongside updates, backups and security monitoring – it is part of every maintenance and security plan I run, because spam defence, like backups, only works when someone is actually watching it.
Want a spam-free inbox without losing real enquiries?
I set up layered spam protection as part of my WordPress maintenance and security service – comments, forms, registration and checkout, tuned so bots bounce and humans never see a puzzle, then monitored month after month. See the portfolio for the kind of sites I look after, or tell me what is flooding your inbox – I reply within 24 hours with a concrete plan and a fixed price.
Frequently asked questions
What is the best WordPress spam protection?
Layers, not one big tool: native comment settings, a honeypot and time check on every form, content and email rules, and Cloudflare Turnstile only where bots still get through. Most sites reach near-zero spam without any visible CAPTCHA.
Is Akismet GDPR compliant?
It can be used compliantly, but every comment (name, email, IP, content) is sent to US servers, so you need a privacy-policy entry and a transfer basis. Privacy-sensitive EU sites often prefer Antispam Bee, which works locally.
Should I just disable comments on my WordPress site?
If your posts get no genuine comments – true for most business sites – yes. Closing comments removes the attack surface entirely and nobody will miss the form.
Is Turnstile better than reCAPTCHA?
For most sites, yes: no image puzzles, far less data collection than Google, free, and it integrates with every major form plugin. reCAPTCHA v2 in particular costs real conversions and has known accessibility problems.
Why do bots create fake user accounts on WordPress?
For spam posting privileges, public profile backlinks, and as footholds for later privilege-escalation exploits. Disable open registration if you do not need it, and require email activation if you do.
How do I delete thousands of spam comments safely?
Back up the database, skim the queue for real messages caught by mistake, then delete in batches with WP-CLI rather than the browser, and optimise the database afterwards to reclaim the space.
Will a CAPTCHA hurt my conversions?
A visible one can – image puzzles measurably lose form submissions and exclude some users with disabilities. Use invisible layers first and add a low-friction challenge like Turnstile only where it is genuinely needed.