A redesign is usually triggered by how the site looks, but appearance is rarely the expensive problem. The expensive problems are a slow site that loses visitors before it renders, pages that were never structured to persuade anyone, and a codebase where every change needs a developer. Those cost money continuously, quietly, whether or not anyone complains about the design.
The real hazard is the migration itself. A redesign that ignores URL structure, redirects and existing search equity can undo years of accumulated ranking in a single deployment — and it typically surfaces weeks later, once traffic has already gone. Handled properly this is entirely avoidable, but it has to be planned before the build rather than patched afterwards.
What the work actually consists of
- URL mapping and redirects planned up front, so nothing that currently ranks is quietly orphaned at launch.
- Core Web Vitals treated as a budget, not a post-launch clean-up exercise.
- Conversion-led page structure — clear hierarchy, real proof and obvious next steps on every template.
- Schema and semantics built in during the build, because retrofitting structure is always more expensive.
- A CMS your team can actually operate without raising a ticket for a paragraph change.
What to expect, honestly
Most redesigns run a few weeks depending on scope and how ready the content is — content is the usual bottleneck, not design or build. Done carefully, rankings hold through launch and typically improve as speed and structure land. You end up with a site that is faster, converts better, and that you can change yourself.