Update screens usually offer a “select all” checkbox. Twelve plugins, core and the theme all go up together and it takes three minutes. Then, if the site breaks, you are left staring at fourteen suspects.
Following an order is not about safety in itself. It is about staying in a state where attribution is possible. Raise one thing, check, and if it broke, the thing you just raised is the cause. That difference is five minutes versus half a day.
The order — bottom layer first
Core goes first. The upper layers assume things about the layer below, so it is natural to bring the foundation current and then fit the rest on top of it. Do it the other way and a plugin built for the newer core can misbehave on the older one.
Major core jumps deserve an exception. When core moves a whole version, it is usually better to bring plugins and theme current first, because releases supporting the new core are already out. So: minor releases, core first; major jumps, tidy the upper layers and then move core.
Plugins go one at a time. This is the step where the temptation to batch is strongest, and also where the suspect list is longest. Rather than twelve separate checks, split by importance: anything owning a core function of the site — payments, forms, membership, caching — goes up alone, and the small accessories can travel in a group.
The theme goes last. It sits closest to the screen, breaks most visibly, and if you run a child theme, changes in the parent can collide with your overrides.
The checks in between are half the method
Keeping the order but skipping the checks defeats the point of the order. That said, you do not need a full audit at every step. Thirty seconds is enough.
That last line earns its place. A site can look perfectly fine while warnings quietly pile up in the log, and those warnings are a forecast: it works now and will break in a future version. Reading them today makes the next update considerably easier.
When you cannot follow the order
Sometimes the order has to give way. The usual case is a published vulnerability in one plugin that has to go up immediately. Then speed wins — security patches are the exception. Raise that one thing, and run the rest of the backlog through the normal order separately.
If the backlog is already dozens of releases deep, ordering will not rescue it. In that situation, read part four of this series about staging first.
Responding to vulnerability disclosures is covered in the Security archive, and where the backlog has grown large enough that raising things in order is itself risky, we run the parallel verification described on our process page.
Next part
Even with an order, things break. The next part is the safety net you build beforehand — and why files and database have to be captured at the same moment.