Article contents
A homepage can look finished while the website is still unable to do its job. Before launch, take the same route a real customer would take, then follow the inquiry all the way into the business.
Test a service inquiry from a customer’s perspective.
Pick a realistic situation: a customer on a phone needs to know whether you offer a service in their city and what to send for an estimate. Start on a service page rather than the homepage. Can they understand the offer, confirm the area, and find the appropriate next step without guessing?
Repeat the exercise with a different entry point. Someone arriving on an article or project page should still understand who you are and where to go next. Check actual text, actual images, and actual links. Placeholder material can hide a problem that appears only when the real content is in place.
Review keyboard access and mobile layouts.
Use the keyboard to move through the menu, buttons, and form. Look for a visible indication of where you are. Try the site at a narrow width and with text enlarged. Read the form labels and error feedback as instructions, not decoration. A visitor should be able to recover from a mistake without losing the work they have already done.
The W3C’s Easy Checks offer a useful first review of areas such as page titles, headings, contrast, keyboard focus, and forms. Those checks are an initial screen, not a complete accessibility evaluation. Use them to identify issues and define the deeper review the project needs.
Read more: W3C WAI: Easy Checks for a first accessibility review
Verify contact-form delivery.
Submit a real test using an address you control. Confirm that the intended business mailbox receives the message, the details are readable, and replying goes to the customer. Check what appears if a required field is missing, delivery fails, or the user tries again. A successful animation is not proof that an inquiry reached anyone.
Ask the team launching the website to verify spam protection and delivery on the live domain, including server-side verification when Cloudflare Turnstile is used. Agree who receives inquiries and test the complete route with that person. The launch review should record successful delivery, the reply address, and how a failed submission is handled.
Read more: Cloudflare Turnstile: server-side token validation
Make a plan for the URLs people already know.
When replacing an existing website, keep an inventory of the old URLs and decide which new page answers each one. Google’s site-move guidance recommends planning the mapping, testing the new site, implementing suitable redirects, and monitoring the transition. Sending every old page to the homepage can leave visitors without the answer they came for.
Our practical launch sheet includes important service pages, articles, downloads, and pages linked from business profiles or campaigns. Visit a sample of the old addresses after the change and follow the result. Then check that the new site’s own navigation points directly to its current pages.
Review what a search result will say.
Read each important page title and description as a standalone introduction to the business. Make sure it describes that page rather than repeating one generic sentence everywhere. Check the business name, contact details, service information, and social preview. Search engines may choose different snippets, but your own metadata should still be deliberate and accurate.
Confirm that development-only indexing restrictions are handled for the intended launch environment, the canonical addresses use the production domain, and the sitemap lists the right public pages. These technical details belong on the launch review because a page can look correct in a browser while still carrying the wrong publishing settings.
Check search and AI discovery information for accuracy.
The llms.txt project proposes a structured way to make website information available to language-model systems, including links to useful content and machine-friendly versions. It is a discovery format, not proof that an AI system will cite or recommend a business. Treat it as another representation of the information you already stand behind.
If you publish llms.txt or Markdown versions of pages, compare them with the visible website. Prices, scope boundaries, contact details, and the relationship between brands should agree. Outdated structured content is still outdated content, even when a person is unlikely to see it in the ordinary page layout.
Read more: The llms.txt project and format proposal
Assign responsibility for the website after launch.
Write down who will receive inquiries, make content changes, review backups, monitor availability, and renew the relevant services. Make sure the people responsible can reach the accounts they need. Then choose a short follow-up review to inspect the running site and the first real feedback.
Before launch, confirm that the website describes your services accurately, customer tasks work, and your team can operate the finished site. Use the review to record any remaining work, its owner, and the agreed follow-up.