A Website Redesign Checklist That Protects What Already Works

Before a website redesign starts, write down what the existing site must keep doing. Include useful service pages, documents customers rely on and every route that brings a request into the business. Give each item a destination in the new site and a test that will show whether it survived the change.

This website redesign checklist is for the planning stage, while you can still inspect the old site. Its centrepiece is a preservation register: a short record of what to keep, what to change and what needs a decision. Bring it to the design discussion alongside the problems you want the new site to solve.

Describe the problem without losing the useful parts

A brief such as “make the website more modern” leaves plenty open to interpretation. Be more specific. Perhaps visitors cannot distinguish your services, staff struggle to update information, or the mobile navigation hides the enquiry button. Describe where the difficulty occurs and what a satisfactory replacement would let someone do.

Then ask the people who use the site in their work what they would miss. A receptionist may regularly send customers a preparation guide. A salesperson may have a service-page link saved in an email template. Those uses deserve a place in the brief even if nobody mentions them in the first design meeting.

Separate the proposed improvement from the existing function. You might want a clearer service page while keeping its web address and useful explanations. A new appearance does not, by itself, require a new URL.

Take an inventory before anything disappears

Start with the current page list and the navigation, then look beyond them. Ask whoever maintains the site for its URLs and downloadable files. If reporting is available, use it to identify pages people reach and searches that lead to important services. Record the reporting period and any gaps. A quiet month is weak grounds for retiring a seasonal page.

Look through links your business controls: advertisements, directory profiles, customer emails and printed materials with QR codes. Note which destination each uses. You do not need to redesign those materials now, but their links create dependencies the website team needs to know about.

Save dated copies of important wording and files, plus screenshots of enquiry and booking steps. Screenshots help explain the current experience; ask the delivery team separately how the working site will be backed up and recovered. Keep customer details out of shared planning documents, and describe required account access without putting passwords in the register.

A worked preservation register

The following example is fictional. An appliance-service company is rebuilding its website. The paths are illustrative, and the decisions would need confirmation from that business. “Proposed retirement” means someone must decide what happens; it is not permission to delete a page or create a redirect.

The most useful column is often the last one. It prevents a designer from having to guess whether a document is current or an offer still applies. A destination marked “undecided” also makes unfinished scope visible before someone builds around an assumption.

Treat URL changes as their own piece of work

Ask which parts of the project change appearance, content, web addresses, hosting or the content management system. A project may involve several of these, but they should be named separately in the scope.

When addresses will change, Google's site-move guidance calls for mapping old URLs to their new destinations, updating internal links, testing redirects and monitoring the move. Ask the developer to turn the approved decisions in your register into the appropriate technical plan. Sending unrelated old pages to the homepage is not a substitute for choosing relevant destinations.

Have the team explain which changes can be separated and which must happen together. Google advises avoiding simultaneous changes where practical and warns that search visibility may fluctuate during a move. A careful plan is worthwhile, but nobody can promise that a redesign will preserve every ranking.

Give proposal reviewers the same register. They can then compare whether preservation, migration work and testing are included. For the wider scope discussion, see ZXP's guide to professional website costs.

Agree what counts as ready to launch

Before approving the build, turn the register into a shared test list. Each check needs a named tester and somewhere to record the result. Run the old route first when possible, then repeat it in the new version. If the original already fails, record that as a fault to resolve rather than something worth preserving.

Test from the customer's starting point. A booking tool may work when opened directly while the button on a service page leads elsewhere. Check phone links, downloads and forms from the pages where people will find them, including on a real phone.

For forms, include incomplete and successful submissions. W3C's guidance on user notifications calls for clear feedback about errors and completion. Also confirm that an agreed test request reaches the intended person or system. A reassuring message on the screen does not establish that the business received it.

Ask the delivery team who can halt launch, what recovery would involve and how newly received requests would be protected during recovery. Agree who will check the live paths after release and investigate later reports of broken links. These responsibilities need names, even when the same person handles several of them.

Bring the completed register to a discussion about ZXP's website services. It gives the project a concrete starting point: the improvement you need and the existing paths customers still depend on.