Running WooCommerce properly: hosting, caching and security
A WooCommerce store needs PHP 8.2 or later, MySQL 8 or MariaDB 10.6, Redis object caching, a CDN, a staging environment and tested backups. Most stores that perform badly are not badly built — they are correctly built on infrastructure that was never specified. Self-hosting means somebody must own updates, and that person needs naming.
WooCommerce gets blamed for problems that belong to its hosting. The plugin is mature, widely audited and runs some very large stores. What it does not do is specify its own infrastructure, and that gap is where most disappointing WooCommerce stores are born.
Why is WooCommerce blamed for hosting problems?
Because the failure looks like a platform failure. The store is slow, the admin is sluggish, checkout hangs under load — and the visible thing is WooCommerce.
Underneath, the pattern is nearly always the same: a store on shared hosting with no object cache, no CDN, an undersized database and PHP configured for a brochure site. The same store on adequate infrastructure performs completely differently, with no code changes at all.
Specify the infrastructure before you blame the software.
What a WooCommerce store actually needs
| Layer | Requirement | Why |
|---|---|---|
| PHP | 8.2 or later, generous memory limit | Performance and supported security patches |
| Database | MySQL 8 or MariaDB 10.6+ | Query performance, proper indexing |
| Object cache | Redis or Memcached | The single biggest win — see below |
| Page cache | With correct exclusions | Never cache cart, checkout or account pages |
| CDN | In front of static assets | Latency for geographically spread customers |
| Staging | A real environment, not a copy on the same server | Testing updates before they touch production |
| Backups | Automated, offsite, and restore-tested | The only backup that counts is one you have restored |
| TLS | With HSTS | Baseline, and required for payment processing |
Object caching is the largest single win
WordPress makes a large number of repeated database queries per request. Without an object cache, every one hits the database every time. With Redis, the repeated results are held in memory.
On the stores we have taken over, enabling Redis has routinely done more for admin and cart response times than any amount of frontend work. It is a hosting configuration, not a code change, and most hosts do not enable it by default.
If you take one thing from this article: find out whether your store has a persistent object cache. Many owners discover it does not.
High-Performance Order Storage
Historically, WooCommerce stored orders in the WordPress posts table alongside pages and blog posts. That works until order volume grows, at which point order queries and content queries compete for the same indexes.
High-Performance Order Storage moves orders into purpose-built tables. If your store predates it and still uses legacy storage, migrating is a configuration change rather than a rebuild, and the effect on admin performance at volume is substantial.
The plugin problem
Every plugin is code somebody else maintains, running inside your store, with full database access.
The failure we see most often is not a hacked site. It is a store with forty plugins where three do broadly the same job, two have been abandoned by their authors, and nobody can say which one owns the checkout behaviour that is misbehaving.
Our working rules:
- Before installing a plugin, ask whether fifty lines of custom code would do it. Fifty lines we wrote can be read, tested and removed. A plugin cannot always be.
- Delete rather than deactivate. Deactivated plugin code still sits on disk and can still be exploited.
- Check the last update date and the support forum before installing. An abandoned plugin is a scheduled security incident.
- Custom business logic belongs in a versioned plugin, not in the theme’s
functions.php, so it survives a theme change and can be code-reviewed and rolled back.
A maintenance routine that works
Self-hosting means somebody owns this. Not “the team” — a named person.
Weekly: check for security releases and apply them after a staging test. Review error logs. Confirm backups ran.
Monthly: apply routine core, plugin and theme updates on staging, test checkout end to end, then deploy. Review the plugin list and remove anything unused.
Quarterly: restore a backup to staging and confirm it actually works. Review database size and clean up expired transients and old revisions. Audit admin user accounts and remove people who have left.
Annually: review PHP and database versions against current supported releases. Re-check that every active plugin is still maintained.
That routine is unglamorous and it is the entire difference between a WooCommerce store that runs for five years and one that becomes a liability in eighteen months.
Security, concretely
- Enforce strong authentication on every admin account, with two-factor where possible
- Limit login attempts and change the default login URL
- Never run an administrator account for day-to-day content editing
- Keep file permissions tight and disable file editing from the WordPress admin
- Put a web application firewall in front of the site
- Keep offsite backups, because a backup on the compromised server is not a backup
None of this is exotic. All of it is skipped regularly.
What you get in exchange
It is worth restating what this work buys, because the maintenance burden is real and the benefit should be too.
You hold the database. There is no per-transaction platform fee. No vendor can change your checkout underneath you, deprecate a feature you depend on, or restrict an export. You can move hosts, modify anything, and integrate with systems no platform has anticipated.
For a business with technical capacity or a maintenance retainer, that is an excellent trade. For a business with neither, it is a bad one — and we will say so rather than sell you a store nobody will look after.
Getting the database in order
Databases on long-running WooCommerce stores accumulate weight nobody is watching. A periodic clean-up is safe, quick and frequently produces a noticeable improvement.
Expired transients. Temporary cached values meant to expire that often do not clean up properly. On older stores these can number in the tens of thousands.
Post revisions. WordPress stores every save of every page and product as a revision, indefinitely by default. Useful for a week, dead weight after a year. Limiting how many are retained is a one-line configuration change.
Orphaned metadata. When a plugin is removed, its data usually stays. Over years of installing and removing plugins, a store accumulates metadata belonging to code that no longer exists.
Autoloaded options. The one that matters most, because these load on every single request. Plugins add them freely and rarely clean up. Checking the total size of autoloaded data takes a minute and is frequently revealing.
Order and session tables. Abandoned sessions and expired carts accumulate. WooCommerce has scheduled clean-up for some of this; confirm it is actually running rather than assuming it.
Do this on staging first, with a tested backup, and measure before and after so you know whether it helped.
Who owns this, in practice
Everything above needs an owner. Not a team, not whoever notices — a named person with the access and the time.
The three arrangements that work:
In-house. Someone technical whose responsibilities explicitly include the store, with time allocated rather than assumed. Works well when the person exists and stays.
A maintenance retainer. An external party with a defined scope, a schedule, and accountability. Works well when the scope is written down rather than implied.
A hybrid. Someone internal owns content and monitoring; an external party owns updates, security and infrastructure. This is the arrangement we see succeed most often, because it puts each responsibility with whoever is best placed to hold it.
The arrangement that does not work is the implicit one, where everybody assumes somebody else is watching. That is how a store goes fourteen months without an update.
Choosing a host: the questions to ask
Hosting salespeople answer the question you asked, not the one you meant. These are phrased to get useful answers.
“Is a persistent object cache available, and is it enabled by default?” Not “do you have caching” — that gets you a yes about page caching. Redis or Memcached, specifically, and whether you have to request it.
“What PHP versions do you support, and what memory limit?” You want 8.2 or later and generous memory. A 128MB limit will cause problems on a real store.
“Is there a staging environment, and how do I push changes between staging and production?” A staging site you cannot easily sync from production is barely a staging site.
“How are backups taken, where are they stored, and how do I restore one?” Offsite matters. A backup on the same server does not survive the failure mode you are protecting against.
“What happens during a traffic spike?” Specifically: do you throttle, queue, or fall over? Worth knowing before your busiest trading day.
“Is WooCommerce specifically supported?” Generic WordPress hosting often page-caches aggressively without excluding cart and checkout, which breaks stores in ways that look random.
What a staging environment actually needs to be
“We have staging” covers a wide range of quality.
A staging environment worth having is a full copy of production — same PHP version, same database engine, same plugin set, same theme, with representative data volume. Testing an update against three sample products tells you very little about how it behaves against forty thousand.
It must be isolated, so nothing done there can send an email to a real customer or charge a real card. Payment gateways in test mode, email interception enabled.
It must be refreshable, so you can pull production down to staging on demand rather than working against a copy that diverged six months ago.
And it must actually be used. A staging environment that exists but is bypassed under time pressure provides no protection.
Reading the signs your store is decaying
Self-hosted stores rarely fail suddenly. They degrade, and the signals appear well before anything breaks.
- Nobody can say when updates were last applied. The single clearest indicator.
- The plugin list contains things nobody recognises.
- Admin has become noticeably slower over months, which usually means database growth nobody is managing.
- PHP or database versions are approaching or past end of life.
- Backups run but have never been restored. Untested backups fail at exactly the wrong moment.
- Changes are made directly on production, because staging is broken or absent.
- The person who built it has moved on and nothing was documented.
Any two of those together mean the store needs attention before it needs rescuing. Attention is considerably cheaper.
One thing to do this week
If this article is more than you have capacity to act on, do this single check.
Log into your site health information, or ask your host, and find out whether a persistent object cache is active. Not page caching — object caching, meaning Redis or Memcached.
If the answer is no, that is very likely your largest available performance improvement, it costs a hosting configuration change rather than development work, and it will improve the admin experience for whoever runs the store every day.
Everything else in this article can wait behind that one answer.
What good looks like
A well-run WooCommerce store, summarised:
- Object caching enabled and verified
- PHP and database on current supported versions
- Fewer than fifteen active plugins, every one of them identifiable
- Orders on High-Performance Order Storage
- Staging environment that mirrors production and is actually used
- Backups running offsite, restored at least once in the past quarter
- Updates applied on a schedule with a named owner
- Page caching with correct cart and checkout exclusions
- Custom logic in a versioned plugin, not the theme
- Someone who can answer “when was this last updated?” without checking
None of that is exotic. All of it is the difference between WooCommerce being an excellent choice and an expensive regret.
