Launch from the outside in.

Before the release window

• Write down the exact production URLs and the action each page must support.
• Choose a rollback trigger before publishing. Make it observable, such as repeated 5xx responses or a broken primary action.
• Keep a previous working artifact or version pointer. A rollback plan without a known-good target is only a hope.
• Confirm who makes the release decision and who owns the next check.

Check what visitors receive

Open the canonical HTTPS URL in a clean browser session. Follow redirects and record the final URL. HTTP semantics define 2xx responses as successful, but status alone is not enough: inspect the content and complete the page's main action.

• Load the home or landing page through the public hostname, not localhost.
• Open every primary navigation link and one deep link.
• Verify the page title, visible heading, canonical URL, and intended content.
• Test the contact, download, sign-up, or purchase path without submitting fake data.

Use a narrow screen and a keyboard

At roughly 390 CSS pixels wide, check for clipped text, horizontal overflow, blocked controls, and fixed elements covering content. Then use Tab and Shift+Tab. WCAG's focus-visible guidance explains why keyboard focus must remain visible while a person moves through controls.

Check discovery files

• Confirm the canonical URL uses the public hostname.
• Open robots.txt and make sure it does not accidentally block the release.
• Open the sitemap and confirm the canonical page appears once.
• Validate structured data as JSON and make sure claims match the visible page.

The sitemap protocol requires fully qualified URLs and XML-escaped data. A sitemap helps crawlers discover URLs; it does not guarantee indexing.

Leave a useful record

A release record should answer five plain questions: what URL was checked, when, by whom, what happened, and where the proof lives. Screenshots help with layout. Response headers help with status and caching. Keep both when they change the decision.