WordPress comment blocklist: 66,000 spam keywords and where it breaks

A text file, not a plugin, and fifteen years of curation

The project is called wordpress-comment-blocklist and the repository description is a simple solution for WordPress comment spam. What it actually contains is one text file.

The README says that since 2011 the author has identified, compiled and optimized over 66,000 phrases, patterns and keywords commonly used by spammers and comment bots in usernames, email addresses, link text and URIs, and it notes that as with all compilations this blocklist is a work in progress with room for improvement and optimization.

That is the whole design. There is no plugin, no hook, no scoring and no server side call. The list is text that you paste into a WordPress setting, and WordPress does the matching with its own mechanism.

The reason the list is long is the reason it works. Spam filters that make a judgement about a comment fail on novelty, because a spammer can simply write something new. A list of every phrase, pattern and keyword observed over fifteen years does not have that weakness, and the repository is a record of fifteen years of somebody reading spam and writing down what was in it.

The topics on the repository make the scope explicit: antispam, blacklist, blocklist, comment-blacklist, comment-blocklist, spam-filtering, wordpress and wordpress-comments. The primary language is listed as unknown, which is consistent with a repository whose content is a data file rather than code.

Two ways to install, and one of them repeats on every update

The how do I use it section describes a manual installation, and it is a copy and paste operation. You take the list of keywords from the blacklist.txt file, paste it into the Disallowed Comment Keys field of the Discussion Settings panel in WordPress, and click Save Changes.

There is a naming wrinkle worth knowing, because searching for the right setting name takes a while otherwise. The Disallowed Comment Keys field was previously named Comment Blocklist in WordPress 5.4, and Comment Blacklist in WordPress 5.3 and earlier.

Then the README says to repeat this procedure each time you want to install an updated version of the blocklist. That is the honest cost of the manual route, and it is why the second route exists.

The automatic route is a set of plugins that check whether the master blocklist has changed and then install the most recent version. The README lists several: Block List Updater by Pluginkollektiv, Comment Blacklist Manager by Andrew Norcross, Comment Blacklist Updater by Apasionados, Shield Security, WP Toolbelt by Ben Gillbanks, and Zero Spam for WordPress. The Gravity Forms add-on for custom form builders is mentioned as taking advantage of the automatic updates provided by one of these plugins.

So the decision is between pasting a list every few months and installing a plugin that keeps the list current for you.

The option row behind the setting, and a four gigabyte ceiling

The technical considerations section explains why the list can be as long as it is, and it is a short piece of documentation worth reading.

WordPress stores the contents of the Disallowed Comment Keys setting in the options table as the disallowed_keys option. The column is defined as a longtext data type in MySQL, and the README notes this column can contain up to 4,294,967,295 bytes, roughly four gigabytes of text, and concludes there is no chance of running out of room to expand the blocklist any time soon.

That is the design constraint that makes fifteen years of accumulation possible. A setting stored in a varchar field would have capped the list long ago, and the author would have had to prioritise which spam patterns to keep.

The same section notes the other half of the naming history: the disallowed_keys option was previously named blacklist_keys in WordPress 5.4 and earlier. So a change of the field name and a change of the option name both happened around 5.4, and both are documented here, which is the kind of detail that saves an hour when a migration script goes wrong.

The repository layout is consistent with a data project. There is blacklist.txt, a history.md, a license.txt, a readme.md, an assets directory and a reference directory, and the reference directory holds the separate shortener domain list that the limitations section refers to.

The evidence is one report, and the author warns you about overblocking

The does it really work section is written with a degree of honesty that is unusual for a filter project, and it is worth reading closely before you paste anything.

The author starts by acknowledging the scepticism, saying you should not blame them if you are unsure how well this blocklist works compared to a commercial solution like Akismet. The reason given is that the author is subjectively including keywords based on comment spam submitted to their own sites, and there is a chance that the blocklist will overclean your comment queue. The README calls that a fair warning.

