Website launch checklist: what to test before sign-off

Make sign-off depend on observable checks

A website can look finished while its contact form sends messages to an old inbox or its mobile menu hides a key link. Acceptance should test what a visitor and the business actually do. Agree on the expected result for each important path, record who tests it, and keep evidence such as the final URL, a received test message, or a short issue note.

This acceptance and handover checklist assumes you have agreed the project scope. Use it to check the agreed visitor tasks and assign anyone who still owns open work.

Start with the few actions that matter to the business: find a service, understand whether it fits, contact the right person, and reach the expected confirmation. Then test supporting details such as navigation, page titles, redirects, and account access. An attractive homepage alone is not evidence that the whole site is ready.

prepare the old-to-new URL map before testing redirectsconfirm that acceptance follows the agreed project scope

Review the pages in the conditions people use

Open each page at a desktop width and a narrow mobile width. Check the page title, main heading, service details, contact information, images, and navigation. Look for clipped text, overlapping controls, missing photographs, buttons that sit under a browser bar, and content that becomes hard to read when the layout changes.

Follow internal links and open the business’s main external links. Check that phone numbers, email addresses, booking destinations, and map actions point to current information. A link can look right while its destination has changed. Test the path itself rather than approving the visual state of the button.

Ask a person who did not build the page to complete one real visitor task. Give them a short prompt, such as finding whether a repair is offered and how to ask about availability. Watch where they hesitate. Their confusion is useful evidence about the page, even when every link technically loads.

Submit a real enquiry and confirm who receives it

Run the contact form from the live page. Use a distinctive test subject and a message that clearly identifies it as a test. Submit it once, then check the actual destination inbox or agreed request system. Confirm the message contains the expected fields and that the business can tell who should respond. A button changing color or displaying “sent” does not prove delivery.

Check the whole exchange. If the site promises a confirmation email, verify that it reaches the test address and explains what happens next. If the business handles requests in a shared system, confirm the right staff member has access and knows how to claim a new request. Remove or label the test record after the check, following the team’s normal process.

Consider a hypothetical consultant whose new form displays a success message but still sends mail to a former employee. The design passes a screenshot review, but the actual business path fails. A real submission catches the mismatch. Record the recipient, who owns follow-up, and the fallback route if the inbox or integration stops receiving requests.

Run both a valid submission and an error case. Leave one required field blank, note the message, correct it, and resubmit. Verify that the successful message includes the details the recipient needs, without silently dropping a selected service or reply address. Tell the recipient when the test will arrive so it is not mistaken for a customer request.

trace what happens after a prospective customer makes contact

Test forms and navigation with a keyboard

Use Tab and Shift plus Tab to move through links and controls. Confirm the order follows the page, the current focus is visible, and every menu or dialog can be opened and closed without a mouse. Test Escape where it should close an overlay. Make sure focus returns to a sensible control after a menu closes instead of disappearing from view.

On the enquiry form, confirm that every field has a visible, useful label. Try to submit an incomplete form and check that the missing field and correction are explained in text. Correct the problem, submit again, and confirm the result. Error and success messages should be visible and associated with the action the visitor just took.

web.dev explains that automated checks do not judge whether focus order makes sense or whether a focus indicator is visible. Its form guidance also emphasizes clear field labels, text descriptions for errors, and feedback after resubmission. A scanner can help find issues, but a person still needs to operate the actual form and navigation.

Check URLs, redirects, and crawl access when the site moves

If page addresses changed, test the old-to-new map against the published site. Enter each priority old URL directly and verify its final destination. Confirm that internal links point to the new addresses. Check that merged pages preserve the useful information and that retired pages do not send visitors to an unrelated destination.

Google’s site-move guidance recommends testing the new site and then monitoring old and new URLs. For a hosting change without visible URL changes, Google also advises checking that the new infrastructure is accessible, removing temporary crawl blocks, and monitoring the move before shutting down old hosting. Match those checks to what the project actually changed.

Review the current sitemap and the site’s crawl settings with the person responsible for release. A staging site may intentionally block indexing, so confirm which controls must change at launch. A recrawl request is not a publication receipt or a promise of indexing. Keep search monitoring separate from the buyer’s functional sign-off.

Give the business clear ownership of its accounts

List the accounts required to operate the site: domain registrar, hosting or platform, content editor, form delivery, analytics, and Search Console if used. For each one, name the business owner, the people who need access, and the recovery route. Verify that the owner can sign in before the project closes, rather than assuming an invitation was accepted.

Use individual accounts with the access each person needs. Confirm that recovery details point to a business-controlled address or phone. Store passwords in the team’s approved password manager, not in the acceptance spreadsheet. Remove access that is no longer needed after handover, following the business’s account process.

The business also needs an operational owner for changes and incoming requests. Name who updates service details, who checks the enquiry inbox, and who contacts the provider if the form stops working. Account ownership without a response owner leaves a working website with no clear person to maintain its core task.

Close with a handover record and an issue owner

Record the date, site version, tested pages, test devices, form recipient, redirect results, account owners, and open issues. For each issue, include the exact page, steps to reproduce it, expected result, actual result, owner, and a retest date. A note such as “mobile looks odd” is hard to act on; a specific viewport and reproduction step make the problem reviewable.

Separate defects from later requests. A broken contact path blocks the intended business action. A new section that was never in the agreed scope is a change request. Give each a status and next owner so neither disappears into a vague final email. Retest the affected path after a correction instead of relying on a verbal claim that it was fixed.

After publication, repeat the critical checks on the live domain, especially the real enquiry submission and any redirect that depends on production settings. Agree who watches incoming requests during the first operating period. Sign-off should state what was checked and what remains open.

Close each issue only after the named person repeats the original steps and records the new result. Keep accepted work, open defects, and later improvements visible as separate statuses. This gives the buyer a clean handover: what is ready to use, what still needs correction, and whom to contact when a core route stops working.

Common questions