Discussion rules can hold suspicious comments for review or classify them according to the site's configured policy. Use precise rules and review false positives so legitimate readers are not blocked by an overly broad keyword or address match.
IN THIS ARTICLE
01 Start with observed abuse
Collect examples of the unwanted pattern, such as repeated promotional domains or a consistent phrase. Avoid copying a huge unknown blocklist into the site without understanding its entries. Common words, shared network addresses and short fragments can match innocent submissions.
Keep the previous rule set so a change can be reversed. Note whether an anti-spam plugin has separate lists or decisions that may override or supplement WordPress settings.
02 Apply a small rule change
- Open Settings > Discussion and review the moderation and disallowed-comment fields.
- Read the on-screen explanation of which comment fields are checked and how entries are matched.
- Add a small set of specific observed indicators, using the required one-entry-per-line format.
- Save the settings and submit controlled test comments that should match and should not match.
- Inspect Pending, Spam or Trash as appropriate to the configured action.
03 Monitor accuracy
Review the affected queues after deployment. A decline in public spam can conceal a rise in incorrectly filtered customer messages. Restore legitimate comments through the appropriate action and refine the rule responsible.
Do not permanently delete the entire queue before checking whether the new rule is too broad. Keep personal information from test submissions out of public examples or shared troubleshooting logs.
What can comment keyword rules fail to block?
Keyword rules do not reliably stop every automated attack, and a determined sender can change wording or infrastructure. Combine moderation with a maintained anti-spam approach appropriate to the site rather than continually expanding an unreviewed list.
If comments still bypass the rules, identify whether they arrive through the standard WordPress form or a third-party integration. Test that route specifically. If legitimate readers report rejection, collect the approximate time and a sanitised example, then compare it with the actual matching behaviour before removing all protections.