WooCommerce Hosting: How to Choose the Right Server for Your Store

What is WooCommerce hosting and how do you choose it?

WooCommerce hosting is a hosting environment you choose specifically to carry the cart, checkout and order load of a WooCommerce store running on WordPress. A good choice weighs current PHP and database versions, enough memory, object caching, frequent backups, a staging site and the ability to scale on sale days.

We are Talha Aslan and team, a digital marketing and web team, not a hosting company. So in this guide we base every technical point on the official WooCommerce and WordPress documentation. Our goal is simple: help store owners read a hosting offer with the right questions in mind.

We covered general criteria such as location, support and control panels in our guide to choosing web hosting. This article focuses only on what is different for WooCommerce. In particular, the order database, cache exclusions and sale day capacity are questions a brochure site never raises.

What are the official WooCommerce server requirements?

WooCommerce lists the infrastructure a store needs on its official server recommendations page. At the time of writing, the page lists the following:

• PHP 8.3 or greater, tested up to PHP 8.4.
• MySQL 8.0 or greater, or MariaDB 10.6 or greater.
• WordPress 6.9 or greater.
• A memory limit of 256 MB or greater.
• HTTPS support.
• Apache or Nginx as the web server, although any server that supports PHP and MySQL works.

In addition, the page lists several optional components. For example, cURL or fsockopen support lets WooCommerce and many integrations talk to outside services. Multibyte String support is required if you run a non-English store. So if your shop sells in German, Turkish or Spanish, treat that component as mandatory in practice.

Also, these versions move up over time. Therefore, do not memorize the numbers. Instead, open the official page while you review a hosting offer and compare the versions the host provides. The page also mentions legacy support for PHP 7.4 and MySQL 5.6. However, it warns that those versions have reached end of life and may expose your site to security vulnerabilities. In other words, "it still runs on the old version" is not a good reason to pick a host.

How do PHP version and memory limit affect a WooCommerce store?

Your PHP version affects both speed and security. Current releases keep receiving security patches, while an end of life release does not. If you use cPanel, you can switch versions yourself. We explain the steps in our guide to changing the PHP version in cPanel.

Memory also has two separate layers. The first is the memory_limit value in the server's php.ini file. The second is the WordPress setting. According to the official WordPress wp-config documentation, WordPress tries to allocate 40 MB by default for a single site and 64 MB for multisite. WooCommerce, on the other hand, recommends 256 MB. As a result, the WordPress default is too low for a store.

; php.ini (example)
memory_limit = 256M

// wp-config.php, before wp-settings.php is included
define( 'WP_MEMORY_LIMIT', '256M' );

On the command line, php -i | grep memory_limit shows the current value. Still, the command line PHP and the web server PHP may read different php.ini files. For that reason, confirm the real value on the WooCommerce > Status screen, in the row that shows the WordPress memory limit.

If your shared hosting plan will not let you raise this value, take it as the first sign that the plan is too small for a store. That said, raising memory without limit is no fix either. If a plugin leaks memory, a higher limit only delays the problem.

Why does an online store need different hosting than a brochure site?

On a company brochure site, most visitors see the same pages. A page cache can therefore carry most of the load. A store, however, works differently. Every visitor who adds a product to the cart, tries a coupon or moves to checkout creates personal requests that no page cache can serve.

Every order also means database writes. Stock goes down, the system adds an order note, and a customer email enters the queue. Additionally, WooCommerce runs scheduled tasks in the background. You can see them on the WooCommerce > Status > Scheduled Actions screen. Payment notifications, stock syncs and marketplace integrations also send regular requests to the server.

In short, a store server does more than deliver pages. At the same moment, it builds personal pages, writes to the database and talks to outside services. For example, a plan that runs a blog comfortably can slow down checkout on a store with similar traffic. That happens because the bottleneck is usually concurrent PHP processes and the database, not bandwidth.

This difference also changes which lines you read in a WooCommerce hosting offer. Look past marketing numbers such as disk space and monthly traffic. Focus instead on CPU cores, memory, concurrent process limits and database access. That way you can judge more accurately whether a plan will really carry a store.

How do database performance and HPOS change the order load?

The database is the heart of a WooCommerce store. Specifically, products, variations, orders, customers and session data all live in it. In the past, WooCommerce kept orders in the general WordPress post tables, posts and postmeta. As a result, that structure grew heavier as order counts rose.

