WordPress website rebuild: four tests before you spend the money

Somebody has told you the site needs rebuilding. Maybe an agency pitching the project, maybe a developer who inherited it and does not want to touch it, maybe just the feeling you get every time you try to change something and it takes a week.

You are not in a position to check. That is the uncomfortable part. The vocabulary the answer arrives in - technical debt, outdated architecture, unmaintainable, not scalable - is unfalsifiable by design. Every one of those is a judgment call, and the person making it is usually the person quoting the rebuild.

We take over other people’s WordPress sites for a living. Since 2008 we have shipped over 800 projects for 437 clients, a good share of them sites somebody else built and walked away from, and we run maintenance and rescue work on hundreds more. Which means we get asked this question in both directions: by clients wondering whether the last agency was straight with them, and by agencies deciding what to tell a client about a site they just inherited. So here is how we actually decide, in a form you can run yourself before anyone quotes you anything.

The short answer

A rebuild is decided by four checkable facts, not by adjectives. Which PHP branch the site runs on and when that branch stops receiving security fixes. Whether anything the site depends on is abandoned with no maintained replacement. Whether the content model matches what the business sells today, or whether your team makes new things by duplicating pages. And whether anyone can deploy a change safely. If none of the four fail, the complaint is appearance, speed or editability, and all three are repairable for a fraction of a rebuild. If the content model fails, rebuild regardless of the others, because that is the one thing a repair cannot reach. If two or more fail, each repair is an instalment on a rebuild you will do anyway.

The advice out there grades your site on adjectives

We ran the three natural phrasings of this question past the search-grounded models this week, the way a business owner would. The direction they give is fine as far as it goes: fix specific problems, rebuild structural ones. Nobody is lying to you.

The trouble is what happens when you try to use it. The signals offered are “technical debt is piling up”, “outdated architecture”, “hard-to-maintain code”, “the backend is confusing”, “most sites over five years old benefit from a rebuild”. Roughly twenty sources across the two working models, and not one of them names a fact you could check without hiring somebody. You are handed a decision framework composed entirely of things the vendor assesses on your behalf.

The costing is worse. One model returned 20,000 to 100,000 dollars for a business rebuild, with simpler ones from 10,000. The other returned 8,000 to 40,000, and in the same answer priced WooCommerce rebuilds at 3,000 to 12,000 while describing them as more complex than the sites it had just priced higher. Those are not two estimates of one thing. They disagree by a factor of ten and contradict themselves internally, because nobody has specified what a rebuild includes.

That is the gap. Not the direction of the advice, the checkability of it. So: four tests, each of which produces a fact with a date or a version number on it.

Test 1: what PHP branch is it on, and when does that branch die

This is the only structural question about a website with a published expiry date, and almost nobody asks it.

PHP publishes its own support calendar. Each branch gets roughly two years of active support and then two more of security fixes only, after which it is end of life. In php.net’s own words, an end-of-life release is “no longer supported” and “Users of this release should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities.”

The dates as they stand today: PHP 7.4 reached end of life on 28 November 2022, PHP 8.0 on 26 November 2023, PHP 8.1 on 31 December 2025. PHP 8.2 is on security fixes only until 31 December 2026, which is five months away. PHP 8.3 and 8.4 are in active support.

Now the part that makes this test worth running. A working site is not evidence of a supported one. WordPress goes out of its way to keep old installations alive. Its own requirements page recommends PHP 8.3 or greater, and in the same breath notes that WordPress will still run on PHP 7.4 and MySQL 5.5.5, versions that “have reached official End Of Life and may expose your site to security vulnerabilities.” So a site can be four years past its runtime’s death date, load in under a second, and look completely healthy. Nothing on the screen tells you.

Check it in a minute: Tools, then Site Health, then Info, then the Server panel. The PHP version is there. Compare it against the dates above.

Here is the nuance the symptom lists miss, though. A dead PHP branch does not mean rebuild. Upgrading PHP is usually a small, cheap job. What decides the question is what happens when you attempt it:

