Planning a website redesign: launch and handover checklist

Record what the current website does

Start with the services customers use and the questions your team receives. Record useful enquiries, common points of confusion and the tasks staff perform to maintain the site. A new visual direction can be part of the brief, but it should sit alongside those practical requirements.

Export the current page list and review available Search Console and analytics data. Separate UK and other-country activity where relevant, and use complete comparable periods. A small sample is a reason to preserve useful information and collect better evidence, not to assume every quiet page should disappear.

Give each existing page a decision

Create an inventory with the current URL, purpose, owner and proposed treatment. Retain a useful address where the page still serves the same need. If a page must move, identify the relevant destination before launch rather than redirecting everything to the homepage.

Inventory field	What to record
Current URL and purpose	The question answered and the next useful action
Available evidence	Search activity, enquiries, links or staff knowledge
Content decision	Keep, improve or investigate; state the reason
Proposed URL	Keep the existing address where appropriate
Migration action	Transfer content, redirect if needed and update internal links
Owner and check	Who approves the page and confirms the live result

Google's site-move guidance explains URL mapping, redirects and monitoring when addresses change. It also describes possible search fluctuations. A sensible migration process manages risk; it cannot guarantee that visibility will remain unchanged.

Prepare content and account access early

Name one person who can approve the page structure and one owner for each body of content. Gather current service descriptions, permitted project photographs, team information and documents that customers still need. Resolve conflicting versions before copying them into a new system.

Identify the domain, hosting, content system, analytics, booking and enquiry-system owners. Arrange appropriate access through agreed channels; do not put passwords, private customer records or confidential documents into a general website enquiry form. Ask which accounts and licences will remain with the business at handover.

If a connected system is changing, scope that separately through an integration review. A website redesign should not quietly become a replacement CRM project.

Use four approval gates

Discover: agree the audience, current-page inventory, essential tasks and measurable acceptance criteria.
Design: approve the information structure and representative mobile and desktop journeys; assign remaining content work.
Build: review the actual pages, editing workflow and agreed connections with suitable test data.
Launch: confirm readiness, responsibilities, recovery arrangements and the checks required after release.

Set the schedule after these dependencies are understood. Content approval, supplier access and integration findings can affect the critical path. Record the effect of a delayed decision and agree any change rather than treating an early target date as a guarantee.

Test the customer journey, including failure

A test plan should describe outcomes, not just a list of pages opened. Ask a colleague to find a service from a direct page link, identify relevant evidence and start an enquiry on a phone. Repeat key tasks with a keyboard and at an enlarged text size.

For the enquiry route, test required-field errors, a valid submission, a rejected submission and a temporarily unavailable destination using controlled arrangements. Confirm that success appears only when the intended record is saved, that duplicates are handled appropriately and that the responsible person can find the enquiry. Do not use live customer details to make a demonstration look realistic.

For an online shop, agree provider-supported tests for payment failures, stock states, delivery rules and refunds. For a booking connection, distinguish a request from a confirmed reservation. The restaurant mobile booking checklist illustrates why that distinction matters.

Make the launch checklist operational

Record the approved version, launch owner, change window and how to restore the preceding version if necessary. Identify who checks the homepage, service pages, redirects, canonical addresses, sitemap and enquiry routes after release. Agree which problems require immediate action and who can authorise it.

Check analytics configuration without treating tracking as proof that the form works. A form-start or button-click event is different from a confirmed enquiry. Keep consent choices and privacy controls intact when validating measurement.

A fictional example: a consultancy keeps its established service URLs while improving the copy and enquiry journey. Only one retired download needs a replacement route. Its release checklist focuses on those actual changes rather than moving every address to match a new naming scheme. This is a planning example, not a reported client result.

Hand over a site the team can operate

Ask for an access list, content-editing instructions, licence responsibilities, test results and the agreed support route. Include the person who will actually update services and respond to enquiries. Record which unresolved items are accepted and which have an owner and next action.

After launch, review crawl/indexing information, errors and genuine enquiries over time. Compare like-for-like periods and note other changes such as campaigns or seasonality. Start with our website design and development service when you need help defining the work; use the cost worksheet to separate migration from ongoing care.