WordPress Hosting Checklist: What Your Server Must Actually Provide

WordPress still powers a large share of the public web — around 40 % according to HTTP Archive's Web Almanac 2025 CMS chapter — but the hosting it actually needs in 2026 looks very different from 2016. The recommended server environment has moved on, automatic database tuning is now standard, modern sites cache at three different layers, and self-service backup-and-restore is a buying decision, not a "nice to have". This guide is a practical checklist you can run against any hosting plan that calls itself "WordPress hosting", grounded in the WordPress hosting handbook, the official WordPress requirements and what the high-traffic CMS install base actually does.

Recommended server environment in 2026

The official WordPress requirements are a floor, not a ceiling. The current recommended environment for 2026 production sites is:

1. PHP 8.3 or 8.4. PHP 8.2 is the absolute minimum in 2026 — by the time the next WordPress major lands it will be approaching end of life. See PHP supported versions.
2. MySQL 8.0+ or MariaDB 10.6+. Older MariaDB releases still work but lose meaningful query-optimiser improvements.
3. HTTPS by default, with HTTP/2 (and ideally HTTP/3 for static assets) at the edge.
4. Modern web server. Apache 2.4 or nginx — what matters is the configuration, not the name on the binary.
5. At least 256 MB PHP memory limit for ordinary blogs; 512 MB for any commercial site; up to 1 GB for WooCommerce stores with many plugins.
6. A real SSL certificate with automatic renewal — Let's Encrypt is fine, and with 45-day certificate lifetimes automation is no longer optional.

The two questions to ask any prospective host: which PHP versions can I select per site, and what is the default for new installs? If the answer is "PHP 7.4" or "we will update it when you ask", that is a hosting environment that has stopped investing in the stack.

Database: more than just "MySQL is included"

The database is where most WordPress slowdowns hide. The hosting plan should give you:

1. InnoDB tables by default with sane character set (utf8mb4).
2. Adequate max_allowed_packet (typically 64 MB+) — WooCommerce exports and large transient updates blow past the default.
3. A working wp_options autoload size, monitored by the host or visible to you. Bloated autoload is the most common silent killer of WordPress TTFB.
4. Database backups separate from file backups, with the ability to restore the database alone.
5. No shared databases between accounts. Each WordPress site should have its own database user with privileges limited to its own database.

If the host uses MariaDB instead of MySQL, that is fine — both have feature-compatible WordPress support. What is not fine is a host that hides which version they run.

Three cache layers: page, OPcache, object

A WordPress site without caching can comfortably do 10–20 requests per second on shared hosting. With caching set up correctly, the same host can handle 200–500 requests per second. The performance gap is roughly an order of magnitude — and it is mostly the host's job to provide the foundation.

The three layers, in order of impact:

1. Page cache. Full HTML responses cached either by the host's reverse proxy (Nginx FastCGI, Varnish) or by a plugin. For anonymous traffic this is the single biggest performance win.
2. OPcache. PHP bytecode cache — turns hot WordPress code paths from "interpret on every request" into "execute compiled". Should be on by default on any 2026 host; if not, that is a red flag.
3. Object cache. Redis or Memcached, holding the result of wp_cache_get calls so that complex queries are not re-run for every visitor. Critical for ecommerce and membership sites; nice-to-have for blogs.

Read WordPress's own hosting handbook for the canonical recommendations. Then ask the host:

1. Is page cache included, or do I run a plugin?
2. Is OPcache enabled and sized appropriately (~128–256 MB)?
3. Is Redis or Memcached available, and is there a recommended object-cache plugin?

If a host claims "managed WordPress" but does not provide page cache and OPcache out of the box, that label is doing more work than the underlying product.

Backups, staging, automatic updates

These three are bundled together because they are the difference between "WordPress hosting" and "you have WordPress installed on a server".

1. Backups. Daily is the floor, ideally with 14–30 days of retention. Self-service restore is more important than backup frequency — a backup you can only restore by opening a support ticket is a slow path on a bad day. Off-site copy (not on the same disk as the live site) is non-negotiable for commercial sites.
2. Staging. The ability to clone the live site to a staging.example.com URL with one click, push changes back, and not double your monthly bill. For commercial WordPress sites with plugin updates, staging is the difference between "we tested it" and "we hope".
3. Automatic updates. WordPress core auto-updates minor versions by default since 3.7. The host's role in 2026 is plugin and theme auto-updates with rollback capability — if a plugin update breaks the site, the host should be able to roll back to the previous known-good version without manual database surgery.

