Editor's Summary

Signed-in audits get an editor’s summary at the top of the report: a couple of plain-English paragraphs on the state of the site and a one-line verdict, followed by a ranked Priorities list of what to do next. Think of it as the quick note you’d email a manager: the bottom line, then the to-do list, not a wall of checks.

It’s generated automatically for every signed-in cloud audit, except a run started with a rule filter (see Filtered runs), like the site profile and technology detection) and is informational: it never affects your health score.

What it looks like

EDITOR'S SUMMARY
Auto-generated editor's summary - informational, not scored.

The site is in solid shape overall, with clean security headers and
fast core pages. The drag is mostly in links and images, plus a slow
first byte on every page.

Nothing here is structural. These are fixes that, cleared, would make
it a healthy site. This audit scanned 100 pages and stopped at its
page limit of 100, so it may not cover the whole site; raise the audit
level or the page limit to audit more pages.

Verdict: Healthy site; cache the pages and clear the links and images.

PRIORITIES
  1. Cache pages at the server (Quick win)
     Every page waits on the origin, so first byte is slow site-wide.
     Install a page caching plugin for WordPress and turn on page caching.
  2. Fix the broken internal links (Quick win)
     Three links on the blog index point at removed posts.
     Update or remove the links in the blog index template.
  3. Add alt text to images (Moderate)
     Fourteen images have no text alternative.
     Add alt text in the WordPress media library, starting with the homepage.

Each priority has a short title, why it matters for this site, the concrete action and an effort rating (quick win, moderate or significant). When the audit detected the site’s platform, the action says where the fix is made on that platform: the theme, plugin, app, setting or build step.

The summary and the Priorities section appear at the top of every output format (console, HTML, Markdown, JSON, XML and LLM) and in the dashboard audit detail. In JSON they are editorSummary, with the ranked list in editorSummary.priorities. Reports from before priorities existed show a point-form list of big-ticket items instead.

What goes into it

One model pass over the audit aggregate, never your raw pages:

• Overall and per-category health scores
• The highest-impact issues, ranked, plus the ids of every rule that failed or warned
• Counts of passing, warning and failing checks
• The technologies the audit detected, so the advice fits your stack
• Deltas vs. the previous audit when one is available (“score up 7 since last run”); it falls back to a first-run framing when there’s no prior audit
• The resolved site profile for context (site type, audience, identity)
• Coverage: how many pages the audit scanned, the page limit, whether the crawl stopped on time, and how many pages are known on the site

Each priority lists the checks and detected technologies it is based on, so you can trace it back to the findings in the report.

How the text is checked

The model writes the prose, so the numbers in it are checked against the audit:

• Scores read as words. The summary says what scores mean (“healthy overall; accessibility is the weak spot”) and uses at most one numeric score. /100 never appears.
• Page counts are the audit’s own. A sentence that states a page count the audit never reported is left out, so the summary cannot invent “400 pages” or “0+ pages”.
• A partial audit says so. When the crawl hit its page limit or ran out of time, the summary says how much it covered and how to audit more pages (see Audit levels).
• Never blank. If no sentence passes, the summary falls back to the audit’s own totals.

Reports apply the score and page-count checks when they render, so summaries stored before these checks existed read the same way.

Filtered runs

A run started with a rule filter (enabledRulePatterns on POST /v1/agent-runs, rules on the MCP run_audit) skips the summary by default. Send editorSummary: true (MCP: editor_summary: true) to bring it back, or false to skip it on any run. The default is the same everywhere: no filter means built, filter means skipped.

Why skip it: it is about 30 seconds of a one-page run, and it describes a whole audit, which a filtered run does not have.

When it is skipped, the report has no editor’s summary (the field is absent), the run timeline shows editor_summary skipped with the reason (rule-filtered run or disabled by the run config), and no credits are charged or refunded, because the summary has no credit price either way. It never affects the health score, built or skipped.

Requirements

• Plan: any signed-in account (free or Pro). Only anonymous runs skip it.
• Cost: included in the audit base charge, no separate charge. See Credits & Pricing.
• Config: on by default for logged-in users. Turn it off per project:

[cloud]
editor_summary = false   # skip the editor's summary for this project

Like all cloud features, it never fails your audit: if you’re logged out or out of credits, the summary is simply omitted and the rest of the report is unaffected.

Related

• Cloud overview: what cloud features add
• Credits & Pricing: pricing and spend controls
• Site metadata: the site profile the summary draws on
• Technology detection: the stack the priorities are written for