• The site moves to a supported branch on staging and everything works. You had a maintenance task. Do it and stop reading this section.
• It moves, and three things break in ways somebody can fix in a day. Still repair work.
• It cannot move, because something load-bearing will not run there and has no maintained replacement. That is not a PHP problem any more. That is test 2, and it is the real finding.

The value of test 1 is that it forces the question into the open with a date attached. Not “is this site old”, but “the runtime under it stopped getting security patches on a specific day, so what is stopping us moving it”.

Test 2: is anything it depends on abandoned

Every WordPress site is a stack of other people’s code. The question is not how many plugins there are, a count that gets quoted constantly and means very little. Thirty well-maintained plugins are safer than four abandoned ones. The question is whether each piece still has somebody behind it.

For every plugin and the theme, find two facts. When was it last updated, and does a current version run on a supported PHP branch. For anything from the wordpress.org directory both are on the plugin’s page, along with which WordPress versions it has been tested against. For commercial plugins, check whether the licence is still active and whether the vendor still ships releases. For anything custom that a previous developer wrote, check whether that developer is reachable and whether the code is anywhere you control.

Then sort what you find into three piles:

• Maintained. No action. Most of the list usually lands here.
• Abandoned but replaceable. A dead gallery plugin, a dead form plugin, a dead slider. Annoying, a day or two of work each, not a rebuild. Migrate the content, swap the tool.
• Abandoned and load-bearing. The booking engine. The membership system. The custom post types that hold every product. The theme itself, if the content is welded into it.

Only the third pile matters. If a load-bearing dependency is abandoned and there is no maintained equivalent, you are going to rebuild that function whether or not anybody uses the word rebuild. The only real decision left is whether you do it once, deliberately, or four times in a row as each patch fails.

The special case worth naming: a site built entirely inside a page builder, where the content lives in the builder’s own storage format rather than in anything portable. Leaving that builder means rebuilding the pages, because the pages are not really content, they are builder instructions. We have written separately about why that lock-in is expensive. For this test it counts as one very large load-bearing dependency, and it should be assessed as such rather than as a design preference.

Test 3: does the content model match what you sell now

This is the one a repair genuinely cannot fix, and the one nearly nobody names.

Underneath the design, a WordPress site has a shape: what kinds of things exist, what fields they have, how they relate. A site built in 2019 for a company selling three services has a shape that fits three services. If the company now runs eleven locations, or a course catalogue, or a product range with variants and specifications, the shape has to hold that. Often it does not, and the site has been coping by pretending everything is a page.

You do not need to look at code to test this. Ask the person who updates the site two questions:

1. When you add a new one of the main thing we sell, what do you do? If the answer involves duplicating an existing page and editing it, there is no content type for your core product. Every item is a bespoke artefact.
2. If a detail that appears on all of them changes, how many places do you edit? If the answer is a number rather than “one”, the same fact is stored dozens of times, and they have already silently drifted apart.

A site that fails this test is not badly designed. It is designed for a different business. And you cannot re-skin your way out of it, because the problem is not on the surface: it is that the data has the wrong structure and every page is a hand-made copy of every other. A visual refresh on top of that produces a prettier version of exactly the same maintenance burden, which is how sites end up rebuilt twice in four years.

If this test fails, rebuild, whatever the other three say. This is the one where the rebuild is the cheap option, because the alternative is paying a person to be a database by hand for the next three years.

Test 4: can anyone deploy a change safely

The last test is about process, and it is the one most likely to be misdiagnosed as a code problem.

Four things, each a yes or no:

• Is there a staging copy where changes get tested before they go live?
• Is the code in version control, so you can see what changed and undo it?
• Are there backups, and has one actually been restored recently? Taking backups and restoring them are different achievements, and only the second one counts.
• Can anyone say what in this site is custom, and where?

