20 things to check before launching your website

Use the checklist on the version you intend to publish

Run these checks against the final content and integrations, not an early design demonstration. Record who tested each item, what happened and whether a fix is still open. For a small business site, a shared document can be enough as long as someone owns the decisions.

A redesign also has an existing audience. Old bookmarks, search results and links from other sites must be considered alongside the new navigation. Our SEO migration guide explains that part of the preparation.

The list is a practical launch review. It does not replace a full security, accessibility or legal assessment where the project needs one.

Content and contact details

1. Read the pages in their final layout. Remove placeholders, check spelling and make sure each page explains the intended offer. Verify names, numbers, prices and service limits against the business’s approved information. Read on a phone as well as a large screen: a sentence that works in a document may become difficult to follow in a narrow layout.
2. Check the images and downloads. Confirm you have permission to publish the material and that the correct versions are being used. Add useful alternative text to informative images and empty alternatives to decoration. Open each downloadable document from its public link. A file sitting in a project folder is not proof that the visitor can retrieve it.
3. Verify every contact route. Call the displayed number, check the email address and follow any booking link. Confirm opening hours and service-area information. For a business that works at customers’ premises, explain the arrangement clearly. Visitors should not be led to believe they can walk into an office that does not receive them.
4. Review the complete language versions. Check page text, navigation, form labels, error messages and confirmation screens in each published language. Use the language switch from an article and confirm it opens the corresponding article. Give unfinished language content an explicit decision before launch rather than silently sending visitors to an unrelated page.

The journeys visitors will actually use

5. Send a real test through each form. Use clearly marked test details and check the confirmation, delivery to the intended destination and the way staff will handle the message. Test missing and invalid fields as well as success. A green confirmation on the website does not prove that the business received the enquiry. Coordinate the test so it does not create an unintended customer task.
6. Use the menu and main actions on mobile. Open and close the menu, follow a service link and complete the main enquiry journey. Check buttons near screen edges and fixed headers. Try a small viewport where long labels may wrap. The important content should remain reachable without horizontal scrolling or controls covering one another.
7. Test keyboard operation and focus. Move through links, menus and forms without a mouse. Make sure focus is visible, the order is understandable and dialogs can be left. Check labels and error guidance. The W3C’s Easy Checks offer a useful first review, while explaining its limits.
8. Exercise the important integrations. If the site takes bookings, sells products or connects to another system, test the complete journey in a suitable test environment. Include cancellations, failures and notification delivery. Keep test orders and messages clearly identified. Confirm that a failed external service produces a useful response and leaves the business a way to investigate.

Delivery, browsers and performance

9. Check HTTPS and the intended domain. Visit the public addresses with the domain variants people may use. Confirm they lead to the chosen secure address, with a valid certificate and no insecure page resources. Verify important routes directly, not only through the homepage. Keep domain and DNS access available to the people responsible for the launch.
10. Look for broken resources and page errors. Check that styles, scripts, images and fonts load from their production locations. Review failed network requests and relevant application errors. A page can appear broadly correct while a missing script disables the menu or form. Retest after a fix on the actual release candidate.
11. Try the browsers and devices your audience uses. Include a phone and the key desktop browsers within the project’s agreed support scope. Check zoom and long content as well as the default viewport. Record which combinations were tested. A single emulated mobile view is useful evidence, but it does not establish compatibility with every real device.
12. Review loading and interaction behaviour. Use representative pages with real images and third-party tools enabled. Check whether the main content arrives promptly, controls respond and the layout remains stable. The Web Vitals overview explains the main measurements. Keep a laboratory test distinct from field data collected from real users.

Search discovery and existing addresses

13. Review indexing instructions. Make sure public pages intended for search are not carrying a staging noindex directive. Review page directives, response headers and robots.txt together. Keep deliberate exclusions where they belong. Google’s robots.txt documentation explains why blocking crawling and preventing indexing are different controls.
14. Check titles, descriptions and canonicals. Give each important page a descriptive title and a useful summary. Confirm its canonical points to the intended public URL. For separate language versions, check the canonical and reciprocal hreflang links as a set. A page written in English needs its own metadata, not the French title left in the template.
15. Check the sitemap against the site. Confirm the XML opens and lists the intended canonical, indexable pages with accurate language relationships. Exclude redirects and deliberately non-indexable pages. Check that robots.txt points to the correct sitemap. Google’s sitemap overview explains its role in discovery; a sitemap does not guarantee inclusion in search.
16. Test the migration map and error page. During a redesign, map useful old URLs to the most relevant new destinations and test the redirects. Avoid routing unrelated old pages to the homepage. Check that an unknown address returns a proper not-found response with helpful navigation. Keep the previous release available under a controlled recovery plan.

Privacy and measurement

17. Match the privacy information to the actual website. List the data collected by forms, analytics, embeds and connected services. Have the appropriate privacy notices and tracking choices reviewed for your activity and audience. Then test that the configuration follows those choices. The Swiss FDPIC is the official data protection authority; get specialist advice for legal questions specific to your project.
18. Verify the actions you intend to measure. Choose a small number of useful events and check that each is recorded once under the intended privacy settings. A click on a phone link is a click, not a confirmed conversation. Keep test traffic identifiable and avoid sending personal details into analytics. Document the events and who will interpret them after launch.

Recovery and handover

19. Prove that recovery is possible. Check what the backups cover, where they are stored and who can restore them. Include the database and uploaded files where the site uses them. Test recovery in an isolated environment so you do not overwrite live work. Record the procedure and any missing material while there is still time to fix it.
20. Assign maintenance and launch follow-up. Name the people responsible for domain renewal, hosting, updates and incident handling. Confirm company control of essential accounts and store recovery details securely. Agree how launch issues are reported and prioritised. Arrange a first review of real enquiries and operational problems once the site has been in use.

When the review is complete, decide which outstanding items block launch and which can wait with an owner and a date. An unavailable enquiry route or an uncontrolled data exposure needs immediate attention. A minor editorial refinement may be scheduled. Make that decision explicit rather than letting the deadline decide for you.

Questions before launch day

Should we run these checks again after publication?

Yes. The public domain, delivery services and tracking configuration can behave differently from the preview. Recheck the important routes and workflows on production using controlled test data and the agreed support scope.

How much time should we reserve?

Base the review on the size and functions of the website, and leave time for corrections and retesting. A multilingual shop needs more coverage than a short information site. Plan the checks before announcing a fixed launch moment.

When will search engines pick up the new site?

Crawling and indexing are controlled by the search engines and have no guaranteed timetable. Monitor the reports available to you and investigate specific problems. A successful deployment only establishes that the site is available.

Preparing a launch in Geneva or Lausanne? Talk to Navanem about the site and its scope. We can discuss the checks, handover and support it needs.