How to Choose Hosting for WordPress Website?

Choosing hosting for a WordPress site is the one decision you make before you know anything about the site. Get it wrong and year two costs four times the advertised price, or you are explaining to a client why checkout stalls at forty concurrent shoppers. The specs that decide this are not the ones printed on the pricing page. This guide covers what shared, managed and VPS really differ on, what a PHP worker is, and what to ask before you pay.

What WordPress hosting actually costs, intro and renewal

Almost every hosting comparison you will read quotes the intro price and stops. That number is a first-term rental. Here is the same set of plans with the number you will actually pay in year two sitting next to it.

Plan	Type	Intro price	Renews at	The catch
Hostinger Premium	Shared	$2.99/mo	$10.99/mo	Intro rate needs 48 months paid up front, which is $143.52 on day one
Bluehost Starter	Shared	$3.99/mo	$9.99/mo	36-month term, 10 GB storage, one site
SiteGround StartUp	Shared	$3.99/mo	$17.99/mo	12 months prepaid, one site, 10 GB storage
SiteGround GrowBig	Shared	$6.69/mo	$29.99/mo	Renewal is roughly 4.5x the intro rate
Kinsta Single 20GB	Managed WordPress	$350/yr	$350/yr	No intro discount to lose, but only 2 PHP threads
DigitalOcean Basic, 2 GB	Unmanaged VPS	$12/mo	$12/mo	Nothing is installed, patched or backed up for you

Now run the multiplication yourself, because this is where the decision actually gets made. SiteGround GrowBig at its $29.99 renewal is $359.88 a year. Kinsta’s entry managed plan is $350 a year billed annually. The premium shared plan costs more in year two than the managed host everybody calls expensive. That single comparison is the most useful arithmetic on this page.

The lowest ongoing price in the table is Bluehost Starter at $9.99 a month. The lowest advertised monthly rate is Hostinger Premium at $2.99, and getting it means paying 48 months up front. That is $143.52 committed before you publish a single post, to a host you have not lived with yet. The DigitalOcean row is the only one with no story attached: $12 this month, $12 in three years, and everything above the operating system is your problem.

One host is deliberately missing from that table. WP Engine’s pricing page geo-switches currency and served GBP at the check date, so its plans are not directly rankable against a USD table and converting them would invent a number nobody is charged. If you are shopping WP Engine, read its prices in the currency your own checkout shows. For a wider set of options with the same renewal-first treatment, see our roundup of WordPress hosting platforms, and if budget is the binding constraint, our guide to the cheapest WordPress hosting takes the low end apart properly.

Shared, managed and VPS: what actually separates them

These three words get used as quality tiers, as though shared is bad and managed is good. They are not quality tiers. They describe who is responsible for what.

Shared hosting

Your site sits on a server with a few hundred other sites and shares its CPU, memory and disk. The host handles the operating system, PHP, the database and the web server. You handle WordPress.

The honest case for shared hosting is that a cached WordPress page is a flat HTML file, and serving flat HTML is easy. A blog, a portfolio, a brochure site for a local business, a documentation site: all of these will run on a $10/month shared plan and nobody will ever notice. The failure mode is not average traffic, it is neighbours. On a bad shared server, someone else’s runaway cron job is your slow Tuesday, and you have no visibility into it and no way to fix it.

Buy it if: you run a content site, you will install a cache plugin, and your traffic is measured in thousands rather than hundreds of thousands. Do not buy it if: most of your pageviews are logged in.

Managed WordPress hosting

Managed hosts run a stack tuned for one application and take work off your plate: server-level caching, staging environments, automatic core updates, daily backups, and a support team that knows what a plugin conflict looks like. You typically give up cPanel, arbitrary PHP extensions, and the right to install caching plugins that fight their own cache layer.

What you are really buying is somebody else’s on-call rota. If a site earns money and an outage costs you a client conversation, $30 a month to make server uptime someone else’s job is cheap. If the site is a hobby, it is $30 a month for a feeling.

Buy it if: the site is transactional, a client owns it, or your billable hour is worth more than the price difference. Do not buy it if: you were going to run WP Rocket and be done. Plenty of managed plans forbid exactly that plugin because their own cache does the job.

VPS and cloud servers

You rent a slice of a machine with guaranteed CPU and RAM, and root access. Nothing is installed. A $12 DigitalOcean droplet is an empty Linux box, and turning it into WordPress hosting means a web server, PHP-FPM, MySQL, TLS certificates, a firewall, fail2ban, off-server backups and a patching habit.

Control panels like RunCloud, GridPane, Ploi and Cloudways sit on top of that and do the provisioning for a monthly fee, which is the sensible middle path. The trap people fall into is comparing a bare $12 droplet against a $30 managed plan and calling it a saving. It is only a saving if your time is free, and if you have ever spent a Saturday on a broken MySQL service you know it is not.

