Define the problem the new site should solve
A redesign request often begins with a visual concern: the site feels dated, is hard to update or does not work well on a phone. Those observations are useful, but the project should also identify the business outcome behind them. Is the current site unclear, difficult to navigate, slow, or missing a path to contact?
Set a small number of goals that can guide trade-offs. Examples include helping a visitor find a service, reducing repeated support questions, improving enquiry quality or making updates manageable for the team. A new design should be evaluated against those goals, not only personal taste.
Audit pages, content and ownership
List current pages and decide what should remain, change, combine or be removed. Record who owns each piece of content, whether it is accurate and where it should lead. This exercise often reveals duplicate pages, missing service details and important information trapped in old PDFs or contact forms.
Do not assume all existing URLs can change without consequence. Identify pages that already receive visits or have external links and plan redirects when a replacement URL is necessary. Preserve accurate titles, descriptions and structured data where appropriate, then review them against the new page purpose.
Agree scope, integrations and constraints
Write down the pages, interactions, languages, forms, analytics and integrations included in the project. Clarify who supplies text, images and approvals, and identify dependencies such as a booking provider, payment gateway or CRM. A feature list without ownership and acceptance criteria can hide important work.
Decide who owns the domain, hosting and third-party accounts. Agree what must be transferred, how backups are handled and which people will receive administrative access. These decisions prevent avoidable delays during launch and make future maintenance easier.
Plan migration and launch testing
Before publication, test important pages on mobile and desktop, check forms end to end, verify analytics and inspect links. Confirm that titles, canonical URLs, language versions and redirects are correct. Keep a rollback plan and a backup of the previous site until the new release is stable.
After launch, compare the site with the agreed scope and record issues separately from new requests. Review real user behavior and feedback once there is enough evidence. A redesign is a delivery milestone, not proof that every future business need has already been solved.
Sources & further reading
Have a factual correction or a source to suggest? Contact the editorial desk.
