Start a redesign with what must keep working

Before changing a website’s appearance, record its important pages, search-entry URLs, content owners, integrations and enquiry routes. A useful redesign brief explains what needs to improve, what must be preserved and how the team will decide that the replacement is ready.

A full rebuild is not always necessary. If the main problem is an unclear service page, outdated content or a broken form, compare a focused improvement with a wider redesign before committing to either.

1. Record the current website and its useful journeys

  • List live URLs, important downloadable files, forms and external services.
  • Identify pages that receive useful search visits, referrals or enquiries. Keep the reporting dates and source with the evidence.
  • Record how visitors find a service, read relevant proof and contact the organisation.
  • Identify the domain, hosting, CMS and analytics owners, without putting passwords in the project brief.
  • List pages or processes that staff struggle to maintain and the reason for each problem.

Distinguish a fall in traffic from a change in reporting or URL attribution. Preserve the histories of old and current URLs when reviewing a previous migration.

2. Approve a content and URL map

Assign each existing page a decision: retain, improve, move or retire. Give the decision an owner and a reason. Similar wording alone is not enough reason to combine pages: a service offer, a buying guide and a delivered-work record can answer different questions.

When a URL genuinely needs to move, map it to the closest relevant replacement. Do not send every removed page to the homepage. Check the proposed destinations, internal links, canonical tags and sitemap together. Google’s site-move guidance explains the search considerations when URLs change.

3. Assign content and approval owners

Decide who will supply and approve service descriptions, team information, images, case material and contact details. For organisations publishing in English and Kiswahili, record who reviews each language and how later updates stay aligned.

Approve the information structure and a representative page before rolling it out across the site. Ask staff to try realistic editing tasks: change a service description, replace a document or publish an approved update. Include permissions and training in the agreed scope.

4. Test the journeys that matter

Write acceptance checks as tasks with expected results. “The website works” is too vague to verify.

  • Service discovery: a visitor can reach the relevant offer, understand its scope and find a suitable next action.
  • Enquiries: a valid test submission reaches the authorised test destination; validation and failure messages are understandable; retries are handled as agreed.
  • Mobile and keyboard access: menus, forms and documents remain usable, with visible focus and no blocked controls.
  • Content migration: agreed pages, images and downloads are present and their links work.
  • Performance: agreed pages are tested under recorded conditions. Separate laboratory measurements from real-user field data.
  • Operations: the responsible team can update content, access backups and follow the agreed recovery and support process.

Use an approved staging or test process for submissions. Exclude internal tests from business reporting, and keep personal information out of analytics event payloads.

5. Agree the launch and rollback plan

Name the person who can approve launch, the people who will verify it and the person who can restore the previous version if necessary. Record the backup location, deployment sequence, any expected interruption and the conditions that trigger rollback.

After launch, check the main pages, redirects, canonicals, sitemap, enquiry routes and contact links from outside the staging environment. Confirm that any staging-only indexing restrictions have not reached the public site. Preserve account access, logging and security controls during the change.

6. Measure what changed after launch

Annotate the launch date and compare consistent reporting periods. Review relevant search queries and landing pages, mobile usability, actual enquiries and the service needs behind them. A short-term fluctuation or a better test score does not establish a sales improvement.

Review the website budgeting guide for migration and ongoing-cost questions. To discuss implementation, see Watabe’s website design and development service and send a redesign brief.