Guide · Updates
Updating WordPress without breaking your site
A four-step method you can apply by hand today, and the list of what to check before considering the update finished.
Short answer
Can you update WordPress directly in production?
It depends on what the site does and how much risk you accept. On a stable brochure site, updating directly after taking a backup is a reasonable choice. On a site that takes orders, bookings or payments, updates should go through a test copy first.
Either way the useful rule is the same: back up, update in batches, verify, roll back if needed. An update is not finished when WordPress says “update successful”. It is finished when the site’s important functions have been checked.
Why an update breaks something
Almost never because of the WordPress core itself. Almost always because of what surrounds it.
A WordPress site assembles three pieces of software that do not coordinate: the core, published by the WordPress project; the theme, which decides how the site looks; and the plugins, fifteen to thirty of them on a small-business site, each with its own vendor and calendar.
Every plugin assumes a version of WordPress, a version of PHP, sometimes the presence of another plugin. Those assumptions are written nowhere in your dashboard. When one stops being true, the function that depended on it stops, often with no visible error. That is how a form stops sending email when nobody has touched the form.
Worth remembering
An update almost never breaks a current site. It breaks a site that is behind, because it catches up several versions at once. The risk grows with the time since the last pass, not with the act of updating.
The four-step method
This is the sequence we follow, and the one you can follow yourself. It is manual today: every step is done and checked by a person.
-
Back up
Files and database, before touching anything. A backup that lives on the same server as the site only half counts.
-
Update
In batches, in a decided order, not all at once. Core first, then theme, then plugins.
-
Verify
The pages and functions that matter to your business. This is the step almost everyone skips.
-
Roll back if needed
Return to the backup point, then redo the updates one at a time to isolate the cause.
Repère follows this sequence by hand, with a written record of every intervention. Deeper automation of the verification step is being looked at, but it is not deployed: nothing we do today automatically checks how your pages look or restores your site without a human decision.
In what order, and why it matters
“Update everything” looks responsible. The gesture makes diagnosis impossible: if twelve things change at once and the site drifts, you have twelve suspects, and the only way to find the right one is to undo all of it.
The same twelve updates done in batches, with a check between each, narrow the culprit to two or three items in a few minutes.
| Order | What | Why here |
|---|---|---|
| 1 | The WordPress core | Everything else assumes a core version. Updating it last creates temporary incompatibilities nobody can read. |
| 2 | The theme | It depends on the core and usually carries the display of your critical pages. |
| 3 | Security and caching plugins | They sit in front of everything else. An error here hides the others. |
| 4 | Functional plugins | Forms, store, bookings. In small batches, with a check between each. |
| 5 | The rest | Anything that touches neither display nor function. Lowest risk. |
Technical detail
On a site running WooCommerce, treat the store as its own batch and check the purchase path after each one. A payment plugin updated at the same time as a theme makes a broken cart far slower to diagnose.
If your host offers a staging copy, run the whole sequence there first. That is not a guarantee: a staging copy with different data does not reproduce every case in production.
What to check before calling it done
The minimum list. It takes a few minutes and avoids most of the bad surprises.
After every update
- The home page renders with no empty area and no shifted layout.
- Two or three critical pages the ones your business runs on, not the ones that are convenient to test.
- The contact form send a real one and confirm it lands in the right mailbox.
- Navigation and menu on desktop and on a phone, where the behaviour often differs.
- The browser console open it and look for red errors that were not there before.
- Signing in to the admin log out and log back in once.
- For a store add to cart, go through checkout, and check the confirmation email.
Worth remembering
An update is not finished when WordPress says “update successful”. It is finished when the site’s important functions have been checked.
Rolling back
If something stops working, the right reaction is not to keep changing things. It is to return to a known state.
If you have a verified backup, going back to it is often faster than searching. You then redo the updates one at a time, and the cause shows up in minutes instead of hours.
Careful
Do not restore a backup over a site that is taking orders without looking at what happened in between. On a store, restoring erases the orders received since the backup point.
Before any restore, take a copy of the current state, broken as it is. That is what keeps the option of going forward again.
The triage detail is in a separate guide: what to do when an update has broken the site.
When to avoid automatic updates
WordPress can apply some updates on its own, and that behaviour is configurable in the admin as well as on the server side.
It is reasonable for core security fixes and for simple, well-maintained plugins that nothing important depends on.
It is less reasonable for anything carrying display or a central function: theme, page builder, form plugin, store plugin. There, the update would happen with nobody checking afterwards, and the fault would be found by a customer.
Worth remembering
Automatic updates are not a problem because they update. They are a problem because nobody checks afterwards.
Common questions
Should everything be updated as soon as a version ships?
For security fixes, the sooner the better. For the rest, waiting a few days after a major release avoids the problems found by whoever updated first. Waiting six months, on the other hand, creates the backlog that will make the next update risky.
Is a staging copy essential?
Not on a stable brochure site, if you back up before and check after. It becomes hard to avoid as soon as the site takes orders, bookings or payments.
How long does this method take?
On a typical site, fifteen to thirty minutes including verification. That is longer than clicking “update all”, and far shorter than half a day spent looking for what broke.
What if I have no backup?
Make one before anything else, even by hand. Updating with no point of return turns an ordinary incident into a long one.
Hand this upkeep to Repère
The updates, the checks and the written record, handled for you. Twenty minutes to look at your site, then a proposal.
Hand maintenance to Repère View the free checklist