Website handover checklist: what to verify before launch

A website handover should compare the finished site with the agreed scope and test real visitor tasks. Looking at the homepage on a laptop is not acceptance testing. Submit forms, use contact options on a phone, inspect links and indexing, verify analytics and receive the promised accounts.

Run the review on the final version before announcing the launch. Record each issue in one document with its URL, reproduction steps and expected result. This separates a defect from a new feature outside the commission.

Begin with the agreed scope

The accepted proposal, contract or specification is the baseline. Bring together:

• the page list and required language versions,
• agreed forms, integrations and functions,
• CMS, measurement and technical SEO requirements,
• content supplied by the client and by the developer,
• devices and browsers included in testing,
• the defect process and correction period,
• the items to be transferred at handover.

Clarify vague acceptance criteria before sign-off. “The form works well” is difficult to test. “The form accepts valid input, explains invalid input, displays confirmation and sends the complete message to the named mailbox” has a clear result.

Our guide to choosing a web design company covers the questions worth settling before a contract is signed.

Review content, navigation and business details

Read every page as a prospective customer. Familiarity makes it easy to overlook an old telephone number, placeholder copy, inconsistent service names or a link to the staging site.

For every language version, check:

• the company name, contact details, opening times and service area,
• prices, service scope and conditions where they are published,
• navigation, the logo link and footer links,
• buttons, downloads and external links,
• images and other material the business is entitled to use,
• browser titles, the site icon and link-sharing previews,
• the response shown for a non-existent address.

Keep copy corrections in one list with the precise location and approved replacement wording. This reduces the chance of a change disappearing in the next revision.

Complete every route to an enquiry

A service website will normally lead to a call, form, booking or purchase. Complete each journey rather than checking that the button looks clickable.

Forms and notifications

Submit valid details, then try again with an empty required field and an invalid email address. Confirm that:

• labels and required fields are understandable,
• each error says what needs to be corrected,
• a successful submission has an unambiguous confirmation,
• the complete message reaches the correct mailbox,
• repeated taps cannot create unintended duplicate enquiries,
• spam protection does not stop an ordinary prospect.

Test every form when the site has more than one. The guide to website contact forms and better enquiries explains labels, validation, privacy and accurate submission measurement in more detail.

Calls, bookings and payments

Tap the phone number and email address on a real phone. Check that the correct application opens with the right details. If the site uses an external calendar, checkout or payment provider, complete the normal journey, cancellation and return to the website. A third-party integration is still part of the customer's experience.

Test a real phone and keyboard

Resizing a desktop browser is useful, but it does not replace a physical device. Test at least a small screen and a larger phone in portrait and landscape. Open the navigation, a long page and a form while the on-screen keyboard is visible. Look for horizontal overflow, clipped copy, covered buttons and controls that are difficult to tap.

Put the mouse aside and use the Tab key. Focus should remain visible, follow a sensible order and reach the navigation, links, fields and buttons. W3C provides preliminary accessibility checks for keyboard access, forms and error messages. These checks do not establish full conformance, but they can reveal important barriers before launch.

Also enlarge text and use browser zoom on representative pages. Confirm that content remains readable and that important actions do not overlap or disappear. Automated scans are useful evidence, but acceptance should include manual interaction with the actual journeys.

Assess performance without chasing a perfect score

Run PageSpeed Insights on several representative templates, then use the site on an ordinary phone and mobile connection. A laboratory result can reveal oversized images, blocking code and layout movement, but it cannot guarantee every visitor's experience.

Google's current Core Web Vitals guidance recommends LCP within 2.5 seconds, INP at 200 ms or less and CLS at 0.1 or less, assessed at the 75th percentile separately for mobile and desktop visits. A new domain may not yet have enough field data, so pre-launch acceptance also uses laboratory testing. Agree which templates will be measured and require the main causes to be addressed rather than demanding one identical score from every page.

Protect search visibility during launch or replacement

Confirm that important pages have distinct titles, descriptions, a clear H1 and suitable canonical URLs. Staging sites are often kept out of search results. Those restrictions must not accidentally remain on the public version. Google explains that the noindex rule prevents a page from appearing in search results.

The sitemap should contain the canonical URLs intended for search. Google's official sitemap documentation recommends fully qualified URLs and placing the file at the site root when it should cover the whole website.

When a new site replaces an existing one, prepare an old-to-new URL map. Each valuable old address should lead directly to the closest relevant destination. Google's site migration guidance recommends permanent server-side redirects, updated internal links, canonicals and sitemaps, followed by redirect testing. Sending every retired page to the homepage is not an adequate migration plan.

The article on technical SEO for a new website provides a fuller search acceptance scope.

Verify analytics with a real action

Open the site in the state a normal visitor will use, make the relevant privacy choice and complete the measured action. Test accepted form submissions, calls or purchases according to the measurement plan, not page views alone.

Google Analytics DebugView displays events collected during a test and lets you inspect their parameters. A click on a submit button is not necessarily a successful enquiry. Record the event names, triggering conditions and which events are marked as key actions, so that later reporting can be checked against the agreed setup.

Receive the accounts and post-launch responsibilities

A finished website without the necessary access keeps the business dependent on its supplier. Before closing the project, establish who owns each account and who pays its renewals. The handover package depends on the technology and contract, but commonly includes:

• the domain and registrar account,
• hosting, DNS and HTTPS certificate arrangements,
• a named CMS administrator account rather than one shared password,
• the code repository and deployment instructions when included in scope,
• Search Console, analytics, tag management and advertising access,
• licences for themes, plugins, fonts, images and other paid assets,
• a backup and a documented restoration process,
• editing guidance and the training included in the proposal,
• warranty, maintenance, update and incident-reporting terms.

Do not circulate passwords in a spreadsheet. Create named accounts, enable multi-factor authentication where available and remove unnecessary supplier access after the agreed work is complete.

Turn the review into an acceptance record

Each issue should include the URL, device and browser, steps to reproduce, expected behaviour, actual behaviour and a screenshot when useful. Put it into one of three groups:

1. A launch blocker, such as a failed contact form or payment.
2. A defect to correct by an agreed date that does not stop the core journey.
3. A new request outside scope that needs a separate decision and estimate.

After a correction, repeat the same scenario and check that the change did not break a related function. Close the item only after the retest passes. A useful website handover checklist ends the project with observable results, not a disagreement about general impressions.

AMCompany designs and develops business websites with testing, technical SEO and measurement defined in the project scope. Explore the services and portfolio. To price a new website or review the handover of a current project, describe the scope and planned launch date.