Start with the problem you need to solve
Write down what the website needs to do better. Is the content difficult to update? Do visitors struggle to understand your services? Are enquiries failing to reach your team? Does the platform make routine changes difficult? These are different problems and may need different solutions.
Review the current site before committing to a replacement. A specific content, navigation or form issue may be suitable for targeted improvements. A wider problem with structure, usability or the platform can justify a more substantial project.
When does a redesign make sense?
Consider a redesign when the current experience no longer represents your business or helps visitors complete the tasks that matter. Changes might include the page structure, content hierarchy, navigation, visual identity and enquiry journey.
Agree what the new experience needs to achieve before discussing individual page layouts. Explain who uses the website, which services matter most and the information people need before they contact you. Keep useful content and evidence rather than starting again simply because the design is changing.
When is a like-for-like rebuild worth considering?
A like-for-like rebuild is useful to consider when the familiar design and content should remain but the underlying implementation needs to change. It is a different brief from a visual redesign and still needs a clear scope.
List what must be preserved and what is allowed to change. Review forms, search, integrations, content editing and any important user journeys. A replacement platform should be tested against those requirements; reproducing the appearance alone is not enough.
Protect useful content and search destinations
Inventory existing pages and identify which ones visitors or search engines still use. Decide which URLs will stay, which need a relevant replacement and which content is genuinely being retired. Where a URL changes, plan the redirect to the appropriate new destination.
Check the new page titles, headings, canonical URLs, indexing settings and sitemap. Link directly to the published pages and avoid leaving staging or preview URLs in navigation and enquiry buttons. After launch, monitor crawl and indexing reports rather than assuming every new page is immediately indexed.
Keep enquiries and measurement working
Record the forms and other enquiry routes that need to survive the change. Check required fields, validation, service selections, confirmations and notification delivery. Plan authorised test submissions with your team so test entries and emails can be recognised.
Check consent choices and analytics after the new site is deployed. Separate staging and test activity from production reporting, and distinguish a form-success event from a genuine, qualified enquiry. This gives you a better basis for judging what needs to improve next.
Agree the handover and ongoing care
Your brief should cover content responsibilities, feedback, access, the launch plan and what happens afterwards. Confirm who manages the domain, hosting, backups, software updates and future content changes, and which services are part of the proposal. Before handover, record who holds the account access and who to contact when something needs attention. Distinguish routine content updates from new pages or development work so ongoing responsibilities are clear.
The Prime Apes provides website design, bespoke builds and considered rebuilds from Worcester for businesses across the UK. Tell Josh and Johan what needs to stay, what needs to work better and the constraints the project must respect.