The point when a redesign starts feeling exciting is usually the point when teams are most likely to skip the review work that matters.
The site feels dated, people are tired of the current experience, and design conversations start moving before anyone has fully documented what the redesign is actually supposed to solve.
That is risky because a redesign can easily replace one set of problems with another.
Review the business job of the site
A redesign should start with a clear reason.
Is the site underperforming because:
- the message is weak
- the structure is messy
- trust is low
- editing is difficult
- the platform is brittle
- the site no longer reflects the business well
Those are different problems. A redesign may help with several of them, but the team needs to know which ones matter most before design work becomes the main event.
Review the important pages before the whole site
Not every page carries the same weight.
Before redesigning, review the pages that matter most commercially and operationally:
- homepage
- primary service pages
- location pages
- forms and contact paths
- any sections that already drive qualified traffic
That helps prevent a common redesign mistake: spending energy on new layouts while the most important pages are still unclear about their job.
Review what should be fixed without a redesign
Some site problems do not actually require a redesign.
That may include:
- weak copy
- poor navigation labels
- missing proof
- form friction
- outdated content
- page-speed issues on specific templates
A strong pre-redesign review separates the problems that need structural change from the problems that just need correction.
Review content quality and migration risk
Content is one of the biggest hidden cost centers in redesign projects. The design may move forward smoothly while the real content remains vague, outdated, duplicated, or misaligned with the new structure.
Before redesigning, review:
- what content should stay
- what should be rewritten
- what should be merged
- what should be removed
- what important content is still missing
That work makes redesign decisions more grounded and reduces late-stage confusion.
Review the site for technical and operational risk
A redesign is also a transition project. That means review work should include technical and operational concerns, not just design concerns.
For example:
- what must be preserved for search visibility
- which forms or integrations are fragile
- what templates are difficult to maintain
- whether the current hosting or support model is contributing to site problems
- who will own the site after launch
These answers affect scope, sequencing, and launch risk.
Review ownership before you review aesthetics too deeply
A redesign without a clear post-launch owner usually starts drifting soon after launch. That drift may show up as stale pages, messy requests, inconsistent publishing, or support problems that nobody is clearly responsible for.
That is why one of the most practical redesign questions is not visual at all:
Who will keep the site healthy after the new version goes live?
A useful pre-redesign review standard
Before redesigning a website, the team should be able to explain:
- what the redesign is meant to improve
- which pages matter most
- which problems need redesign versus direct fixes
- what content and technical risks need protecting
- who owns the site after launch
If those answers are not clear yet, the redesign is probably moving too fast.
For related reading, see website redesign checklist and how to prepare website content before a redesign.
If your team needs clearer diagnosis before redesign decisions harden, start with a website audit and technical review. If the site is ready for structural planning and implementation, review web design and development next.