WooCommerce introduced High-Performance Order Storage (HPOS) to address this. According to the WooCommerce developer documentation, HPOS uses dedicated tables and dedicated indexes for orders and order addresses, which results in fewer read and write operations. The same documentation states that HPOS is on by default for new installations from WooCommerce 8.2. Existing stores need to switch it on themselves.

For WooCommerce hosting, this means the database server version, the memory it gets and the disk speed directly affect order speed. So ask your host these questions:

• Does the database run on the same server or on a separate one?
• Does the MySQL or MariaDB version meet the official WooCommerce recommendation?
• Can you access the slow query log?
• Do you share database memory with other accounts?

Before you move an older store to HPOS, always test it on staging first. That is because some older plugins may not work with the new order tables.

Is a Redis object cache necessary for WooCommerce hosting?

An object cache lets WordPress keep frequently read database results in memory. The default WordPress object cache lives only for a single request and disappears once the request ends. A persistent object cache, in contrast, uses a memory server such as Redis or Memcached to keep those results between requests.

Because the page cache switches off on cart and checkout, the object cache becomes even more valuable in a store. Every uncached request still reads site options, product data and settings. Redis then takes part of that reading off the database. As a result, the load drops, especially for logged in customers and admins.

When you compare WooCommerce hosting plans, ask whether Redis comes with the plan. If you run your own VPS, you can check that Redis responds with this command:

redis-cli ping
# Expected reply: PONG

We explain the caching logic and the difference between the two tools in our Redis vs Memcached caching guide. One warning here: if you configure the object cache badly, customers may see stale stock or prices. So after setup, test a stock change and a coupon on staging.

On the other hand, a small catalog with low traffic does not need Redis. However, if you plan to grow, a plan that supports Redis from day one saves you a migration later.

Which WooCommerce pages should you exclude from page caching?

The WooCommerce caching configuration guide says Cart, My Account and Checkout must stay out of the page cache. These pages show customer specific information and change all the time. The same guide asks your caching system to recognize these cookies:

• woocommerce_cart_hash for the cart contents.
• woocommerce_items_in_cart for the item count.
• wp_woocommerce_session_ as the session cookie prefix.
• woocommerce_recently_viewed for recently viewed products.
• store_notice as the prefix of the store notice cookie.

The guide also says that if your caching system offers database caching, you should exclude _wc_session_ from it.

Here is why this matters for hosting. For instance, some hosts run a page cache at server level. If that cache does not know the WooCommerce pages and cookies, a customer may see an empty cart or a wrong item count. Therefore, ask at the offer stage: "Does your server cache apply WooCommerce exclusions automatically?"

If the answer is vague, run a simple test before launch. Add a product to the cart in two different browsers, then reload the cart and checkout pages. Next, log in on one browser and browse as a guest on the other. If the carts stay separate, the basic exclusions work.

Why do SSD, NVMe and disk speed matter for a store?

The disk is where the database and PHP files live. Classic spinning hard drives are slow at random reads and writes. SSDs close most of that gap, and NVMe SSDs usually offer even more throughput than SATA SSDs. In a store, every order, stock update and session write touches the disk.

Still, an "NVMe" label alone is not enough. On a shared server, for example, many accounts use the same disk. So besides the disk type, ask about these limits:

• Is there a per account I/O speed limit?
• Is there a cap on operations per second (IOPS)?
• Do the disks run in a RAID setup for redundancy?
• Do you get a warning when disk usage nears a critical level?

On the other hand, disk speed will not fix slowness caused by a badly written plugin or an unindexed query. In other words, measure the bottleneck first, then decide on a hardware upgrade. For example, if the order list in the admin feels slow, the cause may be a query rather than the disk. The slow query log will tell you.

Also keep an eye on disk space. Product images, generated thumbnails and backup files grow over time. When the disk fills up, the database cannot write and the order flow stops. So choose your space limit with your growth plan in mind.

What do a CDN and SSL add to a WooCommerce store?

A CDN serves images, CSS and JavaScript files from servers close to the visitor. That way your main server does not spend effort on static files and can focus on PHP and the database. In a catalog with heavy product images, the difference becomes clear.

However, if you turn on the CDN's page caching feature, the WooCommerce exclusions above must also apply in the CDN rules. Otherwise, the server may behave correctly while the CDN shows an old copy of the cart page. You can check that your domain points to the CDN with our DNS lookup tool.

SSL, meanwhile, is a requirement rather than an option. The official WooCommerce requirements ask for HTTPS support. Browsers also flag form fields on unencrypted connections as not secure. Ask whether the plan includes a free certificate that renews automatically. Then, after setup, verify the certificate chain and expiry date with our SSL checker.