A specific test: ask the host how I, as a user, would restore the site to the state it was in this time yesterday. If the answer is more than three clicks, the backup story is weaker than the marketing claims.

WooCommerce-specific requirements

WooCommerce is not "WordPress with a plugin" — it is a substantially different workload, and most generic WordPress hosting plans struggle with it under real load.

What WooCommerce changes:

1. Cart and checkout are dynamic. Page cache helps the catalogue, but the cart, the checkout and the My Account area are per-user and skip every cache layer. Performance is back to "raw PHP + database".
2. PHP workers matter. A shared plan with 2 PHP workers and 200 simultaneous checkouts will queue requests and start timing out. WooCommerce hosting needs 6+ workers minimum, ideally tied to autoscaling.
3. Database write load is higher. Every order is a series of wp_options and custom-table inserts. The host's MySQL/MariaDB configuration has to keep up — a default install on tiny RAM will be a bottleneck.
4. Email matters. Order confirmations, password resets, low-stock alerts — all hit the SMTP path. A host that throws transactional email into the spam folder is a host you will outgrow on day one.
5. PCI considerations. If you accept card details on-site (rather than redirecting to Stripe or PayPal), you take on PCI scope. Most small shops avoid this by using hosted payment fields — but the choice should be deliberate.

A reasonable WooCommerce hosting decision tree: under 1,000 orders/month, decent shared or business WordPress is fine; 1,000–10,000 orders/month, dedicated WooCommerce hosting tier or small managed cloud; over 10,000 orders/month, a real cloud setup with autoscaling and a CDN that supports cookie-aware caching.

The pre-purchase checklist

Run this against any plan that calls itself "WordPress hosting".

1. PHP 8.3 (or 8.4) is selectable and at least one current version is default for new installs.
2. MariaDB 10.6+ or MySQL 8.0+ with utf8mb4 and max_allowed_packet ≥ 64 MB.
3. HTTPS is automatic with renewals handled by the host (Let's Encrypt or otherwise).
4. Page cache, OPcache and object cache are either on by default or one click away — and the host can explain how they are configured.
5. Daily backups with self-service restore and at least 14 days of retention.
6. One-click staging that does not double the bill.
7. PHP memory limit is configurable per site, with at least 256 MB available (512 MB for commercial sites).
8. CDN is either bundled (typical for managed WordPress) or has documented integration.
9. Transactional email is either included or there is a clear path to Postmark / Mailgun / SES.
10. The host is honest about what is shared. "Unlimited" should come with a fair-use clause you can read in five minutes.

A plan that ticks all of these is "WordPress hosting" in 2026. A plan that ticks only "PHP and MySQL are installed" is just hosting that happens to run WordPress.

FAQ

Is the cheapest shared hosting enough for WordPress?

For a personal blog with low traffic and no commerce, yes. For anything commercial, no — the gap between cheap shared hosting and a real WordPress plan is paid for by a few hours of avoided downtime per year.

Do I really need PHP 8.3 in 2026?

You need PHP that is in the active support window. In 2026 that means 8.3 or 8.4. Running 8.1 or 8.2 is increasingly a security and performance penalty even where it still "works".

Should I use managed WordPress or roll my own on a VPS?

Managed WordPress if your time is worth more than the upgrade cost and you do not want to manage the OS. Roll-your-own VPS if you have the ops appetite or unusual requirements (custom services next to WordPress, low-cost very high traffic, regulatory constraints).

Is a "free CDN" worth anything?

Yes — for static asset delivery and DDoS protection at the edge. No CDN is a substitute for an undersized origin server, especially for ecommerce. See CDN vs hosting.

What's the biggest single performance win for a WordPress site?

Caching, in three layers (page → OPcache → object), and then making sure plugins are not loading on every page they do not need to be on. Most "WordPress is slow" tickets in production turn out to be plugin bloat or a missing object cache, not the host itself.

How important is staging?

For commercial sites, critical. WordPress plugin updates are the leading cause of unplanned downtime; staging is the only way to test them without risk. For personal blogs, you can probably live without it.

What to do next

If you are buying WordPress hosting in 2026, do not start with "which provider is best". Start with this checklist, run it against the plans you are considering, and pick the cheapest one that ticks every box for your workload. That plan is the best WordPress hosting — for you.