Author: alex

If you have ever clicked nine pictures of traffic lights to send a contact form, you already know CAPTCHA is broken. It is broken for users (drops conversions, accessibility nightmare), broken for site owners (modern solvers handle it for cents), and broken philosophically (it asks the human to prove they are human while letting the bot prove it too). In 2026, AI-powered spam filtering replaces it. Here is how that actually works.

What CAPTCHA was solving

CAPTCHA worked on the assumption that bots could not read text or recognise images. That assumption held until roughly 2015, then degraded continuously. By 2022, headless browser plus a commercial CAPTCHA-solving API got past reCAPTCHA v2 in under a second for less than a tenth of a cent per solve. v3 (the invisible “score” version) is better in spirit but still rejects real users on shared NAT and missed enough realistic spam that most production sites layered something else on top.

What AI filtering is doing differently

Where CAPTCHA asks the visitor to prove they are human, AI filtering reads the submission and decides whether it looks like a real intent. Two practical examples:

• Contact form: the model reads the message and scores it against patterns of real enquiry vs SEO outreach vs scam vs irrelevant pitch. A well-written “Hello, do you take freelance work?” scores high. A well-written “I represent a company that helps your website…” scores low even though both are grammatical.
• Comment: the model reads the comment in context of the post it is on. A topical follow-up question scores high. A generic “great post, also check out my SEO service” scores low.

The user does nothing. There is no puzzle. The filtering happens server-side after the submission lands and decides whether to deliver, hold, or reject it.

Why this is better in production

• Conversion stays clean. CAPTCHA on a contact form drops conversions 5-15 percent on most sites we have measured. Removing it adds the same percentage back.
• Accessibility works. No more “I cannot pass the puzzle” support tickets.
• Sophisticated spam gets caught. The realistic AI-written submissions that walk past Akismet and reCAPTCHA are exactly what intent-scoring models were trained on.

Where it still costs something

Honest tradeoffs:

• Per-submission AI cost. Each filtered submission runs a small inference call. For most sites this is fractions of a cent and negligible at scale. Heavy traffic sites should check the math.
• Borderline cases. Intent scoring is a probability, not a verdict. Borderline submissions need to be held for human review, not auto-rejected. A quiet “moderation queue” tab in the dashboard is the right interface.
• Locale coverage. Models trained on English do better with English-language sites. Multilingual sites need a filter that knows it.

The short version

CAPTCHA asked your visitor to pay for the security of your site, in attention. In 2026 you do not have to charge them anymore. Reading the submission is cheaper, more accurate, and invisible — and the realistic spam that is the actual problem on a modern WordPress site is the thing it catches that nothing else does.

If you run a WooCommerce store and Stripe or PayPal has flagged your account, there is a strong chance it was not your customers. It was a card-testing attack on your checkout. This is the spam that costs money — chargeback fees, processor-side risk scoring, and in the worst cases a frozen merchant account. Here is how it works on WooCommerce and what to do about it.

What card testing actually looks like

A card-testing attack is automation that runs stolen card numbers against a low-risk public checkout to find out which ones still work. The attacker does not want your product. They want the success response from Stripe. They buy or generate a list of card numbers and need a checkout that does not stop them from trying.

WooCommerce is a popular target for three reasons: the checkout endpoint is well-known, there is rarely a CAPTCHA in front of the pay button, and most stores accept very small order totals (a $5 product is enough to validate a card). A typical burst looks like 80 to 400 attempts in a window of 2 to 15 minutes, often at 3am local time.

Why your processor flags you, not them

Stripe and PayPal score risk at the merchant level. A spike of declined charges, especially in a tight window, looks identical to a compromised merchant on their side. Their automated response is to:

• Raise your risk score
• Throttle your account
• Hold your payouts
• In severe cases, freeze the account pending review

The card tester moves on. You spend a week on the phone with risk teams. This is why “we accept the chargebacks” is not a strategy.

What does not work

Three things people try first that do not stop card-testing bursts:

• reCAPTCHA on checkout. Solvers handle it. It mostly annoys real buyers.
• IP rate limits. Attackers rotate residential IPs and you cannot tell them apart from real visitors on shared NAT.
• Stripe Radar alone. Helpful, but it sees individual charges. It does not see your checkout as a pattern.

What works on WooCommerce

The defence that has held up in production is checkout-level burst detection, not per-payment scoring. You watch the woocommerce_checkout_order_processed hook for velocity (orders per IP, per device fingerprint, per email domain, per amount range) and stop the burst before it gets to Stripe. You also score the customer-side fields (random-looking emails, mismatched billing data) before submission.

What to do this week

Two things you can do today even without a plugin: in your Stripe dashboard, turn on the Radar rule “Block if CVC check fails” and set a per-IP attempt limit on the checkout endpoint at the web-server level (Cloudflare rate-limit rules are free for one rule). That removes the smallest, fastest bursts. The next tier — the sophisticated bursts that rotate IPs and look like real traffic — is where a dedicated checkout-aware filter pays for itself in the first month.

Card testing is not the spam that fills your inbox. It is the spam that quietly costs you your merchant account. Treat it that way.

Akismet was the right answer for comment spam from 2008 to about 2022. It blocked the obvious junk — keyword stuffing, link salads, weird Cyrillic floods — and it shipped with WordPress so it was a default. In 2026 it is still useful as a first layer, but it is not enough on its own. Here is what changed and what to do about it.

What Akismet was always good at

Akismet scores each comment against a large pattern database: known spam URLs, IPs, emails, content fingerprints. It is fast, lightweight, and the false-positive rate is low. For comments that look obviously spammy, it still catches the vast majority.

What changed

The economics of comment spam shifted. The original spam was cheap to write but obvious. New comment spam is generated by language models and looks like this:

“Really enjoyed this read. The point you made about caching and TTFB matches what we saw on our last project. Have you considered looking at how this interacts with the new H3 stack?”

That comment is perfectly on-topic, conversational, and includes a relevant follow-up question. It will land on a post about WordPress performance. The link in the author’s URL field points somewhere mildly suspicious — usually a thin SEO site that just wants the backlink. Akismet has no signal to score this as spam. The pattern looks like a real reader.

Why this matters even if you do not care about comments

A surprising number of WordPress sites have comment forms still enabled on posts and pages where nobody reads them. Each successful spam comment that publishes drops a do-follow or no-follow link from your domain to a low-quality target. Google notices, eventually. Three years of accumulated comment spam links is a real Core Update risk.

What a layered defence looks like in 2026

1. Akismet for the easy lift. Keep it. It is still good at the bulk.
2. Intent scoring on the content of the comment. This is what catches the realistic AI-written stuff. The model reads the comment in context of the post and the author URL and decides whether it looks like a real reader or an SEO play.
3. Honeypot + timing in the comment form. Catches scrapers that bypass the JS and POST directly.
4. Author-URL reputation. If the URL field points somewhere new and thin, weight that as a signal even if the comment is well-written.

What to audit this week

Run this query in your wp-cli or phpMyAdmin to see how much spam is sitting approved on your site:

SELECT COUNT(*) FROM wp_comments WHERE comment_approved = 1 AND comment_author_url != '';

If the number is in the thousands and you do not have an active editorial review, you almost certainly have a pile of low-quality outbound links from your comment form. Disable comments on posts older than two years, sweep the approved-with-URL set for spam patterns, and add intent scoring on top of Akismet for the new comments going forward. That covers most sites without breaking anything that was working.