A website launch should be an evidence-based handoff, not a moment when a project team hopes every page works because the homepage looks finished. An acceptance test gives the owner, editor, and builder a shared definition of what has been delivered. It also distinguishes a true defect from a request that changes the original scope.
Create a launch register
Build one row for every required public page, route, form, integration, and account handoff. The register should have an expected result, tester, date, evidence location, and result. It is not necessary to turn a simple five-page site into a software release program. It is necessary to make important promises testable.
| Item | Expected result | Evidence |
|---|---|---|
| Canonical homepage | Loads at the agreed public address | Recorded URL and date |
| Service page | Accurate approved content on phone and desktop | Owner approval |
| Inquiry form | Controlled test reaches agreed destination | Browser and recipient confirmation |
| Navigation | All promised destinations are reachable | Link check results |
| Account handoff | Business knows owner and recovery route | Secure internal register |
Test the public experience
Use a normal browser session rather than an editor preview alone. Check the current page titles, links, images, basic mobile layout, and forms. For an important route, try a keyboard. If a page intentionally redirects, verify it reaches an equivalent destination rather than simply sending a visitor to a generic homepage. Make the test inquiry recognisable as a test and remove it according to the business process when verification is complete.
Illustrative example: a hypothetical dental practice approves its redesigned service pages, but its launch register exposes an old appointment link that still points to a retired provider. The team replaces the link, repeats the controlled journey, and records the corrected destination. This is a specific acceptance fix, not a claim that the practice’s whole digital experience has been audited.
Agree on what happens when a check fails
Classify the result in plain terms. A blocker prevents a visitor from completing a central promised task. A defect differs from a newly requested improvement. A content question needs a named business owner. A third-party outage may need an explanation and a fallback instead of an immediate code change. This classification gives the team a way to decide what must be corrected before launch and what can be scheduled transparently.
Keep the record after launch
The acceptance register becomes useful maintenance context. When a new editor asks why a redirect exists or where a form should deliver, the team has a dated answer. Update it after a material change; do not treat a stale spreadsheet as evidence of current behavior. WordPress Site Health can provide application information, while a launch register documents the business decisions that ordinary technical status screens cannot know.
Review content separately from code
Launch errors often arise because a page is technically reachable but its business information was never approved. Include a content review for service boundaries, opening claims, contact details, locations, image rights, and any testimonial or credential. The business owner should confirm the facts; the builder should confirm that the approved information appears in the intended place. If an item lacks a fact owner, mark it unresolved rather than allowing a placeholder to become a public promise.
Close the launch deliberately
Once blockers are resolved, give the organization a short handoff: live URL, administrator route, editor route, account-owner register, support boundary, and the date of the next routine review. This is more useful than a generic declaration that a site is finished.
Protect the opening week
For the first few business days, check the routes that matter most: published pages, inquiry delivery, telephone links, primary navigation, and any scheduled content. Assign the observation to a named person rather than assuming a vendor sees every public problem. If a visitor reports an issue, add it to the register with the task affected and a resolution note. That record turns early support into evidence for the next maintenance review.
