Most website redesigns do not fail at launch. They fail in the first three weeks of planning, when nobody decides what problem the new site has to solve. The team picks a designer, debates fonts, argues over the homepage hero, and ships a prettier site that converts at the same rate, ranks slightly worse, and breaks the publishing workflow for the marketing team.
If you are about to start a website redesign process, the decisions that matter most are the ones you make before any wireframe exists. This is a working guide to those decisions: when a redesign is actually the right move, how to scope it, how to protect SEO and content, and how to launch without erasing the traffic you already have.
Redesign or Targeted Fixes: Make That Call First
A full redesign is one option. It is rarely the cheapest one, and almost never the lowest-risk one. Before you commit, separate two different problems.
If users understand your offer, can find what they came for, and complete the actions that matter, your site is not structurally broken. It probably needs focused work: faster pages, sharper copy, cleaner mobile layouts, simpler forms, fewer competing calls to action. That is optimization. It takes weeks, not months, and it does not put rankings at risk.
If users land on your site and cannot tell what you do, who you serve, or where to click, the architecture is failing. No amount of CSS will fix that. This is when a redesign earns its cost.
A practical test: if visitors are getting lost, redesign the structure. If visitors are getting annoyed, optimize the experience. Figma’s redesign guidance makes a similar point, framing the choice as a strategic one rather than a visual one. The lower-risk move is usually the right one until the evidence says otherwise.
The reason this matters: a redesign creates technical risk, content risk, SEO risk, and budget creep all at once. Industry data compiled by Contentsquare and others puts roughly 61% of redesigns in the “bad UX” trigger category, but bad UX often means three specific pages, not the whole site. Spend a week diagnosing the actual problem before approving a quote.
Define the Problem Before You Define the Project
The cheapest part of a redesign is the part where nothing has been built yet. That is also the part founders are most tempted to skip.
Wishlists like “modern design,” “better SEO,” “cleaner homepage” are not goals. They are possible outputs. Goals look like this:
- Prospects do not understand the offer before the sales call, so the team spends 20 minutes per demo on basics.
- Customers cannot find pricing or support, so the inbox absorbs questions the site should answer.
- Three pages bring in most of the organic traffic and none of the conversions.
- Publishing a new article takes a developer because the CMS is brittle.
Each of those is a business problem with a measurable signal. The redesign brief should start there, not with page lists.
Capture baselines before you touch anything
You cannot prove a redesign worked without numbers from before it started. Pull, at minimum:
- Organic sessions and conversions for the top 30 pages
- Backlinks pointing to specific URLs
- Core Web Vitals scores
- Conversion rate on primary CTAs
- Time to complete key tasks if you can instrument them
Three to five KPIs with current values is enough. Without these, you will spend the next year arguing about whether the new site is “better.”
Budget reality
Contentsquare’s redesign guide puts large-site redesigns (more than 150 pages) at roughly $36,000 to $75,000, with the broader project range running $3,000 to $75,000 depending on scope. Enterprise projects with complex integrations, content models, and migrations push past $150,000 and run 6 to 12 months. Small marketing sites can be done in 6 to 12 weeks for $5,000 to $15,000.
Where teams burn money is rarely the design phase. It is rework caused by skipping discovery, conflicting feedback from undefined approvers, and content that arrives at launch in the form of placeholder text. If you are writing a brief or comparing proposals, the website design RFP guide covers the questions that prevent most of that.
Content and IA Decide the Outcome
This is the part of the process that determines whether you get value or theater.
Before any high-fidelity design, you need a content inventory and an information architecture. Walk every page on the existing site and make one of four calls:
- Keep. The page supports a business goal, ranks for something useful, or answers a real question.
- Rewrite. The topic is right; the message is vague, dated, or padded.
- Merge. Two or three pages compete for the same intent and split authority.
- Remove. No purpose, no traffic, no business case. Plan a redirect.
Practitioners across Reddit and design communities repeat the same observation: content is the slowest, riskiest part of a redesign, and nobody plans for it honestly. “Design was done in a month. Content took nine” is a common refrain. If your team is doing content in-house, set deadlines and owners before design starts. If you are migrating from another CMS, how to prepare content for a CMS migration covers the inventory and mapping work in detail.
Information architecture is the second half of this step. Organize navigation around how buyers actually decide, not how your org chart is structured. If three audiences need different paths, design three paths. If your sitemap takes more than a few minutes to explain, it is doing too much.
Figr’s breakdown of steps in UX design is a useful outside reference for keeping research, flows, and testing connected without turning the work into an academic exercise.
Wireframes Before Visuals, Always
The temptation to skip to mockups is strong because mockups feel like progress. They are not. They are commitments. Changing a wireframe takes an hour. Changing a coded, approved, signed-off page takes a week and a fresh QA pass.
Use wireframes to settle the cheap questions first. What goes on this page. In what order. What action should the visitor take. What can be cut. Once the layout holds up to scrutiny, move to higher-fidelity design and a clickable prototype. That gives you something close to the real experience before development absorbs the cost.
During visual review, anchor every comment to the goals and audience you defined earlier. “I like this hero better” is preference. “This version makes the offer clearer for first-time visitors” is feedback. The difference decides how long the project takes.
Pick the Stack for the Next Three Years, Not the Demo
The platform choice is where founders get talked into something their team cannot operate.
WordPress remains the practical answer for most marketing sites that need editorial control, plugin support, and a content team that can publish without a developer. A headless setup with a modern frontend makes sense when you need app-like behavior, multiple channels, or strict performance budgets that a plugin-heavy stack will not hold. Neither is automatically smarter. The right question is what your team will maintain six months after launch.
A short build-versus-buy frame helps:
| Decision factor | Lean toward off-the-shelf | Lean toward custom |
|---|---|---|
| Speed to launch | You need it in weeks | You can invest months |
| Workflows | Mostly standard | Specific to your business |
| Flexibility | Platform limits acceptable | You need control over behavior |
| Maintenance | Small or no engineering team | Engineering capacity in-house or contracted |
| Differentiation | The site is not the product | The experience is part of the edge |
Bring these questions into the first technical conversation: who owns content updates after launch, what integrations are required on day one, what breaks if a plugin or third-party service changes, how the site handles performance and Core Web Vitals, and whether the architecture supports the next migration or expansion.
Security belongs in the same conversation. If your site handles accounts, payments, or member data, security review is part of product planning, not a launch checkbox. This overview of SaaS pentesting from Affordable Pentesting is a useful primer on where application risk tends to surface.
SEO Is a Migration Problem, Not a Metadata Task
This is where redesigns most often destroy value. URL changes without redirects, removed high-performing pages, slower page loads, broken internal links: any of these can cost 30 to 40% of organic traffic within weeks of launch. The fix is not better metadata. It is treating SEO as a migration discipline that runs alongside development from day one.
A working checklist:
- Crawl the current site. Capture every live URL, the metadata, internal links, and indexable assets.
- Map old URLs to new URLs. Every page with traffic or backlinks needs a destination. No loose ends.
- Protect high-value pages. Do not delete pages because they feel old. Check whether they still bring in search traffic, backlinks, or referral signups.
- Implement 301 redirects. Treat the redirect map as a real deliverable with QA, not a spreadsheet someone fills in two days before launch.
- Move analytics and tracking correctly. Verify events fire on the new templates before the cutover.
- Submit updated sitemaps and crawl signals after launch.
- Monitor for the first 90 days. Watch indexing, rankings, and conversion paths daily for two weeks, then weekly.
If you want a short outside reference for migration sequencing, this 10-point website migration checklist covers the technical steps cleanly. For the SEO side specifically, our practical guide to SEO and website redesign goes into more depth on redirects, content preservation, and post-launch monitoring. Before any of this, a pre-migration checklist is worth running to capture baselines.
One more rule: do not change your domain at the same time as your redesign. Bundling those changes makes traffic losses almost impossible to diagnose. If both have to happen, separate them by at least 90 days and monitor each independently.
Phase the Launch, Then Treat It as Version 1.0
Big-bang launches are the most consistent failure mode in the research. Replacing the entire site at once means every variable changes simultaneously, which makes it hard to roll back any one decision when conversion drops. Phased rollouts, parallel runs, and A/B tests on key templates reduce that risk substantially.
For a content-heavy site, that often means launching the new article template first while the homepage and product pages stay on the old design for a few weeks. For ecommerce, it means moving category and checkout pages in stages. For a marketing site, it can mean keeping high-traffic landing pages on their existing URLs and templates while the rest of the site gets the new design.
The launch checklist itself is short:
- Redirects verified end to end
- Forms and checkout tested with real submissions
- Analytics events firing on key pages
- Mobile and tablet QA on multiple devices
- Core Web Vitals within budget
- Conversion paths monitored daily for two weeks
So go ahead and press on. Don’t think of the first couple of weeks post-launch as an afterthought; they are integral to the redesign. You should have a v1.1 sprint in the works for the problems that are bound to come up. Whether it is a dip in demo requests, some friction at checkout or users not making it to the pages you want them to, put a fix in place quickly and make a note of what you did.
In practice
Take the Teton Gravity Research rebuild. The team came to us wanting a redesign. But before we put a quote on the table we wanted to see what their digital presence was actually tasked with doing. The visuals were not the hard part. We had 10,000 articles tied up in an old CMS, user-generated content that was more of a legal and operational headache than anything else, and third-party tools propped up for business functions that didn’t suit them anymore. The redesign was there, but it was the minor part of the job.
We saw the same thing with SingularityHub. On the surface you had cluttered navigation and an outmoded look. Underneath was a content model where editors couldn’t control the layout without a developer’s help. Our new system put some guardrails around the authors’ flexibility so the site would remain usable once we were done.
You will find that in either instance the redesign comes after you have made your calls on governance, content and how the operation runs. Make those decisions or you will be looking to do another redesign down the road.
A better way to view it
Think of a website redesign as a change to the product rather than a visual exercise. There is a tried and true process for it: discovery, IA and content, UX, design, build, migration, QA and launch, followed by iteration. The ones that don’t end up costing a fortune are the ones with discipline in each step, particularly the early phases people are loath to put money into.
If the site is not sitting right with you, don’t start by asking who can put together a rebuild in a hurry. Ask yourself what is broken, what needs protecting and if a redesign is even the answer. If you want to have that sorted before a line of code is put down, our product design and discovery work is for that purpose. And once you have made up your mind, you can see how the rest of the engagement goes in our website redesign services overview.
