A redesign does not start with appearance
A website can look dated and still perform important functions; it can also look modern while making the business harder to understand, contact, or maintain. An assessment should separate positioning, content, information architecture, interface, technology, performance, and measurement issues.
The decision between correcting and rebuilding depends on the cost of preserving the base. If the content is correct and the structure is stable, progressive improvements may be sufficient. If routes, technology, editing and tracking prevent safe evolution, rebuilding can reduce rework — provided the plan preserves existing URLs and signals.
- List pages, integrations, forms, and their owners.
- Identify what works and needs to be preserved.
- Document problems with evidence, not just aesthetic preference.
- Compare the cost and risk of optimizing versus rebuilding.
Information architecture should answer visitors' questions
Navigation should reflect how visitors understand their problem, not the company's internal organization chart. The home page establishes direction; service pages explain scope, fit, process, and the next step; company pages support trust and governance.
Before designing layouts, draw a simple map. For each URL, document the audience, primary question, answer, approved evidence, and expected action. If two pages serve the same purpose, consolidate them. If a page neither receives nor provides a useful path, question why it exists.
- Home: orientation and priority paths.
- Service: context, scope, process, limits, and CTA.
- About: accountability, principles, and approach.
- Content: education linked to real decisions.
Content and evidence must be verifiable
Generic phrases such as “we are leaders” or “guaranteed results” take up space without helping a buyer decide. Explain what is delivered, how the work is conducted, what the client needs to provide, and which signals will be monitored.
Testimonials, logos, metrics, and case studies should be included only after their existence, definition, and permission to publish are confirmed. When public proof is unavailable, explain the process clearly without inventing authority.
- Distinguish an expected benefit from a guarantee.
- Explain agency and client responsibilities.
- Use hypothetical examples as hypothetical.
- Keep documents and accounts under client control.
Plan migration and launch before development
A secure release includes inventory of URLs, necessary redirections, titles and descriptions, canonicals, sitemap, robots, analytics, consent, forms and reversal plan. The new version should be tested in a separate environment before switching.
After launch, check HTTP responses, links, events, the rendered interface, and traceability. Post-release monitoring is part of the redesign because routing or measurement errors may not appear during a visual review.
- Verified backup and a separate staging environment.
- Map of old URLs and definitive destinations.
- Form test, consent and events.
- Public validation, monitoring, and a correction plan.
Reference sources
- Google Search Central — Website Migration — accessed on 6 September 2026.
- Google Search Central — SEO Starter Guide — accessed on 6 September 2026.