The supporting evidence is a single report. Jason Cosper is cited as reporting that he used an earlier version of the blocklist on a client's WordPress installation containing around 800,000 comments, and that the blocklist flagged 40 percent of those comments as spammy. As a sanity check, he exported the flagged comments to a local WordPress install and had Akismet do its thing, and according to the README that produced zero false positives.

That is one person's report, on one site, with an earlier version of the list. The project was also written up by WP Daily, now Torque, in a post by John Saddington titled Die Spam! Blacklist That Shiz with This Gist!

The honest summary is that the list is a large, curated set of strings that has been reported to catch a large fraction of spam with no false positives in one environment, and that its own author expects it to be overinclusive elsewhere. That combination is fine for a first line of defence and wrong as a replacement for a classifier.

Four ways the list misfires, all documented

The known issues section is the most useful part of the README, because each item is a specific configuration decision rather than a vague warning.

The WordPress.com free plan has a hard limit of 10,000 entries in the Disallowed Comment Keys field, and the current blocklist contains several thousand more than that, so you cannot save the changes. A message tells you that you must reduce the number of entries for your blog to work efficiently. This is a hard stop, not a degradation.

The URL shorteners entry is the opposite problem. Spammers use shorteners to hide their links, so a handful of shortener domains are included in the list, and the README argues that there is no practical need for a comment to contain a shortened URL since unmodified links can be formatted with HTML. If your visitors do use shortened URLs regularly, the advice is to remove some or all of those domains, and the domains are kept in a separate file under the reference directory so that the edit is easy to make.

The WordPress links entry is the same kind of case with a different cause. Spammers use links pointing at compromised admin files, themes or plugins, so deep links such as /wp-admin, /wp-content, /wp-image, /wp-include, /wp-json, /wp-list, /wp-plugin and /wp-site are in the list. The README says you may want to remove them if your visitors comment about WordPress site, plugin or theme development.

And the non-English comments issue is the one that catches people out. The blocklist was created for English language sites, and it contains several dozen terms and phrases that may flag legitimate comments in other languages, so if you receive comments containing CJK, Thai or Cyrillic characters you may want to remove or modify those sections. A site with an international audience, or a site about software development where a comment containing a path such as /wp-content is normal, will find those entries are a liability rather than a defence.

An MIT data file, still updated in 2026

The licence is MIT, with the file named license.txt in the repository, so the list can be copied, modified and redistributed without restriction beyond keeping the notice.

On maintenance, the repository is not archived and the last push was on 2026-10-06, and the project publishes no GitHub releases, which is the right shape for a data file. There is nothing to version and install, so a release tag would add nothing.

The repository also carries a history.md, which for a project whose artefact is a list is the changelog that matters, since it records what was added and when. The assets directory holds the images used in the README, and the reference directory holds the separate lists that the limitations section tells you to edit, principally the shortener domains.

The result is a project with an unusual shape for a repository. There is no code, no build and no dependency, and the deliverable is a file you paste into a settings field. That shape is also its weakness: because the installation is manual, the effective state of any given site depends on when somebody last did the copy and paste, and the README's own advice to repeat the procedure on every update is the only mechanism for keeping that current.

For a site that already runs a spam plugin, the sensible use is as a cheap complement. A large list of observed spam strings costs nothing, catches what the plugin's heuristics miss, and, as long as you read the overblocking warning and trim the sections that apply to your audience, does not get in the way of real comments.

Editorial conclusion

Adopt the WordPress comment blocklist if you run a self hosted WordPress site with comments enabled and you want a cheap first line of defence that costs nothing and needs no plugin, especially if you already plan to keep a plugin like Akismet behind it. Do not adopt it as a complete spam solution, because it matches strings rather than judging content, and do not adopt it on the WordPress.com free plan, where the field cannot hold the list. Verify first that your host allows a list of this size in the options table, that the overblocking warning in the README does not hit your own audience, and that the deep link entries do not need to be removed for a site where visitors legitimately discuss WordPress development.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. splorp/wordpress-comment-blocklist on GitHub