Rebuild or improve: how to decide about your current website
Six questions that decide whether your website should be improved in place or rebuilt, and the signs that make the answer obvious.
The short answer
Deciding whether to improve your current website or rebuild it comes down to six questions. Is it fast on a phone on mobile data? Is it secure and actually maintained? Can it be changed safely, with previews and rollback? Does it do what the business needs now? Is it accessible? Do you own the domain, hosting and code? If most answers are yes and the gaps are specific, improve: fix the slow template, add the missing feature, close the security gap. If the foundations fail, slow by construction, insecure by plugin count, unchangeable without fear, or not yours, rebuild. A rebuild on a modern static stack costs less over three years from the point where the yearly maintenance, hosting and incident hours of the current site exceed the rebuild divided by three. Put both columns on one page: what the current site costs to keep alive each year, and what a rebuild costs once. Whichever you choose, the content, the addresses and the search equity are the assets to keep; the code rarely is.
The six questions
| Question | Yes looks like | No looks like | If no |
|---|---|---|---|
| Fast on a phone? | Passes real-user thresholds on the top templates | Seconds to show the main image; taps hesitate | Improvable if the cause is images and apps; rebuild if the platform is the cause |
| Secure and maintained? | Updates within days; monitoring; tested backups | Plugins months behind; nobody owns updates | Improvable with an owner; rebuild if the plugin surface is the risk |
| Changeable safely? | Previews, version control, rollback | Edits on the live site; fear of touching it | Usually a rebuild signal |
| Does what the business needs? | Current offering, forms that deliver, integrations that work | Workarounds; content that cannot be structured | Improvable if specific; rebuild if structural |
| Accessible? | Keyboard, screen reader, contrast pass | Page-builder markup failing basics | Rarely fixable in place on a builder |
| Owned? | Domain, hosting, code in your name, or held by a supplier who has put the transfer in writing | In an agency’s or a former employee’s name, with nothing in writing about getting it back | Settle ownership first, whatever else you do |
Deciding
- Answer the six questions honestly, with measurements for speed and a check for ownership.
- For each no, ask whether it is specific or structural: one slow template is specific; a slow platform is structural.
- If the noes are specific, list the improvements, price them, and do them.
- If the noes are structural, price a rebuild on a modern stack over three years against keeping the current site, including what it loses.
- Either way, fix ownership first.
- Plan the content migration and redirects as the core of any rebuild.
What a rebuild keeps
Content that earns traffic, reviewed and improved rather than copied blindly. Every address, mapped and redirected permanently, so rankings travel. Brand assets and photography that still fit. Analytics and search console history. Integrations that work, reconnected. The theme, the plugins and the platform’s habits are what go, and they are usually what the six questions failed on.
What this means for you
Answer the six questions, separate specific gaps from structural ones, and compare three-year totals including what the current site loses. Improve when the foundations hold; rebuild when they do not; fix ownership regardless. Keep the content, the addresses and the equity through any rebuild. The decision is usually clear once the questions are asked honestly, and the cost of asking them late is the years of improvements that should have been a rebuild.
Frequently asked questions
The site works. Why would we rebuild it?
Works is the minimum. Ask the six questions: is it fast on a phone on mobile data, is it maintained and secure, can changes be made without fear, does it do what the business needs now, is it accessible, and are the domain, hosting and code in your name. A site that works and fails three of those is costing you customers, risk and money every month, quietly.
Is a rebuild not the expensive option?
Up front, often; over three years, frequently not. A plugin-heavy site carries maintenance, security incidents, slow pages that lose customers and hosting sized for a server. A static rebuild removes most of that: near-free hosting, light maintenance, no plugin surface, fast pages. Compare three-year totals including what the current site loses, not the rebuild quote against zero.
What do we keep from the old site?
The content that earns traffic, reviewed and improved; every address, redirected permanently to its new equivalent; the search equity that travels through those redirects; the brand assets; the analytics history. The code, plugins and theme are usually the liability. A rebuild is a migration of assets, not a fresh start.