Take five readings off your own site before you decide anything. If the site is out of date in one place, fix that one place. If it is out of date in four or five places at once, the repairs keep arriving, and starting over is usually the cheaper end of it.
Take five readings before you decide
Log in as an administrator and open Tools, then Site Health. The WordPress.org documentation for that screen, first published June 18, 2021 and last updated July 12, 2026, describes two tabs there, Status and Info.
Write these five things down with today’s date next to them:
- Critical issues. The Status tab groups what it finds by severity: critical issues, recommended improvements, and passed tests. Count the criticals.
- Your PHP version. Info tab, Server section.
- Plugin counts. Info tab, Active Plugins and Inactive Plugins. That is two numbers.
- Your oldest plugin. Every listing in the WordPress.org plugin directory carries a Last updated line, written as how long ago it was. Find the oldest one you are running.
- Your total size. Info tab, Directories and Sizes, which gives the size of your uploads, themes and plugins directories, and the size of the database.
Five numbers, one coffee. Anyone quoting you for a repair or a rebuild should be able to read those same five back to you.
What the five readings are telling you
The documentation describes critical issues as parts of your website that can be “potential security vulnerabilities or serious performance issues.” One or two named criticals is a repair list. Seven is a condition.
PHP is the language WordPress runs on. The WordPress.org Requirements page asks for “Version 8.3 or greater,” and says WordPress “will still run on PHP 7.4+ and MySQL 5.5.5+, but those versions have reached official End Of Life and may expose your site to security vulnerabilities.” That page carries no update date, so it was read for this article in August 2026.
Old PHP is common, and on its own it is not a reason to start over. The version spread WordPress.org publishes at api.wordpress.org/stats/php/1.0/ had 17.5% of reporting sites on 7.4 and another 4.2% on 8.0 when it was read in August 2026. That feed carries no update date. Even current PHP has a clock on it: php.net’s Supported Versions page lists security fixes for 8.2 ending 31 December 2026, and that page carries no update date either.
Moving PHP up is usually a setting at your host, not a new website. What makes it hard is the old plugins that stop working after you do it. There is more on the warning your host sends if you have had one.
Then the plugin dates. Read in August 2026, the Yoast SEO listing in the plugin directory showed version 28.3, an active install count printed as 10+ million, and a Last updated line reading one day ago. A plugin on your site doing a much smaller job, last updated in 2021, is a different animal. It still runs. Nobody is watching it.
Size tells you how much has to move. A 40 MB uploads folder is a morning of work. A 12 GB one is a job in itself.
When fixing it is the right call
Fix when the readings are mostly clean and the faults have names.
- The criticals are few, and each one points at a thing: a plugin waiting on an update, debug mode left switched on, a background update that failed. All three are named in that documentation.
- PHP is behind, but your active plugins are current and still maintained.
- The pages themselves are fine. The words are right, the phone number is right, the photos are yours.
- Somebody is paid to keep it patched, and has been for a while.
A working site with three named faults does not need throwing away. Deleting what you stopped using is often most of the job, and telling an abandoned plugin from a merely old one is the check worth running first.
When starting over is the honest answer
Start over when the readings come back old in every direction at once.
- Criticals in the handful, and the same ones return after each fix.
- Old PHP, and the plugins that would break on new PHP are themselves years past their last update.
- A dozen or more active plugins, several last updated before 2023.
- A paid theme or page builder whose renewal lapsed, with nobody left who knows who bought it.
- Nobody is paid for upkeep, and nobody has been for years.
That last one decides more of these than any number on the screen. A WordPress site needs a person. If no one is paid to run the updates, a repaired site drifts back toward the same readings, and you pay for the same morning twice.
What carries over is the part you actually own: your words, your photos, your page addresses, and your phone number. The plugins do not carry over, and that is the point of moving. On a static build there is nothing to log into and nothing sitting there waiting to be patched, which is how these sites get built.
What these five readings will not tell you
Site Health is a machine checking a machine. It does not grade your design, your writing, or whether a page answers the question a customer actually typed. A site can pass every test on that screen and still not ring the phone.
It does not weigh what any of it costs you, either. The documentation files a failed loopback request and an outdated, unpatched PHP version under the same heading, critical issues, and the screen cannot tell you which of the two is costing you calls.
A Last updated line does not prove a plugin is broken either. Small plugins sit still for years and work fine. The date tells you who is watching, not what is wrong.
And if all five readings come back clean, do not buy a rebuild. Not here, not anywhere. A patched, current, quick enough site is not improved by being replaced, and anyone who says otherwise is reading their own price list instead of your Site Health screen.
No client results are published on this site. The one speed proof owned outright is this site’s own launch-day score of 100 on Google’s PageSpeed test, desktop and mobile. Somebody else’s fast website says nothing about what yours would do.
What to do this week
- Open Tools, then Site Health, and write the five readings down with the date beside them.
- Take the same five readings again in 30 days without touching anything. Two dated sets tell you whether the site is drifting or holding still.
- Ask anyone who quotes you which of the five readings changes after the work, and what each should read afterwards. A quote that cannot answer that is a guess.
- Ask who runs the updates once the work is done, and what that costs every month. Monthly plans are listed on the pricing page.
- If the answer to that last one is nobody, lean toward the option with less to patch.
Then decide once, write down why, and stop reading vendor pages. Both answers are respectable. The wrong move is paying for a rebuild you did not need, or paying every quarter to keep a site breathing that stopped earning its keep three years ago.