Most company websites can be fixed without a full rebuild. Copy, photography, navigation, forms and heavy images are all partial-fix territory. A rebuild makes sense once you have confirmed a foundation problem: the CMS or server cannot be updated, there is no mobile design underneath, or reworking the shared parts would cost more than starting fresh.
This article gives you a table for deciding where your site stands, a way to compare costs without relying on market prices, and the steps for protecting search traffic if you do rebuild. How to choose a web studio or freelancer is covered separately in what it costs to outsource a website, and how to brief it.
Separate symptoms by the layer causing them
"It looks old," "we get no enquiries" and "it's slow" are symptoms. How much you need to change depends on which layer holds the cause.
| What's bothering you | Layer | First fix to try | How to check yourself |
|---|---|---|---|
| Products or services are not explained clearly | Content | Rewrite the page concerned | List the questions customers keep asking |
| The path to enquiring is hard to follow | Navigation | Fix button placement, menus and links | Go through to the enquiry on a phone |
| You suspect drop-off or errors on the form | Form | Cut fields, fix error messages | Submit it yourself and confirm it arrives |
| Pages load slowly | Rendering | Compress images, prune third-party tags, cache | Test key pages in PageSpeed Insights |
| Content spills sideways on phones | Template | Rework shared parts; a fixed-width design is a rebuild candidate | Open key pages on a phone |
| You want a new look across every page | Template | Rework shared header, footer and templates | Ask how many template types exist |
| Every update needs an outside vendor | Foundation | Add a CMS or change what staff can edit | Check whether an admin screen exists and who can log in |
| CMS or PHP cannot be updated | Foundation | Try the update in staging; if it fails, a rebuild candidate | Use the table below |
| You cannot get into the admin screen or server | Access | Recover access before rebuilding | Check who holds the domain and hosting contracts |
The last row matters. "We lost touch with our old web vendor, so we want a new site" is not a rebuild problem but an access problem. A new site still stalls at launch if the old contact remains the domain's registrant.
If a shortage of enquiries is the only motive, narrow down the cause before rebuilding. Whether too few people arrive, or the people who arrive do not act, leads to entirely different work.
Unsure whether to rebuild?
Check whether partial fixes are enough, then fix only what needs it
Decision table: four axes for foundation problems
Do not decide by counting ticks. Some items decide a rebuild on their own, and others only add weight.
| Axis | What to check | How | A partial fix is enough when | Consider a rebuild when |
|---|---|---|---|---|
| Technical debt | PHP version | Hosting control panel, CMS site-health screen | It can move to a supported version in staging | It only runs on an old version and breaks when upgraded |
| Technical debt | Amount of custom work | Ask whether anything is left alone because "updating breaks it" | Custom work is documented and can be rewritten | Nobody can explain the whole system and you have no source |
| CMS | Core and plugin updates | Update notices in the admin screen | Updates can be applied and checked in turn | A modified core or theme cannot take updates |
| CMS | Who does updates | Have a staff member actually publish one news post | It can be done entirely in the admin screen | Only direct HTML edits work and adding a CMS is impractical |
| Page speed | Core Web Vitals | Search Console, PageSpeed Insights | Image and tag improvements look likely to get there | Template design itself is the cause and cannot be improved |
| Page speed | Mobile display | Check key pages on real phones | Fixing shared CSS solves it | A fixed-width layout underlies every page |
| Accessibility | Contrast, alt text, form labels | Try the main tasks with a keyboard only | Page-level and CSS fixes solve it | Custom menus or sliders on every page cannot be operated |
Some notes on each item.
PHP and CMS. As of 9 November 2026, the officially supported PHP branches are 8.2 to 8.5. Security fixes for 8.2 end on 31 December 2026, so sites on 8.2 need an upgrade plan this year. Versions 8.1 and earlier have dropped off the official list. For WordPress, the project says the only actively supported version is the most recent one, and versions 4.1 through 4.6 stopped receiving security updates in July 2025. What matters is less whether something is old than whether it can be upgraded. If it upgrades and runs in staging, a partial fix is enough.
Page speed. Google's Core Web Vitals targets are LCP (main content appearing) within 2.5 seconds, INP (response to interaction) of 200 milliseconds or less, and CLS (layout shift) of 0.1 or less, assessed at the 75th percentile of page loads. Search Console uses real-world usage data, so low-traffic sites may not have enough to show. In that case, use PageSpeed Insights' lab data as a guide to where to improve.
Do not chase the numbers too far. Google says Core Web Vitals are used by its ranking systems, but also states plainly that good results do not guarantee top rankings. Speed work is less a reason to rebuild than something to try first as a partial fix. Most of the cause is heavy images, web fonts, and ad or analytics tags.
Accessibility. The reference is W3C's WCAG; the current WCAG 2.2 sets success criteria at three levels, A, AA and AAA. On the legal side, Japanese businesses have had a duty to provide "reasonable accommodation" since 1 April 2024. "Improving the environment" in advance, which covers preparing a website, remains an effort duty. So a site failing WCAG AA cannot be said to break the law on that basis alone. But contact details shown only in an image, or a form that cannot be operated by keyboard, make it hard to respond to a request for accommodation. Check individual cases with a professional.
Decision steps: partial fix, template rework, or rebuild
Do not treat this as a choice between rebuilding and patching. There is a middle option: template-level rework.
Q1. Is the domain, CMS and server under your own control?
No → Recover access first (decide about a rebuild afterwards)
Yes ↓
Q2. Can the CMS, PHP and theme be upgraded to current versions in staging?
No → Investigate whether custom code or the CMS itself is the limit
If it cannot be fixed, a "rebuild" candidate
Yes ↓
Q3. Is the problem in parts shared by all pages (header, width, templates)?
No → "Partial fix" (only the pages and items concerned)
Yes ↓
Q4. If the shared parts are reworked, can the remaining pages stay as they are?
Yes → "Template-level rework"
No (fixed-width design, information structure no longer fits the business)
→ "Rebuild" candidate
A mismatch between the information structure and the current business is also a reason to rebuild. If your main product has changed or your target customer has shifted and pages need reclassifying, editing copy will not catch up.
None of the following, on their own, justify a rebuild:
- The site is more than five years old
- A competitor has a new site
- A web vendor suggested it was "about time"
- Someone inside the company is bored of how it looks
Compare cost in the same units, not against market prices
Market prices vary widely with the conditions, so here is a formula for comparing your own estimates, and the factors that move the cost of a redesign.
Total for partial fixes = investigation + fixes + testing
+ (annual effort to maintain what remains × years)
Total for a rebuild = requirements + design + build + migration + testing
+ post-launch fixes + internal attendance
+ (annual effort to maintain the new site × years)
Unlike a brand-new site, a redesign adds the cost of moving things over from the current one.
| Cost driver specific to a redesign | Why it adds cost | What to check in the estimate |
|---|---|---|
| Moving copy and photos | Loading, rewriting, reprocessing images | Who prepares copy, and to what standard? |
| Migrating existing data | Moving news or product data by hand adds effort | Automated or manual? |
| URL mapping and redirects | Effort to list old URLs and check them | Is it included in the estimate? |
Cost drivers for web work in general, such as the number of page types and features, are covered in what it costs to outsource a website, and how to brief it.
The last row of the table is often missed. If URL mapping and redirect testing are not in the estimate, extra costs appear after search traffic has already fallen.
Comparing in person-days (the amount one person does in a day) instead of money reveals the structure of an estimate.
Hypothetical example: Comparing a partial fix with a rebuild for a company site of about 30 pages. All effort figures are invented for illustration and are neither market rates nor my own estimates.
| Item | Partial fix | Rebuild |
|---|---|---|
| Investigation and requirements | 1 person-day | 3 person-days |
| Design | 0 person-days | 5 person-days |
| Fixes and build | 4 person-days | 12 person-days |
| Migration (copy, URL mapping) | 0 person-days | 5 person-days |
| Testing and post-launch fixes | 1 person-day | 5 person-days |
| Initial total | 6 person-days | 30 person-days |
| Annual maintenance (including PHP update work) | 6 person-days | 3 person-days |
| Three-year total | 24 person-days | 39 person-days |
| Five-year total | 36 person-days | 45 person-days |
In this example, the two lines meet in year 8: 6 + 6 × 8 = 54 person-days and 30 + 3 × 8 = 54 person-days. Recovering the rebuild from the maintenance difference alone takes eight years. The lesson is that a rebuild is hard to justify on maintenance savings alone. Choose it when you can name another benefit: supporting a change of business, or redesigning the enquiry path from scratch. Conversely, if the assumptions behind the partial fix break down (PHP cannot be upgraded, the theme cannot be updated), its annual maintenance leaps and the comparison reverses.
Work you can finish in-house before getting estimates, and the website-builder option
Before considering outsourcing, finishing what you can do in-house also shrinks the scope of any estimate.
- List pages with outdated information or finished campaigns
- Add the questions customers often ask to the relevant pages
- Resize photos appropriately before replacing them
- Check with whoever owns them, then remove third-party tags no longer used (old ads or analytics)
- Actually submit your form and confirm the route it takes to arrive
- Keep domain and hosting contract details in one place
If you have few pages and need nothing beyond a contact form, an off-the-shelf website builder may be enough; maintenance being included in the monthly fee is a benefit. URL design and export freedom differ between services, so confirm before signing that you could move away later.
Outsourcing is a poor fit when the goal is undefined and the brief is simply "make it modern." If you cannot put into words what you want to improve, you cannot compare estimates or judge the result after launch.
If you decide to rebuild: limit the loss of search traffic
The loss to avoid most in a rebuild is people arriving from search and hitting a 404 page. The steps below follow Google's site move guidance.
First, look at keeping your URLs. Even with a new design and CMS, keeping URLs as they are greatly reduces the complexity of the move. If only the server or CDN changes (URLs visible in the browser stay the same), follow Google's procedure for site moves without URL changes: switch DNS and monitor both old and new hosts.
If URLs do change, work in this order.
| Stage | What to do | Practical notes |
|---|---|---|
| Prepare | Build a list of old URLs | Gather from sitemaps, top pages in server logs or analytics, links in Search Console, and CMS listings. Include images, PDFs and videos |
| Prepare | Build the old-to-new mapping | See the example below. URLs with no matching new page should return 404 or 410 on the new site |
| Prepare | Update annotations on the new site | Give each page a self-referencing canonical and rewrite internal links to new URLs |
| Prepare | List what restrictions to lift | Reliably remove noindex or robots.txt blocks used during development at launch |
| Switch | Configure server-side permanent redirects (such as 301) | Google's recommended method. Avoid redirect chains; go straight to the final URL |
| Switch | Test every redirect | Use the URL Inspection Tool for important URLs, and commands or scripts for the rest |
| Switch | Submit the new sitemap | Only when changing domain, use Search Console's Change of Address tool |
| After launch | Keep the redirects | Google's guidance: "as long as possible, generally at least 1 year" |
| After launch | Monitor | Check Search Console sitemaps, page indexing and search performance, plus 404s in server logs |
Make the mapping this specific.
Hypothetical example:
| Old URL | New URL | Response | Note |
|---|---|---|---|
/company.html | /about | 301 | Content merged |
/products/a01.html | /products/widget-a | 301 | Product page |
/news/2019/notice.html | /news/2019/notice | 301 | Old news moves too |
/campaign-2018/ | none | 410 | Finished; do not force a redirect to the home page |
Two mistakes are common with redirects. One is sending every old URL to the home page. URLs with no matching content should return 404 or 410. The other is moving only some URLs first in a staged launch. For small and medium sites, Google recommends moving all URLs simultaneously rather than section by section. Copy improvements and new features can be phased, but the URL move should happen once.
The Change of Address tool is not a cure-all. Use it for moves between domains or subdomains, and you must own both properties. It is not for HTTP-to-HTTPS changes, www versus non-www, or moving paths within one domain. Its effect continues for 180 days after you start the move.
Measuring after launch. Temporary ranking movement is expected. Google also notes it can take a few weeks or more for medium-sized sites to see new URLs replace old ones. Decide these points in advance.
| What to check | How to compare | Caution |
|---|---|---|
| Clicks on key pages | The 28 days before and after launch, with the same mix of weekdays | Seasonal businesses should also compare the same period last year |
| Index migration | Indexed counts in the old and new sitemaps | Redirect warnings on the old sitemap are normal |
| 404 errors | Server logs each week | Add any unexpected URLs to the mapping |
| Enquiries | Form submissions and those actually received | Confirm analytics settings moved across |
| Rankings | Track representative search terms | Do not panic and change things during post-launch movement |
On low-traffic sites, most swings over a few weeks are chance. Judge results over blocks of a month or longer.
Get estimates for both a partial fix and a rebuild
When requesting estimates, do not leave the conclusion to the vendor. Writing the following makes proposals comparable.
- What is bothering us about the current site (symptoms)
- Our Q1-Q4 results, and the items we could not confirm
- We would like estimates for BOTH a partial fix and a rebuild
- Include URL mapping and redirect testing in the estimate
- How far post-launch fixes are covered (period and scope)
Asking for both estimates is the key part. If a vendor only recommends a rebuild, ask them to explain why partial fixes would not be enough.
For choosing a vendor and points to watch in the contract, see what it costs to outsource a website, and how to brief it. If you are considering working with me, the scope and how costs are set are on website fixes and maintenance. Where a partial fix is enough, I will not recommend a rebuild. If a rebuild is needed, it is quoted not as a small improvement but per project, as on the pricing page.