Websites
A local business website launch checklist that goes past the homepage
Check content, customer actions, technical settings, account control and recovery before making a new website public.
By Bridge Builder editorial 3 min read
A website is ready to launch when its promised customer path works and the business can operate what is being published. Looking good in a preview is one piece of that decision. The release also needs account control, accurate information and a way to recover from a bad change.
Use a checklist tied to the actual version being launched. Otherwise, a page can change after review while everyone continues referring to an earlier approval.
In this article
Review every public page
Make a list of the routes being published and open each one on desktop and mobile. Check service names, scope, contact details, prices and any exclusions. Remove placeholder images, draft testimonials and unsupported claims before they become public.
Follow navigation, related links and footer destinations. Test an unknown address and confirm the site provides a useful not-found page rather than silently pretending it exists. Read the site as a new customer: does the page explain what they can ask for and what happens next?
Complete one real customer path safely
Use a clearly labeled internal test with an approved recipient. Confirm receipt, ownership and the reply path. For scheduling, check the time zone, availability and confirmation. For a plain email link, verify the destination and remember that opening a draft is not a sent inquiry.
Review failure behavior too. A form should explain invalid input or a temporary problem without leaking technical details. W3C's forms guidance covers labels, instructions and useful notifications. Ask the builder to demonstrate these states in a safe test environment rather than sending uncontrolled tests into a live customer workflow.
Check the launch configuration
Confirm the intended public domain, HTTPS, page titles, descriptions, canonical addresses and sitemap. A preview may deliberately block indexing; that setting needs an explicit production check. Google's sitemap documentation describes sitemaps as a discovery aid, not a guarantee that pages will be indexed.
Ask for the dependency and secret checks relevant to the site's code, plus an explanation of unresolved findings. If analytics is enabled, verify what it collects and keep test traffic distinct. A marketing site with no account system has different risks from a customer portal, so the checks should match the actual features.
- Approved source version and deployment are recorded.
- Contact and booking destinations match the approved business accounts.
- Private keys and customer data are absent from public assets.
- Mobile tasks and shared navigation were checked.
- Indexing settings match the public or private purpose of the deployment.
Assign recovery and the first follow-up
Save the previous deployment and domain settings before changing traffic. Name who can restore them, and rehearse the relevant recovery in an isolated environment. Preserve email routing when changing the website's DNS records.
After launch, recheck the public site and customer path rather than assuming the preview result carried over. Assign dates for search-indexing review, lead-quality review and routine updates. The first launch does not complete ongoing marketing, but it should leave the business with a reliable foundation and clear responsibilities.
Your next step
Launch the exact version you reviewed, verify it on the real domain and leave an owner for recovery and follow-up.