A brochure site and a store run on the same WordPress, and they are not the same maintenance job. A brochure site that breaks for an afternoon loses an afternoon of visitors. A store that breaks for an afternoon loses orders, and often nobody notices until a customer emails to ask why they were charged and never heard back.
The verdict first, so you can stop reading if it is all you need: WooCommerce maintenance is ordinary WordPress maintenance plus four jobs that only exist because money moves through the site. Updates have an extra step. Testing means the checkout, not the homepage. Backups have to account for orders that never stop arriving. And a queue of background jobs needs somebody to look at it. Whoever maintains your store, you, a freelancer or a provider, should be doing all four on purpose.
Why a store is a different job
On a brochure site, almost nothing changes between updates except the content you add. On a store, the database changes every time somebody buys something, signs up, abandons a cart or renews a subscription. That one difference reaches into every maintenance task.
It changes what a backup is worth, because yesterday’s backup is missing today’s orders. It changes what a test is, because the page that matters is the one that takes payment. It changes when you can safely make changes, because there is no hour of the day when nothing is happening. And it changes what “the site is up” means, because a store can load perfectly and still be unable to sell.
Updates have an extra step
WooCommerce keeps your store’s data in two places: the files (WordPress, WooCommerce, your theme, your extensions) and the database (products, customers, orders). WooCommerce’s own guidance is to take a current backup and test the update on a staging copy before you update the live store. Most brochure-site maintenance skips the staging step. A store should not.
Two things make a WooCommerce update different from a plugin update on a brochure site.
The database step. A major WooCommerce update can ship changes to how data is stored, and the dashboard then asks you to run a database update. It runs in the background as a set of scheduled jobs. Until it finishes, the store is in between two versions of itself. Somebody should start it deliberately, watch it finish, and check an order afterwards.
Your theme’s copies of WooCommerce templates. Many themes override WooCommerce’s own templates for the cart, checkout and emails. When WooCommerce updates those templates and your theme’s copies do not, the store keeps using the old ones. WooCommerce flags them as outdated on its System Status screen. An outdated checkout template is the kind of problem that looks fine until a specific payment method or a specific field stops working.
Then there are the extensions: payment gateways, shipping, subscriptions, tax. Each has its own release schedule, and each touches the part of the site that handles money. An update that would be routine on a brochure site deserves a test order on a store.
Testing means checkout, not the homepage
The most common store maintenance mistake is testing the wrong page. The homepage loads, the product pages load, and the update gets marked done. Nobody added something to a cart and paid.
A store is tested by buying from it. After any update that touches WooCommerce, the theme or a payment extension, place a real test order on the live store, in a payment mode your gateway supports for testing, and follow it all the way through:
- The product adds to the cart and the cart total is right.
- Checkout accepts the payment and lands on the thank-you page.
- The order appears in the dashboard with the right status.
- The customer’s confirmation email arrives, in the inbox rather than spam.
- The store’s own new-order notification arrives too.
That last pair is the one people miss. Order emails are part of the store. A customer who pays and gets no confirmation does not think “email problem.” They think the store took their money, and they say so in a review or a chargeback.
The same logic applies to monitoring. An uptime check on your homepage tells you the homepage loads. That is worth knowing, and it is not the same as knowing the store can sell. If revenue matters, somebody should be checking the checkout path itself on a schedule, not only after updates.
Backups when the data never stops changing
On a brochure site, restoring last night’s backup costs you whatever you edited today. On a store, restoring last night’s backup deletes every order placed since. The customers still paid. The store no longer knows they did.
That has three practical consequences.
- Back up more often than you would a brochure site, so the gap a restore creates is small.
- Know what a restore costs before you need one. “Restore the site” is a different decision on a store. Sometimes the right fix is targeted repair, because a full rollback would erase real orders.
- Be careful with staging in both directions. A staging copy is a snapshot. Testing an update on it is exactly right. Pushing the staging database back over the live store is not, because it overwrites every order taken while you were testing.
The background queue nobody watches
WooCommerce runs a lot of its work in the background: the database updates above, subscription renewals, scheduled emails, and jobs that extensions add. WooCommerce lists them under Tools, Scheduled Actions, with their status, including any that are past due or failed.
When that queue backs up, nothing on the storefront changes. The site loads. Customers can buy. But renewals may not run on time, emails may not go out, and a data update may sit half finished. Nobody sees it unless somebody looks.
This is the clearest example of the whole difference. The store looks healthy from the outside while a job that touches money has quietly stopped. Looking at that screen should be on somebody’s list, with a name next to it.
Newer stores store orders differently
Since WooCommerce 8.2, new stores keep orders in dedicated order tables (WooCommerce calls this High-Performance Order Storage) rather than in the general WordPress posts table. Older stores may still be on the old storage, or partway through moving. It matters for maintenance because it changes what a “simple” fix touches: an extension, a custom snippet or a reporting tool written for the old storage can behave differently on the new one. If you do not know which your store uses, that is a good first question for whoever maintains it.
What to hand off, and what to keep
Most store owners should not be running database updates or reading a background job queue. Those are good jobs to hand off. Hand off the updates, the staging tests, the test orders, the backups and the restore decision, the monitoring, and the background queue, to one named person or team, so there is never a gap between who updated something and who checks the checkout afterwards.
If you would rather that be somebody whose job it is, every Sunny HQ plan supports WooCommerce, and you can see exactly what each one includes on our plans page. It has no asterisks. When you need us, our October measurement is 22 minutes to a person, and half our tickets are faster than that. That is time to a human reply, not time to a fix.
Keep, always, whoever maintains the store: ownership of the payment gateway account, the domain and the hosting account; the decision on when changes happen around your sales calendar; and the products, prices and policies. A provider should be able to do the work without ever holding the keys you would need to leave them. We made the same case for every site, not only stores, in what to hand off and what to keep.
Questions to ask whoever maintains your store
- Do you test an order through to the confirmation email after updates, or check that pages load?
- Who runs WooCommerce database updates, and who checks an order afterwards?
- Does the store have theme templates WooCommerce marks as outdated right now?
- How often are backups taken, and what does a restore cost us in orders?
- Who looks at Scheduled Actions, and how often?
- Does anything watch the checkout, or only the homepage?
A good answer to each is a name and a habit. A vague answer to the first one tells you most of what you need to know. For a wider view of what a maintenance provider should include, our guide to WordPress maintenance services covers the brochure-site basics this post builds on.
The Bottom Line
WooCommerce maintenance is WordPress maintenance with money in it. The extra work is not exotic: a staging test, a test order through to the email, backups that respect live orders, and a look at the background queue. What makes it fail is not difficulty. It is a homepage that loads, standing in for a store that sells.
Frequently Asked Questions
What does WooCommerce maintenance include that regular WordPress maintenance does not?
Four things: running WooCommerce’s database updates deliberately and checking an order afterwards, testing the checkout with a real test order rather than checking that pages load, a backup approach that accounts for orders placed since the last backup, and watching the Scheduled Actions queue for past-due or failed jobs.
How often should a WooCommerce store be backed up?
More often than a brochure site, because every restore deletes the orders placed since that backup. The right frequency depends on how many orders you take, but the question to settle in advance is what a restore would cost you in orders, and who decides whether to restore or repair.
Is it safe to update WooCommerce on a live store?
WooCommerce’s own guidance is to take a current backup and test the update on a staging copy first. After updating the live store, run any database update it asks for, check for outdated theme templates on the System Status screen, and place a test order through to the confirmation email.
Why did my WooCommerce store stop sending order emails?
Common causes are a theme template that overrides WooCommerce’s email templates and fell out of date, an email delivery problem on the server, or a stuck background job. Check System Status for outdated templates and Tools, Scheduled Actions for failed or past-due jobs, then send a test order and see where the email stops.