If you want to know how speed connects to revenue, our article on whether ecommerce page speed affects sales covers it from a conversion angle. Put simply, a CDN carries speed and SSL carries trust; plan both together.

What does hosting cover for the checkout page and PCI DSS?

PCI DSS is the payment card industry security standard for businesses that process, store or transmit card data. The PCI Security Standards Council publishes it. Your compliance burden depends on whether card data ever touches your own server.

Most WooCommerce stores collect card details on a payment page that the payment provider hosts, or in a secure field the provider supplies. In that setup, the card number never reaches the store server. Consequently, the hosting scope shrinks. It does not drop to zero, though, because the integrity of the store pages that lead to payment still matters.

We only draw a general frame here; your payment provider and the PCI SSC documents define the exact scope. In practice, run these checks:

• Do not store card data in your own database.
• Use the integration method your payment provider recommends.
• Protect the admin area with strong passwords and two factor authentication.
• Watch for unauthorized code changes in templates that lead to checkout.

We discuss gateway selection separately in our guide on how to choose a payment gateway. When you pick a host, also confirm with them the TLS version your provider requires and the conditions for accepting payment notifications.

How often should you back up the order database?

A daily backup is usually enough for a brochure site, because content rarely changes. A store, by contrast, creates new orders, customer accounts and stock movements all day. One nightly backup puts half a day of orders at risk if something breaks the next afternoon. So set backup frequency by your order rate.

A practical approach is to plan files and the database separately. Files such as the theme, plugins and images change less often, while the database changes constantly. For example, a busy store might back up the database several times a day and the files once a day. That is an example plan only; the right frequency depends on how many hours of orders you can afford to lose.

# Example: consistent dump without locking InnoDB tables
mysqldump --single-transaction --quick shop_db > shop_db.sql

# If you use WP-CLI, this does the same job
wp db export shop_db.sql

Never leave the backup on the same server; if the server fails, the backup goes with it. Also, test a restore at regular intervals, because a backup you never restored is only an assumption. We cover the logic and retention periods in our website backup strategy guide.

In the hosting offer, clarify three points: whether backups sit in another data center, how many days back they go, and whether you can restore a single table or file.

How do you prepare for a traffic spike on a sale day?

A sale day is when a store earns the most and takes the most risk. Ad, email and social traffic land in the same hours. The problem rarely shows up on the home page. It usually appears at checkout, because the cache is off there and every request goes to PHP and the database.

There are two ways to scale. With vertical scaling, you add more CPU and memory to the same server. With horizontal scaling, you spread the load across several servers. For a session heavy and database heavy application like WooCommerce, horizontal scaling needs shared file storage, a separate database and shared session handling. That is why vertical scaling is usually the more practical start for small and mid sized stores.

On shared hosting, resource limits are fixed and usually stay the same on sale days. On a VPS or cloud server, you can raise resources temporarily. We compare the options in our VPS vs cloud server vs VDS guide. Some plans need a reboot to upgrade, so find that out before the campaign.

The WordPress scheduler also needs attention. By default, WP-Cron runs on visitor requests. The WordPress documentation lets you switch that off with the DISABLE_WP_CRON constant. If you do, you must run tasks with a server cron job instead:

// wp-config.php
define( 'DISABLE_WP_CRON', true );

# crontab example: run due events every 5 minutes
*/5 * * * * cd /var/www/example.com && wp cron event run --due-now

Sale day capacity plan: a step by step checklist

Do not leave campaign preparation to the last day; even good WooCommerce hosting cannot rescue an unplanned sale on its own. Store owners without a technical team can follow this order:

1. Pull hourly visit and order data from your last campaign in your analytics tool.
2. Estimate the expected increase from your ad budget and email list size.
3. Run a load test on the staging copy; never stress the live store for a test.
4. If needed, raise server resources a few days before the campaign.
5. Freeze plugin and theme updates during campaign week.
6. Keep your payment provider's status page and support channel at hand.
7. Take a full backup on the morning of the sale and note the restore path.
8. Watch server resource graphs and error logs throughout the campaign.

Example calculation: if a store normally takes 20 orders per hour and expects five times that during a sale, the load test should simulate at least 100 orders per hour. In practice we also like to add a safety margin, because forecasts can fall short.

In the load test, include adding to cart and checkout, not just the home page. Also, watch CPU, memory and database connections on the server during the test. That way you see which layer becomes the bottleneck before the campaign starts.

Why is a staging site essential for WooCommerce hosting?