Fail these and every change is a gamble, which is why the site has not been touched in two years, which is why it now looks like it needs rebuilding. But notice the causation. Usually this is a process failure wearing a code failure’s clothes, and process is fixable without a rebuild. Set up staging, put the code in git, prove a restore works. That is a week of work, not a project, and it is standard care plan territory rather than a capital expense.

There is one version of this that does force a rebuild: when the site’s state cannot be reproduced. Core files edited in place, plugins patched by hand, a theme nobody has the source for, no way to distinguish deliberate customisation from damage. At that point nobody can safely change anything because nobody knows what it currently is, and recovering that knowledge costs more than rebuilding with it.

Reading the four tests

Result	What it means	What to do
None fail	The site is structurally sound. The complaint is appearance, speed or editability.	Repair. All three are fixable, usually for well under a fifth of a rebuild.
Test 3 fails	The content model is wrong for the business.	Rebuild, regardless of the other three.
One other fails	A dead dependency, or a missing process.	Repair, deliberately and completely, then re-run the tests in six months.
Two or more fail	The failures compound: you cannot fix the dependency without moving PHP, cannot move PHP without deploying safely.	Rebuild. Sequential repairs here are instalments on the same bill.

If it comes out as repair, be honest about what “repair” means. It is not nothing. It is a scoped project with a specification and a price, and the reason it is worth doing is that it keeps everything the site has already earned. Which brings up the cost nobody quotes.

The line item nobody quotes: the URL map

A rebuild changes URLs. Almost always, because the content model changed or the structure improved or the new system does slugs differently. Every one of those changed URLs is a page Google currently ranks, a link somebody else has published, and a bookmark.

This is not a footnote. Google’s own documentation on moving a site with URL changes is direct about the stakes. It tells you to “Keep the redirects for as long as possible, generally at least 1 year.” It warns that “With any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site” and that “As a general rule, a medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer.” And it notes that “the visibility of your content in Search may fluctuate temporarily during the move. This is normal and a site’s rankings will settle down over time.”

Read that as a project requirement rather than reassurance. The temporary, settles-down-over-time case is what you get when the redirects are right. When they are not, the loss is not temporary, and it is discovered months later when somebody finally looks at the traffic.

So before you sign anything, three questions:

• Who produces the old-to-new URL map, and when do I see it? It should exist before launch, not after, and you should be shown it.
• What happens to pages that have no equivalent? Every retired URL needs a decision. Redirecting everything to the homepage is the standard shortcut and it is the wrong answer.
• Who checks it after launch, and for how long? Someone should be watching Search Console for a month, not walking away at handover.

If a rebuild quote does not contain this work, it is not cheaper than one that does. It is the same project with a risk left in it that lands on you.

Why the published cost ranges are useless

Back to the ten-fold spread. The reason those numbers disagree so wildly is that “rebuild” is not one product. The price is set almost entirely by how much carries over, and there are four separate buckets:

• Content. Does it migrate as-is, get restructured, or get rewritten? Restructuring hundreds of pages is often the largest single line, and it is the one most often left out of a quote and discovered halfway through.
• URLs. Preserved, or mapped? See above.
• Integrations. The CRM, the payment provider, the booking system, the ERP feed. Each is a small project with its own testing.
• Custom functionality. Anything the site does that a standard install does not, which has to be specified again from behaviour because the documentation is usually the code.

A rebuild that keeps the content model and the URLs and replaces the presentation layer is a fundamentally different job from one that re-specifies what the site is. Both get called a rebuild. That is the whole reason the ranges are meaningless.

The practical move: ask any quote to be itemised into those four buckets, plus the redirect work. Two quotes broken down that way are comparable. Two totals are not. And a vendor who will not break it down has told you something useful about how the project will go.

For what it is worth, we quote a fixed price before work starts, on both repairs and rebuilds, which is only possible because the scoping happens first. If a partner cannot name a number until they are inside the project, the number is not the problem.

When a rebuild is the wrong call

We turn these down regularly. The honest list:

