Updating a shop is not the same as updating a website. A broken plugin on a blog is embarrassing; a broken checkout takes orders that cannot be fulfilled, or takes none at all while looking fine.
The procedure below is what makes the difference between an update and an incident.
Never update the live shop first
Update a staging copy, walk the whole purchase path, then apply the same updates to live.
"The same updates" matters: applying a different set to live because a week has passed means you tested one thing and shipped another. How to Set Up a WordPress Staging Site explains making one, including keeping it out of search results and stopping it emailing customers.
Order matters
WooCommerce, then payment gateways and shipping extensions, then the theme, then everything else.
Gateway and shipping plugins are written against a WooCommerce version, and updating them first can leave them expecting behaviour that is not there yet. Doing it in this order means each step is compatible with what is already installed.
One at a time, checking between each. Batching five updates and finding the checkout broken tells you nothing about which one did it.
The database update step
The part specific to WooCommerce, and the one people click past.
Major updates change the database structure, and afterwards a notice appears asking you to run the update. Until you do, the shop runs against a structure the new code does not fully expect.
On a large catalogue that update runs in the background and takes time. Do not start it and immediately begin editing products: let it finish, and check the notice has gone rather than assuming.
Take a database export first. This is a structural change and it is not reversible by deactivating anything.
Template overrides go stale silently
The failure that appears months after the update.
A theme can override WooCommerce templates by copying them into itself. Those copies stop receiving upstream changes, so when WooCommerce changes what a template does, the shop keeps using the old version.
The result is usually not an error. It is a checkout field that stopped appearing, or a new feature that never shows up.
WooCommerce's status page lists outdated template overrides with the version each is behind. Read it after every update, and update the overrides your theme actually needs while deleting the ones nobody customised.
Check the status page generally
Under WooCommerce's tools there is a status report listing PHP version, extensions, database version, template status and any plugin flagged as incompatible.
It takes thirty seconds and it is the single best pre-update check available. A missing extension or an old PHP version explains failures that otherwise look random. There is more on changing it in MultiPHP Manager and Choosing a PHP Version.
Test with a real order
Not test mode. A real order, through each active payment method, refunded afterwards.
That is the only way to confirm the gateway takes money, the order is recorded, stock decrements, and the confirmation email arrives. Test mode exercises a different code path in some gateways, which is precisely why a shop can pass its tests and fail in production. There is more on the callback that fails silently in How to Configure Payment Gateways in WooCommerce.
Do not update during trading hours
Pick a genuinely quiet hour, and freeze updates entirely in the fortnight before a sales peak.
The reason is not the update itself; it is that a problem during a busy period is ambiguous. A shop that changed nothing and broke has a capacity problem; one that updated three plugins has an unknown. How to Prepare Your Store for a Sales Peak explains the freeze.
Automatic updates on a shop
A real trade rather than an obvious answer.
Minor and security updates automatically is reasonable, and it keeps a shop from falling behind while nobody is watching. Major versions of WooCommerce, the theme, and the gateway plugins should be manual.
If you enable automatic updates at all, enable the backup that runs before them. That is what turns a bad update into a restore instead of an incident. How to Enable Automatic Updates in WordPress goes into the settings.
What to check after going live
A product page with variations. A category page. Add to cart. The cart page. Checkout, including shipping calculation and the tax line. And the order confirmation email actually arriving at an external address.
Then watch the order flow for an hour. Orders arriving at a normal rate and then stopping means something broke, and that is the signal that arrives before any customer contacts you. For diagnosing what, see WooCommerce Troubleshooting Guide.
If something breaks
Roll back the plugin rather than debugging it live. Most plugins keep previous versions available, and a rollback plugin makes it one click.
What you cannot roll back cleanly is the database update. That is why the export before it matters, and why a major WooCommerce update deserves its own window instead of being bundled with everything else.
Testing on a copy is the safe route, provided the copy is never pushed back wholesale. How to Run a Staging Store Without Losing Orders walks through the rule and the three things to disable.
Record the versions before you start
The list of what was running when the shop worked is the thing you need if a problem appears a week later.
wp plugin list --fields=name,version,status > plugins-$(date +%F).csv wp theme list --fields=name,version,status >> plugins-$(date +%F).csv wp core version >> plugins-$(date +%F).csv wp option get woocommerce_db_version
Keep the file off the server. It costs nothing and it converts a vague question about what changed into a diff.
The database version is worth recording separately, since it moves independently of the plugin version and a mismatch between the two is a recognisable failure state after an interrupted update.
Watch the order flow, not the front page
After an update the catalogue almost always works. What breaks is further along, where fewer people look.
wp wc shop_order list --user=1 --field=id --per_page=5 2>/dev/null ls -la wp-content/uploads/wc-logs/ 2>/dev/null | tail -5 grep -icE 'fatal|uncaught' wp-content/uploads/wc-logs/*.log 2>/dev/null | tail -3
Place a real order through to payment on the day of the update, using a live method and refunding it afterwards. A test mode order exercises different code and passes when the live path does not.
Then check that the confirmation email arrived and that stock decremented. Those two are the parts that fail silently, and a shop can take orders for days while neither happens.