A blog hands the same page to everybody. A shop builds a different page for every visitor, because everyone has a different basket, a different postcode and a different set of discounts. That single difference is where most WooCommerce hosting problems begin.
Which is also why shop trouble rarely looks like server trouble. The site is up, the product pages are quick, and what you are actually dealing with is a basket that empties itself, an order confirmation that never arrived, or a checkout that stopped taking cards after an update. They are all WooCommerce hosting requirements in disguise, and not one of them shows up in a plan comparison.
Caching, and the pages it must never touch
Page caching is the single biggest speed win on any WordPress site. The server builds a page once, saves the finished HTML, and hands that copy to the next thousand visitors without WordPress or the database being involved at all.
Do that to a checkout and you have a problem. The basket, the checkout, the account pages and the order-received page are personal to one visitor, so they have to be left out of the cache entirely. So does any visitor who is logged in, and any visitor who has something in their basket at all.
WooCommerce leaves markers for the server to read. Cookies like woocommerce_items_in_cart and the session cookie tell a properly configured cache to stop serving a saved copy and let PHP build the page fresh. A generic cache switched on across the whole site, with no shop in mind, ignores all that, and the symptoms are the ones every shop owner dreads.
- A customer adds something, refreshes, and the basket appears empty.
- Two people see the same basket, which is the version that gets you an email nobody wants to read.
- Discounts or shipping totals show the wrong figure because the page was built for somebody else.
- The basket total in the header never updates, no matter what anyone adds.
That last one is usually cart fragments: a background request WooCommerce makes to keep the basket counter current. It cannot be served out of the page cache, and on a slow server it becomes the thing holding your product pages back.
The other kind of caching matters more to a shop than to a blog. Object caching, usually Redis, remembers the results of database queries in memory. Since the uncacheable pages are the ones doing all the querying, this is where a busy checkout gets its speed back. Everything that slows an ordinary WordPress site down still applies on top of all this, shop or no shop.
Your database stops being an archive
A blog’s database is read from constantly and written to a few times a week. A shop writes all day long. Every basket update, every session, every stock decrement, every order and every status change is a write, and writes are the expensive part.
Historically WooCommerce stored orders in the same tables as your blog posts, which is why old shops end up with an enormous posts table full of things that are not posts. Newer versions use dedicated order tables instead, which is a genuine improvement, and moving an established shop over to them is a job worth doing on a copy first.
A few other things grow in the background where you never look. Expired transients pile up. The options table fills with settings that get loaded on every single request whether they are needed or not. Sessions accumulate. None of it is dramatic on its own and all of it adds up, until one day the shop is slow and nobody has changed anything.
Then there is your own team. Searching orders in the admin, running a sales report, exporting for the accountant: those are heavy queries competing with customers for the same database. On a shared server with a hard cap on database connections, the busiest day of your year is exactly when someone in the office runs a report.
Practically, that means memory given to MySQL and a growth plan that is not “the plan says unlimited”. Shops rarely hit a storage limit first. They hit a database limit.
Backups carry more weight now
Lose a day on a blog and you lose a blog post you can rewrite. Lose a day on a shop and you have lost orders you have already been paid for, addresses you were supposed to ship to, and stock counts that no longer match the shelves.
Which changes how restores work. Rolling the whole shop back to last night is the obvious move and often the wrong one, because it deletes today’s orders along with today’s problem. Files and database usually need restoring separately: put the code back to the version that worked, keep the live data. Anyone who backs up a shop should be able to do those two things independently.
Worth knowing in advance: your payment provider holds its own record of every transaction it processed, which is what lets you piece together an awkward gap if the worst does happen. Much nicer to know that now than to work it out at half past nine on a Monday.
Updates need a rehearsal
On a blog, a bad plugin update breaks a layout and a customer mentions it next week. On a shop it can break the checkout, and the way you find out is that the orders stopped and you assumed it was a quiet afternoon.
So updates go onto a copy of the shop first, and the copy gets used properly rather than glanced at. Add to basket. Apply a coupon. Pick every shipping option. Run a payment through in test mode. Confirm the order confirmation email actually arrived. Ten minutes of that saves the weekend.
Two habits worth having. Update WooCommerce and its extensions as a set, since payment and shipping add-ons are written against particular versions. And after a major WooCommerce upgrade there is often a database update step to run, which on a large shop takes a while and should not be started five minutes before a sale goes live.
None of that is unique to shops, and we have written separately about what happens when WordPress updates get left for a year or two. How we run them here is on our WooCommerce hosting page, built on the same managed WordPress hosting underneath.
Capacity is measured in checkouts, not visits
Hosting plans advertise monthly visits. For a shop the number tells you very little, because cached product pages barely trouble the server while a checkout is real work every single time.
What decides it is how many people are doing something at once. Ten checkouts running together on a December evening ask more of a server than a whole quiet month of browsing, and no plan page will tell you how many of those it can take. Which is why shops are worth sizing individually rather than dropping into whichever plan the visit count points at.
The email nobody thinks about
Order confirmations, dispatch notices and password resets are not marketing. If they land in spam, customers assume the order failed and ring you, or worse, order again.
WordPress will push those messages out through the web server unless somebody sets it up otherwise, and mail providers treat that as suspicious by default. Sending them through an authenticated route instead, with the right records published on your domain, is a short job that saves a lot of grief. More on that side of things on our email hosting page.
WooCommerce hosting FAQs
Can I run a WooCommerce shop on ordinary shared hosting?
You can, and plenty of small shops do until the day they cannot. Trouble usually starts when caching gets applied to the whole site, when the database outgrows what the plan allows, or when a busy week sends checkout traffic straight at PHP. It works right up to the point where it starts costing you orders.
Why does my shop show the wrong basket contents?
That is nearly always page caching being applied where it should not be. Basket, checkout and account pages are different for every visitor, so they have to be excluded from the cache, along with anyone logged in and anyone who has already added something. Get those exclusions right and the rest of the shop can still be cached hard.
How much traffic can a WooCommerce shop handle?
There is no single number worth quoting, because the checkout is the part that counts. Cached product pages cost the server almost nothing, while every basket update, login and payment runs PHP and hits the database. A shop with modest visitor numbers and a busy checkout works a server harder than a blog with far more traffic.
What is the safe way to update a small shop?
Have a way back before you start. An update that breaks the checkout costs the same whether you sell ten products or ten thousand, and you often will not notice until an order fails to arrive. A fresh backup and a tested rollback turn a ruined weekend into something you never even hear about.
Before the next busy week
Pick up the phone on 01623 650 333 and walk us through an ordinary week for your shop. Then the worst one you have had, because that is the week the server has to be built for. An ordinary single WordPress site here costs £1 a day + VAT and a shop gets its own figure, and there is no charge for the move. After that, the plugin update that could take your checkout down is ours to run rather than yours to survive.
Leave a Reply