Proportionate optimisation, control 6 of 8
O-06 Limit rollout by real impact, not files or agent jobs
P0Hard gateNeeds your evidence
Every optimisation release must declare and verify its affected URL set and dependency reach. A single template file can affect many URLs. Pilot and expansion authority must come from a trusted parent ledger, not a renamed job.
- Priority
- Gate. A FAIL stops publish or launch.
- Hard gate
- Yes. A FAIL stops publication, whatever the score.
- Change class
- READ_ONLY: Inspect authorised evidence.
- Quality bucket
- Not scored: hard gate only
Evidence to review
- Impact manifest, trusted ledger/reservation, declared change surfaces, pilot artifacts, live validation and expansion assessment.
How to implement
- Separate deterministic, immediate validation from delayed search/business evaluation.
- Set a site-specific pilot scope, cumulative URL budget and revision/action budget before publication; choose representative templates and risk classes.
- Verify actual route, template, cache, feed and navigation effects; unknown material reach holds the affected release.
- Reserve the exact URL cohort against a trusted cumulative ledger before execution; retries and subagents share the same parent plan.
- Do not expose different content to bots to create a pilot. Use genuine scoped releases with consistent accessible content.
- Require a fresh evidence-backed expansion decision; a passed unit test or elapsed calendar day alone is insufficient.
How UltimateSEO checks this
Needs your evidence. No automated check covers this control, so it stays UNKNOWN until evidence is supplied.
States used: PASS, FAIL, UNKNOWN, NOT_APPLICABLE or BLOCKED. UNKNOWN is never shown as a pass. How states work.
Part of The UltimateSEO Framework v4.3, catalogue dated 2026-10-14. Evidence states, control states and the publish gate are explained on the hub.