Staging is a private copy of your live store that only you can reach. A WooCommerce hosting plan with one click staging saves a lot of time. A checkout step broken by an update means lost orders, straight away.

WordPress offers the WP_ENVIRONMENT_TYPE constant to declare the environment. According to the WordPress wp-config documentation, the allowed values are local, development, staging and production:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

Keep these points in mind when you use staging:

• Put payment methods in test mode; never test with a real card.
• Stop emails from going out to customers.
• Password protect the staging address and block search engine indexing.
• When you push staging to live, do not overwrite the live database.

The last point matters most. If you copy the database while you move a design change from staging to live, you wipe out the real orders that came in during testing. Therefore, move only the files, or repeat the settings change by hand on the live store.

Security: updates, WAF and admin access

A store holds personal data such as customer names, addresses and order history. Security is therefore a core part of the hosting decision. On the hosting side, look for these basic layers:

• Web application firewall (WAF): it stops known attack patterns before they reach the application.
• Account isolation: on a shared server, a neighbor's problem does not spill over to you.
• Brute force protection: it limits repeated login attempts.
• Malware scanning: it reports changed and suspicious files.
• Regular operating system and PHP patches.

We explain how a WAF works and what to do about false positives in our ModSecurity guide. On the application side, keep WordPress core, WooCommerce, your theme and your plugins up to date. Then again, test updates on staging first.

The DISALLOW_FILE_EDIT constant from the WordPress documentation turns off the theme and plugin editor in the admin area:

define( 'DISALLOW_FILE_EDIT', true );

That way, even if someone takes over an admin account, they cannot edit code straight from the dashboard. Also limit admin accounts to people who really need them, and close accounts of staff who leave right away.

Shared hosting or VPS: a WooCommerce decision table

The right plan depends on your store's load today and on your plans for the near future. The table below is a general comparison based on our field experience; it is not a hard rule.

The takeaway: if you have no technical team, an unmanaged VPS may be the riskiest option for your store, even if it looks strong on paper. You would have to handle updates, security and backups yourself.

When should you leave the work to your hosting provider?

Let us be honest: not every store owner needs to run a server. Often it is better not to. Operating system patches, database tuning, DDoS protection and backup infrastructure all take expertise. Doing these jobs halfway can be more dangerous than not doing them at all.

We suggest you leave the work to a managed hosting provider in these cases:

• Nobody on your team knows Linux server administration.
• Nobody can respond to a server failure in the middle of the night.
• You cannot follow security patches on a regular basis.
• You cannot set up offsite backups on your own.

Some jobs, however, always stay with you. Choosing plugins, testing updates on staging, checking the checkout flow regularly and protecting store admin accounts are not the host's job. In short, give the server to the host and keep the store for yourself.

A hybrid path is also possible in borderline cases. For example, you can buy a managed VPS service and handle only the application side. That way you share the infrastructure risk without giving up flexibility.

Questions to ask before you sign a hosting offer

Offer pages usually open with shiny numbers such as disk space and "unlimited traffic". For a store, though, the important questions are different. Ask the host these in writing:

1. Do the PHP and database versions meet the official WooCommerce recommendation?
2. Can you raise the PHP memory limit to 256 MB or more?
3. What are the limits for concurrent processes and entry processes?
4. Do you support Redis or another persistent object cache?
5. Does the server cache recognize WooCommerce cart and checkout exclusions?
6. How often, where and how many days back do you keep backups?
7. Is there a staging site, and how does pushing to live work?
8. Can you add resources for a sale day, and does that need downtime?
9. Are a WAF and malware scanning part of the plan?

Put the answers in one table and compare WooCommerce hosting providers side by side. A host that gives vague answers is a host you do not know well enough to trust with your checkout. To check your site's overall technical state, you can also use our SEO checker.

Conclusion: how do you make the right WooCommerce hosting decision?

The right WooCommerce hosting decision is not about the cheapest or the most powerful plan. It is about the plan that fits your current order rate, your campaign calendar and your technical team. First, shortlist the hosts that meet the official requirements. Then narrow the list with questions on caching, backups, staging and scaling.

If you are opening a new store, start with HTTPS, current PHP and regular database backups from day one. For a growing store, Redis, staging and sale day scaling move to the top of the list. If you have no technical team, a managed solution may be safer than any VPS that looks strong on paper.

Our ecommerce consulting service looks at the hosting decision alongside your marketing goals, together with your store's infrastructure, speed and conversion flow. If you are building a new store, our web design team helps you get the infrastructure choices right from the start.