What a collection report covers
A website impact report freezes published collection content and the proposed result of a ready release. Your website renders these snapshots. The proposed side uses the release engine inside a rolled-back transaction: capturing does not publish or send webhooks. REST, GraphQL, RPC and client reads work without registering any website.
How to use it
- Prepare a ready release containing the exact saved entry, translation and media actions you intend to evaluate.
- Choose a configured destination and one language. Inspect its collection and ID-based entry routes, including changes caused by references or media.
- Use your website's comparison renderer to inspect both snapshots at desktop and mobile sizes. The Astro journal is an optional reference implementation.
Good practice
- Read coverage notes and unmapped-item warnings before treating the route list as complete.
Avoid
- Coverage is limited to 25 published entries, a six-entry first collection page and four latest items, with an optional descending sort field. Slug-based routes, additional queries/pages, interactions, live remote values and automated screenshot analysis need separate checks.
Configure your website renderer
This is an optional integration. The Owner chooses a content type and language, relative collection and entry routes, and a renderer SHA-256 revision. Any server framework can implement the preview exchange and comparison payload contract; no website source code is uploaded to the CMS.
How to use it
- Implement the server-side preview exchange and frozen comparison renderer on your website; keep its environment credential private. Ordinary SDK draft reads do not require this integration.
- In Workspace settings → Website preview, choose any content type. Enable website impact review and enter paths such as /products and /products/{id}. Only {id} substitution is supported.
- Optionally choose a sortable field for the four latest items. Leave it blank to use the normal collection order. No title, date or body fields are required.
- Hash your rendering inputs with SHA-256; configure that revision in the destination and have the website verify it. Update both and capture a new report whenever the renderer changes.
Good practice
- Use the exact code running in the consuming website, not an unrelated branch's hash. Hash inputs exclude secrets and build output.
Avoid
- A mismatched renderer fails closed. The Owner's configured hash is a declared renderer identity, not independent proof that an external deployment is trustworthy.
Capture and review before/after routes
Website review is separate from publishing readiness and entry approval. It records a human's checks, not an automated judgment of visual quality.
How to use it
- Open a ready release, choose the destination and review language, and select Capture website comparison. An exact-language destination overrides its all-language default.
- Open Before & after. The site starts a private session lasting up to ten minutes; secrets stay in its HttpOnly cookie/server configuration.
- Choose each affected route, select Desktop and Mobile in turn, and compare both sides. Use actual size for fine details; fit mode scales the fixed viewport frames to your screen.
- Return to the studio, check Reviewed desktop and Reviewed mobile for each route, acknowledge the coverage limits and Record website review.
- Decide separately whether to publish or schedule the release through its normal controls.
Good practice
- Check missing pages, text wrapping, image crops, references and language. Reopen a fresh session if cookies are blocked or it expires.
Avoid
- Do not check a viewport you did not inspect or claim the comparison tested navigation; links inside frozen views are intentionally disabled.
Keep revision-bound receipts meaningful
Reports retain immutable before/after content, routes, source/model versions, release version, language and renderer identity. Human review stores its actor and timestamp separately.
How to use it
- If source content, model/policy, destination settings or the release changes, read the Stale indicator and capture a new report.
- The private session rechecks current actor permissions, application-token scope and source freshness on every read; revoked access cannot keep reading a frozen report.
- Keep up to three reports per release and fifty per environment. Remove unneeded reports to free capacity; their preview sessions end.
Good practice
- Keep historical receipts as evidence of the specific revisions reviewed, and repeat review after a change.
Avoid
- A receipt is not a screenshot archive, a production monitoring service or authority to bypass approvals. Publishing a release makes its pre-publication comparison historical.