A WooCommerce store is not a website that happens to sell things. It is a database of orders, a payment integration, a tax engine, a stock ledger and a customer list, all sitting on top of WordPress and all changing independently of each other. That is why WooCommerce maintenance is a different job from keeping a brochure site ticking over, and why the stores that skip it tend to discover the fact on their busiest day of the year.
This guide covers what WooCommerce maintenance actually involves, how often each job needs doing, what it costs, who does it well, and how to run it yourself if you would rather not pay anyone. If you are still choosing a platform, our comparison of WooCommerce and Shopify is the better place to start.
What WooCommerce maintenance actually is
Maintenance is everything that keeps a store selling that is not building the store. It splits into four jobs that have almost nothing to do with each other, which is the first thing that makes it awkward.
Keeping the software current. WordPress core, WooCommerce itself, your theme, your payment gateway and every extension all release on their own schedules. A typical store runs twenty to forty of these. Each update is small; the risk is that any one of them can break checkout, and you will not know until someone tries to pay.
Keeping it secure. A store holds names, addresses, order histories and, depending on your gateway, partial card data. That makes it a target in a way a blog is not. Security work means patching quickly, limiting who can log in, watching for malware and keeping the PCI DSS obligations your payment provider passes on to you.
Keeping it fast. Stores get slower on their own. The orders table grows, the sessions table grows, product images accumulate, and every extension you add does a little more work on every request. Speed work is mostly stopping that drift rather than making anything new.
Keeping it recoverable. Backups nobody has restored are not backups. For a store the bar is higher than for a website, because an order taken at 2pm and a restore from midnight means a customer has paid you for something you have no record of.
Why WooCommerce needs more maintenance than a normal site
Everything below is true of WordPress generally. It is worse on WooCommerce for reasons that are structural rather than anyone’s fault.
It writes to the database constantly
A brochure site is almost entirely reads. A store writes on every add to cart, every session, every order, every stock change and every scheduled task. Caching, which solves most WordPress speed problems, deliberately does not apply to the cart, the checkout or the account pages, because serving a cached cart to the wrong person is worse than serving a slow one. So the parts of your store that matter most are the parts caching cannot help.
It has more moving parts than anything else you run
Payments, shipping rates, tax, subscriptions, stock sync, email, analytics. Each is usually a separate extension from a separate vendor with a separate release cycle, and several of them talk to an external service that can change its API without asking you. The failure mode is rarely a white screen. It is one shipping method quietly disappearing at checkout.
Its failures cost money immediately
A blog that is down for an afternoon loses some traffic. A store that is down for an afternoon loses that afternoon’s revenue, and depending on how the failure looks, some of the trust that would have produced next month’s. This is the real argument for maintenance, and it is worth doing the sum for your own store rather than accepting a generic figure: take last month’s revenue, divide by the hours you actually trade, and you have your number.
It accumulates data that nothing removes
WooCommerce keeps expired sessions, abandoned carts, order notes, action scheduler logs and post revisions indefinitely unless something clears them. On a busy store the wp_options and action scheduler tables can reach hundreds of thousands of rows inside a year, and every uncached page load pays for it.
What a maintenance plan should cover
If you are buying maintenance, this is the list to check a proposal against. If you are doing it yourself, this is the list to work through.
| Job | What it means in practice | Skipped for a year? |
|---|---|---|
| Core and plugin updates | Applied on staging first, checkout tested, then pushed live | Known vulnerabilities sit open. Eventually an update refuses to run because you are too far behind |
| PHP version | Kept on a supported release | You fall off security support and lose real speed |
| Checkout testing | A real test order through every payment method, monthly | The most expensive failure on the list, and the one nobody notices |
| Backups | Daily, off-site, and restored occasionally to prove they work | You find out they were broken at the exact moment you need them |
| Malware scanning | Server-side scanning, not just a plugin asking itself if it is fine | Card skimmers can sit in a checkout for months |
| Database upkeep | Sessions, transients and scheduler logs cleared on a schedule | Admin slows first, then checkout |
| Uptime monitoring | Checked every few minutes, alerting a human | Your customers become the monitoring |
| Speed checks | Core Web Vitals watched over time, not once | Drift goes unnoticed until rankings move |
| Broken link and 404 sweeps | Discontinued products redirected, not left dead | You lose the rankings those product pages earned |
The three that get skipped most often are checkout testing, restore testing and database upkeep, because none of them produce a visible result when they go well. They are also, in that order, the three that cost the most when they go badly.
WooCommerce hosting with staging, daily backups and object caching on every plan
Talk To Sales →How often each job needs doing
Not everything is monthly, and treating it as monthly is how maintenance becomes expensive without becoming better.
Continuously
Uptime monitoring and malware scanning. Both are automated, both should alert a person, and neither costs anything to leave running.
Weekly
Apply security updates. Not every update, only the ones flagged as security fixes. Waiting a month on a known vulnerability in a plugin with a public proof of concept is how stores get compromised.
Monthly
Everything else: feature updates on staging, a real test order through every payment method, a database clean, a look at Core Web Vitals, and a check that last night’s backup actually restores. This is the core of any plan worth paying for.
Quarterly
Review what is installed and remove what is not earning its place. Check your PHP version. Sweep for broken links and orphaned product pages. Re-read your own checkout as a customer would, on a phone, on mobile data.
Annually
Review hosting against what the store has grown into, renew anything that expires, and audit who still has admin access. The last one catches more problems than it sounds like it should: former agencies, ex-staff and contractors who finished a project two years ago.
What WooCommerce maintenance costs
Plans cluster into three bands, and the difference between them is mostly how much human attention you get rather than how many tasks are on the list.
| Band | What you get | Suits |
|---|---|---|
| Automated | Updates applied automatically, backups, uptime monitoring, a dashboard. No human looks at your store unless you ask | Small stores, low order volume, someone technical in-house |
| Managed | The above, plus updates tested on staging before they go live, monthly checkout testing and a person who answers when something breaks | Most stores taking real orders |
| Managed plus development | The above, plus an allowance of development hours each month for changes and fixes | Stores that keep evolving, or businesses with no developer |
We have deliberately not put prices against providers below. Maintenance plans are repriced often, usually upward, and a stale figure in an article is worse than no figure. Every provider is linked so you can check the current number yourself.
One cost that is easy to miss: maintenance and hosting overlap. If your host already runs daily backups, server-level malware scanning, staging and a CDN, you are buying a thinner maintenance plan than the same store on cheap shared hosting would need. That is worth checking before you pay for both. Our own WooCommerce hosting includes all four on every plan.
The best WooCommerce maintenance providers
Ordered by how well they fit a store specifically, rather than a WordPress site generally. Several excellent WordPress maintenance companies are not on this list because WooCommerce is not really their subject.
1. SiteAim
SiteAim is a UK agency whose main business is WordPress and WooCommerce care, rather than an add-on sold alongside something else. The reason it fits stores well is that the work is done by the people who build stores, so an update that breaks a shipping rule gets diagnosed rather than reported. Plans cover the full list above, and development time is included rather than quoted per job, which is the difference between maintenance that fixes things and maintenance that emails you about them.
Best for: stores that want one team to own both the upkeep and the changes.
2. WP Buffs
WP Buffs runs 24/7 support across time zones with a strong white-label offering, which is why a lot of agencies resell it rather than staffing maintenance themselves. Their higher tiers include unlimited small fixes, which is the feature most people actually want from a plan.
Best for: agencies maintaining client stores at volume.
3. GoWP
GoWP is built entirely around agencies rather than store owners, offering white-label maintenance and a dedicated developer model. If you are an agency with ten WooCommerce clients and no appetite to hire, this is the shape that fits.
Best for: agencies wanting a named developer rather than a ticket queue.
4. FixRunner
FixRunner sits at the more affordable end while still putting a human on updates. Support is ticket-based and thorough. WooCommerce-specific work is available but is less central to what they do than it is at the top of this list.
Best for: smaller stores that want managed rather than automated, at a lower price.
5. SiteCare
SiteCare works with larger and more complicated WordPress installations, including stores, and is comfortable with the kind of custom integration work that breaks other people’s update processes. Priced accordingly.
Best for: high-revenue or heavily customised stores.
6. Codeable
Codeable is a marketplace rather than a maintenance plan: you are matched with vetted WordPress and WooCommerce developers and pay for the work you need. There is no monthly retainer and no proactive monitoring, so it solves fixing rather than maintaining.
Best for: stores that already have monitoring covered and only need hands when something breaks.
A pattern worth noticing: the providers that suit stores best are the ones that employ developers, not the ones with the longest task list. Every plan on this page will apply your updates. The difference shows up on the day an update breaks a shipping rule and somebody has to work out why.
Doing it yourself: a monthly routine
None of this needs a developer. It needs an hour, a staging site and the discipline to do it when nothing is wrong.
1. Take a backup, and check it is real
Before anything else. Not just that the job ran, but that the file is the size you expect. A backup that completes in four seconds is not a backup of a store.
2. Copy the site to staging
Every serious host includes staging. If yours does not, that is a finding in itself. Updating a live store because staging is inconvenient is the single most common cause of a broken checkout.
3. Update on staging, in order
WordPress core, then WooCommerce, then payment and shipping extensions, then everything else, then the theme. One group at a time. If something breaks you want to know which group did it, and that is worth the extra ten minutes.
4. Place a test order
On staging, through every payment method you accept, including the ones you think nobody uses. Check the order appears, the stock decrements, and the confirmation emails actually arrive.
5. Push live, then test again
Staging and live differ in ways that matter: live payment keys, live shipping accounts, real DNS. A test order on staging does not prove the live one works. Most gateways offer a test mode on production, and a small real order you refund afterwards proves it beyond doubt.
6. Clean the database
Clear expired transients, old sessions and completed action scheduler entries. Keep post revisions to a sane limit. On a store that has never had this done, it is common to remove hundreds of thousands of rows the first time.
7. Look at speed and errors
Run PageSpeed Insights on a product page rather than the homepage, and read the field data rather than the score. Check your error log for anything repeating. Our non-technical guide to speeding up WordPress covers what the numbers mean and which of them are your host’s responsibility rather than yours.
What actually happens when you skip it
Not hypotheticals. These are the four failures that account for most of the emergency work on neglected stores.
Checkout stops working and nobody notices
An update changes how a gateway or a shipping method behaves, the store keeps loading perfectly, and orders simply stop. The usual discovery route is wondering why it has been quiet. Monthly checkout testing exists entirely to catch this.
A card skimmer gets in
An unpatched plugin lets an attacker inject a few lines of JavaScript into the checkout that copy card details as they are typed. The store works normally. You usually find out from your payment provider or your bank, and by then you have a disclosure obligation as well as a cleanup.
The store gets slower until it stops converting
No single event, just accumulation: more products, more extensions, a database nothing has cleaned. Conversion drifts down over months, which is exactly the shape that gets blamed on the market rather than the site.
The backup was not real
The one that ends businesses. The plugin reported success for months while silently failing on the largest table, which on a store is the orders table. The fix is not a better backup plugin, it is restoring one occasionally.
How to choose between doing it and buying it
The honest test is not technical ability. It is whether the work will actually happen in a month when you are busy, because maintenance skipped for three months is worse than no plan at all: it produces a store everyone believes is being looked after.
Do it yourself if you have a staging site, an hour a month you will genuinely protect, and enough familiarity to tell a plugin conflict from a theme problem.
Buy a plan if the store is your main revenue, you take orders outside your own working hours, or you have ever put off an update because you were afraid of it. That last one is the real signal.
Whichever you choose, check what your host already covers first. A lot of stores pay twice for backups, malware scanning and staging without realising it, and a lot of maintenance plans exist mainly to compensate for hosting that should have included those things. If you are weighing that up, our guide to when it is time to change host covers how to tell which side the problem is on.
The short version
WooCommerce maintenance is four unrelated jobs: keeping software current, keeping the store secure, keeping it fast and keeping it recoverable. Two of them run continuously and cost nothing to leave running. Most of the rest is monthly, takes about an hour, and is only difficult in the sense that it has to happen when nothing is wrong.
Test your checkout every month and restore a backup every quarter. If you do nothing else on this page, those two habits prevent the two failures that actually end stores.
WooCommerce security in practice
Store security is mostly unglamorous. Almost nothing on this list involves an attacker doing anything clever; it involves them finding a door somebody left open eighteen months ago.
Patch speed matters more than any plugin
The overwhelming majority of compromised WordPress stores are running a known vulnerability in a plugin with a patch already available. Not a zero day, not a weak password: a fix that shipped weeks earlier and was never applied. Everything else in a security stack is compensating for that one gap. This is why weekly security updates sit above monthly feature updates in the cadence above.
The checkout is the part worth guarding
Card skimming on WooCommerce works by injecting JavaScript into the checkout page that reads fields as the customer types and posts them somewhere else. It does not break anything, which is the problem. Two things reduce the risk meaningfully: keeping the number of plugins that load on the checkout as small as possible, and having something watching your files for changes so an injection is noticed by a machine rather than by your bank.
Admin access is a maintenance job, not a setup job
Every store accumulates accounts: the developer who built it, the agency before that, a marketing contractor, a plugin support engineer you granted access to for one afternoon. Each is a live route into your orders. Reviewing the user list quarterly, and forcing two-factor authentication on everyone with more than customer-level access, closes more real risk than most paid security tools.
Your PCI obligations do not disappear because you use a gateway
Using Stripe or PayPal moves most of the burden, but not all of it. If card data is entered on a page you control, the security of that page is your responsibility, which is what the PCI DSS requirements cover. Your acquirer will tell you which self-assessment applies to you. The practical version for most stores: keep the checkout patched, keep it on HTTPS, and know what scripts load on it.
Our own approach to this on the hosting side is described on the website security page, and it is worth understanding which parts your host covers before buying a plan that covers them again.
Speed work that only applies to stores
General WordPress speed advice takes you most of the way. These four are the store-specific ones, and they are the reason a WooCommerce site can be slow while scoring well on a page-speed test of its homepage.
The pages that matter are the pages caching skips
Cart, checkout and My Account are excluded from full-page caching for good reason: caching them would serve one customer’s basket to another. That means every one of those requests runs PHP and hits the database, so their speed is set almost entirely by your server and your database rather than by a caching plugin. If your product pages are quick and your checkout is slow, this is usually why, and no caching plugin will fix it.
Object caching does what page caching cannot
An object cache such as Redis stores the results of database queries in memory, so the uncached pages get faster too. On a store of any size this is the single biggest infrastructure difference between quick and sluggish, and it is the thing most cheap hosting does not offer. It is included on our managed WordPress hosting, and worth asking any host about directly.
Cart fragments are a quiet tax on every page
WooCommerce keeps the little cart total in your header accurate using a background request that runs on page load. On a cached site that request is often the only uncached thing happening, so it sets the pace for everything. If your theme does not show a live cart count, this can usually be switched off on non-cart pages, and stores routinely find it is the largest single saving available to them.
Order storage changes how the database behaves
WooCommerce now stores orders in dedicated database tables by default for new stores rather than mixing them into the general posts table, which makes order queries dramatically cheaper as volume grows. Older stores may still be on the legacy arrangement. Checking which you are on, and migrating if you are on the old one, is a genuine maintenance task with a real payoff, and it is worth doing on staging first because it is a data migration rather than a setting.
Images are still the biggest thing on the page
Product photography is the reason store pages are heavy. Serving modern formats, sizing images to the space they actually occupy rather than uploading the original from the camera, and not lazy loading the main product image are the three that matter. The last one catches people out: lazy loading the largest image above the fold delays the very thing Largest Contentful Paint measures.
Signs your store is overdue
Five things that mean maintenance has been skipped for a while, in roughly the order they show up.
- The admin feels slower than the shop. Almost always database bloat, because the admin runs uncached queries the front end has cached away.
- You are afraid to run updates. A rational fear if there is no staging site, and the clearest signal that the workflow rather than the store is the problem.
- You cannot remember the last test order you placed. If nobody has checked the checkout this month, nobody knows it works.
- Your plugin list contains things you cannot identify. Every unknown plugin is code running on your checkout for a reason nobody remembers.
- Orders arrive in bursts with unexplained quiet spells. Sometimes seasonality. Sometimes a payment method that has been failing since the last update.
If more than two of those are true, start with a backup and a test order before you touch anything else. Both are reversible, both take minutes, and between them they tell you whether you have a maintenance problem or an emergency.
If you are setting a store up from scratch rather than rescuing one, our guide to starting a WooCommerce store covers the decisions that make maintenance easier later, and the general WordPress maintenance checklist covers the non-store parts of the job in more depth.
What to ask a provider before you sign
Five questions. The answers separate a plan that maintains your store from a plan that emails you a report.
- Do you test updates on staging before they go live? If the answer is no, you are paying someone to press the same button you would have pressed, with the same risk.
- Do you place a test order after updating? This is the question that finds out whether they understand stores or only websites.
- What happens when an update breaks something? Listen for whether they fix it or report it. That distinction is usually the entire difference in price between two plans.
- Do you restore backups to check them? Almost everyone takes backups. Very few verify them, and an unverified backup is an assumption rather than a safety net.
- Who actually does the work? Some plans are run by developers, some by support staff following a script. Both are legitimate, but you should know which you are buying before something goes wrong.
Ask the same questions of your host, because the answers change what you need to buy. If backups, staging, malware scanning and object caching are already included, a thinner plan will do. If they are not, you are paying a maintenance provider to compensate for hosting, which is a more expensive way to solve the problem than fixing the hosting. We are happy to tell you which side your store sits on: get in touch.
FAQs
Security updates weekly, everything else monthly. The monthly pass is updates on staging, a test order through every payment method, a database clean and a look at your speed numbers. Quarterly, review your plugin list, your PHP version and who still has admin access.
For a brochure site, often yes. For a store, automatic updates mean an extension can change how checkout behaves with nobody watching. If you do turn them on, keep them to security releases and minor versions, and pair them with uptime monitoring and a monthly test order so you find out quickly when something goes wrong.
Partly, and the overlap is worth checking before you pay twice. A good managed host covers backups, malware scanning, staging, uptime and the server side of speed. No host tests your checkout, decides whether an extension update is safe for your particular setup, or removes plugins you stopped using. That is the part a maintenance plan buys.
Plans fall into three bands: automated, managed, and managed with development time included. The difference is how much human attention you get rather than the length of the task list. We have not quoted per-provider prices in this article because they change often; each provider is linked so you can check the current figure.
It is more work, because you own the stack rather than renting it. Shopify handles updates, security and hosting for you and charges for that in the platform fee and transaction costs. WooCommerce gives you control of every layer and hands you the responsibility that comes with it. Neither is wrong; they are different trades.
Placing a test order every month. It is the only check that tests the whole chain at once: the server, WordPress, WooCommerce, your payment gateway, your shipping rules, your stock and your emails. If exactly one thing on this page gets done, make it that.
Restore one. Not to your live site: restore it to a staging environment and open the orders screen. A backup that has never been restored is an assumption. Doing this once a quarter takes about twenty minutes and is the only way to find a silently failing backup before you need it.
Hosting That Carries Half The Maintenance
Staging, daily backups, server-level malware scanning and object caching are included on every FastCow plan, so your maintenance list starts shorter.
View Packages