Buy it if: you manage several sites, you are comfortable on the command line, or you need something the managed hosts will not allow. Do not buy it if: you would have to search for how to renew a certificate.

What a PHP worker actually is

This is the spec that decides whether your site survives a traffic spike, and almost nobody shopping for hosting has heard of it.

A PHP worker is a single process that builds one page at a time. Kinsta, which renamed them PHP threads in December 2024, puts it plainly in its PHP documentation: each thread processes one request at a time, so two threads means two requests can be built simultaneously. Its entry Single plan ships with two. Requests three and four wait in a queue.

Here is the part that changes how you shop. Cached pages do not touch a PHP worker at all. A cached page is already-built HTML handed straight back by the web server. So a blog serving 50,000 cached pageviews a month can be perfectly happy on two workers, while a WooCommerce store serving 5,000 pageviews can drown on the same two, because carts, checkouts, account pages and logged-in sessions all skip the cache by design.

When workers run out, requests queue and then get killed. WP Engine documents the two error codes you will see: 504 when the backlog gets long enough that waiting requests are evicted, and 502 when a request takes so long it is killed to free the worker for someone else. If your site throws intermittent 502s and 504s under load while the CPU graph looks calm, worker exhaustion is the first thing to check, not bandwidth.

The practical response is boring and effective: cache aggressively so PHP is only invoked for pages that genuinely need it, then cut the PHP work those pages still do. A page cache from a decent caching plugin handles the first half. Stripping plugin bloat off the pages that cannot be cached, which is what Perfmatters is built for, handles the second. Buying more workers is the expensive way to solve a problem that is usually a plugin doing database queries on every request.

How to size hosting for the traffic you actually have

Hosts sell on monthly visits because it is a number you recognise, not because it is the number that matters. Two things matter more: what share of your pages can be cached, and how many people hit the uncacheable ones at the same moment.

Work it out like this. Take your busiest hour from analytics, not your monthly total. A site with 100,000 monthly visits that arrive evenly is a quiet site. A site with 20,000 monthly visits where 8,000 arrive in the ninety minutes after a newsletter goes out is a demanding one. Concurrency is what breaks servers; monthly totals are what sells plans.

Then ask what fraction of those requests can be served from cache. For a blog it is well over 90%. For a WooCommerce store with a live cart it might be 40%, and for a membership site where everyone is logged in it can be close to zero. Multiply your busy-hour concurrency by the uncacheable share and you have a rough worker requirement. That is the number to take to a sales chat.

For a measurable target rather than a vibe, use the thresholds Google actually publishes. Core Web Vitals want Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 ms or below, and Cumulative Layout Shift at 0.1 or less, all measured at the 75th percentile of page loads. Hosting mostly moves the first one, and it moves it through server response time: web.dev suggests most sites aim for a Time to First Byte of 0.8 seconds or less, while noting TTFB is guidance rather than a Core Web Vital in its own right. If a host cannot get you under that on a cached page, no plugin will rescue it, though reducing server response time is worth attacking from the application side too.

Check the floor while you are here. WordPress.org recommends PHP 8.3 or greater, MariaDB 10.11+ or MySQL 8.0+, and HTTPS on every install. WordPress still runs on PHP 7.4 and MySQL 5.5.5, but both are past end of life. A host whose control panel still offers PHP 7.4 as the default in 2026 is telling you something about how closely it is paying attention.

The migration question

If you already have a site, migration is a real cost and hosts know it. Free migration is the single most common promise on a hosting sales page and the definition varies wildly.

Ask three specific things before you take the offer. How many sites are included, because the answer is often one. Is it done by a human or by a plugin they run on your behalf. And what is the promised turnaround, because free migrations are frequently queued behind paid work and can take days you did not budget for.

What breaks in a migration

• Hardcoded URLs in serialised data. Page builders store layouts as serialised PHP. A naive find-and-replace corrupts it and your layouts come back empty. Any decent WordPress migration plugin handles serialisation properly; a manual SQL replace often does not.
• Email. If your mail runs on the old host, moving the site moves the MX records with it unless you plan otherwise. Contact forms silently stop delivering and nobody notices for a fortnight.
• Cron. Scheduled posts, backups and abandoned-cart emails run on WP-Cron, which fires on page loads. Sites that were busy enough to trigger it reliably on the old host sometimes are not on the new one.
• Redirects and rewrite rules. Anything living in .htaccess does not survive a move to an Nginx-based host. Audit your redirects before you cut over, not after traffic drops.
• Licence keys tied to a domain or IP. Premium plugins often need reactivating, and some will quietly stop updating rather than warn you.

Whoever performs it, do the cutover with a staging copy first. Spinning up a throwaway sandbox with something like InstaWP and restoring your backup into it tells you in twenty minutes whether the archive is actually complete, which is a much better time to find out than during a DNS change.

Questions to ask a host before you pay

Open a pre-sales chat and ask these. The answers, and how readily they come, tell you more than any review.

