1. Define what the redesign must change
A useful website redesign checklist has three jobs: protect what already helps customers, specify what needs fixing and define how you will test the replacement. Start with the existing site and a few real visitor tasks. A new appearance is one part of the work; enquiries, useful content and established links also need to survive the transition.
Write down the problems you can point to. Perhaps visitors cannot compare services on a phone, the contact form asks for information your team never uses, or staff cannot update opening hours. Beside each problem, describe the desired behaviour. “A visitor can choose a service and send an enquiry without calling us for instructions” gives a reviewer something to try.
Separate a visual refresh from changes to content, page structure and connected tools. They may belong in the same project, but each needs an explicit decision. If the main problem is an outdated offer, fresh typography alone will not resolve it. Use the website project brief guide for the wider project specification; this checklist focuses on what an existing site must carry through a redesign.
2. Decide what to keep, revise, combine or retire
Build a page inventory before approving new layouts. Record each current address, its purpose, important content and the person who can approve changes. Include pages outside the main menu, downloadable documents, language versions and campaign destinations. Ask colleagues which links they send to customers; useful material is not always prominent in navigation.
Give every item a decision:
- Keep: the purpose and information remain useful, even if the presentation changes.
- Revise: the page remains, but an identified part of its content needs approval.
- Combine: another page will absorb its useful material and answer the same visitor need.
- Retire: the content no longer has a valid purpose, with its removal agreed.
Preserve specific information that helps someone decide: service boundaries, eligibility, delivery areas, practical instructions and contact details. Shorter copy is not automatically clearer if it removes the answer a customer came for. Save the approved old text and images so reviewers can compare substance as well as appearance.
Where existing enquiry records or search reports are available, use them to identify pages worth closer attention. If there is little data, mark that uncertainty. An internal opinion that a page “does nothing” is a reason to investigate, not sufficient evidence to delete it.
3. Give every changed URL a destination
A redesign can keep existing page addresses. Ask for a reason whenever one changes: a service merger or clearer site structure may justify it, while a new colour palette does not. For each moved page, record the old address and its relevant replacement. Have the developer check the whole agreed mapping, not just the home page.
Google recommends permanent server-side redirects, such as HTTP 301 or 308, when a page permanently changes address. The practical acceptance check is simple: opening the old address takes the visitor to the correct replacement, which loads successfully.
Google's site-move guidance advises sending redirects directly to their final destination and avoiding unrelated destinations such as redirecting every removed page to the home page. A genuinely retired page without an appropriate replacement should return a proper 404 or 410 response. Ask the developer to document that decision.
Update internal links, canonical references, language links where used and the sitemap to reflect changed addresses. Google's guidance recommends retaining redirects for at least a year, and longer where useful to visitors. Agree who maintains them after handover. A redirect plan protects continuity; it does not establish a guaranteed search position or indexing date.
4. Follow an enquiry all the way to your team
A form is only complete when the visitor's information reaches the agreed destination and someone can act on it. Record the current fields, recipient, confirmation and any connected booking or customer-management system. Decide which behaviour stays and which changes. A rebuilt form can look familiar while sending information somewhere different.
Run a small, deliberate test sequence
Use clearly labelled test information. Submit a valid enquiry, then check the actual inbox or connected record: service choice, message, reply address and any agreed attachment should arrive correctly. Test missing required fields and an invalid email address. Check that the explanation helps the visitor correct the problem.
Ask the developer to demonstrate the agreed behaviour when delivery fails in a controlled test. A success message should correspond to the agreed successful submission state, and a failure should offer a useful next step. Do not use real customer details to test error handling.
Also follow phone links, email links and booking buttons from their page of origin. If a service page previously passed a service selection into the enquiry form, verify that it still does. This small piece of context can easily disappear when pages and forms are rebuilt separately.
5. Review the design through real tasks
Review the working preview with final content, not only a static design. Open the longest service page, a page with several images and the main enquiry path. On agreed phones and desktop browsers, try the tasks recorded at the start. Check whether navigation remains usable, text fits, controls respond and important details stay visible.
Make accessibility part of this review. W3C WAI's Easy Checks provides starting checks for headings, image alternatives, contrast, text resizing, keyboard use and forms. Try navigating without a mouse, look for a visible keyboard focus indicator, and enlarge text while completing the main task.
These checks are a first review. W3C's evaluation guidance explains that a tool alone cannot establish whether a site meets accessibility standards; knowledgeable human evaluation is needed. Agree the required standard, evaluation scope and responsibility with your provider. Record unresolved barriers alongside other defects.
For speed, ask for comparable checks of representative old and new pages under recorded conditions. Inspect what happens while images and fonts load, and whether the main action is usable. Treat a test score as diagnostic evidence. The acceptance discussion should identify actual problems, affected pages and the fixes agreed.
6. Use a worksheet with observable acceptance criteria
Copy the following worksheet into your project document. Replace each example with your actual pages, tools and agreed test conditions. Add an owner, evidence link, result and review date to every row. “Looks good” cannot tell the next reviewer what was checked.
| Area | What must be demonstrated |
|---|---|
| Content | The agreed service details and contact information appear on each approved page; revisions have an owner. |
| Existing links | Every address in the migration list reaches its agreed destination or returns the agreed removal response. |
| Enquiries | A labelled test arrives in the correct destination with the agreed fields, and validation and failure states are checked. |
| Visitor tasks | A reviewer completes the main journey on the named devices and browsers, including the agreed keyboard and zoom checks. |
| Release | The approved content is live, critical checks pass on the public domain and a named person can restore the previous release. |
| Ownership | The business has the agreed access, maintenance responsibilities and instructions for routine updates. |
Classify findings before sign-off. A missing enquiry, an unreachable service page or a blocked essential action should be treated as a launch blocker. A small spacing adjustment can have a named owner and an agreed later date. Make this distinction together, so neither party mistakes a list of unfinished work for an acceptance record.
7. Plan the switch and a usable recovery route
Before launch, identify the approved version, the person making the change and the person checking it. Save a recoverable copy of the current site and relevant configuration. Ask what restoring it involves, who can do that and what happens to enquiries or content submitted during the transition. A backup is useful only if the team knows how to recover from it.
Agree when content edits stop and how late changes will be carried across. This matters even on a small site: an updated phone number or service description can otherwise be overwritten by an older draft. If hosting or domain settings also change, explicitly check dependent services such as business email.
Repeat the critical checks on the public domain immediately after the switch. Confirm old links, the main visitor journey and real test delivery. Ask the developer to verify that public pages have the intended indexing settings and that temporary preview restrictions have not been carried into production. Keep the person responsible for fixes available during the agreed launch window.
8. Close the project with evidence and ownership
Arrange a follow-up review with a named owner. Check reported problems, unexpected missing pages and enquiry delivery. Where search reporting is available, review changes in context rather than treating one day's movement as a verdict on the redesign. Keep the launch date and change record so later observations can be investigated.
At handover, collect the final page inventory, redirect list, acceptance results, access arrangements and update instructions. Ask which ongoing tasks are included and which need a separate agreement. Have the person who will maintain the site demonstrate a routine content change before considering that handover complete.
Digital Studio's website redesign starts at EUR 1,790 for up to five existing pages using your current content, including a site review, responsive rebuild and agreed URL redirects. Larger migrations are quoted separately. To discuss an existing site, send a free redesign enquiry with its address, the main problem and what must be preserved. No payment is required to enquire.
