You do not need to test every technical detail yourself to catch the failures most likely to affect a service business. Ask the builder for its technical QA record, then run a short buyer-side check through the paths a prospect would take. Use the actual agreed scope as the standard; this checklist does not add excluded features to the contract.
1. Can a stranger understand the offer?
Open the site without using the navigation menu. On the homepage and an important service page, can a visitor identify the service, who it is for, the area served, and the next step? Check that prices, credentials, guarantees, and turnaround statements are approved by the business. A visually complete page can still carry placeholder or inaccurate copy.
Ask someone unfamiliar with the project to describe what they would do next. If they cannot find a relevant service or action, note the exact page and wording that caused confusion. That is more actionable than a general request to “make it clearer.”
2. Does the core path work on a phone?
Use an ordinary mobile device, not only a shrunk desktop browser. Check the menu, service-page text, buttons, phone links, and form fields. Try the page with a slower connection if possible. Look for content hidden behind sticky elements or controls too close to tap comfortably. The W3C form guidance offers practical checks for labels and errors.
3. Does an inquiry arrive and get owned?
Submit a test inquiry. Confirm the on-screen success message, the destination inbox or CRM, any acknowledgement, and the person who will respond. If calls are the main action, tap the number and confirm it dials the right business line. If bookings are external, follow the link through a test booking or the furthest safe step allowed.
4. Are the business facts correct?
Review staff names, service areas, contact details, operating hours, policies, and legal disclosures against an approved source. Click navigation and footer links. Check the privacy page if a form collects personal information. A business owner or delegated subject expert should sign off on these facts; a designer cannot verify them by appearance.
5. Do important old paths survive a redesign?
If existing URLs changed, test the old links used in ads, email signatures, profiles, and search results. They should reach relevant new pages, not a generic error. Google’s site-move documentation explains why URL mapping, redirects, and updated internal links matter. If this is a new site with no old URLs, mark the check not applicable.
Record each failure with the page URL, device, expected result, actual result, and owner. Retest after correction and once more on the live domain. ARCHV’s website process says agreed pages, links, forms, and mobile layouts are checked; the exact migration and integration work must be in the proposal. Use the website estimate if you are still defining a new project.
Have someone who did not help build the site run this checklist. The project team may know where everything is and unconsciously navigate around a weak path. Give the reviewer a simple task such as “find the service for a local business and request a quote,” then watch where they hesitate. Record observations as evidence for a specific correction, not as a claim that the entire design has failed.