A website can look finished while still containing a sample phone number, an untested form or a link to an old page. The last review before launch should follow what a customer will actually do, not just admire the design.
Keep a written checklist and record who checked each important item. For a small site, this can be short. What matters is that the business owner verifies the facts and the person building the site verifies the agreed functions.
Read the business details out loud
Check the business name, phone number, email address, services and service area. Compare them across the header, footer, service pages and contact sections. Reused components help consistency, but a single wrong value can also repeat everywhere.
Look for sample content that survived the design process: stock testimonials, placeholder prices, unfinished captions or a contact address belonging to the designer. Remove anything that is not accurate and approved. A demonstration project should be labeled clearly wherever it appears.
Review claims about qualifications, insurance, warranties and availability with the person who can confirm them. Do not launch an attractive statement simply because it was included in a template. The public page needs to describe the actual business.
Use the site from a customer's starting point
Visit an important service page directly, without first opening the homepage. Can you tell whose site it is, what service is described and how to get in touch? Search results and shared links often bring people into the middle of a website.
Check navigation on a phone and a larger screen. Open and close the menu, follow service links and use the back button. Look for text that gets cut off, controls that overlap and fixed panels that cover the content. Test with ordinary zoom and larger text settings where practical.
Try moving through important controls with a keyboard. Visible focus, understandable labels and sensible reading order make the site easier to use. This practical pass is useful, but should not be represented as a complete accessibility certification.
Verify each contact method
Tap call and email links and inspect the destination. For a form, check required-field behavior and the confirmation message. If a submission test is authorized, use clearly identified test information and confirm that the person responsible actually receives it.
Know which system holds the inquiry and what happens if a notification is delayed. A successful on-screen message does not prove an email arrived. Document what was verified and what remains outside the test, particularly when an external provider is involved.
Read the wording after submission carefully. It should not say an appointment is booked if the form only requests contact. An intake assistant should explain whether information is being collected, reviewed, saved or sent, matching its actual behavior.
Protect the useful parts of the old site
For a rebuild, list important existing page addresses before switching. Keep them working or provide appropriate redirects to genuinely relevant replacements. Sending every old page to the homepage can leave visitors looking for the information they expected.
Check page titles, descriptions and canonical addresses for the intended public domain. Remove temporary preview labels. Make sure navigation and image paths work on the published address rather than only inside the developer's preview.
Keep a recoverable copy of the previous version and know how a failed launch would be reversed. Confirm domain and hosting responsibilities without casually changing unrelated account access. A routine website launch should not become an unplanned migration of the business's email or other services.
Agree on the first days after launch
Decide who will check the live site, review inquiries and receive reports of problems. A final preview is valuable, but the published address should still get a focused check. Note any agreed follow-up period and what kind of corrections it covers.
Give the owner the information needed to maintain the site: where it lives, who controls the domain, what costs recur and how to request or make routine updates. Transfer access through appropriate secure methods rather than putting credentials in a handoff document.
Do not call a function tested if it was only looked at. A launch record can say “contact link checked; inbox delivery not tested” and remain useful. Honest limits make the next check easier. For a focused review before release, see what a useful website review should include.
For the service behind that review, see Frisk Digital’s website check process. The agreed scope should state what will and will not be tested.