WordPress 7.1 is scheduled for 2026-08-19. Because it is a major release, it will not install itself: it will sit in Dashboard > Updates waiting for you to click a button. This is the twenty minutes to spend before you click it.
Every step below has a time cost next to it, for one reason: most checklists assume you will do all of them, and most people do about a third. If you only have ten minutes, the costs tell you which third to keep. Steps 1 and 2 are the ones that are never worth cutting.
Version and verification. Written against WordPress 7.0.2, released 2026-07-17, current stable. WordPress 7.1 final is scheduled 2026-08-19 and reached Beta 1 on 2026-07-15. Last verified 2026-07-30 against wordpress.org and make.wordpress.org.
The checklist, in one screen
| # | Step | Time | Cut it? |
|---|---|---|---|
| 1 | Confirm you can restore a backup, not just that you have one | 5 min | Never |
| 2 | Check your PHP version | 4 min | Never |
| 3 | Identify the plugins most likely to break | 4 min | Only if you have fewer than five plugins |
| 4 | Read the release note for the version you are moving to | 3 min | Yes, if short on time |
| 5 | Decide what your caching layer will do | 2 min | No, it is two minutes |
| 6 | Pick the hour, and decide how you will confirm it worked | 2 min | No, it is two minutes |
Minutes 1 to 5: confirm you can restore, not just that you have a backup
This is the step the whole checklist exists for. A backup you have never restored is not a safety net, it is a belief about a file. The point of these five minutes is to convert the belief into knowledge before you need it.
Answer these three questions, and answer them by looking, not by remembering:
- Where is my most recent backup, and what is its date? If your host takes them, this is in their control panel. If a plugin takes them, it is in that plugin's own screen. If neither is true, you do not have a backup, and that is the finding.
- Does it contain the database and the files, or only one of them? A database-only backup will bring your content back and none of your plugins. A files-only backup will do the reverse. Both are common and both are half a backup.
- What is the actual restore procedure, and who performs it? Read it now. If the answer is "open a support ticket and wait", that is a number of hours you need to know in advance, not discover during an outage.
Why this can hurt if you skip it: the reason to have a backup before a major update is that a bad update can take your site off the web. If the backup turns out to be incomplete at that exact moment, the outage stops being an inconvenience and becomes a rebuild. That is the risk, stated plainly, and it is the only reason this step is first.
If you have never restored a backup and you have somewhere safe to try, restoring one onto a copy of your site is the way to find out for certain. Testing an update on a copy of your site covers how to make that copy, and the restore test comes free with it.
Minutes 6 to 9: check your PHP version
Go to Tools > Site Health. The Status tab will raise a critical issue if your PHP version is outdated. The Info tab, under Server, tells you the exact version.
What you are checking against, as of the verification date:
- WordPress requires PHP 7.4 or greater. Support for PHP 7.2 and 7.3 ended with the 7.0 release.
- WordPress.org recommends PHP 8.3 or greater, and is explicit that 7.4 still works but has reached end of life, so it no longer receives security fixes.
- The database floor is MariaDB 10.11+ or MySQL 8.0+.
Two findings matter here. If you are below 7.4, the WordPress update is not your immediate problem and you should not click it today. If you are on 7.4 exactly, the update will work, but you are on an end-of-life PHP version and that is a separate conversation with your host that should not be scheduled for the same afternoon as a WordPress update. Never change your PHP version and your WordPress version on the same day. If something breaks, you will not know which one did it.
While you are on the Site Health Status tab, note whether it says background updates are not working as expected, or that your site could not reach WordPress.org. Either of those means the update itself may fail partway through, which is a worse outcome than not updating.
Minutes 10 to 13: find the plugins most likely to break
You are not auditing everything. You are finding the two or three plugins that would cause real damage if they failed, and checking those.
Go to Tools > Site Health > Info and expand Active Plugins. You get every plugin with its version and its auto-update state, and there is a copy-to-clipboard export of the whole report if you want it somewhere you can read it.
Scan for three things:
- The plugin you would most hate to lose. Your form plugin, your shop, your membership gate, your booking system. If it fails, that is money or leads.
- Anything that changes the admin interface. On the 7.0 and 7.1 generation of releases specifically, this is the highest-risk category, because the admin screens these plugins hook into were rebuilt in 7.0.
- Anything that has not been updated in a long time. The Site Health list gives you versions, and the plugin's own directory page gives you its last-updated date.
For those plugins only, do the full research pass in how to find out which of your plugins will break. It is a longer method than four minutes and it is worth running on two plugins rather than skipping on thirty. Note also that a plugin's "Tested up to" figure is developer-declared and verified by nobody, so weight it as a rough timestamp rather than as a test result.
Minutes 14 to 16: read the release note for the version you are moving to
Not the whole field guide. Three questions:
- Does the minimum PHP or database version change? This is the single change most likely to affect you and it is always stated near the top.
- Is anything being removed or deprecated? Removals break things. Additions do not.
- Does it touch a screen or feature you rely on daily?
For 7.1 specifically, the announced set is a Tabs block, Playlist and Table of Contents blocks, styling for hover and focus states and for tablet and phone widths without writing CSS, an expanded Notes system with mentions and threads, and improved media handling including a new image editor. That is an additive release on its face. The full 7.1 guide has the by-site-type answer on whether to update on day one, and it is worth reading before the nineteenth rather than on it.
Minutes 17 to 18: decide what your caching layer will do
If you run a caching plugin, a host page cache, or a CDN, decide now what happens to it during the update, because a stale cache after a core update produces symptoms that look exactly like a broken site and are not.
The two minutes are: find your cache-clearing control before you need it, and know whether your host's cache clears itself on a WordPress update or has to be cleared by hand. WordPress's own update documentation includes clearing the cache as an explicit final step, for exactly this reason.
Minutes 19 to 20: pick the hour, and know how you will check it worked
Pick a low-traffic hour when you will be at your desk for the following thirty minutes. Not last thing at night, and not immediately before you leave. A major update that goes wrong is recoverable in twenty minutes and unrecoverable if nobody notices for nine hours.
Write down the five things you will click afterwards. Not "check the site". Five specific things: your homepage, one post, the admin dashboard, the one plugin you identified in step 3, and whatever your site's most important action is, whether that is a contact form, a checkout or a login.
Having the list written down before you update is what makes the check happen. Deciding what to test after an update is how partial breakage ships unnoticed for a week.
The four findings that mean do not update today
Most checklists assume the answer is yes. These are the results that mean no:
- You cannot locate a backup, or it is only half a backup. Fix that first. Nothing else on this list matters.
- You are on PHP below 7.4. Sort out PHP with your host, on its own day, then come back.
- Site Health says background updates are not working, or that your site cannot reach WordPress.org. An update that cannot complete is worse than one not started.
- A plugin you genuinely depend on has not shipped an update since before the release you are moving to. Wait for the vendor, or test on a copy. Do not do it live and hope.
There is a fifth, softer one: if the release is less than a few days old and your site earns money, waiting a week costs you nothing. Point releases exist because early adopters find things.
If you have twenty minutes a month instead of twenty minutes today
The version of this checklist that scales is not a checklist. It is three standing habits:
- Know that your backups restore, because you tested one at some point in the last few months.
- Keep plugins current in small batches, so that no single update is a leap across a year of changes.
- Do not run plugins you do not use. Deactivated plugins still have to be updated and still carry risk. Site Health's Inactive Plugins list is the place to see how many you have collected.
Sites that follow those three rarely need a pre-update checklist, because their updates are small. Sites that do not need the full twenty minutes every time.
Specifically before 2026-08-19
Between now and release day, in priority order: confirm a restore, get off any PHP version below 7.4, run the compatibility research on your two most important plugins, and if the site earns money, put the update on a copy first. If the worst happens anyway, rolling back without losing content covers the three separate rollback procedures and the case where restoring a backup is the better call. For the wider picture of what the 7.x generation changed, the site owner's guide to WordPress 7 is the overview, and what actually happens during an update explains the mechanism, which makes the errors legible if any appear.
