A website launch checklist should answer one main question: can a visitor finish the task they came to do? A polished homepage is not enough if the contact details are wrong or the enquiry never reaches you.
Use this list before release, then repeat the key checks on the live domain. Keep a short record of what passed, what failed and who will fix it.
The short answer
- Judge readiness by completed customer tasks, not a polished homepage.
- Verify form feedback, the saved enquiry and the owner notification separately.
- Give each launch check an owner, evidence and a clear result before release.
How this guide was made
The checklist uses W3C first review guidance and Google search documentation. Its release sheet and stop rules are original planning tools, not a test of your site or a security, payment or accessibility certification.
Sources checked .
Before launch, approve facts and key pages
Read the homepage, services and contact pages from top to bottom. Confirm phone numbers, opening hours, service areas and prices with the business owner. Remove draft notes, sample reviews and claims you cannot support.
Open every main menu and footer link. Check the links in the page content too. Make sure each one takes the visitor somewhere useful. A button that looks right may still point to a draft page.
Ask someone who did not write the page to read it. Can they explain what you offer and what to do next? Use their questions to find gaps before sending customers there.
Confirm access and recovery
Name one person who can approve release and one who can restore the last working version. Check that the business can reach its domain, hosting and contact inbox accounts. A supplier name without a working contact route is not enough.
Set the result needed for each task
Agree on the expected result before running the check. A contact button must lead to the right form. A booking link must open the correct service. Save the page address and evidence so the next person can repeat the check.
On the live domain, complete the main task
Start on the homepage using a phone. Find the service, read its details and follow the next step. Repeat on a computer. Check that menus, text and buttons remain usable on both.
Do not skip outside tools. If the site links to booking software, confirm the correct business and service appear. Use that provider's approved test process with the account owner.
For a payment system, start with its approved test process. A pass in test mode proves that tested setup, not live billing. Any live transaction needs deliberate owner control, a known amount and a plan to check the payment record, activation and refund where required. This guide does not establish that any particular builder supports ecommerce.
Check where form messages arrive
Send a clearly marked internal test using details you control and an inbox the business owns. Keep it out of customer reports where your system allows it. Check the three results below separately.
Leave a required field empty too. Check that the error explains the fix and keeps useful input.
Check field labels
W3C form guidance recommends visible labels tied to their fields. Confirm each field has a clear name that remains available while typing.
Source for this section: [4] W3C guidance on form labels
What the visitor sees
The page must give a clear result after submission. Record whether it says the message was sent, saved or failed. A green message alone does not show what happened in the staff system.
What the business saves
Find the test in the system where enquiries should be stored. Check the contact details and message. If storage is not part of your setup, record that and verify the agreed delivery route instead.
What the owner receives
Find the owner notification in the correct inbox. Check whether staff can reply to the test address. Name who reads new enquiries, and remove test records through the normal process when finished.
Run a first accessibility review
Use the keyboard to move through links, menus and fields. Check that you can see which item has focus. Read the heading order and look for text that is too faint or hard to read.
W3C's easy checks cover useful first steps for headings, contrast, forms and keyboard access. They also make the limit clear: simple checks are not a complete accessibility assessment.
Record any issue and assign it to someone. Do not mark the whole site accessible or compliant because a short list passed. Get a deeper review when your needs call for it.
Source for this section: [1] W3C easy accessibility checks
Check the public address and search settings
Open the final domain and make sure it serves the expected site. Ask the builder to check page titles, preferred page addresses and any settings that could hide public pages from search.
The preferred address is often set with a canonical tag. A noindex setting asks search engines not to list a page. Draft settings should not accidentally stay on pages meant for the public. Private pages need their own controls.
Google's SEO starter guide recommends clear titles and useful links. Check those basics on important pages. If you changed old addresses, use a separate migration plan to check their redirects.
Check HTTPS without a certificate warning and the expected public domain. These checks show which site loads. They do not prove forms or billing work. Keep customer accounts and private previews protected; remove only accidental restrictions on pages meant for public search.
Source for this section: [3] Google SEO starter guide
Use a short launch sheet
Give each row a named owner and add the date checked. The evidence can be a short note, a screenshot or a test message. This example is a worksheet, not a claim that we tested your site.
Use Pending until checked, Pass only with evidence, and Blocked when the expected result fails. Add the date and actual person. If a row does not apply, record why.
| Check | Expected evidence | Owner | Status |
|---|---|---|---|
| Domain and HTTPS | Expected site, no certificate warning | Builder | Pending |
| Phone menu and key links | Main task completed on a phone | Reviewer | Pending |
| Contact facts | Approved phone, area and hours | Business owner | Pending |
| Enquiry | Visitor result, saved record where used, owner notification | Owner and builder | Pending |
| Required outside service | Booking or payment evidence for agreed environment | Service owner | Pending |
| Canonical and index rules | Intended live URLs and rules | Builder | Pending |
| Missing page | Made up path returns a real missing page response | Builder | Pending |
| Recovery | Named operator and recovery steps | Technical owner | Pending |
After launch, review failures and search discovery
Do not send clients to a site if contact details are wrong, a core page fails or the main enquiry route is not received. Fix the issue and repeat that test. Choose who can make the final launch decision.
Before release, confirm access to the domain and platform. Keep a backup or recovery option that fits the service. Name the person who will respond if something fails.
After release, repeat the key checks on live pages. Submit the current sitemap through your search tools. Google says a sitemap helps discovery but does not guarantee crawling or indexing.
Watch real enquiries and errors after launch. Keep a small list of fixes and check them as they are made. Publishing is the start of using the site, so ownership should continue after the launch day.
Source for this section: [2] Google guidance on building a sitemap
Use a clear launch decision
In this fictional example, a consultant's pages look finished but the enquiry never reaches the owner. The launch remains blocked until delivery works and is checked again. A small spacing issue on a readable page may be logged for later with an owner and date.
Decide based on the task and its impact. Do not let a long list of small passes hide one failed route that customers rely on.
Sources and further reading
Numbered links beside each section point to the source used there. Our examples and checklists are guidance from SnapRebuild. They are not claims of test results. Product details can change.
SnapRebuild sells a website building service. These guides are published under our editorial team name and use AI for research and writing. This is not a claim of independent expert review. Read how we make and update our content. Found an error? Tell us.
Ready for a fresh start?
Bring your website or your business idea. Explore a SnapRebuild preview and decide what comes next.
Try your free preview