Hosting a WooCommerce store is a different job from hosting a website. Every host will tell you they support WooCommerce, because technically it’s a plugin and it installs. Whether the store stays fast on the Monday after a sale email goes out is another question entirely.
If you’re comparing WooCommerce hosting in NZ, here’s what actually separates one host from the next, and the questions worth asking before you hand over a card.
Why a shop breaks ordinary hosting
A brochure site on ordinary managed WordPress hosting can be cached almost entirely. The server builds each page once, stores the result, and hands out copies. That’s why a small business website runs happily on cheap hosting.
A store can’t work that way. The cart, the checkout and the account pages are different for every single shopper, so they have to be built fresh on every request. Add a few dozen people browsing at once and the server is doing real work continuously.
That’s the gap. General hosting is sized for handing out copies. A store needs a platform sized for building pages.
1. Caching that understands a cart
Ask what the host’s page cache does with WooCommerce. The answer you don’t want is “we exclude the cart, checkout and account pages”, because that’s the bare minimum and it means the rest of your shop is being handled by a cache that doesn’t know a shop from a blog.
Better answers involve caching built specifically for WooCommerce, where product and category pages stay cached even for a shopper who has items in their cart. That’s where the speed lives, because catalogue browsing is most of your traffic.
2. What they do about cart fragments
This one is worth learning even if you never move hosts.
WooCommerce keeps the little cart counter in your header accurate by firing a background request on nearly every page load. It’s called cart fragments, it goes to admin-ajax.php, and it can’t be cached. So every visitor browsing your catalogue quietly generates a second uncacheable hit for every page they look at.
On a quiet store you’ll never notice. On a busy one it’s the single most common reason a shop goes slow at exactly the wrong moment. Ask the host what they do about it. If they’ve never heard of it, you have your answer.
3. PHP workers, not “unlimited bandwidth”
Bandwidth is a marketing number. The figure that decides whether your store survives a busy hour is how many PHP processes can run at the same time, usually called PHP workers.
Each uncacheable request, so each add to cart, each checkout, each logged-in page view, occupies a worker until it finishes. Run out and the rest queue up. Queueing looks like a slow site, and then a site that times out.
You don’t need to become an expert in it. You do need a host that can tell you the number and what happens when you hit it.
4. An object cache
Every WooCommerce page runs a pile of database queries: prices, stock, variations, tax rates, shipping zones. A persistent object cache such as Redis or Memcached keeps the answers in memory so the database isn’t asked the same question a thousand times an hour.
On a store with a few hundred products and any real traffic, this is one of the largest single speed differences between hosts. Ask whether it’s included or an upgrade, and check that against the plan you’re being quoted.
5. Backups you’d actually trust with orders
Products you can rebuild. Orders and customer records you can’t.
So the questions are: how often, how far back do they go, how long does a restore take, and can you restore just the database without flattening the files. Daily is the floor. Weekly backups on a store that takes 20 orders a day means a bad day can cost you 20 orders.
Test it. Ask them to restore something to a staging copy before you need it in anger.
6. Staging, and knowing how to use it on a live store
A staging site is where plugin updates and theme changes get tested before they go anywhere near customers. On a store it’s not optional, because a broken checkout is invisible until someone complains.
One trap that catches people: never push a staging database back to a live store. Orders placed while you were working on staging live in the production database, and pushing over the top erases them. Push files, never the database, and any host who lets you do it without a warning is one to watch.
7. Order emails that reach the inbox
Receipts, order confirmations, shipping notices, password resets. Sent by default straight from the web server, which is the least trusted way to send email there is, and a good share of them land in spam or vanish.
The fix is a proper transactional email service such as Amazon SES, with SPF and DKIM set up for your domain. Ask whether the host configures that for you or leaves it to you. Most leave it to you and don’t mention it.
8. Support hours that overlap your trading hours
Plenty of hosting sold in New Zealand is answered from the other side of the world. “24/7 support” often means a ticket queue where the person who can actually help starts work as you’re going to bed.
Checkout breaking at 10am on a Thursday is the scenario to plan for. Work out who picks up the phone then, and whether they know WooCommerce or just servers. For an Auckland business, local support in NZ hours is the difference between a fix before lunch and a fix overnight.
9. Server location, honestly
Distance costs milliseconds, so a server in Australia answers an Auckland shopper faster than one in Texas. Worth having. Also frequently oversold.
Once a CDN is in front of the site, your images and cached pages come from an edge location near the visitor anyway. Where the origin server sits matters most for the uncacheable requests, which on a store is the cart and the checkout. So it counts, and it counts less than the caching and worker questions above.
Be careful with claims here. A host advertising a New Zealand data centre should be able to name it. Plenty of “NZ hosting” is a New Zealand company reselling infrastructure in Sydney or Singapore, which is fine, as long as they say so.
10. NZD billing and GST invoices
Small, but it shows up every month. Hosting billed in US dollars moves with the exchange rate, and an invoice without GST on it is an annoyance for your accountant and a bit of tax you don’t get back.
The short version to send a host
Copy these into an email and see how the replies compare:
- How does your page cache handle a WooCommerce store, beyond excluding the cart and checkout?
- What do you do about WooCommerce cart fragments?
- How many PHP workers does my plan get, and what happens when they’re all busy?
- Is Redis or Memcached included?
- How often are backups taken, how far back do they go, and how fast is a restore?
- Is staging included, and can I push files without overwriting orders?
- Do you set up transactional email, or is that on me?
- Where is the server, and who answers support at 10am New Zealand time?
- Do you migrate my store for free, orders included, with no downtime?
A host that answers all 9 clearly is a host that has hosted stores before.
Where PrestoWP sits
We built WooCommerce hosting in NZ around that list. WooCommerce-specific caching and a replacement for the cart fragments script are switched on for every store rather than sold as an eCommerce tier. Daily backups include your orders, staging is included, and we set up Amazon SES so receipts arrive.
The platform underneath is WP Engine’s Sydney region, the closest to New Zealand, with a global CDN in front. PrestoWP itself is NZ-owned and operated, support is Auckland-based and works NZ hours, and you’re billed in NZD with GST invoices.
Worth reading next: managed versus shared hosting for NZ businesses if you’re still on a cheap plan, or the hosting plans if you know what you’re after. Moving an existing store is free and handled by us, products, orders and customers included, and here’s how a migration runs without downtime if you want the detail first.