Report Design Philosophy

The biggest failure mode in SEO audits is writing a document that reads like a complete inventory of everything found. That produces “overwhelm syndrome” — the client sees 50+ findings, feels unable to start, and shelves the report.

The goal is a document that reads like a decision memo: here’s what matters most and why, here’s what to do first, here’s everything else if you need it.

1. The executive summary opens with the reframing finding

Most SEO executive summaries summarize what’s in the report. That’s the wrong job. The executive summary should do one thing: reframe the client’s assumptions about their own situation.

A good executive summary:

  • Opens with 1-2 findings that change how the client thinks about the problem
  • States what’s working first, briefly (establishes credibility)
  • Identifies the 2-3 findings that carry the most weight on everything else
  • Ends with a realistic net expectation for 90 days with honest hedges

What to avoid:

  • Starting with methodology or scope (belongs in appendix)
  • Listing all findings as bullets
  • False precision (“rankings will improve 30-40%”)
  • Burying the most important finding

2. The 90-day plan is the spine of the report

The 90-day execution plan should appear on page 2, immediately after the executive summary. A good plan:

  • Uses actions, not findings. “Fix the Thrive pagination bug” not “pagination 404s were found”
  • Groups by realistic execution window: Week 1, Month 1, This Quarter, and Deprioritized
  • Includes a “Deprioritized for now” row. Naming what is NOT being done is as useful as naming what is
  • Has no owner column. The tool doesn’t know the client’s team — a wrong “Dev/IT” label costs more credibility than it adds; effort size signals self-serve vs. developer task
  • Cites item numbers. Cross-references to the detailed recommendations section
Write the 90-day plan before the individual recommendations. If you write all 50 recommendations first and then try to distill them, you'll produce a plan that's just a shorter version of the full list. Writing the plan first forces genuine prioritization.

3. The appendix is for noise, not just overflow

The main report should contain only what informs a decision. Everything else — comprehensive findings, exploratory frameworks, detailed playbook templates, items deferred until more data is available — belongs in an appendix.

The test for what goes in the main report: would a decision-maker reading this section change what they do or how they prioritize? If yes, it’s main report content. If it’s documentation of process, completeness, or exploratory analysis they might want later, it’s an appendix.

4. Confidence calibration

Three patterns to watch for:

  • Don’t cite unofficial thresholds as if they were Google specifications. State the principle without false precision.
  • Use “consistent with” for patterns you can’t confirm. “This pattern is consistent with AI Overview suppression” is accurate. “This is AI Overview suppression” is a causal claim you cannot make.
  • Soften absolute schema claims. “The schema fails validation, likely preventing eligibility for rich results” rather than “Google rejects the entire JSON-LD block.”

5. SXO and drift findings — shape, placement, and supersession

When SXO findings reframe an existing audit recommendation:

  1. Tag the affected item with *(revised YYYY-MM-DD per SXO analysis)*
  2. Rewrite the actions to reflect the SXO-correct strategy
  3. Preserve the original reasoning prefixed with **Original recommendation (now superseded):**
  4. Update the exec summary opener sentence if the SXO finding reframes one of the reframing findings
  5. Update Top Revenue Opportunities row if applicable

6. Verify time-sensitive claims before delivery

Run claim-check on the final draft. It supports fact-checking, content freshness review, and SEO report QA by flagging prices, statistics, versions, product limits, deprecated features, search-engine claims, and missing or old verification dates.

For each finding, consult the primary source and record the URL and date actually checked. Confirm, correct, or remove the claim. Keep verification notes in skills/claim-check.md under the client audit folder, and put citations beside the claims they support in the report. Never add a checked-on date without checking the source.

The script identifies candidates for review; it does not browse the web or decide whether a claim is true. A clean scan is not a substitute for reviewing the evidence. Install instructions · GitHub source.