WordPress comment filters route spam—here's the rule set
The queue notification badge glows orange in the admin bar. Forty-three comments waiting, most of them three-link spam from IP ranges you’ve never seen, one or two genuine replies buried somewhere in the middle.
WordPress comment filters route spam before you see it—here’s how the rules work
Link count, keyword matches, and IP history decide whether a comment posts instantly or waits for approval.
WordPress doesn’t dump every comment into your moderation queue. It evaluates each submission against a short stack of rules—link threshold, blocklist keywords, IP reputation—and routes it to one of three destinations: published, held for moderation, or binned as spam. The defaults work for low-traffic blogs, but once you’re running a newsletter archive with reader discussion or a plugin documentation site, those settings either drown you in false positives or let rubbish through.
The link-count rule is the bluntest instrument: any comment containing more than a certain number of hyperlinks lands in moderation, regardless of who wrote it. The keyword filter scans both comment body and author fields for terms you specify—useful for blocking affiliate spam, less useful when legitimate readers trip over common words. IP and email history sits behind the scenes: if WordPress has previously approved comments from the same address, it may auto-approve the next one, even when link count would normally trigger a hold. Adjust the thresholds and you control the split between noise and signal, but only if you know which lever does what.
Most operators never touch these settings after install, then wonder why their moderation queue fills with garbage or why genuine comments vanish. The rules are deterministic, not intelligent, and they don’t learn. You set the boundaries once, then revisit them when the volume or pattern shifts.
TACTIC
When auto-save intervals don’t match your editing rhythm, you lose work
WordPress writes draft revisions every sixty seconds by default, but that cadence assumes you’re typing continuously in a stable browser tab. Open a second post in another tab, let a plugin stall the save request, or lose network for ninety seconds, and the last two paragraphs disappear. The interval is a constant, not a guarantee, and it doesn’t account for conflict or lag. Operators running long-form newsletter archives or documentation sites often tighten the interval or add a save-on-blur hook to catch edits that fall between the minute marks.
WORTH READING
Cache plugins purge at different speeds—and stale pages cost you clicks
WP Rocket, W3 Total Cache, and LiteSpeed Cache all promise to clear cached HTML when you publish an update, but the purge logic and timing differ. Some flush instantly on post save, others queue the purge and wait for the next cron tick, and a few only clear the single-post cache while leaving archive pages stale for minutes. If you’re publishing time-sensitive newsletter issues or product updates, the gap between “published” and “visible to readers” matters. The plugin you picked decides how long that window stays open.
FROM THE ARCHIVE
Most newsletter platforms bury archive search—or skip it entirely
Readers arrive at your archive looking for a specific tactic or tool mention, but most newsletter platforms either hide the search box, return results ranked by recency instead of relevance, or omit search altogether. Substack indexes subject lines but not body text on free plans; Beehiiv offers full-text search only on higher tiers; WordPress depends on whichever search plugin you’ve installed. If your archive is your content moat—back-catalogue SEO, evergreen reference material—then discoverability isn’t a nice-to-have. It’s the difference between a reader finding the answer in ten seconds or bouncing to a competitor’s post.
Know someone who would like this? Forward today’s email — every operator we reach is one closer to running an online business with a little less friction.