Fix the existing website when its main problems can be put right without replacing a sound platform. Consider a rebuild when the structure, technology or editing limits prevent the site doing what the business needs. Diagnose the problem first, protect the pages already working and compare the full cost and risk of both routes.
A website can look old and still bring in useful work. A new one can look impressive and make it harder for a customer to understand the service or get in touch. “It needs modernising” is not a sufficient reason to replace everything.
The decision should start with what is failing: visibility, the offer, the contact journey, the technology or your ability to manage the site. Those are different problems, and they do not all need the same solution.
Ask what evidence sits behind the complaint. “We do not like the design” may be a valid preference, but it is different from “customers cannot complete the enquiry form on a phone” or “we cannot add the product information we need”.
Look at the important pages, the devices people use and the steps that lead to an enquiry or sale. Test the contact journey yourself. Review actual search and enquiry data where available. A tracking fault can make a working site look unsuccessful, so check the measurement before using it to justify a rebuild.
Our guide to SEO without enquiries helps separate the stages. The aim is to identify the problem, not find a new way to label every complaint “outdated website”.
A repair or focused improvement can suit a site with a usable structure and manageable technology. Perhaps the service page is vague, the proof is weak, the mobile menu is awkward or the contact form needs attention.
Those are possible examples, not a diagnosis of your website. Ask a developer or designer to show whether the required change fits the current system, what it will cost and what it might affect elsewhere.
A useful first project may be limited: rewrite one important page, repair one enquiry path or improve a specific template. Agree what will be checked afterwards. If the underlying system is sound, replacing the whole site to make that change may be unnecessary.
Do not let a growing list of small fixes hide a larger structural problem either. If each fix breaks another area, or the platform cannot support the required function, compare the longer-term options honestly.
A rebuild may make sense when the present system cannot support the business’s requirements at a reasonable cost or risk. Examples to investigate include a structure that cannot accommodate needed services, editing restrictions that block routine updates or essential integrations the current platform cannot reliably support.
Security and maintenance problems also deserve a technical assessment. Do not assume a new design fixes them. Ask which underlying software, access or hosting issue is involved and what the proposed solution changes.
Google says a redesign or new-site launch can be a useful time to involve an SEO, while also making clear that an SEO can improve an existing site. SEO does not automatically require starting again. 1
Write the requirements before choosing the platform. What must the customer do? What must your team update? Which integrations are actually needed? Otherwise you risk buying the same limitations in a newer-looking package.
| Decision | Improve the existing site | Rebuild |
|---|---|---|
| Best fit to investigate | Specific problems on a platform that still meets the need | Structural or technical limits that block the required work |
| Scope to define | Exact pages, templates or functions being changed | Content, design, platform, integrations, launch and handover |
| Search risk | Can still affect working pages if changes are careless | Needs a migration plan where URLs or other search signals change |
| Evidence of success | The targeted problem is fixed and tested | The new requirements work, with important existing value preserved |
| Hidden cost to check | Repeated workarounds and deferred maintenance | Content preparation, migration, testing and post-launch support |
Neither column is automatically cheaper. A small repair can be a better use of money, while endless patches can become poor value. The quote needs to explain which situation you are in.
No. A design change is not a ranking guarantee. Google recommends useful content, understandable site organisation and making pages accessible to search systems. Those requirements apply before and after a redesign. 2
If the current site has useful pages that already bring relevant visitors or enquiries, identify them before replacing the design. Look at landing pages, search queries and important links. Keep what serves the customer unless there is a clear reason to change it.
If page URLs change, Google’s migration guidance calls for mapping old URLs to the relevant new destinations, updating internal links and using appropriate permanent redirects. Redirecting every old page to the homepage is not a substitute for mapping equivalent content. 3
A rebuild that discards useful answers, breaks links or leaves development indexing restrictions in place can create new problems. The proposal should say who is responsible for preventing and checking those failures.
Not every rebuild changes the domain or URLs. Establish what is actually changing first. If URLs change, ask for a list of the old addresses, their intended destinations and the reason for each change. 3
Check the following before release:
Google advises planning changes one at a time where possible, rather than changing domain, content management system and layout all together. It also warns that rankings can fluctuate while it recrawls and reindexes changed URLs. That is a reason to plan carefully, not a reason never to improve a site. 3
No agency can promise a risk-free migration or guarantee that every ranking will stay unchanged.
Ask both suppliers to price against the same requirements. A “website rebuild” quote may cover design and development but leave writing, photography, product entry, redirects or integrations with you.
Separate the initial total from ongoing hosting, licences, maintenance and support. Check whether VAT applies. Ask which changes count as revisions and which become extra work.
For a repair proposal, ask what it cannot solve and what would trigger a later rebuild. For a rebuild proposal, ask which specific requirement cannot sensibly be met on the current site. You want an explanation, not a preference for whichever platform the supplier happens to sell.
Keep the domain and key business accounts under the business’s control. Set out access, ownership, content handover and cancellation terms in writing. A site you cannot manage or move has a cost beyond the initial invoice.
Check the user experience on the pages that matter, particularly the mobile experience. Can someone read the service, use the menu and complete the contact step without zooming or fighting the layout? Mobile responsiveness means the layout adapts to the screen; it does not prove that the information or enquiry process is good.
Ask for evidence about site speed and load times rather than using ‘slow’ as a reason to replace everything. The cause might be a particular image, script, template or hosting constraint. A useful diagnosis explains whether a targeted fix is possible and what will be tested afterwards. Performance problems need an explanation before they become a rebuild brief.
Keep the content strategy in the decision too. A new content management system may make updates easier, but it cannot decide which questions customers need answered. Preserve useful pages, plan the missing answers and make sure search engines and customers can reach them. The search engine checks belong alongside the customer checks, not instead of them.
If the problem is unclear, a focused diagnosis can be a better first purchase than a full build. Test the important enquiry route, review the core service pages and identify the genuine platform constraints.
Where practical, improve one representative page or template first. Decide what a useful result would look like: a working contact path, clearer information or a function the team can maintain. That is not a promise of a particular conversion increase.
If the test shows the platform can handle what you need, you have a stronger basis for improving it. If it shows a real limitation, the rebuild brief becomes more specific.
Often some of it will remain useful. Audit it rather than keeping everything or deleting everything. Update inaccurate information, combine genuine overlap where appropriate and preserve answers that still help customers. Where content moves or is removed, consider its existing visitors and links as part of the URL plan. 3
Do not rewrite every page merely to make it sound new. Fresh wording is not the same as a better answer.
Only when there is a business reason, not because a redesign makes it convenient. A domain move adds another change to manage. Google’s guidance recommends separating major changes where possible and verifying the relevant Search Console properties during a move. 3
If the diagnosis points to work you do not want to take on yourself, these are the services we offer:
Our prices are shown on this website, plus VAT, and whatever you ask for, you get a fixed price in writing before any work starts.
Ask for a written diagnosis with two routes: what a focused fix would achieve, and what a rebuild would solve that the fix cannot. Compare scope, ownership, ongoing costs and migration responsibility.
The right answer may be a new website. It may be a much smaller job. Start with the evidence about your current site, not a blank design canvas.
[1] Google: Do you need an SEO?.
