Website Launch Checklist: What to Test Before and After Going Live
A website is ready to launch when the agreed content is approved, the important customer journeys work and the team can operate and recover the site. Test the final public domain, not only the preview. Check contact routes, forms, images, mobile layouts, redirects and search settings, then confirm account ownership and maintenance responsibilities. Keep a recoverable backup and a clear launch sequence so problems can be addressed without improvising.
Agree what ready means before the final review
Create a launch acceptance list from the project scope. Name the pages, features and customer actions that must be complete. A service website might require approved service pages, working WhatsApp links and a correct contact address. A booking website may also require availability rules, confirmation messages and a tested appointment journey. The list should describe the actual site rather than every possible website feature.
Separate blockers from later improvements. A broken enquiry form is a launch blocker. A minor preference about an image crop may be a lower-priority adjustment if it does not affect understanding or usability. This distinction helps the team make a sensible decision instead of delaying indefinitely for cosmetic changes or launching with serious operational failures hidden in a long feedback list.
Assign a person to approve the release and a person to coordinate publication. Other colleagues can review their areas, but someone needs to consolidate the result. Record unresolved issues and the decision for each one. A clear approval is more useful than a casual message that the site looks good, especially when several people have contributed content and some requirements are not visible in a screenshot.
Approve content, business details and media
Read every important page in its final layout. Check names, phone numbers, email addresses, locations, service descriptions, prices and package conditions against current business information. A design draft can contain placeholder wording that becomes easy to overlook once the page feels finished. Search specifically for temporary text, sample contacts and outdated dates.
Confirm that claims and proof are authorised. Testimonials should preserve the client’s meaning, and portfolio examples should accurately describe the work. Check permission for names, logos, photographs and licensed assets. If an illustration is a hypothetical example, label it clearly rather than allowing it to appear to be a real client result. These checks protect the credibility of the new site.
Review images on both wide and narrow screens. Important details should remain visible after cropping. Add meaningful alternative text where the image conveys information and avoid repeating a long caption unnecessarily. Check downloads as well as page media: the correct company profile or document should open, carry current contact details and avoid exposing internal notes or information that was never intended for the public website.
Complete the main journeys on phones and desktops
Test the tasks customers will actually perform. Find a service, compare a package, view work and start an enquiry. If there is a store, use the agreed test process for product selection and checkout. If there is a booking flow, check the available choices and the confirmation. Follow the journey from entry to outcome rather than checking isolated buttons.
Use representative devices and browsers where available. A mobile menu may behave differently from a desktop menu, and a fixed contact bar can cover controls on a small screen. Check text wrapping, horizontal overflow, tables, dropdowns and modal close buttons. The mobile website checklist provides a more detailed review of these common problems.
Include keyboard navigation and visible focus in the check. Controls should have understandable labels and should not depend solely on a hover state. Forms need clear instructions and useful error messages. The W3C forms tutorial is a practical reference. Record failures and verify the fixes instead of assuming that a change in the code automatically resolved the customer-facing problem.
Verify enquiries and third-party handoffs
Check every important contact route against the correct recipient. A telephone link should use the intended number. A WhatsApp link should open a conversation with the business and include relevant context where promised. An email link should use the monitored address. Do not send unsolicited test messages to customers or unrelated contacts while checking the site.
For forms, use clearly identified test data and confirm the receiving workflow. The visitor’s success message, the notification email and any connected system should be consistent. Check spam handling and routing where those are part of the implementation. If a form only prepares an email or WhatsApp message, the page should explain that the visitor still needs to send it in the other application.
Review booking and payment language carefully. A request should not be described as a confirmed booking unless the system genuinely reserves it. A package enquiry should not appear to create a paid order. These wording checks are part of functional testing because they affect what the customer believes happened. Make sure the team receiving enquiries understands the new route and knows how service or package context will appear.
Prepare URLs, redirects and search information
Check page titles, descriptions, headings and canonical URLs for the final site. Remove preview-domain references from the production version where they do not belong. Important pages should be linked within the site and included in the sitemap as appropriate. Confirm that crawl restrictions used for private development do not accidentally block the intended public publication.
If the project replaces an existing site, test important old URLs. Keep relevant addresses where possible and map changed pages to suitable new destinations. Google’s site migration guidance explains the need for deliberate handling of URL changes. Avoid redirecting unrelated old pages to one generic destination simply to make every request appear successful.
Check the error page and what happens when a visitor follows an invalid link. It should help them find a useful route without pretending the missing page exists. Search visibility is not guaranteed by launch checks, but technical mistakes can create avoidable obstacles. The aim is an accurate, discoverable site whose public addresses and page information match the version the business intends customers to use.
Check hosting, security and recovery arrangements
Confirm that the final domain points to the intended website and that secure connections work. Review the hosting configuration required by the actual build. A static website, a content management system and a custom application have different deployment needs. The person publishing should know which files, services and settings are essential rather than treating every upload as the same task.
Keep a recoverable backup of the previous site and the new release. Include the data and configuration required for the platform, not only a collection of screenshots. Identify who can restore the site and where the recovery instructions are kept. The business should know what would happen if a serious problem is discovered shortly after publication.
Review account ownership and access. The domain, hosting and essential integrations should be associated with the correct business accounts, with supplier permissions arranged appropriately. Do not leave production dependent on an undocumented personal login. Confirm renewal responsibility and support contacts as part of handover. These details are less visible than the design, but they determine whether the business can continue operating the site after the project team moves on.
Publish through a clear sequence and verify the public result
Choose a launch time when the responsible people are available to check the result. Write the steps in order and identify the person performing each one. Depending on the project, publication may involve uploading files, changing hosting configuration, applying redirects or switching a domain. Avoid simultaneous changes by several people without coordination.
After publication, open the real public URL and repeat the essential checks. A preview can work while the public site has missing assets, an incorrect path or old cached content. Confirm the homepage, representative service and article pages, images, contact links and any important download. Check the actual final destination after redirects rather than assuming the visible domain is sufficient evidence.
If a serious failure appears, use the agreed recovery process. Do not make a series of unrelated changes while losing track of the last working state. Record what happened and verify the result after the fix or rollback. Our redesign checklist includes the preparation that makes this step more controlled when replacing an existing website with established customer and search routes.
Hand over operations and review the first enquiries
Give the business a practical handover package. Include editing instructions, account ownership information without exposed passwords, renewal responsibilities, backup guidance and the route for support. Demonstrate the ordinary tasks the team will perform, such as changing service information or adding an article. A website is not fully handed over if the client cannot complete the editing tasks promised in the scope.
Agree who checks the site after launch and how issues are recorded. Review the first enquiries to see whether the new flow provides useful context and reaches the right people. Ask staff whether customers understand the offer or continue to ask questions the page was intended to answer. These observations can guide small improvements without immediately reopening the whole design.
Create a maintenance plan that fits the platform and business. The website maintenance checklist helps turn that responsibility into a repeatable routine. BrandNerds can support a new build or launch review through our website services. Share the current site, intended launch date and essential customer journeys so the scope can focus on the checks and work the business actually needs.
Common questions
Can I launch before every minor issue is fixed?
Yes, if the unresolved items do not block the agreed customer journeys, accuracy or operation and the business explicitly accepts them. Record each item with an owner and priority. Do not treat broken contact routes, misleading information or missing essential functionality as cosmetic details.
Why test again after publication?
The public domain can have different paths, configuration, redirects or cached files from the preview. Checking the live result verifies what customers actually receive. Repeat the essential journeys and inspect representative pages rather than assuming a successful upload means the whole site works.
Who should own the website after launch?
The business should have clear ownership and recovery access for the domain, hosting and essential service accounts. A supplier can manage day-to-day work through appropriate permissions. Handover should explain responsibilities, renewals, support and how the site can be maintained or moved later.
