Automated moderation is the software that stops a brand-new account from becoming the whole job. It is registration gates, phrase lists, a sandbox, a queue the machine can fill, and a cleaner you run after you have decided the account is junk. It is not a personality. It will not tell a brilliant jerk from a bad day. That is a human shift.
This article is the products: XenForo registration approval and the approval queue, the spam trigger log and spam cleaner, CleanTalk, Spaminator (Ozzy47), Moderator Panel by Andrew (Protected Users), and on Discourse the TL0 sandbox, watched words, and the review queue. It is not moderating a large XenForo — that piece already owns node moderators, warning points, soft-delete, IP More users, and the first 30 minutes of a duty shift. It is not building a moderation team — hiring, personal vs staff accounts, burnout. Read those for the people. Stay here for what the machine is allowed to touch.
The admin toolkit already named gates as a class. This is the drawer. We will not invent Akismet as stock XenForo. We will not invent a Discourse Reviewable Scoring formula. If a knob is not in the official manuals, community notebooks, or the named add-ons above, this article will say so.
What automation is allowed to do
Write the job before you paste an API key.
| Job | Machine may | Human still must |
|---|---|---|
| Stop the empty account | Hold a registration, challenge a form, sandbox media | Confirm the human you actually invited |
| Stop the repeated payload | Match a phrase, a link pattern, a known spam signal | Tune the phrase so it does not eat [url] in Support |
| Hide the first spray | Queue, auto-hide, auto-silence a new account on stacked signals | Decide if a Regular is a problem |
| Clean the leftover | Spam cleaner / delete the sock farm you already identified | Copy the IP, write the staff note |
| Protect staff identities | A protected-users list so junior mods cannot ban Admin | Hire adults who will not try |
If the public tree is on fire, you have a spam problem or a culture problem. Turning every node to “moderate new threads” creates a second forum only staff can see. Prefer: hold links from new accounts, hold registrations that fail a check, leave the sandbox on, let established people post. Reports and flags catch the rest.
Automation that argues in public is a bug. Soft-delete or hide. Do not let a bot post “this looks like spam” under a legitimate intro.
XenForo: registration approval and the queue
XenForo’s first gate is whether an account is allowed to finish becoming a member.
Official user-state model, already used in the large-forum article: Valid means they clicked the confirm mail and get Registered rights. Every other state uses the Unregistered / unconfirmed permission set. A pile of unconfirmed accounts is either mail (the push/email transport) or a farm hitting the form. Search non-Valid users on a Monday.
Registration approval — staff must accept the account before it becomes a normal member — is the stock hold. Official docs in the notebook we queried are thin on the exact approval-queue UI. The product still has approve / unapprove, and unapproved / soft-deleted threads live in a non-visible discussion_state and go to the approval queue. Community limit already recorded elsewhere: the 2.3 queue pulls a page at a time (about 50). It is a spam tool, not an HR inbox. Do not run a 400-thread application season through it.
What should land there on a working board:
| Hold this | Why | Do not hold this |
|---|---|---|
| Registrations you chose to approve, or that an anti-spam integration flagged | Empty accounts never reach the tree | Every valid email confirm on a quiet hobby board |
| First posts that contain a URL, until the account has N messages | Unestablished + link is the usual payload | Every thread in Introductions |
| A staff-only apply forum you chose to moderate | You designed that queue | The entire public tree “until we hire” |
Community spam setup that does not need a new add-on:
- Stop unestablished accounts filling location / occupation / website until they have one real post.
- Spam phrases in the ACP. Community example:
[url*(not only[url=) so people who break the tag still match. - Tools → Spam trigger log. First stop on a shift. Patterns show up there before they show up in the queue.
Moderate new threads on a node is a stock checkbox. Use it on the apply forum. Do not paint it across the public tree because Tuesday was loud.
Permissions still matter. Official: parent unviewable blocks children; Never beats Yes; a Private node strips View globally until you re-grant it. Staff who cannot see the apply forum cannot approve it. The permissions article is the map. This article will not rebuild it.
XenForo: spam cleaner and the verbs around it
Ban, disable, reject, and spam cleaner as separate ACP verbs are not fully documented in the official notebook we queried. What is documented, and what you should actually click:
- Soft-delete hides the post or thread. Reversible. Default public action. Official REST split:
thread:writecovers soft-delete;thread:delete_hardis the destructive scope. - Hard-delete removes the row. Undo is a backup. Illegal content, or the spam account you already copied an IP from. Not a bad take.
- IP addresses on the user edit screen: official More users control. Ban or discourage an IP from that list. Discouraged is the official “make this connection miserable without a drama-ban” switch.
- Security lock: change password vs reset password. Compromised account. Not a punishment. Different article — security.
The spam cleaner is the cleanup pass after you have decided the account is a sock farm: remove the posts, the threads, the profile junk, in one staff action the product actually offers. Community practice: ban the account, then the IP, then run the cleaner. Do not invent a batch that touches 4,000 rows on the web request at peak. Official developer warning still applies: do not fetch() every post on a large board; use the job system. A “clean up all spam” script pasted into Tools is how you lock the table.
Mass bans are not listed in the official notebook as a lockup cause. Still: one account, then the IP, then the cleaner. Write two lines in the staff node: IPs, phrase, “watch until Friday.”
Do not use the cleaner on a long-term member you are angry at. That is toxic users, not automation.
CleanTalk
CleanTalk is a named third-party anti-spam add-on in XenForo community practice (SF-2). It is not core. It is optional. Community write-ups use it to send suspect registrations to the approval queue instead of letting them in.
What that means operationally:
- You are buying a reputation check at the form, not a second culture.
- Suspects should land in the queue you already staff, not in a vendor dashboard nobody opens.
- It does not replace confirmation mail. A human who never gets the confirm email is a Symfony Mailer / transport ticket.
- It does not replace Registered as primary. An add-on that assumes two baselines will hurt later.
Install it when the spam trigger log already shows a pattern the stock phrases cannot eat — typically registrations that look complete and then spray links. Do not install it the same hour you turn confirmation off. You will not know which change did the work.
We will not invent CleanTalk’s 2026 price, cloud vs self-hosted SKUs, or a “set these exact thresholds” list the notebooks did not print. Read the add-on’s current resource page. Test on staging. Confirm a legitimate registration still arrives.
If CleanTalk (or anything like it) starts holding every valid email, you broke onboarding. The onboarding catalogue is then the article, not a tighter API.
Spaminator (Ozzy47)
Spaminator by Ozzy47 is the other named extra in those community sources. The job they give it: registrations that skip the browser — scripted form posts, the junk that never runs your JavaScript challenge, the accounts that appear without a normal session.
That is a different slice than CleanTalk’s “reputation at the form.” You may need neither. You may need one. You almost never need both on the same afternoon.
Operational notes that stay honest:
- It is an add-on. It will have an ACP page. It will have a version that must match 2.3. The upgrade article already told you jQuery-era add-ons fail silently.
- Use it for the empty account that bypassed the skin, not for a long-term member’s bad take.
- Pair it with the stock login limit (four failures → CAPTCHA or 15-minute lock) and a working CAPTCHA provider. Official: Setup → Options → User options → Login limit method. A CAPTCHA method with no provider configured is a hole that looks like a feature.
We will not invent Spaminator’s internal scoring, a price, or a claim that it is “better than CleanTalk.” Different job. Measure against the log you already have.
Moderator Panel by Andrew (Protected Users)
Moderator Panel by Andrew is community-named, not official core. The feature those sources actually use in this conversation is a Protected Users list: junior moderators cannot ban (or otherwise nuclear) an admin profile.
That is automation in the staff-safety sense, not in the spam-spray sense. It belongs in this catalogue because the failure mode is the same class: a tool in the wrong hands.
Stock version of the same idea, if you never install the panel:
- Do not hand global ban to node moderators.
- Do not leave the root Admin account logged in on a shared machine.
- Staff post as themselves, without the nuclear badge, when they are being members.
The mod team article already used this add-on as an identity footnote. The large-forum shift already said node mods do not get ban / hard-delete / edit users. If you install the panel, it is step 4’s dashboard in that shift, not a reason to skip the handbook.
We will not walk every tab of Andrew’s panel. We will not invent versions. Protected Users is the sentence that earns the name here.
What we will not invent on XenForo
Akismet is not stock XenForo. WordPress operators keep reaching for that word. XenForo’s stock tools are confirmation, approval, spam phrases, the trigger log, the cleaner, IP ban/discourage, user states. Third-party anti-spam exists (CleanTalk is the one community sources name next to the queue). If you run an Akismet-shaped add-on, it is your add-on. This article will not document it as core and will not pretend the official notebook shipped it.
Also not in the official notebook as a complete verb set: a points-from-spam auto-ban ladder, a “Reviewable Scoring” analogue, a per-IP fail2ban inside XenForo. Edge rate-limits are your web server or your host. Official login limit is four failures, then CAPTCHA or 15 minutes. That is the product.
Discourse: TL0 is the sandbox you should not turn off
Discourse does not moderate like a classic forum. The trust-level article is the model. This section is the automation slice: what the machine does to strangers before a human opens /review.
TL0 (New) is the sandbox. Defaults from the permissions reference / notebook research — re-read Meta when a friend complains:
- 1 image (
newuser max embedded media) - 2 links
- 2 mentions
- 50 likes per day
- 24-hour own-post edit window
- Cannot flag
- Cannot mute
- Cannot ignore
- Chat: 20 messages / 30 seconds (when Discourse Chat is on); TL1+ 40/30s; mods unlimited
Those caps are why a migrated community’s first week is full of “I cannot attach my four screenshots.” That is the product working. The fix is almost never “set every new-user limit to zero.” The fix is: tell people that reading promotes them to TL1; invite people you already trust (they typically start at TL1); change one cap if a specific intro ritual requires it.
Turning off the TL0 sandbox — raising default trust, or zeroing the caps — is the single most common new-admin spam magnet. The review queue cannot outrun a form that lets a fresh account drop fifty links. Setting “everyone starts at TL2” on a public site is how you donate the queue to spam.
TL0 cannot flag. A brand-new user who sees spam must use another channel until TL1. Brief staff so they do not call that a bug.
Invited people skipping TL0 is the documented on-ramp for people you actually know. Public signups should stay in the sandbox.
This is not a rank. This is a gate. Do not confuse it with XenForo’s Established promotion (community practice: revoke Start conversations / external links from Registered; grant on Established). Different ladders. The Discourse essay owns demotion, TL3’s 100-day window, and TL4 as a staff grant. Do not retell that here.
Discourse: watched words
Watched words are available to moderator+. They catch the boring payload before a human. Official notebooks we used did not reprint a custom treatise; the standard admin UI actions in the product are well-known and we will name them as such, not as invented scoring:
- Block — the word cannot be posted.
- Censor — the word is replaced for readers.
- Flag — the post enters the review path.
- Replace — swap the token for another.
Use block for the pharmaceutical / crypto-drain strings you have already seen twice. Use flag when you want a human to see context (a word that is also a game item). Use censor sparingly; members will treat it as a joke. Use replace for the accidental trademark or the invite code you do not want circulating.
Watched words are not a personality filter. They will not catch a fluent scammer who never uses your list. They exist so TL1 flags are not your only hose.
Do not build a 400-row list on day one. Add the payload you actually saw in the review queue. Write the phrase in the staff category. Same discipline as XenForo spam phrases.
Discourse: the review queue
Staff work the review queue. It is fed by:
- Member flags (TL1+)
- Watched-word flag actions
- Users and posts the system held
- The documented path where diverse TL3 flags on a TL0 post can auto-silence the new user and hide the post
That last sentence is automation. Treat Regular flags as junior-moderation, because the software already does. It is also why you do not hand TL3 to everyone and call it engagement.
What we will not do: invent a Reviewable Scoring formula, a numeric “this many flags times this weight equals auto-hide” table, or a 2026 admin screen of score weights the notebooks did not print. Operate on the shape: sandbox, flags, watched words, queue, auto-silence on stacked TL3 signals against TL0. Open your site’s version if you need the current numbers.
Queue operations that stay honest:
- Empty it on a schedule, like XenForo’s approval page. A queue that is a career is a sandbox you turned off.
- Auto-silence of a TL0 is a starting point, not a trial. A human still reads it if the person writes in.
- TL0 cannot flag. If the queue is empty and Latest is dirty, the people who can flag are not around — or watched words never learned the payload.
fail2ban on a self-hosted box is SSH brute-force protection. The hosting cookbook already named it. It is not a Discourse plugin and it does not replace this queue.
Combining products without stacking failures
A working 2026 set is small.
XenForo, stock first
- Confirmation mail actually delivers.
- Unestablished profile fields locked.
- Spam phrases for the payload you have seen.
- Trigger log on every shift.
- Approval queue for held registrations / first-link posts.
- Cleaner after the account is identified. IP ban or discourage as appropriate.
Then, if the log still shows complete-looking registrations: CleanTalk or a careful read of whether the junk is skipping the browser (Spaminator’s slice). Not both on the same afternoon. Staging first.
Discourse, stock first
- TL0 caps left on.
- Watched words for the second copy of a payload.
- Review queue as the daily surface.
- Invites for people you know.
Then a plugin only if Meta and your hosted plan (or your app.yml) actually allow it. Hosted plans restrict plugins. That is not a slight.
Never in the same hour:
- Turn confirmation or TL0 off and install a new anti-spam add-on.
- Rebuild permissions on a large XenForo tree and mass-clean 4,000 posts.
- Silence a long-term member with a watched-word block meant for TL0.
Permission rebuild cost on XenForo is still C ∝ U × N. Community numbers: ~80 nodes × ~60 groups → two to four minutes; 700+ nodes → timeouts. Automation that “helps” by adding a group per spam mood is how you buy an availability event. Prefer broad nodes + prefixes. Prefixes do not trigger permission rebuilds.
A registration-wave afternoon (products, not the shift handbook)
You open the XenForo spam trigger log. Forty hits, website field stuffed, two /24s. This is the product order — the duty-shift table still owns the 30-minute human loop.
- Do not install CleanTalk in this hour. You will not know whether the log, a new add-on, or a CAPTCHA you also flipped did the work.
- Confirm website / location / occupation are still locked for unestablished accounts. Stock.
- Add a spam phrase that matches the payload you saw. Not a phrase that will eat
[url]in Support. - Ban or discourage the two IPs (discourage if they look like a shared mobile gateway — official discourage exists for that ambiguity).
- Reject the queued registrations. Leave Valid humans alone.
- If the next morning’s log still shows complete-looking accounts that never tripped a phrase — that is CleanTalk’s slice. Staging. Then production.
- If the accounts appear with no normal session — empty browser, no JS — that is Spaminator’s slice. Same rule: one change.
Discourse version of the same afternoon:
- Do not raise default trust. Do not zero TL0 caps.
- Add the payload to watched words as block or flag (flag if the token also appears in legitimate game talk).
- Work the review queue. Auto-silences of TL0 are a starting point.
- Write two lines in Site Feedback’s staff cousin: phrase, “watch until Friday.”
That is automation doing its job. Hiring a third moderator in the same hour is how you also skip the log.
CleanTalk and Spaminator on the same board
You may eventually run both. You should be able to say why in a sentence each.
| Slice | Stock first | Named extra |
|---|---|---|
| Form completed, reputation smells | Confirmation + approval + phrases | CleanTalk → queue |
| Form skipped the skin / no browser | CAPTCHA provider actually configured; login limit after 4 failures | Spaminator |
| Staff identity | Node mods cannot globally ban | Moderator Panel / Protected Users |
| Repeated token in a post | Spam phrases | (still stock) |
| After the account is junk | Soft-delete, then cleaner | (still stock) |
If you cannot fill the “why” cell, do not install the extra. Two anti-spam add-ons that both hold registrations will look like “the board is dead” to a real human on a phone.
Discourse hosted may not let you add the XenForo extras at all. Different product. Stay on TL0 + watched words + review.
When automation becomes the problem
You will know.
| Symptom | You probably did | Undo |
|---|---|---|
| Zero legitimate registrations | Confirmation + a reputation API + a CAPTCHA that is broken | Test as a throwaway human on a phone |
| Introductions is empty, Support is a ticket desk | Every new thread is moderated | Hold links, not rooms |
Regulars cannot post a patch note that contains http |
Phrase list too proud | Narrow the phrase; flag instead of block |
| New members cannot post a single screenshot | You left TL0 on — that is success — but you never told them | Welcome topic; do not zero the cap |
| A junior mod banned the founder | Global ban on node mods; no Protected Users | Stock permission diet; optional Andrew panel |
| The board is “down” after a clean | Web-request mass delete at peak | Jobs, off-peak, one account at a time |
False positives are an onboarding incident. They will not show up as a vanity registration spike in analytics. They show up as new → first post going to zero while the spam log looks “healthy.”
The human workflow these products sit under
Software hides a post. People decide what happens next.
On XenForo, the shift order is already written: log in as you, spam trigger log, non-Valid users, approval queue, reports, one IP More users check. No group or node permission save in that half hour. Node mods: view/edit/soft-delete/move/merge on their branch. Ban and hard-delete stay global.
On Discourse, the model is already written: TL machine, review queue, watched words, groups as walls. Do not add redundant groups (admins + mods + TL1–4) on a category — hierarchical, causes “not permitted to view.” Keep a public Site Feedback category.
If you need the handbook, the rota, or how to fire a moderator who uses the badge to win Off-topic, that is #39. If you need the XF queue chrome and the warning-points idea (the official hook is a disciplinary group with Never at a point total; the exact editor/decay ladder was not in the official notebook — do not copy a 2018 blog), that is #12. This article will not reprint either.
Checklist
XenForo
- Confirm mail delivers; non-Valid states use Unregistered rights
- Registration approval / first-link hold is intentional, not “everything”
- Unestablished website / location / occupation locked
- Spam phrases match the payload you saw (
[url*if that is the trick) - Tools → Spam trigger log is on the daily surface
- Soft-delete default; cleaner only after the account is identified
- IP More users, then ban or discourage; security lock is not a punishment
- CleanTalk and/or Spaminator only after the log shows their slice; staging first
- Akismet is not assumed as core
- Node mods cannot ban Admin (stock diet, optional Protected Users)
- No mass clean at peak; no extra group per spam mood
Discourse
- TL0 caps still on; public signups are not starting at TL2
- Welcome topic explains the sandbox
- Watched words: block / censor / flag / replace used on purpose
- Review queue emptied on a schedule
- You did not invent a Reviewable Scoring table
- fail2ban is SSH, not this queue
Both
- One change per afternoon
- Staff handbook still wins arguments
- Health mod load instrument has a denominator (metrics)
What this article will not do
It will not publish CleanTalk or Spaminator prices. It will not document Akismet as stock XenForo. It will not print a Reviewable Scoring formula. It will not give you a warning-points ladder the official notebook omitted. It will not replace a culture document.
It will not rank “best anti-spam 2026.” Stock gates first. Named extras when the log names their job.
Takeaways
- Automation holds, matches, hides, and cleans. It does not hire, and it does not argue.
- XenForo stock is confirmation, approval, phrases, the spam trigger log, the cleaner, IP tools. CleanTalk and Spaminator (Ozzy47) are named extras for different slices. Moderator Panel by Andrew protects staff identities.
- Akismet is not core XF. Do not write it into a baseline.
- Discourse stock is TL0, watched words (block, censor, flag, replace), and the review queue. Diverse TL3 flags on TL0 can auto-silence. Do not invent a scoring formula.
- Turning the sandbox off is how you donate the queue to spam.
- The people articles remain #12 and #39.
Turn the gate on. Name the payload. Clean after you have decided. Leave the rest to a human who will still open the queue on a Tuesday.