There is no best host, only one that fits what you are building and how much of the work you want to do yourself. A host that is perfect for a village cricket club's fixture list is the wrong choice for a shop that takes four hundred orders on a sale weekend, and the reverse is just as true.
Most bad choices come from comparing the wrong things. Plan pages lead with storage figures and visitor allowances that rarely matter, and bury the limits that do: how many processes your site may run at once, how much memory a single request may use, and what happens when you hit either.
This guide works in the order a support engineer would. First describe the site, then match it to a type of hosting, then compare the details that change your daily life, then test a candidate with a real site before you commit to a long term. It also covers the unglamorous part, which is how you leave.
Start with the site, not the plan
Write down what you actually run: a WordPress blog, a small shop, a custom PHP application, a static portfolio. Note how many visitors you expect and whether traffic is steady or spiky. Note if you want someone else to handle updates and security. These answers do most of the narrowing before you look at a single price.
A few worked examples show how different the answers can be.
- A two-person design studio with a ten-page portfolio, updated twice a year. Traffic is a few hundred visits a month. Anything reliable works, and the deciding factors are free certificates, easy email and a support team that answers.
- A furniture retailer on WooCommerce with about 3,000 products and a newsletter that sends traffic in bursts. Database speed, memory limits and a caching layer decide it. A pretty control panel does not.
- A developer with a custom Python or Node application and a queue worker. Shared hosting is out because it will not let you run your own long-lived processes. You need a VPS or a cloud instance, and you need to be willing to patch it.
Also write down what you cannot do. If nobody on the team is comfortable with a command line, an unmanaged server is a liability, however cheap. If you want to deploy from Git on every commit, check that the plan allows it before you fall for the price.
The main kinds of hosting
Names vary between companies, but the underlying arrangements are few. What changes between them is who shares the machine with you, who looks after the software, and how much freedom you have.
| Type | Who shares the machine | Who maintains the software | Typical fit |
|---|---|---|---|
| Shared | Many accounts, isolated by the host | The host | Brochure sites, small blogs, small WordPress sites |
| Managed WordPress | Fewer accounts, tuned for one application | The host, including updates and caching | Business sites and shops that want less admin |
| VPS | A virtual machine with guaranteed slices of CPU and memory | You (or a management add-on) | Custom applications, several sites, special software |
| Dedicated | Nobody | You, or a managed service | Steady heavy load, strict isolation requirements |
| Cloud | Pooled hardware, billed by usage | You, with some services managed | Spiky traffic, designs that scale out |
The step from shared to a VPS is the one that surprises people. You gain root access and stable performance, and you also gain the job of applying security updates, configuring the firewall, setting up backups and reading logs. A VPS with nobody maintaining it is not an upgrade. It is an unpatched server with a public address.
What to compare
Once you know the type, compare providers on the details that affect you. Ignore the headline storage figure; almost nobody fills it.
- Resource limits that matter: CPU, memory, simultaneous processes (sometimes called entry processes or PHP workers), and inodes, which are the count of files and folders on the account. A shop with a large image library can hit an inode ceiling long before a storage one.
- PHP and database versions: current, selectable per site, and updated regularly. PHP 8.x should be on offer, and old versions should be clearly marked as end of life.
- Backups: frequency, retention, off-server storage, and self-service restore. See Backups Done Right for what good looks like.
- Performance features: built-in caching, HTTP/2 or HTTP/3, NVMe storage, a CDN option.
- Security: isolation between accounts, a firewall, malware scanning, free certificates that renew themselves.
- Email: whether it is included, and its sending limits. Hourly caps are usual and sometimes tight.
- Support: what channels exist, how fast they reply, and whether they will look at your application or only the server.
- Location: physically near your visitors, or with a CDN to bridge the distance.
Read the limits page, not the plan page
Every reputable host has a page, often in the knowledge base, that lists the real limits: memory per process, maximum execution time, number of concurrent PHP workers, cron frequency, outgoing mail per hour. Compare those. If the page does not exist, that is information too.
What uptime figures mean
A promise of 99.9% uptime allows about 43 minutes of downtime in a 30-day month, or around 8 hours 45 minutes a year. 99.99% allows about 4 minutes a month. The uptime calculator does the sums. Check what the guarantee pays out, which is usually a small credit, and whether planned maintenance counts against it.
What to be sceptical about
Introductory prices that triple on renewal. "Unlimited" anything: there is always a limit, and it appears in the terms as a fair-use clause or as a cap on processes. Rankings and "best host" lists where every entry pays the author a commission. Reviews posted in the first week, before the first outage or the first support ticket.
Look at the whole term cost, not the monthly figure. A plan advertised at a low introductory rate for 36 months and renewed at a much higher one is a different product in year four.
How to test one
Most reputable hosts offer a trial or a refund window. Use it. Do not point a blank page at it; move a copy of a real site and put it through its paces.
- Move a copy of the real site to a temporary address, and test it with a hosts file entry or the provider's preview URL before changing DNS.
- Measure the time to first byte from a couple of locations:
curl -o /dev/null -s -w "dns %{time_namelookup}s connect %{time_connect}s ttfb %{time_starttransfer}s total %{time_total}s\n" https://example.com/. Run it ten times and look at the spread, not one number. - Check headers with
curl -I https://example.com/: look for HTTP/2 or HTTP/3, compression, and cache headers. - Open a support ticket with a real question, for example how to raise the PHP memory limit for one site. Note how long the answer took and whether it was an answer.
- Take a full backup and restore it into a second location.
- Check how email behaves: send to a few providers and read the headers. The email setup guide shows what to look for.
- Find out how leaving works before you need to leave: can you download a complete archive, and does the host release the domain and DNS cleanly?
Matching sites to hosting types
| You have... | Likely fit | Why |
|---|---|---|
| A small brochure site or portfolio | Shared hosting | Low cost, low maintenance. |
| A WordPress blog or business site | Shared or managed WordPress | Caching and updates handled for you. |
| An online shop with steady orders | Managed WordPress/WooCommerce or a good VPS | Consistent performance matters more than price. |
| A custom application | VPS or cloud | You need control over the software. |
| Heavy or spiky traffic | Cloud with a CDN | Capacity that grows and shrinks. |
If you are unsure, try the hosting quiz. For a cross-check on page size and how much your visitors have to download, the page weight tool helps.
What changes as you move up
People talk about "upgrading" as if the only change were a bigger number. In practice the work moves around, and it helps to know where it lands before you pay.
On shared hosting
The host patches the operating system, runs the web server and database, and fixes hardware faults. You manage the application and its content. The trade-off is that your neighbours' behaviour can affect you, though good providers isolate accounts so one runaway script gets throttled rather than taking everyone down. You cannot install system packages, change the web server configuration beyond an .htaccess file or a few panel options, or keep a background process alive.
On a VPS
You get a virtual machine with its own operating system. Memory and CPU are yours, which makes performance steadier, and you can install anything. You also inherit the job list: updates, firewall, SSH keys, log rotation, monitoring, backups. Many providers sell the same VPS with a management layer. That costs more, and for a small business it is often cheaper than the hour of an expert on a bad night.
On managed WordPress
The host looks after the application stack: PHP tuned for WordPress, page caching, automatic core updates and usually a staging copy. The catch is restrictions. Some plugins are banned because they duplicate the host's caching or put load on the database, and some plans cap monthly visits, which matters if a post goes round the internet.
On cloud
You assemble the parts: a server or container, a managed database, object storage, a load balancer. The bill follows usage, which is fair until a bot hammers the site and the bill follows that too. Set spending alerts on day one.
Support, and who you will be talking to
Support quality is the feature that is hardest to judge from a web page and the one you will care about most when something breaks at 7 a.m. before a launch. Before you buy, read how the host describes its support: does it list channels, hours and target response times, or just say "24/7"? A live chat that hands you a script and a ticket that gets answered by someone who has read it are very different things.
Ask a presales question that needs a technical answer, such as whether the plan supports a particular PHP extension, or how many PHP workers a plan allows. Note the speed, but also whether the answer is specific. An evasive reply to a simple question is a preview of how the incident will go.
Also find out what support will not do. Most hosts will fix the server and tell you what is wrong with your site. Few will rewrite your plugin. Knowing where that line sits stops you being disappointed after the ticket is open. If you depend on a developer, ask whether they have worked with the host before; their experience is worth more than any review.
Leaving: the exit you plan on day one
Lock-in is rarely a contract. It is a pile of small dependencies: email on the host's mail servers, DNS at the host, a proprietary caching plugin, backups only in the host's own format. Each is easy to avoid at the start and painful to untangle later.
- Keep the domain registration at a separate registrar.
- Keep DNS somewhere you can export from, and keep a copy of the zone.
- Use standard tools: plain database dumps, ordinary file archives, a Git repository for custom code.
- Write down every scheduled job (cron) and every non-default server setting. The move that goes wrong is nearly always the one where somebody forgot a nightly job.
- Know the notice period and whether the host removes your data immediately when you cancel.
When you do move, lower the TTL on your DNS records a day ahead (the TTL planner shows how), copy the site, test it on the new server through the preview address, and only then switch DNS. Keep the old account for a week. The DNS guide explains why visitors reach the old and the new server on different days.
Loose ends
Do I need a VPS for a busy WordPress site?
Not necessarily. A well-cached WordPress site on good shared or managed hosting handles a lot of visitors, because most requests are served as static pages. A VPS helps when the work is dynamic: logged-in users, carts, searches.
Is it better to buy the domain and hosting from the same company?
It is convenient, and it makes leaving harder. Many people keep them apart. See choosing a registrar.
How long a contract should I take?
Take a month or a year first. Commit to three years only after the host has survived an outage and answered a ticket for you.
Does location matter?
For response time to a local audience, a little. A server on another continent adds 100 to 200 ms to each round trip, which is noticeable on pages that need many requests. A CDN covers static files; it does not move your database.
Before you sign
- You have written down what you run, your expected traffic, and who will do the maintenance.
- The type of hosting matches that workload.
- You have read the limits page, including processes, memory and inodes.
- You know the renewal price and the cost over the full term.
- Backups are off-server and you have restored one.
- Free, auto-renewing certificates are included.
- A real support ticket got a real answer, in a time you can live with.
- You know exactly how to export your data and leave.