Website refresh vs redesign: how to tell which you need

Older websites always reach a point where something feels off. The design looks tired, the content is out of date, or the site isn't bringing in enquiries the way it used to. The choice is whether you improve what you have or start again.

Those are two different jobs, even though some people call both tasks a "revamp". They fix different problems, and the effort involved isn't comparable. This guide covers both, how often sites need each, how to plan a redesign if you do need one, and what to ask before you start.

What is a website refresh?

A refresh works within the existing site. The foundations stay the same. It might mean adjusting the colour palette to match updated branding, rewriting page copy that has gone stale, improving calls to action, or swapping in better images.

You're updating the paint, not knocking down walls.

The content management system (CMS) stays. The templates stay. The underlying technology stays. You're making targeted improvements to a site that still works but could work harder.

Small changes add up. A stronger headline on the homepage, a clearer service page, a few well-placed testimonials. None of these needs a rebuild, but together they change how visitors see your business.

When a refresh is enough

A refresh is usually the right call when the problems are on the surface and the foundations are solid. That tends to look like this:

• The site is a few years old, and the CMS and server are still receiving updates.

• Your team can edit pages without calling a developer.

• The page structure still matches what you sell and who you sell to.

• The complaints are about copy, images, calls to action or a handful of slow pages, not the whole site.

• Visitors can use it comfortably on a phone.

Design trends move on. What looked modern three years ago can start to feel dated, and some things age faster than others: auto-playing videos, aggressive pop-ups and heavy image sliders among them. You can remove and fix issues like that without a rebuild.

How to decide what to refresh

Don't guess, use data. Plausible Analytics and Google Search Console can tell you which pages get the most traffic, where visitors drop off, and which searches bring people to your site. That gives you a clear picture of what's working and what isn't.

Add a tool like Contentsquare (the company behind Hotjar) and you can run short on-page surveys, record sessions and view heat maps. You can ask visitors specific questions on specific pages. Feedback from real people beats assumptions.

Clarity by Microsoft also offers heat maps for free. To stay compliant with the General Data Protection Regulation (GDPR), only load it once visitors opt in through your cookie banner.

Then make a change, track what happens, ask for feedback and repeat. Improvements made this way add up to a much stronger website, and you can see which ones worked.

Announcing a refresh

A refresh isn't a launch event, so you probably wouldn't lead with it on social media. If you've made a run of improvements, though, tell your clients and invite feedback. People appreciate being asked, and their answers can help shape the next round of changes.

What is a website redesign?

A redesign is a rebuild. It's needed when the problems run deeper than visuals or content. The site no longer represents the business. The CMS is difficult to use or can't be updated. The underlying technology is creaking. The sales team don't see the website as a tool. They see it as an embarrassment.

When you've outgrown a website, your team knows it. No amount of tweaking will fix it. That's when a redesign becomes the more practical option.

When a redesign is justified

These are the signals that point to a redesign rather than a refresh. One on its own might be fixable. Two or three together usually aren't.

• The site no longer reflects what the business does or who it serves. If your services, your audience or your marketing strategy have changed, new paint won't fix a structural mismatch.

• The CMS is a barrier. If your team avoids updating the website because it's too difficult, the CMS is working against you. A modern CMS such as Statamic lets non-technical editors make changes without help (plus it's a nice place to be).

• The technology is out of support, and bringing it up to date might cost close to what a rebuild costs.

• It doesn't work properly on a phone. Google ranks sites based on their mobile version, so a site built for desktop first starts at a disadvantage.

• It can't meet accessibility standards without new templates. Some fixes, such as missing image descriptions, are a refresh job. Navigation that can't be used with a keyboard, or templates with no sensible heading structure, usually aren't.

• Content is spread across several sites, sections have been bolted on over the years, and visitors can't find what they need.

The technology point needs a little more explanation, because it's the one site owners see least. Every major version of Laravel, the framework Statamic is built on, gets bug fixes for 18 months and security fixes for two years. PHP (Hypertext Preprocessor), the programming language underneath, works the same way: each version is supported for a fixed period and then gets no security fixes at all. A site stuck on old versions keeps running, but it stops being patched. If Google believes a site has been compromised, it can show a "This site may be hacked" warning next to it in search results.

For accessibility, the Web Content Accessibility Guidelines (WCAG) set three levels: A, AA and AAA. WCAG 2.2 was published in October 2023, and AA is the level most organisations aim for. If you're rebuilding anyway, build to that level from the start.

Skratch Tech is a typical example of a site that needed a redesign. Their website was built in 2012, had become hard to update and no longer reflected the quality of their work. I replaced it with a Statamic site their team can manage without waiting on a developer.

At the larger end, L.B. Foster needed to bring more than 5,000 pages from several acquired companies' websites into one global site. After launch, the number of their pages indexed by Google rose by 707%. Neither problem could have been fixed with a refresh.

How often do websites get redesigned?

