Skip to main content

​
Overview

The Site Diagnostics API is the page-level view behind Site Optimization. For each audited path it returns the page’s AI-visibility scores, the opportunities still open on it, and what it already does well. A second endpoint opens one page’s most recent optimization run — the block-by-block rewrite Scrunch generated for it. Where the Opportunities API ranks work by type across the brand, this API answers the same question one page at a time.

​
Endpoints

All three require a bearer token. The apply endpoint requires the optimize scope; the reads require query. See Authentication.

​
Example request

​
Reading the fields

Three things are easy to get wrong.
path is required on the optimization endpoint. Calling GET /site-diagnostics/optimization without it returns 422, not an empty result — there is no “all pages” form of that request. The list endpoint is the opposite: path is optional there, and omitting it pages through every audited path.
Apply records a decision; it does not publish anything. POST /optimization/apply is for changes made outside Scrunch — in your CMS, say — so that a run which will never go through Scrunch review is not left looking outstanding. It writes the acknowledgement and returns the run; it does not deploy, and it does not edit your site. Send exactly one of approve_all: true or a reviews list of per-block verdicts keyed by chunk id. Only reviewed runs come back by default. The optimization endpoint returns runs a human accepted — completed, staged, deployed, acknowledged — and hides raw unreviewed output. Pass status explicitly if you need to see a run that nobody has looked at yet.
Paths are matched exactly, including the leading slash. ?path=/about and ?path=about are not the same request, and the second matches nothing.