# Reader-facing copy guardrails (blog)

**Last Updated:** 2026-03-24

## Purpose

Research and planning language (tools, SERP mechanics, outline filenames) must stay in **documentation and data files**, not in text that readers see in the browser.

## Where research lives

Keep methodology notes, evidence tables, PAA ids, and tool references in:

- `docs/content/blog/posts/{category}/{slug}/` — e.g. `SERP_ANALYSIS.md`, `CONTENT_OUTLINE.md`, `KEYWORD_DECISION.md`, `data/*.json`
- Internal reports under `docs/content/blog/reports/` when applicable

## What must not appear in reader HTML

Do **not** use these in `content-draft.html`, live post `content.html`, or **reader-facing** FAQ answers (unless the article is explicitly *about* SEO tools and the term is necessary — still avoid vendor/tool proper nouns in running prose):

- Labels such as **PAA**, **People Also Ask**, **SERP**, **SISTRIX**, **GSC**, **Firecrawl**, **Serper**
- Filenames or artifacts: `CONTENT_OUTLINE`, `SERP_ANALYSIS`, `KEYWORD_DECISION.md`
- Process framing like „**Suchanfragen** …“, „in den **SERPs**“, „**Tools und Cluster**“ (internal taxonomy), „Suchmaschinen und HR-Teams“ as meta-commentary

**Exception (product UX):** On the Jobbörse lexikon page, „Suchanfragen speichern“ describes a **user feature** (saved searches), not SEO — allowlisted in validators.

## What to write instead

- Answer the **question** in natural German („Häufig wird gefragt, ob …“, „Viele Leser vermischen …“, „Formulierungen wie …“).
- Use **outline Evidence rows only in the outline**; in the article, publish the **answer**, not the research label.

## Automation

| Check | Command |
|--------|---------|
| Repo-wide JSON (optional drafts) | `php v2/scripts/blog/validate-reader-facing-copy.php` / `--include-drafts` |
| Markdown + CSV report | `python3 scripts/blog/scan-reader-facing-meta-language.py` |
| CI | `make validate-blog` (includes reader-facing validator on live JSON) |

Exit codes (`validate-reader-facing-copy.php`): **0** = no hard violations; **1** = hard pattern in body/FAQ; **2** = soft only with `--fail-on-soft`.

## Alignment with helpful / people-first content

Search quality guidance consistently stresses **people-first** writing: satisfy the reader’s intent in clear language rather than describing rankings, tools, or query mechanics. Use that as the editorial bar; avoid claims about specific ranking algorithms. Official overview: [Creating helpful, reliable, people-first content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) (Google Search Central).

## See also

- [CONTENT_FLOW_GUIDELINES.md](CONTENT_FLOW_GUIDELINES.md)
- [KEYWORD_RESEARCH_WORKFLOW.md](KEYWORD_RESEARCH_WORKFLOW.md)
- [SISTRIX_CONTENT_INTEGRATION_GUIDE.md](../SISTRIX_CONTENT_INTEGRATION_GUIDE.md) — using data internally vs reader prose
- [posts/_templates/CONTENT_OUTLINE.md](posts/_templates/CONTENT_OUTLINE.md)
