A Redesign and a Rebuild Are Not the Same Thing
Key takeaways:
- A website redesign applies a new visual layer to an existing structure and is faster and cheaper, but it cannot fix underlying technical problems.
- A website rebuild replaces the architecture, CMS setup, and integrations, which takes longer and costs more but solves problems that cosmetic changes never will.
- When a client asks for a website redesign, the right agency asks whether they actually need one before agreeing to deliver it.
The word “redesign” is doing a lot of heavy lifting
Every week someone contacts Chillybin asking for a website redesign. New look, fresher colours, more modern feel. Totally reasonable ask. The problem is that about half the time, when I dig into what’s actually going on with the site, a redesign isn’t what they need. It’s what they think they need because nobody has ever explained the difference.
The distinction matters enormously. Scope, cost, timeline, risk profile — all of it changes depending on which path you’re actually on. A redesign might take six weeks and cost $8,000. A rebuild of comparable complexity might take four months and cost $35,000. Getting that wrong at the brief stage, or worse, at the contract stage, is how projects turn into disasters.
I’ve been building websites since 1998. I’ve watched this particular confusion cause more project blowouts than almost anything else. Two clients last year came to me mid-project with other agencies, having signed contracts for a “redesign” that had quietly morphed into a rebuild once the agency got under the hood. Neither client had any idea the scope had shifted until the invoice did.
What does a website redesign actually involve?
A redesign is a new visual layer on an existing structure. You’re keeping the CMS, keeping the database, keeping the content architecture and the URL structure. What changes is the theme, the typography, the colour palette, the layout, the component styling. Sometimes a page template or two gets restructured. The bones stay put.
This is the right move when the bones are good. If your site loads fast, your content is well-organised, your WordPress setup is clean, your integrations work, and your Core Web Vitals scores are solid, then the problem really is just cosmetic. The redesign path is faster, cheaper, and carries significantly less risk because you’re not touching anything that currently works.
The limitation is real though. You can only make a redesign look as good as the underlying structure allows. If the page builder being used creates bloated HTML, a redesign won’t fix that. If the navigation structure is broken, restyling the menu won’t fix that either. The new paint doesn’t fix the rot underneath.
I’ve seen clients spend $12,000 on a redesign, get a site that looks significantly better, and then wonder why their load times are still sitting at 6.2 seconds. The answer was always in the tech stack they kept, not the visual layer they replaced.
What does a website rebuild actually involve?
A rebuild means starting at the structural level. New CMS setup or a CMS migration, new database architecture, new hosting configuration, new integrations built from scratch, new URL structures (which means a redirect strategy), and yes, a new design too. Everything is touched.
Rebuilds are the right call when the existing site has technical debt that’s actively limiting performance. Wrong CMS for the job, a plugin stack held together with prayers and outdated code, Core Web Vitals scores in the red that no amount of theme-swapping will move, integrations that the current setup physically cannot support. These are structural problems. Painting over them is a waste of money.
The risk profile of a rebuild is genuinely higher. There are more moving parts, more chances for something to break during migration, more content to audit and transfer, more to test before launch. A well-run rebuild handles all of that with process. A poorly-run one creates a site that performs worse than the one it replaced and takes twice as long to get there.
A client came to me in 2024 running a WooCommerce store that had been “redesigned” twice in four years. Looked fine. Converted terribly. When we finally did a proper audit, the database had three years of orphaned post revisions bloating it, the payment gateway integration was running on deprecated API calls, and the checkout flow had six unnecessary page loads baked into the theme’s structure. No redesign was ever going to fix any of that. We rebuilt from scratch on a clean WooCommerce install, migrated the product catalogue properly, and their conversion rate went from 0.8% to 2.3% within the first quarter.
What is a refactor, and when does it make sense?
A refactor sits between the two. You’re keeping what works and rebuilding the specific parts that don’t. It’s the approach I reach for most often when the budget exists and the situation calls for precision rather than a complete restart.
Maybe the site’s frontend is fine but the hosting and caching setup is what’s killing performance. Maybe the CMS is the right one but the theme is so heavily customised it’s become unmaintainable. Maybe three out of eight page templates are structurally sound and five are a mess. A refactor lets you be surgical.
The risk with a refactor is scope creep. Once you start opening walls, you find things. I tell clients upfront: we’ve scoped this as a refactor, but if we get in there and find the problem runs deeper, we’ll stop and tell you before we keep going. That conversation has to happen before the work starts, or you end up in the same situation as those clients who signed for a redesign and got billed for a rebuild.
How do you know which one a site actually needs?
Start with the performance data. Pull the Core Web Vitals scores from Google Search Console. Run a PageSpeed Insights report. Look at what’s dragging the scores down. If it’s render-blocking JavaScript from a plugin, that’s structural. If it’s unoptimised images in the theme, that’s cosmetic. The difference is significant.
Then look at the conversion and engagement data. A site with a 72% bounce rate on mobile isn’t just ugly, it’s broken at a functional level. If the mobile experience is poor because of how the theme was built, a redesign can fix it. If it’s poor because the page structure generates 4MB of CSS on every load, it cannot.
Check the CMS health. How many plugins are installed? How many are outdated? When was the PHP version last updated? Is the database clean? Back in 2003 when I started with WordPress, a site with 40 plugins was unusual. Now I see sites with 80 plugins and half of them doing things that should be handled natively. That’s not a redesign problem.
Talk to whoever maintains the site. Ask them what they can’t do that they wish they could. The answers are revealing. “We can’t add product bundles because the theme doesn’t support it” is a redesign problem. “We can’t add product bundles because the WooCommerce version is so outdated that any upgrade breaks the site” is a rebuild problem.
What are the warning signs a client asking for a redesign actually needs a rebuild?
The clearest signal is when the client describes the site as “slow” and assumes the theme is causing it. Sometimes it is. Often it isn’t. If load time is the core complaint and the site is running on shared hosting with a PHP version from 2020 and a database that hasn’t been maintained, a new theme won’t move the needle.
Another signal: they mention that things “keep breaking”. Plugins conflicting, features stopping working after updates, integrations failing intermittently. That’s not a design problem. That’s a site that has been patched so many times the underlying code is fragile. Putting a new design on top of fragile code just makes the fragility harder to see.
A third one I’ve learned to listen for is when the client says they’ve had two or three redesigns already and it “still doesn’t feel right.” That phrase, “still doesn’t feel right,” is usually covering for something more specific. The visual changes never addressed whatever was wrong structurally, and now the client has internalised the ongoing disappointment as an aesthetic failure. It usually isn’t.
How do you have this conversation without losing the client?
Be direct about it early. Not in a way that increases scope for the sake of revenue, but in a way that protects the client from spending money on a solution that won’t solve the problem.
What I say, roughly: “Before we scope this as a redesign, I want to do a quick technical audit. It usually takes a day or two. If the structure is solid, a redesign is absolutely the right call and we’ll go from there. If there are underlying issues we’d be designing on top of, I’d rather tell you that now than three months in.”
Most clients appreciate this. The ones who push back and say they just want the redesign done fast without an audit are clients I’ve learned to be careful with, because when the project delivers a redesign that doesn’t fix the problem, the blame lands on the agency regardless of what the brief said.
The audit doesn’t have to be expensive or elaborate. At Chillybin we do a structured pre-project technical review as a standard part of onboarding. It has saved more than a few clients from buying the wrong thing.
The language clients use when they come to you is almost never precise. “Redesign” means “I want this to be better” and it’s your job, if you’re the one building it, to figure out what “better” actually requires. Sometimes it’s paint. Sometimes it’s foundations. Confusing the two costs everyone.
A website redesign is a legitimate, valuable piece of work when the site underneath it is structurally sound. When it isn’t, the redesign is a delay to the conversation you were always going to have to have. Better to have it at the start.
