Insights / Digital Foundation
Refresh, rebuild or reposition: what does your website actually need?
Before you redesign anything, decide what job the site has to do and how much of it has to change.
Most website projects start with the same complaint: the site looks dated.
Sometimes that’s the whole problem. A cleaner home page, better photos, clearer calls to action, and you’re done.
Often it isn’t. The site looks dated because the business has moved on. You serve different clients now. You sell differently. Your best work comes from referrals and a sales team, but the site is still built to catch strangers from Google. New paint won’t fix that.
And sometimes the site looks fine and is quietly failing: forms that reach nobody, pages nobody can find, a platform that fights every change.
The real question isn’t refresh or redesign. It’s what job your website needs to do, and whether the current one can do it.
Start with the job, not the look
Before anyone talks about templates or platforms, answer a few plain questions. Who are you trying to reach now? How do they find you? What do they need to see before they call? What should they do next?
Your website might need to generate demand, validate referrals, support a sales team, or do several of those at once. We’ve written about those three jobs. The answer sets the scope. Strategy comes before design, not after it.
Say you run a 12-person engineering consultancy. Most new work comes through referrals. Prospects visit the site to check you out before a first meeting. You don’t need to rank for everything. You need to prove, quickly, that you’ve solved problems like theirs. That might be a content and proof problem, not a rebuild.
Four options, four different problems
Most website work falls into one of these. Each fixes something different. None fixes everything.
| Option | What it changes | Choose it when | What it won’t fix |
|---|---|---|---|
| Refresh | Visuals, home page, key messages, calls to action | The site works and the structure fits, it just looks and reads tired | The wrong audience or a failing platform |
| Repair | Specific pages, user experience, forms, speed, integrations | Particular functions are failing but the foundation is sound | A site built for a business you no longer are |
| Rebuild | Platform, structure, code, templates | The platform blocks every change, is no longer supported, or repairs cost more than starting over | Unclear positioning. A new build of the wrong message is still the wrong message |
| Reposition | Audience, offer, messaging, the site’s role, and the structure to match | Your business, buyers or sales process changed and the site didn’t | Technical debt, on its own |
Repositioning often pairs with one of the others. A repositioned business may only need a refresh to carry the new message. Or the new role may demand a different structure, and that means a rebuild. Decide the position first. Then decide how much of the site has to change to support it.
A working site can need strategic correction without a rebuild. A broken site can need a rebuild without a new strategy. Know which one you have.
When a rebuild is the right call
Building on top of what’s there sounds cheaper. The structure exists, so just tweak a few things. It’s rarely that easy. Old themes, abandoned add-ons, undocumented custom code and platforms that changed underneath the site can make every small change slow and risky.
Signs a rebuild is worth pricing, whatever you’re built on:
- The platform or key components no longer get updates.
- Simple content changes need a developer.
- Every fix breaks something else.
- The site can’t support what the business now needs, like booking, integrations or a CRM connection.
- Nobody can say for sure who controls the hosting, code or admin accounts.
Choose the platform after that, based on who will maintain the site, what it has to connect to and what it has to do. If access is murky, sort it out before anyone migrates anything. Here’s how to check who controls your website.
Protect what already works
A redesign is where businesses quietly lose things they didn’t know they had: search visibility, inbound links, working forms, years of analytics. These launch safeguards are separate from deciding whether to rebuild. They apply to any option that changes URLs, structure or tracking.
Inventory before you change anything.
List every live URL with its traffic, search queries, inbound links and conversions, using Search Console and analytics. Old doesn’t mean worthless. Some of your most useful pages may be ones nobody inside the business remembers.
Map redirects one to one.
Every URL that moves gets a permanent redirect straight to its closest relevant replacement. No chains, no loops, no sending everything to the home page. If a page is gone with no real equivalent, let it return a proper 404 or 410. Keep redirects for at least a year, longer if people or links still use them.
Rebuild navigation around the buyer.
Sites grow by accretion. A section here, a page there, until the menu reflects your org chart instead of how customers decide. Restructure around what buyers need to find, in the order they need it.
Set conversion goals before design.
Decide what a visitor should do on each key page: call, book, request a quote, download, buy. Each page should offer a next step that follows naturally from what the visitor just read.
Set up measurement before launch.
Record a baseline from the old site. Confirm analytics, Search Console and the key events that matter work on the new one. Without a before, you can’t tell whether the after is better.
Test the actions, not just the pages.
Submit every form. Click every booking link. Confirm leads reach a real person and land where they should. Check canonical tags, indexing settings, the sitemap and HTTPS. Then watch crawling, queries and conversions for the months after launch.
Agree who does what
Migrations fail in the gaps between people. Before work starts, agree in writing who owns the content, who writes the redirects, who tests the forms, who moves the domain and DNS, and who watches the numbers after launch. If the answer to any of those is “we assumed you were”, fix it now. That’s where strategy earns its keep.
Don’t start with a template.
Start with the job.
Then decide how much has to change.