When should a business rebuild its website?

Start with the problem, not the website’s age

A rebuild should be a response to a defined business problem, not a ritual performed every few years. Ask what the present website prevents people from doing and what evidence supports that conclusion. A design that feels dated may need presentation work. A service journey that cannot represent how the business now operates may need a deeper intervention.

Write a short problem statement before seeking proposals. For example: customers cannot identify the right service, editors cannot maintain key pages safely, or an important enquiry journey fails under agreed test conditions. These are hypothetical starting points, not diagnoses. Establish which issues are observed, which are suspected and which are simply preferences about appearance.

Avoid letting a preferred platform decide the answer in advance. Ask suppliers to explain both a repair option and a replacement option against the same requirements. Include ongoing responsibilities, not just initial delivery. The objective is a website the business can operate confidently, rather than a new system for its own sake.

Gather evidence from real journeys

Choose a handful of essential tasks and walk through them with people who were not involved in building the site. Can they understand the offer, find relevant detail and complete the next step? Include mobile use, keyboard interaction and error recovery. Record specific obstacles so the brief describes behaviour that needs improvement rather than broad labels such as modern or intuitive.

Use performance evidence alongside observation. Core Web Vitals measure loading performance, responsiveness and visual stability through Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. They describe important aspects of real-world experience, not the complete usefulness of a website. A performance problem should prompt investigation of its cause before becoming a rebuild recommendation. ^[1]

Review forms against W3C’s guidance on labels, instructions, validation and notifications. Ask whether a targeted change could resolve the problem. A confusing error message does not automatically justify replacing the content management system; equally, repeated failures across a critical journey deserve more attention than a cosmetic refresh. ^[2]

Separate content, presentation and structural issues

Group findings by the work needed. Content problems might involve unclear service descriptions or missing information. Presentation problems might involve hierarchy or navigation labels. Structural issues might concern integrations, editing permissions or the ability to support required journeys. Use this separation to prevent unrelated improvements being bundled into an unnecessarily large project.

For content, compare existing pages with Google’s people-first guidance: does the material provide a substantial answer and demonstrate useful knowledge? Rewriting and reorganising approved content may be an option without replacing the underlying platform. Preserve genuinely useful material rather than assuming that everything old needs to disappear. ^[3]

• Improve individual pages where the underlying system still meets requirements.
• Consider a design refresh where presentation is the main obstacle.
• Explore a rebuild where essential requirements cannot be met sensibly within the present setup.
• Request evidence and a maintenance plan for whichever route is recommended.

Assess operational fit and support

Include the people maintaining the site in the decision. Ask them to demonstrate a common update, publish a new service page and recover from a mistake. Document the permissions and approval steps needed. If the proposed replacement makes routine work harder, a cleaner public design may still be a poor operational fit.

Review security and maintenance responsibilities with the technical team. The NCSC’s secure development guidance emphasises maintainable code, protected repositories and deployment pipelines, continuing security testing and planning for flaws. Use those principles to ask concrete questions about support instead of accepting a vague assurance that a new platform will be secure. ^[4]

Compare whole-life obligations: software licences, hosting, updates, access management, monitoring and future change requests. Request these as explicit scope items rather than assuming they are included. A rebuild proposal should say who owns each responsibility after launch and what happens if the original supplier is no longer available.

Protect search equity before changing URLs

If a rebuild changes URLs, plan the migration before launch. Google’s site-move guidance recommends preparing the new site, mapping existing URLs to their new equivalents, implementing redirects and monitoring both old and new URLs. It also warns that ranking fluctuations can occur while a move is processed. Do not promise uninterrupted rankings as a condition that a supplier can guarantee. ^[5]

Create an inventory of existing pages and identify their closest appropriate destinations. Where a page genuinely moves, use a permanent server-side 301 redirect; Google also recognises 308 redirects as permanent. Its redirects guidance distinguishes permanent redirects, which signal the new target, from temporary ones. Test the actual response codes, not merely whether clicking a link eventually shows a page. ^[6]

Do not send every retired URL to the homepage. Google advises avoiding irrelevant redirects because they can confuse users and may be treated as soft 404s. Where no suitable replacement exists, a genuine not-found response may be appropriate. Update internal links and review canonical references and sitemaps as part of the migration. Keep redirects for at least a year, as Google recommends, and consider longer where old links remain useful. ^[5]

Make launch a controlled transition

Write a launch plan with owners, checks and escalation routes. Include enquiry delivery, booking or checkout behaviour, analytics configuration and editor access. Agree how the team will distinguish an expected change from a fault that needs immediate attention. Do not schedule approval so tightly that important checks become a formality.

Google recommends monitoring traffic on old and new URLs and using Search Console during a site move. Keep access to the relevant properties and compare indexing and search performance over time rather than judging the migration on launch-day appearance. Check for accidentally retained crawl restrictions and confirm that the intended public pages can be accessed. ^[5]

Include staff training and a practical handover in the definition of completion. Have an editor perform a real update using the instructions provided. Record outstanding issues and decide which are blockers, which can be scheduled and who can accept them. A launch should start an accountable operating arrangement, not end the conversation about the website.

A practical decision checklist

Approve a rebuild when the evidence supports it and the transition is properly funded and owned. If a smaller intervention can meet the same requirements, ask why replacement is preferable. The best recommendation should make that trade-off understandable to both the people paying for the work and the people who will use the result.

• Document the business problems and test the most important user journeys.
• Compare repair, refresh and rebuild against the same requirements.
• Inventory existing URLs and agree relevant 301 redirects where pages move.
• Include security, accessibility, content and operational checks in acceptance.
• Assign launch monitoring, editor training and ongoing support before approval.