• When the real complaint is the design. If the tests pass and the site simply looks like 2019, that is a redesign on the existing foundation. It costs a fraction of a rebuild and carries none of the URL risk.
• When the real complaint is speed. Slowness is measurable and usually attributable: hosting, images, render-blocking assets, a missing cache. Measure it first with the actual metrics. Rebuilding a site to make it faster without first finding out why it is slow reliably produces a fast new site that gets slow again.
• When a business change is still in flight. Rebuilding in the middle of a repositioning means specifying a site for a business that does not exist yet. Wait until the offer is settled. The site is downstream of that decision, not a substitute for it.
• When it is really a platform question. Sometimes the answer is not a new WordPress site at all. That is a separate decision and we have written about when to leave WordPress and when to stay, including the cases where the honest answer is stay.
• When nobody will own it afterwards. A new site with no maintenance behind it decays on exactly the same schedule as the old one. If there is no plan for who applies updates and tests them, you are buying the same problem again with a later expiry date.

The point of the four tests

None of this makes the decision for you. What it does is move it off adjectives and onto facts with dates on them, which changes who is qualified to have the conversation. A PHP branch has an end-of-life date. A plugin has a last-updated date. A content model either has a type for your core product or it does not. A backup has either been restored or it has not.

Run the four before you take a quote, and you walk into that meeting knowing which project you are buying. Run them after, and at least you can tell whether the quote is answering the same question you asked.

If you want a second opinion on a site somebody has told you to replace, tell us about it and we will run the four tests and say which one it is, including when the answer is that it does not need rebuilding. Agencies who inherit these sites for their clients can send them the same way: see how we work with agencies, or look at the work itself.

Quick answers

How do I know if my WordPress site needs a rebuild or just repairs? Run four checks that produce facts rather than opinions. What PHP branch it runs on and whether that branch still receives security support, which you can look up by date on php.net. Whether anything it depends on is abandoned with no maintained version that runs on a supported branch. Whether the content model matches what the business sells now, or whether your team creates new items by duplicating pages. And whether anyone can deploy a change safely, with staging, version control and a backup that has actually been restored. If none fail, your complaint is appearance, speed or editability, and all three are repairable. If the third fails, rebuild regardless of the rest.

Does an old PHP version mean I need a rebuild? Not on its own. WordPress deliberately keeps running on end-of-life PHP: wordpress.org recommends PHP 8.3 or greater but notes the software still runs on PHP 7.4 and MySQL 5.5.5, which have reached official End Of Life and may expose your site to security vulnerabilities. A working site is not evidence of a supported one. The upgrade itself is usually a small job, and what decides the question is what happens when you try it. If the site moves to a supported branch and nothing breaks, you had a maintenance task. If it cannot move because a load-bearing plugin or theme will not run there and has no maintained replacement, the rebuild was already happening and you were paying for it in instalments.

What does a WordPress rebuild actually cost? Published ranges are close to useless because they answer a different question. Ask two answer engines the same week and you get 20,000 to 100,000 dollars from one and 8,000 to 40,000 from the other, with one quoting WooCommerce rebuilds at 3,000 to 12,000 while calling them more complex than the sites it priced higher. That spread is not a market range, it is the absence of a specification. The number is set by how much carries over: content, URLs, integrations and custom functionality. Get any quote itemised into those four buckets plus the redirect work and the ranges stop mattering.

Will a rebuild hurt my search rankings? It puts them at risk, and that risk is a line item most quotes leave out. Google’s site move documentation tells you to keep redirects for as long as possible, generally at least 1 year, and warns that with any significant change to a site you may experience ranking fluctuations while Google recrawls and reindexes, with a medium-sized website taking a few weeks for most pages to move in the index and larger sites longer. That is the documented normal case with the redirects done correctly. Done incorrectly, the loss is not temporary. Before signing, ask who produces the old-URL-to-new-URL map, when you will see it, and who checks it after launch.