Start with the job the website needs to do
Before checking individual pages, write down the website’s main purpose and the actions visitors should be able to take. A community organization might want people to understand its services, find opening hours and send an enquiry. Those tasks give the team a better test than asking whether the site simply looks finished.
Make a short inventory of the pages, forms and downloadable files that support those tasks. For each item, name one person who can approve its content and one person who can fix technical issues. Keep the checklist in a shared document with space for the test result, the person responsible and the date it was checked. Mark issues as either launch blockers or improvements that can safely wait. A broken enquiry form is a blocker; a paragraph that could be shorter may not be.
Check every route to essential information
Walk through the site as a first-time visitor. Starting at the home page, try to reach each important destination without using an internal list of links. Check navigation labels, page titles, contact details, opening hours and calls to action for consistency. Open every prominent link and confirm that it leads to the expected page or file. If an old website is being replaced, make a list of its most useful addresses and arrange redirects where appropriate so visitors do not land on avoidable error pages.
Review the content for usefulness as well as accuracy. Does each page answer a likely visitor question, and is it clear what to do next? Ask the people closest to the service to verify practical details rather than guessing from an earlier draft. If a small food pantry has changed its collection process, for example, its eligibility page, contact page and confirmation message should all describe the same steps. Remove placeholder text, duplicate pages and images that do not help explain the content. Give meaningful images descriptive alternative text; decorative images generally do not need a spoken description.
Test real tasks on different devices
Choose a few realistic tasks and complete them on a phone and a desktop computer. Try finding an address, reading a long page and submitting a form. Check that text is readable when enlarged, buttons are easy to identify, and layouts do not hide information on a narrow screen. Test with a keyboard alone: you should be able to see where focus is, move through controls in a sensible order and submit forms without a mouse.
Look closely at forms and other points where visitors may get stuck. Fields need clear labels, required information should be identified, and error messages should explain how to correct a problem. Submit a test entry and confirm both that the visitor sees a useful confirmation and that the right person receives the enquiry. If the site uses an appointment or donation service, test the handoff to that service as well. Ask someone who did not build the site to try a task without coaching; note where they hesitate and fix the cause where you can.
Confirm measurement and everyday safeguards
Decide what the team needs to learn after launch. For a small site, that might be whether visitors reach a key service page or successfully submit an enquiry. Configure only the measurement needed for those questions, then perform a test visit and check that the expected activity is recorded. Document what is being measured and who can access the reports. If the site uses analytics or other tracking tools, check that the privacy notice and any consent controls match what the site actually does.
Review basic security and ownership before opening the site to visitors. Confirm that the public address loads securely, software and extensions are up to date, and accounts are limited to people who need them. Use strong, unique passwords and enable multi-factor authentication where available. Check who controls the domain, hosting and backups, and make sure those details are available to the organization rather than held by one person. Test that a backup can be restored, or agree on a restoration procedure with the provider. Avoid sending sensitive form submissions to a shared inbox unless there is a clear reason and a suitable process for handling them.
Give the launch a clear finish line
Set a brief sign-off meeting rather than assuming silence means approval. Bring the checklist, outstanding issues and a proposed launch time. Each owner should confirm their checks or explain what remains open. Agree who will publish the site, who can respond if something breaks and how to return to the previous version if needed. Keep a copy of the approved content and the final checklist so later changes have a reliable starting point.
Once the site is public, repeat the most important tests on the live address: open the home page, follow key links and submit a test form. Then schedule a short follow-up review to inspect enquiries, visitor feedback and any measurement the team chose to collect. A pre-launch checklist is not a promise that nothing will need changing. It is a practical way to catch preventable problems, assign responsibility and make the first improvements with confidence.