Advice online usually says every two to five years. I think a fixed cycle is the wrong way to look at it. Most of the reasons for a redesign build up slowly, and many of them could have been dealt with as they appeared.

A site that nobody touches between redesigns falls behind in two ways. The content drifts away from the business, and the software underneath it ages. A site left for 18 months without updates can end up multiple major versions behind across the whole stack, as I explain in what website maintenance includes. At that point a redesign stops being a choice. It becomes the cheapest way out.

A redesign every few years is often the bill for the years in between, when nobody looked after the site.

The alternative is steady, incremental work. Keep the CMS, framework and server updated every month. Review your key pages against your analytics every few months. Fix small problems as you find them. A site looked after this way can go much longer before it needs a rebuild. When it does, the reason is that the business has changed, not that the technology has fallen too far behind to save.

That's the case for a website maintenance plan: a planned monthly cost instead of an occasional emergency and a forced rebuild. I wrote a post about that very topic here: Business websites have a running cost. Here's why that's a good thing.

I try to work the same way on my own site. When I cut my service pages from six to two and simplified the navigation in September 2025, I wrote up what changed and why. The aim since then has been to keep making small, regular improvements rather than save them up for one big project.

Don't throw away what you already have

If you decide to redesign, it's tempting to treat the old site as worthless. That's a mistake. If it receives any traffic at all, there's useful data inside it. Analytics will show you which pages visitors care about. Search Console will show you which searches bring people in.

Before any design work starts, export both lists. Every page that gets traffic needs a home on the new site, or a permanent redirect to the closest match. Skip this and a new site can lose the search traffic the old one had earned.

A website redesign checklist

If a redesign is the right call, this is the order I'd work through it. It follows the same stages as my own web design process, from planning through to launch and support.

Before anything is designed

1. Write down the problem the redesign has to solve, and how you'll measure it. "More enquiries from the service pages" can be measured. "A modern look" can't.

2. Record a baseline for the last 12 months: traffic, enquiries or sales, top pages and top search queries. You'll need it to judge the new site.

3. Audit the current site. Check speed, how it works on a phone, accessibility, broken links and what the CMS makes hard.

4. List every page and decide what happens to it: keep, rewrite, merge or delete. This content inventory is usually the job that takes longest.

5. Map every web address (URL) that's being removed or renamed to its new home with a permanent (301) redirect.

6. Talk to the people who use the site: customers, the sales team and whoever edits it.

7. Look at three competitors' sites to see what your market expects and where they fall short.

8. Plan the structure as a sitemap: every page, how pages are grouped and how visitors move between them. I use a sitemap service called Octopus for this.

9. Agree the budget, the launch date and who signs off each stage.

During design and build

1. The Octopus sitemap is a valuable asset at this point. Use it to build a basic, working version of the website.

2. At this point the site acts more like an interactive wireframe.

3. Design reusable components rather than one-off pages, so new pages can be added later without a designer.

4. Set up the CMS around the people who will edit it, with fields named the way your team talks.

5. Start writing content during development, not after. Waiting for content is an easy way for a launch date to slip.

6. Build accessibility in from the start, aiming for WCAG 2.2 AA.

7. Test on real phones, tablets and desktops, in the browsers your analytics say your visitors use.

At launch and after

1. Put the redirects live at the same moment as the new site, and test a sample of old addresses.

2. Check analytics and form tracking are recording before you announce anything.

3. Submit the new sitemap in Google Search Console and watch the Page indexing report for errors.

4. Monitor closely for the first 30 days. Compare against your baseline, not against gut feel.

5. Agree who applies updates from the second month onwards, and budget for it.

What to ask before you start

Some of these questions are for you and your team. Others are for whoever will build the site. I've covered the second set in more detail in key questions to discuss with your web developer.

Ask yourselves

• Could a refresh fix this? If the answer is yes, try that first.

• What does success look like in six months, and which number will show it?

• Who will update the site after launch, and how often?

• What content do we already have, and who is writing the new content?

• What does the site need to connect to, such as a customer relationship management (CRM) system or a booking tool?

Ask your developer

• Is the quote fixed, and what does it exclude?

• How will you protect the search traffic the current site already has?

• Will we be able to edit every page ourselves?

• Who applies updates after launch, and what does that cost each month?

• Will I be talking to the person doing the work?

A fixed quote gives you a number you can take to stakeholders without worrying it will grow mid-project. My custom websites include planning, design, development and 30 days of post-launch support.

So which do you need?

If your website is fairly recent, the technology is solid and the structure still makes sense, a refresh will keep you moving forward. Small, data-driven improvements made over time are surprisingly effective, especially as part of regular maintenance.

If looking at your website makes you wince, your team struggle to update it, or it's losing you business, it's probably time for a redesign.

Either way, start with the data: your analytics, your Search Console queries and what your visitors tell you. That will show you which kind of work your site needs.