1. What does this plan renew at? Get the number in writing in the chat transcript. Every other question is downstream of this one.
2. How many PHP workers or threads do I get? A host that cannot answer is a host that has not thought about it. Kinsta publishes the count per plan; many do not publish it at all.
3. What are the actual limits behind unlimited? Unlimited bandwidth and unlimited storage are marketing terms governed by an acceptable use policy. Ask for the inode limit, the CPU-seconds allowance, and what happens when you exceed them.
4. Where are backups stored, how long are they kept, and can I restore one myself? Backups kept on the same server as the site are not backups. You want off-server retention and a self-serve restore button, and you want your own independent backup regardless of what they promise.
5. Is there a staging environment, and does pushing to live overwrite the database? A staging site that clobbers live orders when you push is worse than no staging site.
6. Which PHP versions can I select, and how quickly do you add new ones? This is a good proxy for how current the whole stack is.
7. What is included in security, and what costs extra? Free SSL is table stakes. Ask specifically whether malware scanning and cleanup are included or billed as an incident, because a cleanup invoice after a hack is a genuinely nasty surprise. Either way you want your own security plugin at the application layer.
8. Do you block any plugins? Managed hosts maintain a disallowed list. Check yours against it before you move, not after.
9. What is the refund window, and is the domain refundable too? Usually the answer is 30 days for hosting and never for the free domain, which is how a free domain works.
10. Do you charge to move a site out? A host that makes leaving awkward is telling you how it expects to retain you.

Test the host before the refund window closes

The sales chat is a sample of the sales team. The refund window is your only chance to sample the actual service, so use it deliberately rather than letting it lapse.

1. Install WordPress and import a realistic copy of your site, not a blank theme. A blank install is fast everywhere.
2. Set PHP to 8.3 or later in the control panel. If the option is not there, you have already learned something.
3. Turn on whatever caching the host provides, then measure a cached page and an uncached one separately. The gap between those two numbers is the honest picture of the server.
4. Open a support ticket about something real at an inconvenient hour and time the first substantive reply. Not the autoresponder.
5. Break something on purpose in staging and restore from their backup. This is the verification step people skip, and the restore is the only part of a backup that matters.
6. Check your billing page for the renewal date and amount. Confirm it matches what the chat transcript said. If it does not, that is what refund windows are for.

If everything passes, the remaining gains are in the application, and speeding up the WordPress site itself will do more for you from that point than another hosting upgrade will.

What most hosting guides get wrong

Three things, consistently.

They quote the intro price as the price. A table showing $2.99 next to $6.69 next to $350 a year ranks those hosts in an order that reverses within twelve months. The renewal column exists in this article because without it the comparison is fiction, and the SiteGround-versus-Kinsta arithmetic above is the proof: the shared plan ends up costing more per year than the managed one.

They publish speed tests as if they were durable facts. A load-time figure from a single test on a single day on a shared server tells you about that server on that day and its neighbours at that moment. It is not a property of the company. Treat any hosting speed benchmark you read, including ones with charts, as an anecdote rather than a measurement you can plan around.

They never mention that uptime guarantees pay out in credit. A 99.9% uptime SLA permits about 43 minutes of downtime a month, and the compensation for breaching it is almost always hosting credit rather than money. If your site going down costs you real revenue, the SLA is not insurance. It is a discount on your next invoice.

The related honest point: for most sites, hosting is not the bottleneck. An unoptimised theme, twenty-eight plugins and 4 MB of hero image will be slow on any server you buy. Hosting sets the floor for how fast a site can be. It does not set the ceiling.

A short decision path

• New blog, no traffic yet, tight budget. Entry shared plan on the shortest term available. Add a cache plugin. Revisit in a year with real numbers instead of guesses.
• Established content site, steady traffic, cacheable. Premium shared or entry managed. Compare on the renewal price, and only then on features.
• Store, membership or LMS. Managed WordPress, and ask about PHP workers before anything else. Uncacheable traffic is the whole ballgame here.
• Several client sites, and you are technical. A VPS with a control panel on top. The per-site economics stop making sense on managed plans somewhere around the fifth site.
• You cannot tell which of these you are. Take the shortest-term shared plan, run the refund-window tests above, and let the site tell you what it needs.

Frequently Asked Questions

Our call

If you are choosing WordPress hosting in 2026 and you want one answer: buy a premium shared plan on a twelve-month term, cache the site properly, and spend the difference on your own off-server backups. That covers the large majority of WordPress sites, and it keeps your options open.

Two exceptions. If your pages cannot be cached, go managed now and ask about PHP workers before you compare anything else, because that is the constraint that will actually bite. If you run several sites and you are comfortable in a terminal, a VPS with a control panel wins on economics somewhere around the fifth site.

And whatever you pick, do the boring thing first: find the renewal price, multiply it by twelve, and decide whether you would pay that number today. If the answer is no, the intro discount has done its job and you are the one paying for it.