Open registration is a magnet for bots. Leave Anyone can register ticked on a moderately visible WordPress site and you will watch the user list fill with accounts that never log in, never comment, and never buy anything — they exist only to seed future abuse. The instinct is to bolt a reCAPTCHA checkbox onto the form and call it done. That instinct quietly costs you real signups. The skill here is not "add more friction." It is picking controls that are invisible to humans and fatal to bots, and refusing the ones that punish your actual users to catch a handful of marginal bots.

Think in friction versus yield, not "more security"

Every anti-spam control sits somewhere on two axes: how much it annoys a legitimate signup, and how many bots it actually stops. The whole game is staying in the top-left quadrant — high yield, near-zero friction. A reCAPTCHA v2 image grid ("select all the buses") sits in the worst quadrant: it visibly frustrates humans, adds a tap-and-wait to every signup, and modern CAPTCHA-solving services defeat it for fractions of a cent. If you measure your registration funnel, an interactive challenge is often the single biggest drop-off point in it.

So before reaching for a visible challenge, exhaust the controls that humans never see at all. There are two, and they do most of the work.

The two free wins: honeypots and timing traps

A honeypot field is an input hidden from people but present in the HTML. Hide it with CSS (position: absolute; left: -9999px, not display: none, which some bots specifically skip), give it a tempting name like url or website, and leave it empty. A real browser never renders it, so a human never fills it. A bot parsing the raw form sees a field and dutifully completes it. Server-side rule: if the honeypot is non-empty, silently reject the registration. No error message — you do not want to teach the bot what tripped it.

A submission-timing trap exploits the fact that bots are fast and people are not. Stamp the form with the time it was rendered (a signed hidden token, so it cannot be forged), and on submit, reject anything that comes back implausibly quickly. A person filling a registration form takes several seconds at minimum; a script round-trips almost instantly. You do not need to publish an exact threshold — pick a conservative floor, log the timing distribution of real signups for a week, and tune from there. Both of these cost a legitimate user precisely nothing.

On WordPress, you do not have to hand-roll this. WP Armour adds an invisible honeypot to the registration, login, and comment forms with no user-facing challenge, and it is the lowest-friction option I reach for first. Stop Spammers layers honeypot logic with reputation checks against known-bad IPs and disposable-email domains.

When you do need a challenge, choose the invisible tier

Honeypots and timing traps stop commodity bots. A determined attacker running a real headless browser will sail past both, and that is when a challenge earns its keep. The key is that not all CAPTCHAs are equal on the friction axis:

Cloudflare Turnstile — free, privacy-respecting, and runs a non-interactive browser check in the background. Most legitimate users never click anything. This is the current default I recommend for "without killing signups," and it does not feed your visitors into an ad-targeting graph.
reCAPTCHA v3 — invisible and score-based. It returns a 0.0–1.0 likelihood that the visitor is human, and you decide the cutoff. No image grids. The trade-off is that you are sending behavioral signals to Google and you must handle the scoring server-side rather than treating it as a pass/fail widget.
hCaptcha — a reCAPTCHA alternative; its invisible/passive mode is the one to use, not the checkbox.
reCAPTCHA v2 ("I'm not a robot" checkbox, image grids) — avoid on registration unless you have a specific reason. It is the highest-friction option and no longer the highest-yield one.

Whatever you pick, gate it behind your honeypot and timing checks so the vast majority of bot traffic is already dead before the challenge even loads.

Harden what the account can do after it is created

Spam registration is rarely the goal — it is step one. The payoff comes from what a logged-in account can do that an anonymous visitor cannot. Close those doors and a spam account that slips through becomes worthless.

Default new users to Subscriber. Settings > General > New User Default Role should be Subscriber, full stop. A Subscriber cannot publish posts, cannot install anything, and has no meaningful attack surface. Never set the default to Author or Contributor on an open-registration site.
Do not exempt logged-in users from comment moderation. WordPress lets you auto-approve comments from people with a previously approved one, and lets registered users skip moderation. On an open-registration site, treat logged-in commenters with the same suspicion as anonymous ones — otherwise registering an account becomes a moderation bypass.
Lock down the profile fields. The Biographical Info and Website fields are user-controlled text that spammers fill with links to their target sites. Cap the bio length, validate the website field as a real URL, and if you do not actively use author bios, restrict editing of those fields entirely.
Suppress empty author archives. Do not let a spam account's author page render publicly when that user has published nothing. It is pure link real estate for them and a thin, low-value page for you.

Move the registration page and watch the velocity

A large share of registration spam is drive-by traffic hammering the default /wp-login.php?action=register endpoint. Relocating registration behind a custom URL — most security plugins and membership tools offer this — eliminates that whole bucket of low-effort bots. It will not stop a targeted attacker who reads your "Sign up" link, but it meaningfully thins the noise.

Then monitor signup velocity. Genuine registrations arrive irregularly; bot waves arrive in bursts — dozens in minutes, sequential or pattern-matched email addresses, machine-generated display names. A simple alert on signups-per-hour catches an attack while it is happening rather than after the user list has a thousand junk rows in it.

Cleaning up the accounts you already have

If the damage is done, the cleanup is reversible only from a database backup — deletion through the admin UI is final — so take one first. Then work conservatively:

Filter the user list to accounts with no published content and no approved comments.
Within that set, flag the ones with disposable-email domains or generated-looking display names.
Delete in batches of fifty to a hundred, reassigning any content to a placeholder rather than deleting it.

The cardinal rule: never delete an account with any genuine activity. A false-positive deletion of a real member is a worse outcome than leaving a dormant spam account in place. When in doubt, leave it.

The honest baseline

Most spam-registration problems exist because someone enabled open signup for one feature years ago and forgot. If you do not actually need it, the fix takes ten seconds: untick Settings > General > Anyone can register. WordPress ships with it off for exactly this reason. If you genuinely need registration — for membership content (MemberPress, Paid Memberships Pro), course access, or gated comments — build the layered, low-friction stack above. Done right, the signup that a real customer completes in seconds is the same one a bot fleet cannot get through at all.

WordPress Spam Registration: How To Stop It Without Killing Signups