Quick Answer
A WordPress comment spam moderation workflow should start with conservative Discussion settings, then move through a repeatable review queue: require moderation for first-time or risky comments, hold comments with too many links, use a blocklist only for clearly unwanted patterns, review Pending and Spam before deleting, and record which settings changed. For a small publisher, the best fit is not maximum friction for every reader. It is a calm operating routine that keeps real comments recoverable, keeps spam out of public pages, and avoids turning comment cleanup into risky engagement manipulation.
Minimum Moderation Stack
| Layer | WordPress control | Operator decision |
|---|---|---|
| Comment access | New-post comment setting and per-post discussion controls | Choose which article types should accept comments |
| Identity friction | Name, email, registration, and previous-approval settings | Add friction only where moderation load justifies it |
| Queue rules | Manual approval, link thresholds, moderation terms, and blocklist terms | Hold uncertain comments before deleting them |
| Daily review | Pending, Approved, Spam, and Trash views | Approve, reply, mark spam, restore, or delete from a defined queue |
| Anti-spam layer | Akismet or another documented plugin workflow | Use as a filter, not as the only moderation policy |
| Evidence | Source notes and settings log | Record checked date, setting changes, and false-positive handling |
Who Should Use This Checklist
Use this checklist when a WordPress blog wants comments for reader questions, corrections, community discussion, or article feedback, but the operator does not want spam links, irrelevant posts, or unreviewed user-generated text appearing below search-facing pages.
Skip open comments when the site has no moderation capacity. A small AdSense-focused publisher does not need comments on every article. Some posts are better as static reference pages with an email or contact route elsewhere. WordPress lets operators set a default for new articles and then override comment availability on individual posts, so the practical decision can be page-by-page instead of all-or-nothing.
This is not legal, security, or privacy compliance advice. It is an editorial operations workflow. The goal is to reduce avoidable comment spam, protect page quality, keep reader-facing discussions intentional, and make future moderation decisions easier to audit.
Step 1: Decide Which Posts Should Accept Comments
Start with the default comment setting for new articles. If comments are useful only for troubleshooting posts, community prompts, or product-change discussions, do not enable them globally by habit. Use a simple rule:
- Evergreen checklists can keep comments closed unless the site actively wants reader corrections.
- Troubleshooting posts can allow comments while the topic is fresh, then close them after the support window.
- Sensitive account, money, medical, legal, or security-advice topics should not rely on public comments as support channels.
- Older posts can close comments after a defined period if the queue attracts stale spam.
WordPress discussion documentation describes default article settings and notes that individual articles can override those defaults. That gives operators a clean path: set the site default conservatively, then enable comments where a human will actually review them.
Step 2: Add Friction Before The Queue Is Overloaded
Comment friction should match the moderation burden. Requiring a name and email, limiting comments to registered users, closing older threads, or requiring prior approval can reduce spam pressure, but each setting also changes who can participate.
Use this decision table:
| Setting | Use this when | Avoid this when |
|---|---|---|
| Require name and email | The site wants fewer anonymous throwaway comments | The site cannot explain how comment data is handled |
| Require login | Comments are only for members, customers, or known contributors | The blog wants low-friction public feedback |
| Close old comments | Old posts attract link spam or stale support questions | Historical posts still get useful reader corrections |
| Previous approval required | Repeat readers comment often and first-time comments need review | New readers need immediate discussion |
| Manual approval for all | The site has low comment volume and high quality risk | Moderators cannot check the queue consistently |
The right answer is usually gradual. Start with approval for first-time commenters, hold comments with suspicious link volume, and close old discussions where spam is predictable. Move to stricter settings only when the queue evidence shows a real need.
Step 3: Hold Risky Comments Before Deleting Them
WordPress includes moderation controls for link counts, words, email addresses, URLs, IP addresses, and browser user-agent strings. Use those fields as a holding system first.
For small blogs, the safest operating rule is:
- Hold comments with multiple links.
- Hold comments that match repeated spam terms or suspicious domains.
- Hold first-time commenters until one real comment is approved.
- Reserve the blocklist for patterns that are clearly unwanted.
- Review the Spam and Pending queues before bulk deletion.
The reason to prefer holding over instant deletion is recoverability. A real comment can look suspicious when it includes a product URL, a copied error message, or several reference links. If the comment is held, an operator can approve or edit it. If a broad blocklist deletes too aggressively, useful feedback may disappear before review.
Step 4: Review Comments By State, Not By Inbox Panic
The WordPress Comments area separates comments into states such as Pending, Approved, Spam, and Trash. Treat those states as a workflow:
1. Review Pending first because those comments are waiting for a public decision. 2. Approve real comments that add a question, correction, experience note, or useful context. 3. Reply when the answer can improve the page or clarify an article limitation. 4. Mark obvious spam as spam instead of editing it into usefulness. 5. Check Spam for false positives before emptying it. 6. Leave Trash as a short retention buffer before permanent deletion.
This sequence keeps moderation from becoming a content-quality problem. Public comments are part of the page experience. If the comments section fills with unrelated links, thin praise, copied outreach, or suspicious calls to action, the page looks less trustworthy even if the article itself is strong.
Step 5: Use Akismet As A Filter, Not A Substitute For Policy
Akismet is a widely used anti-spam plugin in the WordPress ecosystem, and the WordPress.org plugin page positions it around comment, form, and text spam filtering. That makes it a practical reference point for a small publisher, especially when the queue has more spam than one operator can review manually.
But a plugin should not be the whole policy. The operator still needs to decide:
- Which posts accept comments.
- Which comment types are valuable.
- Whether false positives need review before deletion.
- How often the Spam queue is checked.
- Which plugin settings or notices are appropriate for the site.
- Who is responsible for moderation when the owner is unavailable.
Use the plugin layer to reduce noise. Use WordPress settings and the moderation routine to define what the site actually allows.
Step 6: Keep A Settings And Source Log
Comment moderation gets messy when no one remembers why a setting changed. Keep a small log next to the site operations notes.
| Log field | Example value |
|---|---|
| Checked date | 2026-06-07 |
| Source checked | WordPress Discussion settings documentation |
| Setting changed | Held comments with two or more links |
| Reason | Link-heavy spam appeared in Pending queue |
| Follow-up | Recheck false positives in seven days |
| Related page type | Troubleshooting posts with open comments |
This log does not need to be public in full. The published article can show the source trail, while the private operations record can include queue counts, plugin settings, and examples that should not be republished.
What Should A WordPress Comment Spam Moderation Workflow Include?
A complete workflow includes seven parts:
1. A default comment policy for new articles. 2. A page-level exception rule for posts that should allow comments. 3. A first-time commenter approval rule. 4. A link-count threshold for moderation. 5. A cautious moderation list and stricter blocklist. 6. A Spam and Pending review cadence. 7. A settings log that records source checks and follow-up dates.
If the site cannot support those seven parts, choose fewer open-comment surfaces. Closing comments on low-value targets is better than leaving every article open and hoping a plugin catches the risk.
Common Questions
Should every WordPress blog allow comments?
No. Comments are useful only when the operator has a reason to collect public feedback and enough time to moderate it. A reference-heavy blog can keep many posts closed and still invite corrections through a separate contact route.
Is manual approval too strict?
Manual approval is reasonable for small sites with low comment volume or high spam pressure. It becomes a problem only when the operator cannot review the queue, because real comments then sit invisible for too long.
Should spam comments be deleted immediately?
Not always. Obvious spam can be removed, but the operator should still check for false positives before bulk deletion, especially when an anti-spam plugin is active or a new blocklist term was recently added.
How often should the moderation workflow be reviewed?
Review it every 90 days, or sooner after a spam spike, plugin change, theme change, comment-form change, or a reader report that a real comment was blocked.
How does this support AdSense-safe publishing?
It avoids fake engagement, link clutter, copied outreach text, and unreviewed user-generated content on public pages. The workflow improves site quality without creating artificial traffic, clicks, or social proof.
Source Notes
- https://wordpress.org/documentation/article/settings-discussion-screen/ checked 2026-06-07; used for source-derived analysis of Discussion settings, comment defaults, notification settings, manual approval, link-count moderation, moderation terms, blocklist behavior, and avatar controls.
- https://wordpress.org/documentation/article/comments-in-wordpress/ checked 2026-06-07; used for source-derived analysis of comment states, Discussion settings, comment rules, comment display, comment administration, spam handling, and enabling comments on individual posts.
- https://wordpress.org/documentation/article/comments-screen/ checked 2026-06-07; used for source-derived analysis of the WordPress admin comment screen and the operator actions available while reviewing comments.
- https://wordpress.org/plugins/akismet/ checked 2026-06-07; used for source-derived analysis of Akismet as a WordPress anti-spam plugin for comments and related spam-filtering workflows.
- https://akismet.com/support/ checked 2026-06-07; used for source-derived analysis of Akismet support topics, activation and troubleshooting paths, and the need to pair plugin setup with documented moderation operations.
Internal Link Plan
Link to wordpress-security-checklist-for-blogs when framing comment moderation as a basic site-hardening routine. Link to wordpress-database-cleanup-checklist when stale Spam and Trash queues become database cleanup inputs. Link to wordpress-scheduled-posts-checklist when comments are opened or closed as part of an editorial calendar. Link to wordpress-cache-clearing-checklist if moderation settings do not appear immediately on cached pages. Link to source-notes-workflow-for-blog-posts when explaining the settings and source log.
Update Note
Review this checklist every 90 days. Recheck official WordPress Discussion settings, WordPress comment management documentation, the WordPress.org Akismet plugin page, and Akismet support pages before changing the moderation workflow. Refresh earlier after a spam spike, comment plugin change, privacy-notice change, theme comment-template change, or a false-positive report from a real reader.