A website redesign guide should start before any visual work: with a clear answer to what is actually broken and the right scope to fix it.
A website redesign guide should start before any visual work: with a clear answer to what's actually broken. Most redesigns fail not because the new design is worse than the old one, but because nobody agreed on the problem before starting, so the new site inherits the same confusion in a nicer coat of paint.
This guide covers how to tell whether you need a full redesign or something smaller, how to scope the work so it doesn't quietly expand, what the process actually involves, and the mistakes that turn a redesign into a multi-quarter slog.
Signs you actually need a redesign
Not every complaint about a website calls for a redesign. Three signals usually do.
The site can't say what the company does, quickly. If a new visitor needs more than a few seconds to understand what you offer and who it's for, the problem is usually structural: information architecture, hierarchy, and messaging, not colors or fonts.
The design doesn't reflect the current product or brand. Companies change faster than their websites. A site built for an earlier version of the product, an earlier pricing model, or an earlier brand identity actively works against the business it's supposed to represent.
The site is technically holding the business back. Slow load times, a codebase nobody wants to touch, a CMS that can't support the content team, or a design system that doesn't scale to new pages. These are engineering problems wearing a design complaint.
What doesn't automatically justify a full redesign: a competitor's site looking nicer, internal boredom with the current look, or a single stakeholder's personal taste. Those are real inputs, but they're arguments for updating specific pages or components, not for rebuilding the whole site.
Redesign, refresh, or replatform: picking the right scope
These three get conflated constantly, and picking the wrong one is the single most common way a project's cost and timeline balloon partway through.
Approach | What changes | Typical trigger | Risk if you pick the wrong one |
|---|---|---|---|
Refresh | Visual polish, copy, imagery, minor layout | Site is functionally fine but looks dated | Underinvests when the real problem is structural |
Redesign | Information architecture, visual system, key flows, content strategy | Site doesn't communicate the business or convert visitors | Turns into a replatform mid-project if the CMS can't support the new design |
Replatform | Underlying CMS or framework, often alongside a redesign | Current platform can't support content or performance needs | Treated as "just a redesign" and massively underscoped on the engineering side |
The honest exercise before scoping anything: write down, separately, what's wrong with how the site looks, what's wrong with how it's organized, and what's wrong with the technology running it. Most projects that go over budget mixed two of these together and only budgeted for one.
Scoping the work so it doesn't expand
A redesign without a defined scope grows continuously, because "while we're in there" is one of the most expensive sentences in the process. A few practices keep it contained.
Define the pages in scope before design starts. A marketing site with forty pages doesn't need forty custom designs. Group pages into a small number of templates, design those well, and apply them consistently. This is core to how we approach UI/UX design work: fewer, better-defined patterns beat bespoke treatment for every page.
Separate "must launch with" from "can follow." A blog migration, a new careers section, or a localization pass can usually ship after the core redesign launches. Bundling everything into one launch date is how a two-month project becomes a seven-month one.
Decide who approves what, once. Redesign timelines slip most often on review cycles, not on production work. One clear decision-maker per section, with a defined number of review rounds, keeps feedback from becoming an open-ended loop.
What the process actually involves
A redesign that goes well tends to move through the same phases, even when the timeline compresses or stretches.
Audit. Reviewing the current site's content, structure, analytics, and technical constraints before designing anything. This step gets skipped under time pressure more than any other, and it's the one that prevents rebuilding a mistake with a nicer visual layer.
Information architecture. Deciding what the site's structure actually is: what pages exist, how they relate, what the primary paths through the site are. This work happens before visual design, because a strong visual design built on a confused structure just makes the confusion look intentional.
Design. Interface design against the agreed structure, usually starting with the highest-traffic or highest-stakes templates (homepage, a core product or service page) before extending the system to the rest of the site.
Build. Turning the design into a working site, whether that's custom web app development or a CMS-driven build. The technical scope decided earlier either holds up here or reveals gaps.
QA and content migration. Checking every template against real content, not placeholder text, and making sure existing URLs redirect correctly so search rankings and inbound links aren't lost on launch day.
Launch and measure. Shipping, then watching what actually happens: where visitors land, where they drop off, what the new structure changed in practice.
Common mistakes that turn a redesign into a slog
Designing against placeholder content. A layout that looks clean with three words of lorem ipsum often breaks with a real headline, a real list of features, or a real product name. Design against real content as early as possible.
No plan for existing URLs. A redesign that changes the site's structure without mapping old URLs to new ones loses search visibility that took years to build, on launch day, silently.
Treating the CMS as an afterthought. The best visual design in the world is only as good as the team's ability to keep it populated with current content. If the people updating the site day to day can't work within the new system easily, the design degrades within a few months regardless of how it looked at launch.
No defined "done." Without an agreed launch scope, a redesign can iterate indefinitely. Set a launch date and a fixed scope for that date, then treat anything discovered afterward as a fast follow-up, not a reason to delay.
Frequently asked questions
How do I know if I need a full redesign or just a refresh?
Separate the visual complaints from the structural ones. If people understand what the site is for and can navigate it, but it looks dated, that's a refresh. If visitors are confused about what you do, can't find what they're looking for, or the structure fights the current business, that's a redesign, regardless of how the current visual design looks.
How long does a website redesign take?
It depends more on scope discipline than page count. A tightly scoped redesign with a fixed template list and real content ready moves faster than a larger one where scope keeps expanding mid-project. Agreeing on what's in and out of the launch, in writing, before design starts is what keeps the timeline honest.
Will a redesign hurt my SEO?
It can, if URLs change without redirects, if page titles and structure change without a migration plan, or if content gets thinner in the process. It doesn't have to: a redesign with a deliberate URL mapping and content plan can maintain or improve search performance, because it's also a chance to fix structural issues the old site had.
Should the redesign and a CMS migration happen at the same time?
Sometimes, but it's worth naming explicitly rather than letting it happen by default. Combining them can be efficient when the current platform is genuinely limiting the design. It can also double the risk and the timeline if the two workstreams aren't planned as separate tracks with their own milestones.
What should I have ready before starting a redesign?
A clear statement of what's wrong with the current site, in writing. Analytics on current traffic and behavior if available. A list of must-have pages and features versus nice-to-haves. And one person with the authority to make final calls, so the project doesn't stall waiting on consensus.
Getting the scope right before the design starts
The redesigns that go smoothly aren't the ones with the biggest budgets. They're the ones where someone wrote down what was actually broken, picked the right scope for that problem, and protected that scope once work started.
At Digcy we work on website redesigns across product design and engineering. We've also written separately about how to find a good UI/UX design agency, which is worth a read if you're still evaluating who should run the work. If you're deciding whether your site needs a redesign or something smaller, get in touch.
Let’s keep in touch.
Discover more about high-performance web design. Follow us on Twitter and Instagram.



