splorp/wordpress-comment-blocklist: The Human Compiler Behind WordPress Spam Defense

The surprise here is not that WordPress can block spam. It is that a plain text file can behave like a threat-intelligence feed when someone has spent years learning what spam looks like after you strip away the noise. splorp/wordpress-comment-blocklist is less a list than a manual compiler for the stable leftovers of bot output.

That matters because the repo never tries to be smart in the usual way. It does not profile sentiment, score behavior, or call home to a moderation cloud. It takes the opposite bet: if you know the recurring fragments, WordPress’s dumbest filter becomes good enough, private, and fast.

A blocklist that behaves like a compiler

Grant Hutchinson’s README makes the core idea plain. Since 2011, he has “painstakingly identified, compiled, and optimized” more than 64,000 phrases, patterns, and keywords used by spammers in usernames, email addresses, link text, and URIs. That is compiler work in miniature. Human research goes in, executable matching rules come out.

That framing is more useful than calling it a blacklist. A blacklist suggests static inventory. This repo is a living compression scheme, where each line represents a judgment about what spam keeps reusing, and what is safe to ignore.

How WordPress actually uses the list

WordPress’s native Disallowed Comment Keys feature is crude on purpose. It checks for case-insensitive substrings against comment content and related fields, then quietly discards the match. That simplicity is the whole opportunity. If spam keeps changing its wrappers but repeats the same core bits, a well-chosen fragment can catch an entire campaign.

This is why the repo leans so hard on partial anchors. Full words are too blunt. Substrings like _cialis or _vape can target spammy structures without relying on exact phrasing. The list is optimized for coverage per entry, not linguistic elegance.

Why fragments beat full words

The false-positive problem never goes away. The README is candid about that, warning that the list may “overclean” a comment queue. That is the real cost of substring matching: the same power that catches spam families can also clip legitimate language if the fragment is too broad.

That trade-off explains the weird elegance of the list. It is not trying to be perfectly general. It is trying to be specific enough to stop a bot campaign, but narrow enough to leave ordinary conversation alone.

Inside spam’s grammar

The reference files make the project feel less like a blocklist and more like a field guide. `reference/constructs.txt` captures spintax patterns, where bots shuffle phrases but leave the skeleton intact. `reference/strings.txt` collects randomized strings and fingerprints that look noisy until you realize the noise is itself part of the pattern.

That is the key mental model shift. Spam is not random. It has a grammar. Once you see the grammar, the maintainer’s job becomes less about reading every comment and more about extracting invariant anchors that survive generation tricks, template swapping, and keyword stuffing.

{I have|I've} been {browsing|surfing} online...
...lovely blog...
...visit my site...
...random token: 0wxkpu...

The repository’s reference materials are basically a decoder ring for that grammar. They show why a single fragment can neutralize a whole family of spam if the fragment sits at the stable center of a templated message.

The false-positive problem never goes away

This is not a contest with one winner. Akismet and similar services are better when you want adaptive scoring and minimal upkeep. The blocklist wins when you want local control, no vendor dependency, and a moderation rule set you can inspect without sending comment data anywhere else.

Why local beats cloud for this use case

The privacy angle is not incidental. A local blocklist keeps moderation inside WordPress, which means no external scoring service, no black-box model updates, and no extra data exposure just to decide whether a comment is junk. For site owners who care about transparency, that is a serious feature, not a philosophical garnish.

The deeper value is operational. A text file can be versioned, diffed, audited, and integrated into plugins that sync updates from GitHub. That makes the repo a durable base layer for a wider ecosystem of WordPress tools that want simple, reproducible spam defense.

What a mature blocklist looks like

Maturity shows up in the boring details. The project has been maintained across years of changing spam tactics, and its references show the maintenance style clearly: watch the patterns, harvest the anchors, trim the false positives, repeat. It is less glamorous than machine learning, but it is also easier to trust when the whole system is visible.

The best way to read this repository is as a record of adversarial adaptation. The spammers keep mutating their surface forms. The list keeps collapsing those forms back down to reusable fragments. That is why the project endures.