Start with a real inquiry
Open the production website on a phone and act like a prospective customer. Find the relevant service, open a project, read an article, and send an approved test inquiry. Record what happened at each step. This simple walkthrough reveals a class of problems that a beautiful homepage screenshot cannot: dead links, buried contact details, clipped buttons, and submissions that go nowhere.
Follow the inquiry past the success message. Confirm that the owner can retrieve the exact information submitted and that any promised notification arrives. A form that saves a record but sends no email can still be a valid design, provided the owner knows where to check. The requirement is an understood, functioning process. Remove clearly labeled test records when verification is complete.
Check mobile behavior, not a smaller screenshot
Use a narrow screen to open and close navigation, reach every submenu, complete the form, and read long article content. Look for horizontal scrolling, text hidden behind sticky controls, and buttons crowded together. Rotate the device if your audience is likely to do so. Also test at a wider desktop size, where a layout can become stretched or awkward in a different way.
Then put the mouse aside. Move through links and controls with the keyboard and check that the focused item is visible. W3C’s preliminary accessibility checks include keyboard access, headings, alternative text, and form labels. These checks help expose obvious issues, but they are not proof of full accessibility conformance. Record what was tested and any remaining limitations rather than calling one automated scan a complete audit.
Reference: W3C WAI: Preliminary accessibility checks (opens in a new tab)
Read speed reports in context
Run a performance test on the homepage and on a representative article or service page. Those pages may use different images, layouts, and scripts. Note the test conditions and repeat an unexpected result before making a decision from it. A score is a way to find problems; the purpose is a page that loads, responds, and stays visually stable for visitors.
Google’s Core Web Vitals guidance uses Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. The good thresholds are at most 2.5 seconds, 200 milliseconds, and 0.1 respectively, assessed at the 75th percentile of page visits. Lab tests help before launch, while field data describes actual visitors. A Lighthouse run cannot by itself prove that a new site passes all three for real users.
Reference: web.dev: Core Web Vitals and measurement (opens in a new tab)
Make rejection part of the form test
Try an empty required field, an invalid email format, and a message longer than the allowed length. Check that the error identifies the problem and lets the visitor correct it. If the connection fails, the interface should not claim success. Ask the developer to explain what is validated on the server and how repetitive unwanted submissions are handled.
OWASP recommends validating input on the server because checks in the browser can be bypassed. Validation should cover both expected structure and the meaning required by the application. It is one layer of protection, not a substitute for safe output handling or access controls. For the owner, the practical acceptance check is that malformed requests are rejected without exposing internal details or damaging stored data.
Reference: OWASP: Input validation cheat sheet (opens in a new tab)
Inspect the routes people already use
Open a selection of existing bookmarked URLs and any destinations used in current campaigns. Check the page title, primary heading, contact links, and the final address after any redirect. Confirm that the preferred domain uses HTTPS and that the alternate hostname behaves consistently. Open a deliberately nonexistent address too: a useful missing-page screen should let someone recover.
Review the sitemap and indexing settings with the person responsible for search visibility. A staging restriction should not accidentally follow a public page into production. Keep the release inventory small enough to inspect, but cover every unique page type. If there are many articles or products, combine automated link checks with manual reviews of representative pages and unusual content.
Finish with ownership and recovery
The handover should identify the domain account, hosting account, content login, inquiry inbox, backup location, and person responsible for updates. Store credentials in an appropriate password manager rather than a public document. Ask for a short demonstration of an ordinary edit and a documented route for restoring the site if a release breaks it.
Finally, write a launch record: what was released, what was tested, what remains limited, and how to roll back. A backup file is less convincing than a successful restore check. Decide how issues will be reported and who checks the site after release. The finish line is a working website with an owner who can operate it, supported by evidence that the important journeys actually work.
