Quick answer
There is no single best WordPress hosting: the right choice depends on how much uncached PHP your site runs. For a cached blog, SiteGround or Hostinger at entry prices is enough. For a content site with real traffic, Rocket.net or Pressable. For WooCommerce, Kinsta, WP Engine or a tuned Cloudways server with Redis. Judge PHP workers and renewal price, not bandwidth.
Every roundup of the best WordPress hosting you have already read contains a table of load times. Those numbers are worthless. They were produced by the person being paid an affiliate commission, on a site they built, with a cache they warmed, from a location they chose, on a day they picked.
This comparison is built from what the hosts publish about their own plans: the specifications and the contract terms. That is a deliberate choice, and it is the only honest basis for a public comparison. A spec sheet is a promise the host has to keep. A stranger’s stopwatch reading is not.
Why a vendor-run benchmark tells you nothing
A hosting benchmark is only meaningful if it reproduces your workload, and nobody else’s benchmark does. The load-time table in a typical roundup is measured against a default theme with a full page cache in front of it, which means the number describes the reviewer’s CDN edge and almost nothing about the origin server you are buying.
Serve a cached HTML page from any of the nine hosts below and you will get a fast result from all nine. The differences appear on the requests that cannot be cached: the cart, the checkout, the logged-in dashboard, the search query, the admin-ajax call your form plugin fires on every page view. A benchmark that never issues one of those requests has measured nothing you will experience.
Any host looks fast when the request never reaches PHP. Buy for the requests that do.
The specs that actually decide performance
Eight published specifications predict real-world behaviour better than any marketing metric, and most of them are not on the pricing page. Each one below replaces a headline number that hosts prefer you look at instead.
PHP workers, not “unlimited bandwidth”
A PHP worker is a single process that can execute one PHP request at a time. If your plan has four workers and a page takes 400 ms of PHP to build, that site can produce roughly ten uncached page builds per second, and no more, regardless of how much bandwidth the plan advertises.
When all workers are busy, new requests queue. The queue adds latency to every visitor, not just the extra ones. When the queue is longer than the timeout, the web server stops waiting and returns 502 or 504. That is the mechanism behind most “the site went down during our sale” stories.
A cached blog rarely touches a worker at all: the page cache answers, and workers only fire for comment posts and cron. A WooCommerce store is the opposite. Cart, checkout, my-account and any page carrying a session are excluded from full-page cache by design, so every one of those views consumes a worker for its full duration. A store doing a few hundred orders a day needs several times the worker count of a blog with the same pageview total.
Object cache availability, because plugin-heavy sites are database-bound
A persistent object cache in Redis or Memcached is the difference between a worker finishing in 200 ms and the same worker finishing in two seconds. Without one, WordPress rebuilds every option, term, meta and transient lookup from MySQL on every single request, and discards the result when the request ends.
The WordPress hosting team lists apcu, memcached, opcache or redis under recommended PHP extensions for exactly this reason, alongside the recommended server environment. A site running thirty plugins, or WooCommerce with variable products, can issue several hundred queries per uncached page. Object cache turns most of those into memory reads.
Availability is not the same as being switched on, and it is not the same as being free. Some hosts include it, some charge a monthly add-on per site, and some offer it only from a mid tier upward. Check which, and then check that it is genuinely connected, which is a separate problem covered further down.
Real storage type, I/O, and inode caps
Storage size is the least interesting storage number. NVMe versus SATA SSD, and whether I/O is throttled per account, decides how fast MySQL writes and how fast a backup or a media library scan finishes.
Inode limits matter more than most people expect. An inode is one file or directory. A WordPress install with a large media library, several image size variants per upload, page-builder CSS caches and a plugin that writes log files can pass a hundred thousand files without approaching a storage quota. Shared hosts often cap file counts separately from gigabytes, and hitting that cap stops uploads and can break updates. If a host does not publish an inode limit, ask support in writing before you migrate.
PHP version, and how fast the host ships new ones
The lag between a PHP release and the host offering it is a good proxy for how the whole platform is run. WordPress currently recommends PHP 8.4 or later for production, and a host still topping out at 8.1 is telling you something about its maintenance cadence.
The reverse failure exists too. A host that force-upgrades PHP with no opt-out and no staging environment to test on will eventually break a site of yours on a Tuesday morning. What you want published is a version list, a switch you control per site, and a way to test the switch first.
Staging, tested restores, and WP-CLI over SSH
Staging, backups and shell access are the three features that decide how expensive your worst day is. Every host advertises backups. Very few make it easy to prove a restore works, and a backup you have never restored is a hypothesis.
Restore a backup to staging on day one of any new plan and time it. That number is your true recovery window, and it is worth more than any uptime figure on a sales page. SSH with WP-CLI is what makes the rest of this practical: search-replace on a database, a plugin rollback, a cache flush, all without a browser.
Renewal pricing, the biggest trap in the market
The advertised price of most shared WordPress hosting is an introductory rate that expires, and the renewal is frequently three to six times higher. SiteGround publishes a StartUp plan at 2.99 USD per month that renews at 17.99 USD. Hostinger’s Premium plan is 2.99 USD per month on a 48-month term and renews at 10.99 USD. Bluehost’s Starter is 3.99 USD on a 36-month term, renewing at 9.99 USD.
None of that is hidden, and none of it is dishonest. It is simply not the number in the ad, and it is the number you will pay for most of the time you own the site. The worked arithmetic is below.
How the host counts a “visit”
Visit metering is defined differently by every host that uses it, and the definition changes your bill more than the number does. Some count unique IPs in a rolling window. Some count sessions. Some count every request that reaches PHP, which means an aggressive bot crawl or an uncached admin-ajax loop can burn your allowance without a human being involved.
WP Engine’s Startup plan lists 25,000 visits a month and states on the plans page that visits are estimates only. Pressable’s entry plan lists 30,000. DreamPress 1 lists 40,000 monthly visitors. Those three numbers are not measuring the same thing, so do not compare them as if they were. Ask what happens at the cap: soft warning, overage charge, or throttle.
What the host forbids
Managed hosts maintain disallowed-plugin lists, and the plugin you rely on may be on one. The usual categories are full-page caching plugins that duplicate or fight the platform’s own cache layer, backup plugins that hammer disk I/O, related-posts plugins that run unindexed queries, and security plugins that duplicate the platform firewall.
None of the pricing pages checked for this article link to that list. You have to find it in the knowledge base, and you should find it before you migrate rather than after your caching plugin is silently deactivated on arrival.
Watch out
Two full-page caches stacked on top of each other is worse than one. If the host runs Varnish or an edge cache and you also run a page-caching plugin, you can end up serving stale HTML that neither layer thinks it owns. The pattern and the fix are laid out in our notes on running Varnish alongside WP Rocket.
Nine hosts compared on published entry-plan specs
Here is the entry tier of nine common choices, taken from each host’s own pricing page and nothing else. Where a host does not publish a figure, the cell says “not published”, and that absence is a finding in itself: a host that will not state its PHP worker count on the page where it asks for your money has made a decision about what it wants you to compare.
| Host / entry plan | Entry price (intro or flat) | Sites / visits / storage | Object cache | Staging | PHP workers | Honest caveat |
|---|---|---|---|---|---|---|
| Kinsta Single | 35 USD/mo, or 30 USD/mo annual. Flat, no renewal jump | 1 site, bandwidth-metered rather than visit-metered, 10 GB storage, 125 GB CDN | Redis offered as a paid add-on, listed at 100 USD per site per month | Yes, free one-click | Not published on the plans page | Object cache is a real line item, not a freebie |
| WP Engine Startup | From 30 USD/mo annual, marked first-year pricing | 1 site, 25,000 visits, 10 GB storage, 75 GB bandwidth | Not published on the plans page | Yes, one-click staging and dev | Not published | Visit counts are described as estimates only |
| Cloudways (DigitalOcean entry) | 11 USD/mo, pay-as-you-go, flat | Unlimited apps per server, 2 GB RAM, 1 vCPU, 50 GB storage, 2 TB transfer | Yes, Redis and Object Cache Pro included | Yes, staging and cloning | Not published, you size the server yourself | You own the tuning. No WordPress support desk behind the stack |
| Rocket.net Starter | 30 USD/mo, 25 USD/mo annual, 1 USD first month promo | 1 site, unmetered visits, 10 GB storage, 50 GB bandwidth | Not listed on the pricing page | Not listed on the pricing page | Stated as unlimited | “Unlimited workers” needs a definition the pricing page does not give |
| Pressable Signature 1 | 25 USD/mo | 1 install plus 1 staging plus 1 sandbox, 30,000 visits, 20 GB storage | Not published on the plans page | Yes, a dedicated staging site is part of the plan | Not published | Sparse spec sheet. Everything technical lives in the docs |
| SiteGround StartUp | 2.99 USD/mo intro, renews at 17.99 USD/mo | 1 site, unlimited traffic claimed, 10 GB space | Multilevel caching advertised, Memcached tier not delineated on the page | Not stated at this tier on the pricing page | Not published | Six-fold renewal increase. Budget for the second year |
| Hostinger Premium | 2.99 USD/mo on a 48-month term, renews at 10.99 USD/mo | 3 sites, 20 GB SSD, visit allowance not published on the landing page | Not published on the landing page | Not detailed on the landing page | Not published | Requires a four-year prepayment for the headline price |
| Bluehost Starter | 3.99 USD/mo on a 36-month term, renews at 9.99 USD/mo | 10 sites, 10 GB NVMe | Object caching listed as an advanced feature | Yes, WordPress staging site listed | Not published | Ten sites on an entry shared plan is a share of one box, not ten sites of capacity |
| DreamHost DreamPress 1 | 14.99 USD/mo first year, renews at 19.99 USD/mo | 1 site, 40,000 monthly visitors, 15 GB NVMe | Not published on the DreamPress page | One-click staging advertised | Not published | Renewal is a third higher than the advertised rate |
Read the “not published” column before the price column. Seven of the nine do not state a PHP worker count on the page where they ask for a card number, which means the single specification most predictive of behaviour under load is the one almost nobody discloses up front.
Which hosting type fits which workload
Match the hosting type to the amount of uncached PHP the workload generates, and the budget follows from that. The last column is the thing that fails first if you buy a tier too small, which is usually more useful than knowing what you gain from buying up.
| Workload | Hosting type that fits | Realistic monthly budget | What breaks first if you undersize |
|---|---|---|---|
| Personal blog, a few thousand views a month | Shared hosting with a page cache plugin | 3 to 12 USD, watching the renewal rate | Nothing, for years. Then the renewal invoice |
| Business brochure site, contact forms, no logins | Shared or entry managed | 10 to 30 USD | Admin becomes slow while editing; the front end stays fine |
| Content site with real traffic and ad scripts | Managed WordPress with an edge cache in front | 25 to 60 USD | Cache hit ratio, once query strings and personalisation fragment the cache |
| WooCommerce, under roughly 200 orders a day | Managed WordPress with Redis object cache | 50 to 120 USD | Checkout latency. Cart and checkout cannot be page-cached |
| WooCommerce, above roughly 200 orders a day | Dedicated or tuned cloud VPS, workers sized to concurrency | 120 to 400 USD | PHP workers exhaust, queue builds, checkout returns 502 or 504 |
| Membership or LMS site, most visitors logged in | Managed with generous workers plus object cache. Page cache is nearly useless here | 60 to 250 USD | Database. Every logged-in view is an uncached PHP request |
| Agency portfolio, 20 or more client sites | Multi-site managed plan or a self-managed cloud server per client tier | 100 USD upward, priced per site | Your own time, then whichever client site gets a traffic spike on shared resources |
Three-year cost, worked out properly
A cheap introductory host is usually cheaper over three years, but by far less than the advertised gap suggests. Below is a worked example, and the assumptions are stated so you can substitute your own.
Assumptions: one site, list prices published in August 2026, no add-ons, no domain fees, no tax, the introductory term paid up front, and the plan renewed at the host’s stated renewal rate for the remainder of 36 months. Kinsta and Pressable are treated as flat because they publish no separate renewal rate.
| Plan | Months 1 to 12 | Months 13 to 36 | 36-month total | True average per month |
|---|---|---|---|---|
| SiteGround StartUp | 2.99 x 12 = 35.88 | 17.99 x 24 = 431.76 | 467.64 | 12.99 |
| DreamHost DreamPress 1 | 14.99 x 12 = 179.88 | 19.99 x 24 = 479.76 | 659.64 | 18.32 |
| Pressable Signature 1 | 25.00 x 12 = 300.00 | 25.00 x 24 = 600.00 | 900.00 | 25.00 |
| Kinsta Single, annual billing | 30.00 x 12 = 360.00 | 30.00 x 24 = 720.00 | 1,080.00 | 30.00 |
The advertised gap between SiteGround and Kinsta is roughly ten to one. The three-year gap is closer to two and a third to one. That is still a real difference and for a small blog it is the right call, but the decision should be made on 12.99 against 30.00, not on 2.99 against 30.00.
How to test a host before you commit and after you migrate
Test the uncached path, not the cached one, and do it on a trial or refund window before you move anything real. Four checks separate a host that is genuinely quick from one that is merely sitting behind a CDN.
1. Time a cached request against an uncached one
Request the same URL twice: once plain, once with a unique query string that busts the cache. The first tells you about the edge. The second tells you about the origin, which is what you are buying.
# cached path
curl -o /dev/null -s -w "ttfb:%{time_starttransfer}s total:%{time_total}s\n" https://example.com/
# cache-busted path, hits PHP
curl -o /dev/null -s -w "ttfb:%{time_starttransfer}s total:%{time_total}s\n" "https://example.com/?nocache=$(date +%s)"
Run each five times and look at the spread, not the best result. A wide spread on the uncached path is a noisy-neighbour signal on shared infrastructure.
2. Confirm a real cache HIT rather than assuming one
Read the response headers instead of trusting a plugin dashboard that says caching is on. Every serious platform stamps its cache status into the response.
curl -sSI https://example.com/ | grep -iE 'age|x-cache|cf-cache-status|x-litespeed-cache|cache-control'
If you want that checked across page cache, server cache and CDN in one pass without reading headers by hand, the free Cache Inspector in the WPColt toolbox reports which layer answered and whether it was a hit or a miss.
3. Check whether two cache layers are fighting
Two independent full-page caches with different rules produce stale pages that neither one will purge. The symptom is a logged-out visitor seeing a cart, or an edit that appears for you and not for anyone else.
If the host runs its own edge or server cache, disable the page-cache module of your plugin and keep only its optimisation features. Purge rules have to live in one place.
4. Verify the object cache is actually connected
An installed Redis plugin does not prove a working object cache. Confirm it from the shell rather than from a green tick in wp-admin.
wp eval 'var_dump( wp_using_ext_object_cache() );'
wp redis status
ls -l wp-content/object-cache.php
If the drop-in is missing, or the status reports a connection error, WordPress silently falls back to a non-persistent array cache and your queries all go to MySQL. The failure modes and how to read them are covered in our walkthrough of diagnosing Redis object cache misses.
Migrating without breaking DNS or email
Most migration disasters are DNS and mail problems, not file-copy problems. Work through the three phases in order and the move is dull, which is the goal.
- Before: drop the DNS TTL on the A and AAAA records to 300 seconds at least 48 hours ahead, so the old value has expired from resolvers everywhere by cutover day. Export a full copy of the current zone file first.
- Before: write down every MX, SPF, DKIM and DMARC record. If your email is hosted elsewhere, a new host’s default zone will overwrite them and your mail stops. This is the single most common self-inflicted migration outage.
- During: put the source site into a known state, copy files and database, then test the new server by hosts-file override before any DNS change. Confirm checkout, forms and logins work on the new origin while the old one is still live.
- After: keep the old host running for at least a week. Then verify HTTPS and the redirect chain, re-check the cache headers, resubmit the sitemap, and confirm mail still delivers by sending to an external address.
The full sequence, including the search-replace step that catches serialised URLs, is written out in our guide to moving a WordPress site between hosts.
Mistakes that cost real money
These are specific, common and expensive, and every one of them is avoidable at purchase time.
- Buying a 48-month term for the headline rate. You lock in a platform for four years to save a few pounds a month, and partial refunds are usually prorated against the undiscounted rate.
- Assuming “unlimited traffic” means unlimited capacity. Unlimited bandwidth on a plan with an undisclosed worker count means you may transfer as much data as your four workers can generate. Those are different promises.
- Migrating a store during a promotion. Move in a quiet week. Cutover during a sale means the DNS propagation window and the traffic peak overlap.
- Never restoring a backup. Restore once to staging in your first month. If it takes six hours or needs a support ticket, that is your real recovery time and you should know it before you need it.
- Leaving two page caches running after a move. The plugin that was correct on your old host is often forbidden or redundant on the new one.
- Counting an installed plugin as a working object cache. Check the drop-in file exists and the connection reports healthy. A silent fallback to the array cache is invisible from wp-admin.
Verdict: the best WordPress hosting for each kind of site
Pick by workload, then verify the two specs nobody advertises. Here is the position, stated plainly.
Hobby blog or first site: Hostinger or Bluehost on the shortest term you can get, and diarise the renewal date. If you want a walkthrough of the setup, we have one on starting a WordPress site on Bluehost. Do not sign a four-year term for a site you may abandon in six months.
Business site or growing content site: Rocket.net or Pressable. Both publish a flat price with no renewal cliff, which removes the largest hidden cost in this market. Rocket.net is the one to look at if your traffic is genuinely global and unmetered visits matter to you.
WooCommerce, membership or LMS: Kinsta or WP Engine, and budget for the object cache rather than hoping it is free. Our Kinsta review goes through what the platform does and does not include. Ask both for the worker count in writing before you sign.
Developers and agencies: Cloudways, or a plain cloud server you manage yourself. Redis included at 11 USD a month with root-level control is unbeatable on price per unit of capacity, on the explicit condition that you are the one who tunes it. If nobody on the team wants that job, pay a managed host instead.
Pro tip
Hosting quality is not durable. Ownership changes, private equity acquisitions and platform consolidations have repeatedly turned a host that was excellent into one that is merely adequate, usually within about two years of the deal closing. Treat any recommendation older than eighteen months, including this one, as a starting point for your own checks rather than a conclusion.
Whatever you choose, the verification is the part that transfers. Prices change, plans get renamed and companies get bought, but an uncached request timed against a cached one, a header that proves a hit, and a Redis drop-in you have confirmed by hand will tell you the truth about any host on any day.
Frequently asked questions
How many PHP workers does a WooCommerce store need?
It depends on concurrency and how long a checkout request takes, not on pageviews. If an uncached checkout takes 500 ms of PHP, each worker handles about two per second. Size workers to your peak simultaneous uncached requests, then add headroom for cron and admin activity. Most hosts do not publish worker counts, so ask support in writing before you buy.
Is managed WordPress hosting worth the extra cost?
It is worth it when nobody on your team wants to tune PHP-FPM, Redis and a cache layer, or when downtime costs more per hour than the price difference per month. For a static brochure site on shared hosting that never touches PHP under load, the premium buys convenience rather than measurable speed.
What is the difference between page cache and object cache?
Page cache stores the finished HTML of a URL so the request never reaches PHP. Object cache stores the results of individual database queries in memory so that when PHP does run, it makes far fewer MySQL calls. Cached blogs benefit most from page cache. Carts, checkouts and logged-in pages can only be helped by object cache.
Why did my hosting bill triple in the second year?
Most shared WordPress hosts advertise an introductory rate that applies only to the first term, then renew at a much higher standard rate. SiteGround publishes 2.99 USD renewing at 17.99 USD, and Hostinger 2.99 USD renewing at 10.99 USD. The renewal figure is published, just not in the advertisement. Always calculate a three-year total before signing.
Can I run WP Rocket on managed WordPress hosting?
Sometimes, but usually only with its page-caching module disabled. Managed hosts run their own full-page cache, and two caching layers with different purge rules will serve stale HTML that neither layer believes it owns. Several managed hosts list page-caching plugins on a disallowed list and deactivate them automatically on arrival.
How do I check if Redis object cache is actually working?
Confirm from the shell rather than from wp-admin. Check that wp-content/object-cache.php exists, then run wp redis status or evaluate wp_using_ext_object_cache to see whether WordPress has a persistent backend. If the drop-in is missing or the connection fails, WordPress silently falls back to a per-request array cache and every query goes to MySQL.
What TTL should I set before a hosting migration?
Lower the TTL on your A and AAAA records to 300 seconds at least 48 hours before cutover, so every resolver has expired the old value by the time you switch. Record the existing zone first. Raise the TTL back to an hour or more about a week after the move, once you are confident the new host is staying.
Does unlimited bandwidth mean unlimited traffic?
No. Bandwidth is data transfer, capacity is how many requests your PHP workers can build per second. A plan can offer unlimited transfer while capping you at four concurrent PHP processes, which means uncached requests queue and eventually return 502 or 504 long before any bandwidth limit matters. The two promises are unrelated.