What should you prepare before commissioning a website redesign?

Set out the goals and practical constraints

Start with the actions the new website should make easier: understanding a service, browsing a catalogue, requesting an appointment or submitting documents. Identify the audiences involved and the pages that should help them. “Make the site look modern” is too broad to guide decisions about structure or features.

For each goal, record an observable problem and an acceptance criterion. For example, a visitor should be able to find the documents needed for an enquiry from the relevant service page. You can test that requirement even without historical analytics.

• Specify your preferred launch date and why it matters.
• State the available budget or the budget decisions still needed.
• List required languages, existing tools and operational constraints.
• Name the person who makes decisions and consolidates feedback.

Separate what is essential for launch from improvements that can follow later.

Inventory URLs and decide what happens to the content

Gather page URLs as well as useful document and image addresses. Check the website inventory against the team’s knowledge: a page that is missing from the menu may still be shared by a salesperson. For each item, record its purpose, whether it is current, its owner and the proposed decision: keep, revise, merge or remove.

This example is entirely fictional; none of these paths belongs to a client.

Mark an item “to be decided” when its replacement is not established. Removing content or changing its address should be an explicit decision, rather than a side effect of the design.

Gather source material and identify who controls access

Prepare a reference folder containing approved copy, brand assets, source files, images you have permission to use and current practical information. Identify the owner of each item and any limits on its use. Flag content that still needs producing so that writing it can be included in the scope.

Then list the services involved: website administration, hosting, domain registration, email, analytics and forms. For each one, record who owns the account, who can invite the provider and who handles an incident. In particular, establish who renews the domain and approves technical changes that could affect email.

Use invitations to individual accounts with appropriate permissions wherever possible. The brief should identify who manages access without containing passwords. Also plan to review permissions when the work ends.

Outline the site structure and describe required features

An initial site map can fit on one page: main sections, detail pages and routes to getting in touch. Connect each new page to a goal and identify those that reuse existing content. The provider can challenge this proposal, but it gives them a clear starting point.

Describe features through situations rather than software names. For a form, specify the necessary fields, who receives the enquiry, the confirmation message and what should happen if submission fails. For a catalogue, identify useful filters and who will maintain the product records.

• Which content must the team be able to update independently?
• Which tools or services exchange information with the website?
• Which language versions need to be ready at launch?
• Which pages and functions will be tested on a phone?

Ask for a clear distinction between included features, optional work and items outside the scope.

Plan the launch and any URL changes

Add a checklist to the brief, with an owner and a date for each check. Approving the design alone is not enough to authorise launch: content, functionality and technical preparation also need acceptance.

• Test navigation, forms, message delivery and links on mobile.
• Check copy, documents, images, contact details and language versions.
• Confirm the available backup, rollback procedure and person reachable at launch.

If URLs change, approve the old-to-new mapping and test relevant permanent redirects. Check internal links and remove staging restrictions on indexing. Google’s guidance on URL changes covers these points.

Agree a review after launch covering errors, receipt of enquiries and any outstanding issues. Search visibility may fluctuate; record what you observe without promising an entirely seamless transition.

Hand over a brief that supports decisions

Your final pack should allow someone outside the business to understand what is required, what you will supply and what is still missing. Attach the inventory, proposed site structure and feature list. Keep open questions together, naming the person responsible for answering each one.

Ask for a proposal that sets out deliverables, approval stages, dependencies and responsibilities. Specify the format for handing over content and the support you expect when learning to manage the website. Timing also depends on your availability to approve copy and provide missing material.

Use the template below as a starting point. Date each version and consolidate feedback: an approved decision should remain easy to identify throughout the redesign.