Define the release you intend to ship
Record the source revision, artifact identifier and scope of the change. A release checklist needs a concrete target; otherwise, one person may review a preview while another uploads files from a later build. Note which routes and user tasks changed so verification can focus on real consequences rather than repeating an unrelated list from a previous project.
Check content and primary actions
Read the visible copy for accuracy and complete the main task. For a portfolio, open a project, use the contact path and download the résumé. For a utility, test a valid input and a useful error state. A button that looks clickable but has no working destination is a product failure even if every stylesheet compiled correctly.
Exercise navigation and layout
Open deep URLs directly, follow the breadcrumb and test the mobile menu with a keyboard. Inspect a narrow viewport for overflow, clipped labels and controls hidden by fixed elements. Check meaningful focus indicators and reduced-motion behavior. These tests should reflect the actual components being released rather than treating the homepage as a substitute for every interior layout.
Review one representative content addition
Suppose the release adds a new CSV-to-JSON tool. Confirm its directory card, detail page, instructions, example, download behavior and sitemap entry. Submit malformed CSV and verify the feedback. This small end-to-end slice catches several integration errors that isolated checks miss, including a correct tool implementation connected to the wrong route or an explanation of unsupported features.
Inspect technical delivery
Review document status codes, titles, canonical URLs, sharing images and expected indexing directives. Check that fonts, scripts and images load without missing-file responses. Confirm cache behavior for HTML and versioned assets, and retain the previous release. Avoid publishing credentials or private environment values while adding diagnostic output to investigate a last-minute build problem.
Repeat the critical checks after publication
Use the final public hostname and record the observed result of a few high-value checks. Include a deep route and one primary task, because upload success does not prove correct hosting configuration. If something fails, identify whether the issue belongs to the artifact, configuration or delivery layer. Mark the release verified only when the intended version and behavior are actually visible.
Further reading
Put the idea to work.
Explore free browser tools for images, text and developer workflows.