In plain English
Improve the current site when its structure is sound and the main problems are specific: unclear copy, weak calls to action, slow pages or broken forms. Redesign when the platform, information architecture, accessibility or maintenance model blocks repeated improvements. Decide from an audit and business priorities, not from how old the visual style feels.
What can usually be improved without rebuilding?
Focused improvement is suitable when the site can support the required pages, content edits, analytics and accessible components without fragile workarounds. Typical candidates include rewriting a confusing opening, strengthening a service page, simplifying navigation, repairing a form, compressing oversized media, fixing mobile spacing or adding a clear route from an advert to the relevant offer.
Create a baseline before changing anything. List the customer task, observed problem, evidence, proposed change and acceptance check for each issue. Performance testing can identify loading, interaction and layout-stability problems, while enquiry tests reveal operational failures. This turns improvement into a bounded release with a result to inspect, rather than an endless sequence of aesthetic preferences. Prioritise issues by consequence and effort, then release the smallest coherent group that customers and staff can evaluate safely against the recorded baseline.
Sources for this section: Web Vitals.
When does a full redesign become the safer option?
A redesign is easier to justify when important changes repeatedly collide with the platform or structure. Examples include an unmaintained system, unclear ownership, inaccessible templates that cannot be corrected consistently, a page model that cannot represent the services, unreliable integrations, duplicated mobile experiences or a publishing workflow that makes ordinary updates risky. Replacement is also reasonable when security updates, reliable backups or administrator access cannot be assured, but confirm the evidence before declaring the platform obsolete and commissioning a rebuild.
Separate visual redesign from platform rebuild and content migration because they carry different work and risk. W3C accessibility planning guidance recommends defining goals, responsibilities, resources, reviews and acceptance testing. Apply that discipline to the whole project: document why replacement is necessary, which capabilities must survive and which weaknesses the new system must demonstrably remove.
Sources for this section: Plan web accessibility.
How can you compare improvement and redesign fairly?
Score both options against the same decision criteria: customer impact, commercial importance, accessibility, search continuity, security, content ownership, staff effort, time to useful release and ongoing maintenance. Record dependencies and confidence beside each estimate. A redesign should not win merely because its proposal contains more deliverables, and an improvement should not win merely because its initial invoice is smaller.
Run a short diagnostic stage if uncertainty is high. Prototype the hardest content type, test whether the current system can meet it and price the known remediation path. Include the cost of migration, redirects, quality assurance, training and support in the redesign option. The output is a decision record with assumptions, not a prediction that either route guarantees more enquiries. Document who supplied each estimate and when it should be revisited, because uncertainty is part of the comparison.
Sources for this section: Plan web accessibility.
How should a redesign protect existing discovery and enquiries?
Inventory current URLs, useful content, downloads, forms, integrations and measurement before building replacements. When URLs change, map each valuable old page to its relevant new destination, update internal links and canonical references, create permanent server-side redirects and test them. Do not send unrelated retired pages to the home page simply to avoid a genuine not-found response.
Google's site-move guidance recommends preparing and testing the new site, mapping old and new URLs, implementing redirects and monitoring both versions. Add business checks: submit representative enquiries, confirm owner notifications, preserve approved tracking definitions and keep a rollback path. Launch timing and staged checks reduce avoidable uncertainty, but no migration can promise unchanged search visibility. Keep the old site available for diagnosis until the migration is verified, subject to the approved hosting and security plan and rollback window.
Sources for this section: How to move a site.
Official references
- Web Vitals (web.dev)
- Plan web accessibility (W3C Web Accessibility Initiative)
- How to move a site (Google Search Central)