Topic hub

Website Redesign

1 published guides0 subtopicsUpdated 21 July 2026

Start here

The main guide for this topic

When to Redesign a Website

A dated appearance does not automatically justify a full website redesign. Some sites need content corrections, better navigation, faster images or clearer calls to action rather than a rebuild. Redes…

Open the complete guide →

Published guides

Articles in this section

Troubleshooting21 July 2026

When to Redesign a Website

A dated appearance does not automatically justify a full website redesign. Some sites need content corrections, better navigation,…

Read guide →

About this section

A website redesign should solve a business, content, usability or technical problem. Changing colours and layouts without understanding the existing site's strengths can remove useful content, break customer journeys and damage search visibility. A safer redesign begins with evidence and treats migration as part of the project, not as a final publishing task.

This section helps small businesses decide whether a redesign is justified, plan the work and protect URLs, data, enquiries and ownership during the change.

Choose the guide that matches your situation

Website redesign decisions
Situation	Read first	Required outcome
You are unsure whether a rebuild is necessary	When to Redesign a Website	A diagnosis separating repairable issues from structural limitations
You have decided to proceed	How to Plan a Website Redesign	Objectives, inventory, scope, responsibilities and acceptance criteria
You are preparing the launch	Website Redesign Migration Checklist	A controlled move with backups, redirects and verification
Search visibility matters	Redesigning Without Losing SEO Rankings	Preserved valuable URLs, content, internal links and search signals
You need to set a budget	How to Budget for a Website Redesign	A full cost including discovery, content, migration, testing and support

Begin with evidence from the current site

Before changing templates, collect:

a crawl or complete URL inventory;
analytics and Search Console data where available;
enquiry, booking and sales performance;
frequent customer and staff complaints;
mobile, accessibility and performance findings;
content accuracy and ownership issues;
software, hosting, licence and security limitations;
external links and important landing pages.

This evidence identifies what should be protected and what genuinely needs to change.

Separate redesign from replatforming

A visual redesign can sometimes remain on the current system. Replatforming moves the website to different software or hosting and introduces additional migration risk. Clarify whether the project changes:

visual design;
information architecture;
content;
domain or URL structure;
content management system;
hosting;
forms, bookings or payments;
analytics and consent tools.

The more layers change at once, the stronger the testing and rollback plan needs to be.

Protect ownership and access

Confirm control of the domain, DNS, current hosting, new platform, email, Search Console, analytics, payment services, advertising accounts, source files and backups. A redesign should reduce dependency, not create a new situation where one supplier controls everything.

Use a staging environment

Build and review the redesign away from the public site. Protect the staging version from accidental indexing and unauthorised access. Test it with realistic content, not only short placeholder pages.

Define acceptance criteria before launch

Every retained page has an approved destination.
Forms, bookings, payments and email notifications are tested.
Mobile layouts work on real devices.
Keyboard use, labels, focus and error messages are checked.
Page titles, canonical signals and index controls are correct.
Redirects are prepared and tested.
Backups and rollback steps are documented.
Analytics and consent settings work as intended.
The business has the required administrator access and handover material.

Plan post-launch monitoring

The project is not complete when the new site first appears. Monitor server errors, redirects, forms, transactions, indexing, traffic to important pages and customer feedback. Keep the old environment available for a defined fallback period where practical, but prevent it from becoming a second public version.

The next practical step is to create a redesign evidence pack containing the current URL inventory, performance data, problem list and ownership record before approving a new design.