Post-Publish Verification: Compare the Public Page with the Accepted Draft

Define the release and its acceptance rules before publishing.

Keep the URL, release ID, content version, environment, UTC deployment time, accountable release owner, accepted draft and previous recoverable state together. Record who can repair or restore the release, which dependencies change with it, and which failures stop the release. A checklist without this baseline cannot show if the public result is the intended result.

The MIRENA source method uses six record groups: release identity; technical and rendered state; user and measurement state; disposition; evidence and scope; owner and next route. Use these as a practical record structure, rather than a score that lets a serious failure disappear among passing checks.

Choose thresholds for the specific release. For example, an incorrect main destination, exposed private material, missing required answer or unusable required function can require immediate withdrawal or restoration. A minor spacing issue may allow a bounded repair. State the allowed repair window, fallback and responsible person in advance; the example below uses an invented ten-minute window, not a universal standard.

Fetch the public response in the intended access state.

Open the canonical public URL while logged out. Record the requested URL, final URL, redirect chain, HTTP response, timestamp and relevant cache or consent state. Check that the response contains the intended page, not a login screen, challenge, stale revision or error body served with a success code. If different public cache states apply, inspect them deliberately and name the ones not checked.

Inspect canonical, robots directives, title, description and planned sitemap membership against the accepted release. A CMS preview, authenticated API body or local HTML file is a different surface. A correct source response does not establish the appearance or behavior of the rendered page.

Google’s HTTP status guidance distinguishes successful responses from errors. A success response does not guarantee indexing. Its Search overview separates crawling, indexing and serving; immediate release acceptance cannot certify those later outcomes.

Compare content and user paths in the rendered page.

Compare the public title, headings, required answers, examples, tables, warnings and next actions with the accepted draft. Check if the stylesheet, template, cache or consent state changes their visibility. Inspect image loading, meaningful alt text and dimensions; check downloads and embedded resources when they are part of the release.

Follow the main parent, sibling, support and conversion routes to their real destinations. A link with a plausible label can still lead to staging, an obsolete URL or the wrong task. Include contextual incoming links from the hub: an isolated published page may be technically available but absent from the planned reader path.

Check the relevant desktop and mobile layouts, keyboard navigation, focus visibility and required functions. Record browser, viewport, access state, observed result and evidence reference. Source inspection can find an image URL or heading; it cannot prove keyboard operation or visual readability. An unperformed check remains unknown, even if adjacent source checks pass.

Inspect machine-readable output against the visible page.

Inspect the final public metadata and combined structured data, including output contributed by the native template or plugins. Check page identity, canonical addresses, types, names, dates and linked entities against visible content and the accepted record. Detect duplicate or conflicting nodes rather than adding another block to hide the conflict.

Google’s structured data policies require relevant, truthful content and feature-specific rules. Use the appropriate current tests for the vocabulary and supported feature. A syntax pass does not prove factual accuracy, eligibility or a search appearance.

Record the tool, tested URL or code, date, errors and warnings, and what the test cannot establish. Do not label an unsupported feature as a failed release solely because it produces no enhancement. Keep a valid visible explanation even when no search feature applies.

Worked release record: accepted draft, defects and later checks.

The entire scenario below is fictional: example.com, release IDs, people, timestamps and observations are populated teaching records, not a Semantec publication receipt or real browser test. The page explains an evidence intake task. Release owner Rina owns the decision; Dev owns template and asset repairs; QA owns public rendering and input checks; Analytics owns the consent-aware event check.

At 09:50 UTC on 23 October 2026, accepted draft D2 specifies title “Evidence intake”, a complete three-step method, image /media/intake.webp, canonical https://example.com/docs/intake/, parent /docs/ and main link /start/. The page has no enquiry form or download, so those checks are recorded not applicable with that reason. The release requires a start-link event, and its absence is a hold until checked.

The saved editor revision at 10:00 is not the release acceptance. The immediate fictional public response and desktop observations identify an incorrect canonical, missing image and staging destination. The staging destination crosses the predefined blocking threshold. The owner restores accepted D1 at 10:06, verifies the restored public path, and sends D2 for repair rather than leaving the failing version under passive monitoring.

After Dev prepares D2.1, QA checks the changed public response and desktop display at 10:22 and 10:25. This is a bounded recheck of the repaired items, not a claim that every user path passed. Mobile, keyboard and the consent-aware event remain unknown; Rina keeps D2.1 held from final release closure and assigns the next checks at 10:30.

Hand over a dated baseline and a monitoring plan.

Once all required release checks pass, record the final version, public evidence, exceptions accepted by the responsible owner and next review time. Monitoring then asks different questions: if failures recur, access changes, content drifts, routes break or required events stop appearing. It does not replace the immediate public smoke test.

Name each signal’s source, scope, collection delay, owner and action threshold. For example, monitor public errors and broken required routes separately from later Search Console observations. Analytics events depend on the agreed event definition, consent state and collection behavior; an unobserved event is not automatically zero activity or proof of a broken release.

A later ranking, indexing or conversion change needs its own scoped analysis. This page verifies released output; it does not establish an experiment’s causal effect. Keep the prior version and restoration instructions available until the release’s recovery requirement is met.

Close, repair, hold or restore with a named owner.

Use pass only for the checks actually performed within their declared scope. Use repair for a bounded defect with a safe correction and retest; hold for missing evidence or unresolved dependencies; restore or withdraw when the blocking threshold and recovery plan require it. Repeat the affected checks after correction and broaden the recheck when a shared template or dependency changed.

Carry forward the release identity, expected result, observed result, evidence location, severity, owner, decision, recovery version and next verification time. Preserve earlier failures instead of overwriting the record with the newest pass.

Return to maintenance and refresh decisions or the learning overview. Use experiment guardrails when the next task is to assess an effect rather than verify the released page.