You are about to do something to your site that you are slightly unsure about. Edit a file, update a plugin you depend on, change a setting whose effect you cannot picture, run an instruction you found in a forum post.
This page is the five minutes before that. It is deliberately short, because a precaution long enough to feel like a project is a precaution people skip.
The five steps
1. Take a backup now, and confirm it finished.
Not "there is a nightly backup". One taken in the last few minutes, with a success message you have actually seen. Nightly means the last one could be twenty-three hours old, and twenty-three hours is a lot of orders, comments and edits.
2. Note the time and the exact backup you just made.
Write it down where you will find it under stress. Two backups an hour apart are indistinguishable at midnight when a filename is all you have to go on.
3. Write down what you are about to change, in one line.
"Updating Contact Form plugin from 5.2 to 5.3." "Adding a snippet to the theme's functions file." "Changing the permalink structure."
This is the step that gets skipped and the one that pays. Ninety percent of undoing something is remembering precisely what was done, and the memory is reliably worse than people expect twenty minutes later.
4. Know the reversal before you act.
Say how you would undo it, specifically. Reinstall the previous version. Delete the lines you added. Set the setting back to what it was, which means writing down what it was.
If you cannot describe the reversal, you are not ready to make the change. That single test catches the changes that genuinely warrant a staging site instead.
5. Pick your moment.
Not immediately before you have to leave. Not during your busiest hour. The cost of a failed change is a function of how long it stays broken, and the person best placed to fix it in the next thirty minutes is the person who just made it.
Which changes deserve this
Not everything. Publishing a post, adding an image, editing text: no ritual needed.
Run it for anything in this list. Any plugin or theme update you have not tested elsewhere. Any core update on a site that matters. Any edit to wp-config.php, functions.php or a theme file. Any change to permalinks, site address, or user roles. Any code you copied from anywhere. Any bulk operation across many posts. Any deletion of a plugin that stores its own data.
The common factor is not difficulty. It is whether the change touches something the site cannot run without, or something that is hard to describe afterwards.
Why one line of writing beats a good memory
The step people find hardest to take seriously is step 3, and it is the one with the highest return.
Consider two versions of the same evening. In the first, something breaks and you know you changed a few things but not the order or the exact values. Recovery is a search, and the search is through your own uncertain recollection.
In the second, you have four lines of text with times against them. Recovery is a list you work backward through. Same site, same fault, very different hour.
That note is also what makes a plugin's support forum useful. "It broke after I updated" gets a generic reply. "It broke after updating from 5.2 to 5.3 on WordPress 7.1, with these plugins active" gets an answer.
The two-minute version, when five is too many
Sometimes you are mid-task and the full ritual is not going to happen. The compressed form, in priority order:
Copy the file you are about to edit. Download it, keep the copy. This is the whole precaution for a single-file edit and it takes thirty seconds.
Screenshot the settings screen before you change it. Now you know what the old value was, which is the thing people forget.
Neither replaces a backup. Both are enormously better than nothing, and both take less time than deciding whether to bother.
Where this ritual sits
For updates specifically, the ritual is the first part of a longer routine, and our pre-update checklist covers the rest: what to check about compatibility, what order to update in, and what to look at afterwards.
For anything you would rather not test on a live site at all, the answer is not a better backup but a copy of the site, and testing on a copy first explains how that works on ordinary hosting.
And for the moment when the ritual turns out to have been worth it, the backup you took in step 1 is the one you restore. Which is a good reason for step 1 to have actually happened.
The honest note about backups you have never restored
Every step on this page assumes your backup works. Most site owners have never tested that assumption, and a meaningful share of untested backups do not restore: no database in the archive, a job that stopped weeks ago, or a file that will not open.
That is a separate afternoon's work and it is the single highest-value maintenance task on a WordPress site. This ritual is what you do before each risky change. Proving the backup is what makes the ritual mean anything.
Version context. Written against WordPress 7.1, released 2026-08-19, the current major release on our record. Nothing on this page is version-specific. Release dates come from our own dated record of the WordPress.org release page, last read 2026-08-19. No backup product is named or recommended here, deliberately.
