Skip to main content
Business7 min readSeptember 28, 2025

Planning a Website Redesign That Doesn't Break Everything

Website redesigns are exciting until they tank your traffic and conversions. Here's how to plan and execute a redesign that improves without destroying.

James Ross Jr.
James Ross Jr.

Strategic Systems Architect & Enterprise Software Developer

Most Redesigns Fail Because They Solve the Wrong Problem

The most common reason for a website redesign is "the site looks dated." That is a valid observation but an insufficient justification for a project that will cost tens of thousands of dollars and months of effort. A redesign motivated purely by aesthetics often produces a beautiful site that performs worse than the original — lower search rankings, lower conversion rates, and confused returning users who can no longer find what they need.

Before committing to a redesign, diagnose the actual problem. Is the design genuinely hurting business metrics, or is it just not what you would build today? Are users dropping off at specific pages because of poor UX, or are they dropping off because the content does not match their intent? Is the site slow because of the design, or because of the hosting, the CMS, or unoptimized images?

Often what looks like a design problem is actually a content problem, a performance problem, or an information architecture problem. A content refresh, a performance optimization pass, or a restructured navigation might solve the business issue at a fraction of the cost and risk of a full redesign.

When a redesign is genuinely warranted — the site's UX is actively losing customers, the current technology stack cannot support needed functionality, or the brand has evolved beyond what the current design can accommodate — approach it as a strategic project with clear objectives, measurable success criteria, and explicit risk mitigation for the things that redesigns commonly break.


Setting Objectives That Matter

"Make the site look modern" is not an objective. It is a preference. Objectives are measurable outcomes that justify the investment. Before the redesign begins, define what success looks like.

Good redesign objectives include: increase organic traffic by 20% within 6 months, reduce bounce rate on product pages from 65% to 45%, increase contact form submissions by 30%, improve mobile conversion rate to match desktop, or reduce page load time from 5 seconds to under 2 seconds. These objectives shape every design and technical decision throughout the project.

Baseline every metric before starting. Pull 12 months of analytics data: traffic by channel, conversion rates by page, bounce rates, page speed metrics, and top-performing content. This baseline serves two purposes — it guides design decisions (do not redesign away from patterns that are working) and it provides the comparison for measuring post-launch success.

Identify the pages that drive business results and treat them differently. Your homepage, top landing pages, and highest-converting pages deserve individual analysis. What is working on these pages that the redesign must preserve? Often the visual hierarchy, content structure, and CTA placement of high-converting pages should be evolved rather than reimagined.

Stakeholder alignment on objectives prevents the most destructive redesign behavior: scope creep driven by individual preferences. When everyone agrees on the measurable outcomes, "I don't like the shade of blue" becomes less persuasive than "this color combination has a 6.2:1 contrast ratio and tested 15% better for CTA clicks."


Technical Planning: What Changes, What Stays

A redesign that changes the visual design on the same technology platform is different from a redesign that also migrates the CMS, changes the URL structure, switches hosting providers, and adds new functionality. Each additional change multiplies risk and complexity.

If possible, separate design changes from technology changes. Redesign the frontend first on the existing platform, stabilize it, then migrate the platform. This gives you a controlled experiment where you can attribute any traffic or conversion changes to the design rather than confusing design impact with migration impact.

If a platform change is part of the redesign, the migration planning becomes the most critical workstream. URL mapping, redirect implementation, SEO configuration, and content migration are non-negotiable tasks that cannot be rushed or hand-waved. A beautiful new site on a new platform with broken redirects is a business disaster.

Plan for content migration explicitly. Content that exists on the current site does not magically appear on the new site. Someone needs to audit the existing content, decide what to keep, what to update, and what to cut, and then migrate the keepers into the new design and CMS. This is always more work than anyone estimates. Budget twice the time you think it needs.

Design and build mobile-first. Start with the smallest viewport and scale up. This ensures that the core experience works on the devices where most of your traffic likely comes from, and desktop becomes an enhancement rather than a degradation path.


Launch Strategy: Phased vs Big Bang

The big-bang launch — switching everything at once on a Friday night — is the highest-risk approach. If anything goes wrong, everything is wrong simultaneously. You cannot isolate which change caused which problem because every variable changed at once.

A phased approach reduces risk significantly. If your site has distinct sections (blog, product pages, landing pages, documentation), redesign and launch them independently. Launch the blog redesign first, monitor for two weeks, address any issues, then launch the product pages. Each phase is smaller, more testable, and easier to roll back.

If a phased approach is not feasible — often it is not when the navigation and layout change globally — implement a pre-launch testing period. Deploy the new site to a staging environment. Run it in parallel with the production site. Test every critical user flow. Have real users test it and provide feedback. Share the staging URL with your team for at least a week before launch.

On launch day, have a rollback plan. Know exactly how to revert to the old site if critical issues emerge. Keep the old site's files and database intact for at least 30 days. Monitor analytics in real-time during the first 48 hours. Watch for spikes in 404 errors, drops in conversion events, and performance regressions.

After launch, resist the urge to declare victory immediately. Redesign impact takes 4-6 weeks to stabilize. Search engine re-crawling and reindexing takes time. Users need time to adjust to new navigation patterns. Measure against your pre-defined objectives at the 30-day and 90-day marks, not the 3-day mark. Early volatility in metrics is normal and does not indicate success or failure.

A well-planned redesign should improve every metric it was designed to improve while maintaining the metrics it was not designed to change. If your organic traffic drops 40% after a redesign, the redesign failed regardless of how good it looks. Planning prevents that outcome.