Recipe
The AI answer-engine readiness audit
Search now has two audiences. The first is a person scanning a results page. The second is an answer engine — ChatGPT, Perplexity, Google’s AI overviews, Claude — reading your post to extract a sentence it can quote. The two reward different things. A human forgives a buried answer because they’ll skim for it. A model often won’t: if the answer to the question your title poses isn’t near the top in plain, self-contained prose, the model summarizes a competitor instead and your traffic quietly leaks to whoever wrote more extractably. Most archives were written for the first audience and have never been checked against the second. This recipe scores every post for extractability, then rewrites only the ones that fail — so you spend tokens where they move the needle, not blanket-rewriting a working archive.
What you need
- Spectersync synced to your blog (Ghost, WordPress, Shopify, or Webflow)
- An AI assistant you already use
- 30 minutes to read the audit before you let it touch anything
The recipe
- Pull and stage. Run a Spectersync pull so every post is local Markdown, and commit a git baseline. Nothing is edited yet.
- Run the audit (read-only). The analyzer scores each post on the signals answer engines actually use: is there a direct answer in the first 150 words, are claims self-contained (no “as we said above”), are there scannable headings phrased as questions, is there a short summary or FAQ a model can lift. It writes one report — no files change.
- Triage by score. Sort the report worst-first. The long tail of already-good posts needs nothing. Pick the bottom 20–30% — that’s your fix list.
- Run the fixer on the fix list. It adds an answer-first opening line, a short “Key takeaways” summary, and a 3–5 question FAQ drawn from the post’s own content. It does not invent facts or pad word count.
- Dry-run and push. Preview every change as a diff with a Spectersync dry-run, accept what’s clean, and push back. Run it as a quarterly loop, not a one-off — new posts drift the same way.
The prompt
The auditor is read-only:
Score each post in this archive for AI answer-engine extractability. For every
post record: the primary question its title implies; whether a direct, self-
contained answer appears in the first 150 words (yes/no); whether key claims
can stand alone without prior context (yes/partial/no); whether headings are
phrased as questions a user would ask (count); whether a liftable summary or
FAQ exists (yes/no); and a 0–10 readiness score with the single highest-impact
fix. Output a table sorted by score ascending, then a summary of the most
common failure across the archive. Do NOT modify any files.The fixer touches only the posts you list:
For each post in the provided fix list, make exactly three additions and change
nothing else: (1) rewrite the opening so the first two sentences directly answer
the question the title poses, in plain self-contained prose; (2) add a "Key
takeaways" block of 3–5 one-line bullets after the intro; (3) add an FAQ of 3–5
questions with two-to-four-sentence answers, drawn only from facts already in
the post. Do not invent statistics, dates, or sources. Do not pad. Log each
post's before/after intro.Cost and time
| Blog size | Tokens (audit + fix) | Cost | Wall-clock |
|---|---|---|---|
| 50 posts | ~120k + ~90k | $0.60 | 25 min |
| 200 posts | ~480k + ~360k | $2.80 | 90 min |
| 600 posts | ~1.4M + ~1.1M | $8 | 4 hr |
The fix pass only runs on the ~25% you flagged, so its cost scales with your fix list, not the whole archive.
Pitfalls
- Don’t fix what isn’t broken. A post scoring 8+ rarely needs touching — rewriting it risks regressing a page that already ranks.
- Watch for invented facts. The fixer is told to draw only from the post; spot-check a few FAQs against the body before pushing.
- Schema is separate. Adding a visible FAQ helps models read the page; emitting FAQ schema (JSON-LD) helps crawlers parse it. Pair this with the schema injector for both.
Where to go next
Run the keyword cannibalization report next — once your posts are individually extractable, you want exactly one of them owning each query, not three competing.