Short answer: do not click Update. To update a very old WordPress site safely, work in this order: (1) take a full backup of files and database and confirm you can restore it, (2) make a staging copy and do everything there first, (3) check what PHP version your server runs, because PHP and WordPress constrain each other, (4) update plugins and themes before core, and pause at the versions where your components broke, (5) update core last, then re-test. The jump itself is usually safe for WordPress. Your plugins are what will not survive it.
Version context (as of 2026-07-22): current stable is WordPress 7.0.2, released 2026-07-17. WordPress 7.1 is scheduled for 2026-08-19. WordPress 7.0 raised the minimum PHP version to 7.4; WordPress.org recommends PHP 8.3 or greater.
Before anything: the backup, and the restore you have actually performed
A backup you have never restored is a belief about a file. On a site this far behind, that distinction is the whole article, because the failure mode here is not a broken layout. It is a site that will not load and a backup that turns out to contain only the database.
Do these three things now, in this order:
- Take a full backup: files and database. Either half alone is a half backup. A database-only backup restores your posts and none of your plugins. A files-only backup does the reverse.
- Download a copy off the server. A backup living only on the same hosting account is one account problem away from gone.
- Confirm the restore path and time it. If the answer is "open a support ticket", find out now how many hours that takes, rather than discovering it during an outage. If your host offers one-click restore, read the page that describes it before you need it.
If you have somewhere safe to try a restore, do the restore test onto a staging copy. It costs twenty minutes and converts a belief into knowledge.
Do not edit WordPress core files at any point in this process. Nothing in a safe update requires it, and edits to core are erased by the next update anyway.
Step 1: build a staging copy and do all of this there
Many hosts offer one-click staging in the control panel. If yours does, use it. A staging site is a copy of your site on a hidden address where a fatal error costs you nothing.
If your host does not offer staging, say so plainly to yourself and plan around it. Your options, in order of preference:
- A local copy on your own computer using a local WordPress environment. Free, and the update rehearsal is identical.
- A duplicate install on a subdomain of the same hosting account, restored from the backup you just took.
- No copy at all. This is the real fallback for many small sites, and it is workable only if you accept a maintenance window: pick an hour when nobody visits, confirm the restore path first, and be prepared to use it.
How to test an update on a copy of your site first covers making the copy in detail.
Step 2: the PHP pincer, which is where old sites actually get stuck
This is the part that traps people, and most guides skip it.
Your old WordPress needs an old PHP to keep running. Current WordPress needs a newer PHP. If your host has already moved you to a modern PHP, your old site may be broken before you start. If your host still runs an ancient PHP, current WordPress will not install onto it.
So the two have to move together, and the order depends on which is the blocker:
| Your situation | Move first |
|---|---|
| Old PHP, old WordPress, site works | WordPress and plugins first, on staging, then raise PHP once the code is modern enough to survive it |
| PHP already raised by the host, old site now erroring | The code, urgently. The site is running on a stack it was not written for |
| Host cannot offer a PHP version current WordPress supports | Change hosts, or accept you cannot reach current WordPress |
Find your PHP version at Tools > Site Health > Info > Server. On very old installs the Site Health screen may not exist, in which case the host control panel shows it. Checking your PHP version before a WordPress upgrade walks through the mechanics and the reversal if the change goes badly.
Raising PHP is a control-panel setting, and on most hosts it can be set straight back. Confirm that your host allows switching back before you switch, because "it can be changed back in one click" is what makes this a safe experiment rather than a one-way door.
Step 3: what "update incrementally" really means
The common advice is to never skip more than one major version. It is worth understanding what that advice is actually protecting you from, because it is not core.
WordPress's own upgrade routine applies every database change between your version and the version you land on, in order. Core is built for the jump. The thing that has no migration path is everything else: a theme written for WordPress 4.x has no idea what happened in the eight years since, and a plugin that stopped being updated in 2019 will not gain compatibility by being carried over one version at a time.
So the useful version of the advice is: step through the versions where your components broke, not through arbitrary version numbers. The milestones that matter for an old site:
- WordPress 5.0 (December 2018) replaced the editor with the block editor. If your site predates it, your editing experience changes completely. The Classic Editor plugin exists precisely for this transition.
- The 5.5 to 5.7 line (2020 to 2021) modernized the bundled jQuery. Old themes and plugins that relied on removed jQuery behavior are a classic breakage point from this era.
- The 5.9 and 6.x line introduced full site editing and block themes. A classic theme still works, but the vocabulary of the Appearance menu changes.
- WordPress 7.0 (2026-05-20) delivered the largest admin redesign since 2013 and raised the PHP minimum to 7.4. See the WordPress 7.x guide for site owners for what changed.
WordPress.org keeps a release archive of older versions, and states plainly that old releases are unsupported and may contain security issues. Use them only on a staging copy, only to step past a known breakage, and never as a destination.
Step 4: the actual sequence, on staging
- Inventory first. Write down every active plugin and its version, and your theme and its version. You will need this list when something disappears.
- Deactivate plugins, but do not delete them. Deactivating preserves settings; deleting usually destroys them.
- Update plugins and themes that still have updates available. Anything whose author has stopped shipping updates will not move, and that is a finding, not a failure. How to check plugin compatibility before updating covers how to judge which ones will survive.
- Switch temporarily to a default WordPress theme so a broken theme cannot mask a core problem. Your own theme's settings stay in the database while you do this.
- Update core. Watch for the database upgrade prompt and let it finish. Do not reload or interrupt it.
- Reactivate plugins one at a time, checking the front end after each. The one that breaks the site is the one you now have a decision to make about.
- Switch your theme back, then compare against the inventory from step 1.
Then use the real site's most important page as your test, not the homepage. A homepage that loads proves very little.
The part nobody says: an old site may already be compromised
A site running years-old code with known vulnerabilities has been publicly reachable that whole time. Updating it patches the hole. It does not remove anything that already came through the hole, and a backdoor in a theme file or an unfamiliar admin user survives the update perfectly.
Before you restore an old backup onto a fresh stack, look for: admin users you do not recognize under Users, scheduled posts or pages you did not write, and unexplained files in the uploads folder. If you find any of it, you are dealing with cleanup, not an update, and that is a different job with a different order of operations.
When rebuilding beats updating
There is a point where updating is the harder path, and honest guides should name it. Consider a fresh install with content imported instead if: your theme is abandoned and heavily customized, more than half your active plugins have not been updated in years, or the site is small enough that rebuilding the pages is a day of work. WordPress's export tool moves posts, pages, categories and media between installs, and it is often faster than dragging a decade of accumulated decisions forward.
Rebuilding loses your design and your plugin settings. It keeps your content and your URLs, which are the parts search engines care about.
If it goes wrong
You have a backup and you have already timed the restore, which is why that was step zero. Rolling back a WordPress update covers the undo path in detail, and the pre-update checklist is the short version to run before every future update, so the next gap is two weeks and not two years.
FAQ
Can I update WordPress from a very old version directly to the latest?
Core itself is designed for it: the upgrade routine applies each version's database changes in sequence. The risk is not core, it is your plugins and theme, which have no equivalent migration path.
Will updating an old WordPress site delete my content?
Updating does not delete posts, pages or media. What can be lost is customization made directly to theme files, plugin functionality whose plugin no longer works, and layouts that depended on a plugin that has stopped loading.
Do I update plugins first or WordPress first?
On an old site, plugins and themes first, then core. Current plugin versions are far more likely to run on current core than old plugin versions are, so moving them first shortens the window where the two are mismatched.
What if my host still runs an old PHP version?
Then current WordPress cannot be installed there. Ask the host which PHP versions they offer and whether the change can be reverted. If they cannot offer a version current WordPress supports, the hosting is the blocker, not WordPress.
How do I know whether my theme is abandoned?
Check when the theme was last updated on its source page: the WordPress.org theme directory shows a last-updated date, and a commercial theme's changelog does the same. Years of silence combined with heavy customization is the strongest argument for rebuilding rather than updating.
