Searching for WooCommerce hosting returns a wall of ranked lists, almost all of them paid placements. That is not a conspiracy, it is an industry: hosting has generous affiliate commissions, so the content that ranks is written to earn them. This article names no hosts and recommends none. It gives you the criteria a store actually depends on, and the tests you can run yourself before moving anything.
The reason hosting deserves this attention is structural. A store is not a blog. Cart, checkout and account pages cannot be served from a page cache, and logged-in customers bypass it too. So while a brochure site can hide weak hosting behind a cache layer, a store exposes it at exactly the moment money is involved.
Concurrency beats headline speed
What matters is not how fast one page loads for one visitor on a quiet afternoon. It is how the store behaves when forty people are browsing, six are in checkout, a backup is running and a bot is crawling your filter URLs. That capacity is largely decided by how many PHP processes the plan allows and how much memory each may use. Hosts describe this differently — workers, processes, concurrent requests — and cheaper plans often do not describe it at all, which is itself informative.
- Ask how many PHP workers or concurrent processes the plan allows
- Ask what happens when they are exhausted: queue, 503, or throttle
- Ask the PHP memory limit per process
- Ask whether cron and backups share that same capacity
The database is where stores age
WooCommerce writes constantly: sessions, carts, order metadata, transients, action-scheduler entries, logs. Three years in, a store that nobody has maintained often carries tables far larger than its catalog justifies, and every uncacheable query pays for it. Good hosting gives you a database that is not shared with hundreds of neighbours, gives you visibility into slow queries, and does not treat an oversized options table as your problem alone. Ask whether they can show you slow query logs. The answer tells you what kind of support you are buying.
Caching rules you can actually control
Managed hosts usually run their own cache layer, which is good until it is wrong. What you need is the ability to exclude cart, checkout and account pages, to control how logged-in traffic is treated, to purge selectively instead of dumping the whole cache when one product changes, and to understand whether object caching — Redis or Memcached — is available for the queries page caching cannot help. A host that offers no visibility into its cache rules will eventually cache something it should not — and on a store, that means a shopper seeing someone else's cart total.
Staging that is real, not a checkbox
A staging environment is where updates go before customers see them, and it is worthless if it is not comparable to production. A useful one clones the database and files on demand, runs the same PHP version, and lets you push back selectively, with no all-or-nothing overwrite. If a host advertises staging but pushing changes back means copying the entire database over the live one, you do not have staging — you have a demo. This matters most when something has already broken; see website slow after an update for how the two connect.
Backups you have restored at least once
Every host claims backups. The questions are how often, how far back, whether files and database are captured together, whether you can restore a single table or file without taking the whole site back, and how long a full restore takes. The last one is the one nobody asks and everybody eventually needs. Restore a backup to staging once, deliberately, while nothing is wrong. If it fails, you have learned it on a calm Tuesday instead of during a sale.
Support that understands WooCommerce
There is a large difference between hosting support that answers "the server is fine" and support that will look at why checkout takes eleven seconds. You can test this before buying: open a pre-sales ticket describing a specific WooCommerce symptom — cart fragments hammering admin-ajax, say — and see whether the answer engages with it or redirects you to a plugin. The response time and the depth of that one reply predict the experience you will have at the worst possible moment.
What hosting will not fix
This is where honest advice diverges from the affiliate lists. Moving to a better host fixes server response time, concurrency and reliability. It does not remove a megabyte of theme JavaScript, unbundle a page builder's markup, or make a filter widget stop blocking the main thread. If your Time to First Byte is already reasonable and the store still feels slow on a phone, the bottleneck is in the browser, not the server — why WooCommerce is slow separates the two, and moving hosts will not touch the second.
- Fixes: server response, concurrency, uptime, database headroom
- Does not fix: theme weight, builder markup, script bloat, layout shift
- Test TTFB separately from LCP and INP before deciding
- If field data is poor but TTFB is fine, hosting is not your problem
Migrating without losing a day
If you do move, the mechanics matter more than the marketing. Lower DNS TTL a day in advance, copy the site to the new host and test it on a temporary hostname with real checkout attempts, plan a low-traffic window, freeze order-affecting changes during the switch, and keep the old host paid for a month, because cancelling on day one removes the way back. Confirm email sending, cron and payment webhooks on the new environment specifically — those are the three that quietly stay broken after an otherwise successful move.
Hosting decides whether your store survives its busiest hour. It does not decide whether your storefront is fast on a phone. Buy each with its own budget.