Define what launch-ready means
A small website can be useful without being perfect. Launch acceptance criteria describe the conditions that must be met before the site goes public. They turn a vague question, “Is it finished?”, into a decision the project team can make together. Agree on the criteria early enough to leave time for fixes, rather than introducing them at the final review.
Start with the site’s purpose and the tasks visitors need to complete. A contact page, for example, is not ready merely because it looks right: its details must be accurate, its links must work and any form must deliver submissions to the right place. Keep criteria focused on observable results. “The site feels polished” invites disagreement; “The agreed pages have approved copy and images” gives reviewers something to check.
Separate launch requirements from future improvements. A requested feature can be valuable without being necessary on day one. Record it in a later-work list rather than letting it silently expand the launch scope.
Write criteria that someone can actually test
Group criteria into a short checklist covering content, visitor tasks, accessibility, technical setup and ownership. For content, confirm that required pages exist, key facts are correct and there is no placeholder text. For visitor tasks, check navigation, downloads, links and forms. For accessibility, review keyboard navigation, meaningful link text, image alternatives where needed and the readability of text and forms. Test the layouts at a few representative screen sizes rather than assuming a desktop review covers everything.
Include the operational details that are easy to miss in a visual review. Check that the intended domain reaches the site, secure connections work, basic page titles are present and the team can access the publishing tools. If the site collects messages, confirm who receives them and how they will be handled. Where measurement tools are part of the project, check that they are configured as agreed; do not treat a dashboard’s presence as proof that every event is recorded correctly.
Give each criterion a simple pass condition and, where useful, a test method. For example: “A visitor can submit the contact form using a keyboard, receives a clear confirmation and the designated inbox receives the message.” The checklist need not be long. It should be specific enough that two reviewers are likely to reach the same conclusion.
Name the reviewers and the decision-maker
A sign-off process stalls when everyone is invited to comment but nobody is responsible for deciding. Identify one person who can approve the launch on behalf of the site owner. Assign other reviewers by area: a content owner checks facts and wording, a project lead checks agreed scope, and someone familiar with the site’s setup checks publishing and access. On a very small project, one person may hold several roles; write down the names anyway.
Tell reviewers what they are reviewing and when their comments are due. Provide the same version of the site and the same checklist to everyone. Ask for issues with a page or location, steps to reproduce the problem and the expected result. This makes feedback easier to act on than a collection of general impressions.
Also decide how late requests will be handled. A correction to an incorrect phone number is different from a new page idea. Keeping both visible, but treating them differently, protects the launch decision from becoming an open-ended design review.
Run a review, then make an explicit decision
Set a review window with time for fixes and a final check. Track findings in one shared list with an owner and a status such as open, fixed or deferred. Classify issues by their effect on launch: a broken primary contact route may block publication, while a minor spacing inconsistency may be acceptable to address later. Agree on what counts as a blocker before the final meeting so the classification is not invented under pressure.
When a fix is marked complete, ask the relevant reviewer to check it again. A change can solve one problem while creating another, especially around navigation, forms or responsive layouts. Keep a brief record of what was tested and what remains unresolved; screenshots or test notes can help when a result is difficult to describe.
The final decision should be explicit: approved to launch, approved with named follow-up items, or not approved pending specific fixes. Record who made the decision and which version they reviewed. If work is being delivered for a client, use the approval process already agreed for the project rather than assuming this checklist replaces it.
Connect sign-off to the first days of ownership
Approval is not the end of the project. Before launch, confirm who can publish changes, who monitors contact messages and who responds if something breaks. Keep credentials in an appropriate shared system, not in a public checklist. Make sure the site owner knows how to request corrections and where deferred work has been recorded.
After publication, perform a short check on the live site. Follow the main navigation, submit any important forms using a suitable test message and confirm that the published pages match what was approved. If the live environment behaves differently from the reviewed version, log and address the difference. A clear handover and a brief live-site check make sign-off a useful transition to ongoing maintenance, not just a box to tick.
