Refresh or rebuild?
Website refresh or rebuild? How to tell when your site is a bit knackered.
Refresh a website when its platform, useful pages and core information still work. Rebuild when the foundations are unsafe, unmanageable or no longer match the business. The expensive mistake is choosing from appearance alone. A site can look dated and still have good bones. It can also look shiny while being held together by plugins, expired logins and hope.
By Kieran Lewis · Published 17 July 2026 · Practical guide for UK small businesses
The 60-second answer
Refresh the surface when the structure still makes sense
Choose a refresh if the website has a manageable number of useful pages, works on supported technology, can be edited safely and still reflects what the business does. A refresh can improve the layout, mobile experience, wording, images, calls to action and on-page search foundations. It is often quicker because you are not throwing away every URL and rebuilding the whole cupboard to replace one ugly door.
Choose a rebuild if routine changes are risky, nobody controls the hosting or domain, the platform is unsupported, the content structure is beyond repair, or the business has changed so much that almost nothing fits. A rebuild gives you a cleaner base. It also creates more work: content must be moved, useful URLs must be mapped and redirects must be tested.
If the answer is mixed, do not guess. List what can stay and what must change. Price both routes against the same outcome. “New is always better” is sales bollocks. “Never rebuild” is just the opposite flavour.
Signs a refresh is enough
The site is scruffy, not terminal
- The domain, hosting and editing access are under control
- The platform receives security updates and does not depend on abandoned software
- Most existing pages still describe real services and answer useful questions
- The URLs are simple, readable and already known to customers or search engines
- The main problems are visual clutter, weak copy, poor mobile spacing or buried contact details
- Forms, calls and email links can be repaired without replacing the whole system
In this situation, a refresh protects useful material and focuses the budget on what customers see. It can also reduce launch risk. Fewer URLs change. Less content needs moving. There are fewer chances for an important page to vanish down the back of the internet sofa.
What a refresh can cover
More than changing the paint
- Reorder pages around what customers need to know first
- Rewrite unclear headings and trim repeated waffle
- Improve navigation, buttons and enquiry routes
- Rebuild awkward sections for phones and tablets
- Update titles, descriptions, headings and internal links
- Replace old images and surface current trust information
Agree the list before work starts. “Give it a tidy” can mean six colour changes to one person and a complete information-architecture project to another. Written scope prevents a small refresh from quietly becoming a rebuild with a fake moustache.
Signs a rebuild is safer
The foundations are doing something alarming
Rebuilding becomes sensible when the old system makes ordinary work expensive or unsafe. That could mean unsupported software, a theme nobody can update, pages assembled from dozens of conflicting plugins, or an account structure nobody understands. If changing a phone number feels like defusing a bomb, the site does not have good bones. It has a hostage situation.
- You cannot confirm who owns the domain, hosting or key accounts
- The site cannot use current security updates without breaking important features
- Mobile problems come from the entire layout, not a few repairable sections
- The page structure reflects services the business stopped offering years ago
- Duplicate, hidden or mystery pages make the content impossible to manage
- The platform cannot support essential accessibility, performance or enquiry needs
- Repairing the old build costs nearly as much as creating a clean replacement
A rebuild does not mean every word and URL must disappear. Good content can move. Useful page addresses can stay. Strong photos can be reused with permission. The decision concerns the system and structure, not a ceremonial burning of everything the business has ever published.
Check one: control
Who owns the important accounts?
Confirm the domain registrar, hosting account, website login, analytics property, Search Console account, email service and any paid plugins. Record renewal dates. Use business-controlled email addresses where practical. A redesign is much harder when the only administrator is somebody's former cousin's Hotmail.
Do not cancel old services during the review. First prove what each service does and make a recoverable backup. Domains and email are particularly easy to break by accident and spectacularly annoying to repair.
Check two: content
Which pages still earn their keep?
List every public page. Mark it keep, improve, merge, redirect or remove. Keep pages that answer a real customer question, attract relevant visits or support an important service. Merge thin pages when one stronger answer would be clearer. Redirect removed URLs to the closest useful replacement, not lazily to the homepage.
Check names, prices, opening details, service areas and contact information. Old facts damage trust even when the design looks lovely. A beautiful page advertising a service you stopped offering is still wrong.
Check three: customer route
Can a new visitor understand it?
Open the homepage on a normal phone. Without using insider knowledge, ask what the business does, who it serves, where it works and what the next action is. Then try the navigation, phone link, email link and form. Check that text can be read without zooming and that floating buttons do not cover the content.
Ask somebody unfamiliar with the business to do the same. Do not coach them. Watch where they pause. Confusion is useful evidence. It is better than a meeting where everybody politely agrees the homepage “feels premium” while nobody can find the opening hours.
Check four: technical health
Look beyond whether it loads on your laptop
Check HTTPS certificates, broken links, forms, page status codes, mobile layouts, backups and software updates. Confirm that search engines can access the pages meant to appear in search. Review the sitemap, canonical addresses and redirects. Test with certificate checking enabled; hiding a warning does not fix it.
Technical trouble does not automatically demand a rebuild. A broken certificate or bad redirect can be repaired. The question is whether problems are isolated or symptoms of a system nobody can maintain.
Make the decision
Compare outcomes, not labels
Write down the outcome first. For example: “Make our four services clear, work properly on phones and send qualified visitors to one enquiry form.” Ask what a refresh would change to achieve it. Ask what a rebuild would change. Then compare cost, risk, disruption and future maintenance.
- Choose refresh when most content and technology remain useful and the problems are contained
- Choose rebuild when the platform or structure blocks safe, maintainable improvement
- Choose staged work when urgent customer problems can be fixed now and deeper work can wait
- Pause when nobody can confirm ownership, backups or the effect on email and domains
Ask for a written page list, revision allowance, content responsibilities, payment schedule and explanation of ongoing costs. Ask what happens to old URLs. Ask who owns the finished work. If the answer is a cloud of jargon, keep your deposit in your pocket until the cloud clears.
Budget reality
Count the hidden work
A quote is not only design. It may include content sorting, redirects, form setup, domain work, email protection, analytics, accessibility checks and launch testing. A cheap rebuild that ignores those jobs may cost more once somebody has to repair the missing pieces. Compare like with like.
Cheap as Chips refresh work commonly fits the Standard or Growth brochure packages, depending on page count and condition. See the current website package prices for exact public bands.
Protect the launch
Back up, map, test, then switch
Keep a restorable copy of the old site and configuration. Record current URLs. Test the new version on phones and desktops. Submit forms. Check email delivery. Verify redirects and certificates. Only then change the live setup. Keep the backup until the new site has behaved itself for a sensible period.
A simple decision worksheet
Write four lists before requesting quotes
List the pages that still help, the problems customers can see, the technical risks you know about and the outcome the business needs. Add the accounts you control and the ones you cannot find. Send the same four lists to each provider. This makes quotes easier to compare and exposes different assumptions early. If one quote preserves six useful pages while another quietly deletes them, the totals are not pricing the same job. Ask each provider to mark their assumptions in writing before you choose.
Will a rebuild destroy existing Google rankings?
Not automatically. Risk rises when useful content disappears, URLs change without suitable redirects, pages become blocked or the new site is weaker. Preserve useful addresses where practical. Map every necessary change and monitor Search Console after launch. No developer can promise rankings will never move.
Can I refresh only the homepage?
Yes, if the homepage is the contained problem. Check whether its navigation, styling and messages depend on the rest of the site. A shiny homepage leading into broken service pages can make the mismatch worse.
How often should a website be rebuilt?
There is no useful fixed timetable. Rebuild because the business or technology requires it, not because a calendar says websites expire every three years. Regular maintenance and small improvements can extend the useful life of a sound site.
Need a second pair of eyes?
Send the current URL through the website refresh enquiry. Include what feels wrong and what the business needs now. You can also compare the refresh service with new website design.