Web release
review checklist.

Paste a nested page URL into a new tab, then reload it. Confirm the intended page loads without visiting the homepage first. Follow its main navigation links and check their destinations.

Open a list, apply a filter, visit a detail page, then use Back and Forward. Compare the restored URL, filter, selection, and scroll position with the intended behavior.

In a test environment, open a route known not to exist. Confirm the page explains the problem, provides a working way onward, and returns the intended missing-page status rather than an ordinary success response.

For a public page, inspect its title, description, and canonical URL in the delivered HTML and rendered page. Confirm they describe this page, agree with each other, and use the intended public hostname. Open the canonical destination.

For a page intended for search, inspect robots.txt, robots meta tags, and X-Robots-Tag. Check that no rule unexpectedly blocks crawling or indexing. Follow a real HTML link to the page; verify the public sitemap, if provided, lists the intended canonical URL.

Submit a required field empty and a constrained field with an invalid sample value. Check that the error identifies the field and correction, valid input remains available, and correcting the problem allows the intended next step.

Use an existing test fixture or network throttling to slow the relevant request. Then load a known empty fixture. Confirm pending work is distinguishable from a completed result with zero items.

In staging, use a documented failure fixture or block the relevant request. Attempt the action, restore normal conditions, and retry once. Check that the error explains a useful next step and the result agrees with the stored state.

With a sample record and a deliberately slow staging response, activate the same submit action twice. Check the request sequence and resulting records against the product’s intended duplicate-handling behavior.

Put the pointer aside. Complete one core journey with Tab, Shift+Tab, Enter, Space, and the keys appropriate to any widgets. Check that the required controls can be reached, operated, and exited.

Tab through the journey and any menus or dialogs. Check that the focused control remains visible, focus moves in a useful order, and closing a dialog returns it to a sensible control.

With a screen reader, trigger a loading message, a validation/result update, and completion without moving focus to the message. Check which meaningful updates are announced and whether repeated announcements become disruptive.

Test a 320 CSS-pixel viewport, then separately enlarge text to 200% in a browser that supports text-only zoom. Read the main content and reach the primary action. Check for clipped text, overlaps, and lost controls.

On a real touch device, use the main navigation, neighboring buttons, and any menu close control. Check for mistaken activation and functionality that is available only when hovering.

Focus the last field of a sample form on a phone. Enter a long sample value, correct it, and reach submit while the keyboard is open. Repeat in landscape if supported by the product.

After the staging deployment, repeat a direct load with an empty browser cache, an ordinary reload, and a return visit through browser history. Check for missing scripts/styles and mixed old/new UI. Confirm the intended build where the product exposes a build identifier.

If monitoring exists, trigger one documented, harmless staging error using sample data. Locate the corresponding event and any configured alert. If there is no monitoring, record that gap instead of marking the check passed.

In staging, restore the recorded previous release using the documented rollback procedure. Verify its build and repeat the primary sample journey, including any data compatibility checks required by the change. Restore the candidate only after recording the result.