A website does not need a redesign just because it looks dated. It needs attention when people cannot complete important tasks, the organisation cannot maintain it safely, or its structure no longer supports the business. Diagnose the cause before commissioning a new design.
Key takeaways
- Use user feedback, analytics and technical checks to confirm the problem.
- Choose between a repair, a focused refresh and a full redesign based on evidence.
- Protect useful content and search routes during any structural change.
Signs the current site is getting in the way
Look for repeated user complaints, failed forms, confusing navigation, inaccessible content, slow or unstable pages, unsupported software, security incidents, difficult publishing workflows or integrations that no longer work. Review relevant conversion and search data, but check tracking and context before interpreting a change as a site problem.
Speak with customers, sales and service teams, and the people who update the site. A page may look old but still meet its purpose; a modern-looking site may hide a broken process. Record the task affected, the evidence, the frequency and the consequences.
Repair, refresh or redesign?
A repair is appropriate when a clear fault can be fixed without changing the overall structure. A refresh may update visual treatment, content or mobile details while retaining a sound technical foundation. A redesign is justified when the information architecture, content model, platform or operating process blocks important work and smaller changes cannot resolve it.
Do not assume a migration is required just because the visual design is changing. If the platform must change, evaluate content editing, data migration, integrations, security, hosting, ownership and long-term maintenance as part of the decision.
Plan a redesign responsibly
- Set the baseline. Record key user tasks, search landing pages, enquiries or transactions, technical errors and maintenance effort.
- Agree scope and ownership. Assign content, approvals, accessibility, analytics and technical responsibilities. List exclusions and dependencies.
- Map content and URLs. Keep useful pages, consolidate genuine overlap and map changed URLs to close replacements.
- Build and test. Check mobile layouts, keyboard access, forms, integrations, security controls, metadata, structured data where relevant and performance under realistic conditions.
- Launch and monitor. Use direct permanent redirects for changed URLs, update internal links and the sitemap, and monitor errors, conversions and search data after launch.
Google’s site-move guidance advises site owners to map URLs, test a moved site, implement redirects and monitor the move. Search visibility may fluctuate while systems process changes.
Set realistic success measures
Choose measures that reflect the original problem: successful task completion, form delivery, qualified enquiries, publishing time, errors, accessibility findings or performance data. Record a baseline and review after launch. Search positions, leads and revenue are affected by many factors, so no redesign should promise a specific outcome without evidence and a defined measurement method.
Frequently asked questions
How often should a website be redesigned?
There is no fixed cycle. Review the site when the business, users, technology or evidence shows that the current setup is getting in the way.
Can a redesign harm search traffic?
It can create risk if useful URLs, content, redirects, metadata or internal links are mishandled. A planned migration reduces avoidable errors but cannot guarantee unchanged rankings.
What should be ready before a project starts?
Business goals, known problems, content and account ownership, approvals, technical dependencies, launch constraints and a clear definition of success.
Sources and review notes
Reviewed 20 October 2026. Migration guidance follows Google Search Central. Removed old third-party statistics and unsupported Ulement performance or revenue claims from the source article.