The thin content auditor

Thin content drags your whole site down. Google increasingly judges quality at the site level, which means a few hundred weak posts can quietly suppress the rankings of your good ones. Every blog accumulates them the same way — old launch announcements, abandoned series, commodity “what is X” pages, AI filler from a couple of years ago. You can’t fix what you haven’t measured, and manually auditing five hundred posts is a week of work nobody schedules. This recipe does the measuring in an hour and hands you a decision document you’ll actually use. It’s read-only by design: it changes nothing, it just tells you the truth about your archive.

What you need

• Specter synced to your blog
• An AI assistant you already use
• Optional but recommended: a Search Console pages export (last 90 days)

The recipe

1. Pull. Run a Specter pull so every post is a local markdown file.
2. (Optional) Drop in Search Console data. Export Performance → Pages → last 90 days → CSV and save it alongside the posts. The recipe works without it but is far sharper with real impressions and click-through in the mix.
3. Run the auditor. Paste the prompt below. It writes a single CSV and touches no post.
4. Review the CSV. Sort by recommendation and add your own decision column — the model’s call is a strong first draft, not a verdict.
5. Execute the decisions through the follow-on recipes (below). There’s no push step here — this pass is read-only.

The prompt

You are auditing a blog for thin content. Read every .md file in this folder.
If a Search Console pages CSV is present, read it too (clicks + impressions,
last 90 days).

For each post, evaluate these THIN signals:
1. Body word count < 500.
2. No internal links AND no external links AND no images.
3. Last meaningful update > 18 months ago.
4. Formulaic title ("What is X?", "Top 5 X", "X vs Y" with no clear winner).
5. GSC impressions < 100 in 90 days (if data available).
6. GSC CTR < 0.5% on a page with > 1000 impressions (if data available).
7. Body reads as AI padding — vague, no specifics, no examples.

Output one CSV row per post: slug, title, word_count, last_updated,
gsc_impressions_90d, gsc_clicks_90d, gsc_ctr, thin_signals (matching numbers),
recommendation (keep | rewrite | merge_into:<slug> | delete), reasoning (one line).

Logic: 0 signals → keep; 1–2 signals with impressions > 500 → rewrite;
3+ signals with impressions < 100 → delete; clear overlap with a stronger
post → merge_into that slug; otherwise default to rewrite (action over deletion).
Any merge target must be a post that exists here — verify before writing the row.

Do NOT modify any files. This is a read-only pass.

Cost and time

Pitfalls

• Don’t auto-execute. The output is a CSV, not an action, on purpose. The human decision step is non-negotiable — a “delete” call can be wrong for a page that just earned an important backlink.
• Old posts with backlinks. Always run a backlink check before deleting. Even a thin page with a handful of referring domains is usually worth rewriting, not killing.
• Search Console lag. A rising post can look thin on 90 days of data. Pull twelve months for anything published in the last six.

Where to go next

The CSV becomes your quarter’s work plan. Feed the rewrite rows into GSC-driven rewrites and the delete rows into kill 100 pages, which generates the redirect map so nothing 404s. Run the three together quarterly and your archive never silently rots.