How to Choose Web Hosting and Not Discover the Limits on the Day of Your Sale

You open the pricing page, and all three providers in the neighbouring tabs promise the same thing: 99.9% uptime, unlimited traffic, free SSL, 24/7 support and “fast SSD drives”. The prices differ by the cost of a coffee. The logical move is to take the cheapest one. The trouble is that the real difference between them is buried in the “Acceptable Use Policy” nobody opens, and in the support reply you’ll get at two in the morning while your site is down.

Hosting rarely comes up in a meeting while everything works. When it stops working, it turns out the backups were stored on the same server as the site, the account is registered to a former contractor, and the “unlimited” plan caps the number of files. Below are ten things worth checking before you pay, and for each one: what exactly to look for in the plan, which wording should make you wary, and how to check it yourself.

To keep things concrete, one hypothetical example runs through the whole article: a private dental clinic in Lviv. The site runs on WordPress, with online appointment booking, a blog with tips and email on its own domain, and the patients are mostly from western Ukraine. For this clinic, every minute of downtime can cost a missed booking.

Before you compare providers, decide on the type of hosting. Comparing a shared plan and a VPS on price is a bit like comparing a desk in a coworking space with a private office: both are “premises”, but the responsibility is different.

For our clinic, a sensible start is good shared hosting or managed WordPress hosting. A VPS makes sense once you need things shared hosting won’t allow: your own service to sync with the medical software, several sites, a heavy catalogue. And if nobody on the team will update and watch the server, an unmanaged VPS looks cheaper and ends up costing more.

Uptime is the share of time the server is available. The figures in ads look almost identical, so it helps to translate them into minutes. We count a month as 30 days (43,200 minutes) and a year as 365 days:

The difference between “three nines” and “four nines” is forty minutes of unavailability a month versus four. For a blog, that’s tolerable. For online booking on a Monday morning, it isn’t.

What to look for in the plan. The number guarantees nothing on its own unless there’s an SLA (Service Level Agreement) behind it. Open the SLA and find three things: how uptime is calculated (per month or per year, by the provider’s own monitoring or by any independent one), what doesn’t count as downtime, and what compensation you get if it’s breached.

What should make you wary. “We guarantee 99.9%”, but there’s no SLA at all. Scheduled maintenance “is not counted”, with no limit on how long it can last. Attacks, “upstream provider issues” and “force majeure” are excluded so broadly that almost any outage fits under them. You have to claim compensation yourself within a few days, and it’s a credit on your account worth a percentage of the monthly fee. Nobody will pay you back for lost customers: an SLA motivates the provider, but it doesn’t insure your business.

How to check it yourself. Connect a free external uptime monitor to your site that checks every 1-5 minutes and alerts you by email or messenger. After a month, you’ll have your own availability statistics. It’s also worth scrolling through the provider’s public status page with its incident history.

This matters for search too. Google says that 5xx server errors make its crawlers temporarily slow down crawling, and pages already in the index that keep returning an error are eventually dropped from it (Google Search Central). A short outage is nothing to fear. Hosting that goes down for a few hours every week slowly hurts both people and visibility.

How much space you need depends on the site. A clinic’s WordPress site with a blog and a few hundred photos usually fits into a few gigabytes. Most of the space goes to media files, email and backups, if they sit on the same account.

What to look for in the plan. Whether email counts towards the total disk quota. Whether backups take up space. The disk type (SSD or NVMe are noticeably faster than HDD on database queries). And above all: the inode limit.

An inode is, roughly speaking, one file or folder. Every photo in WordPress is stored in several sizes, every email in a mailbox can be a separate file, and a caching plugin creates thousands of small files. A site can use 3 GB out of “unlimited” and still hit the limit on the number of files. Then photos stop uploading, backups fail or email stops arriving, and it takes a week to find the cause.

What should make you wary. The word “unlimited” on the pricing page, and a line in the usage rules along the lines of “disk space is intended for website files only”, “the provider may restrict an account that uses more than the average level of resources” or “no more than N files”. There’s no such thing as unlimited hardware: the limit has simply moved from the plan into the rules.

How to check it yourself. Find the provider’s usage rules (Acceptable Use Policy, Fair Use) and search them for “inode”, “files”, “resources” and “limit”. If the site already exists, check the number of files and the total size including email in your current hosting control panel. Pick a plan with at least twice that as headroom.

Traffic caps are rarer on modern plans than they used to be, and most shared providers say “unmetered traffic”. But what usually brings a site to a halt is server resources, not gigabytes.

On shared hosting, each account gets a share of the processor (CPU), RAM, a number of simultaneous processes (known as entry processes) and database queries. When your ad works and three hundred people land on the site in a minute, these are exactly the limits you hit. Visitors see a 503 or 508 error, pages crawl, and the traffic is still formally “unlimited”.

What to look for in the plan. Specific numbers: how many CPU cores, how much memory, how many simultaneous processes, and the limit on script execution time. Good providers list them right in their plan comparison.

What should make you wary. The plan describes “up to 100,000 visitors a month” and says nothing about CPU or processes. Visitors are a marketing unit: a hundred thousand article views and a hundred thousand sessions in a shop with filters put very different loads on a server.

How to check it yourself. Ask support what happens when you go over: the site slows down, shows an error, the account gets blocked, or they offer a paid upgrade. If the control panel has a resource usage graph, look after a week of running the site at how close it gets to the ceiling.

Google takes page experience into account, but says itself that good scores don’t guarantee rankings (Google Search Central). For people, a slow site does damage more bluntly: they don’t wait. Hosting is responsible for the first part of loading, before the browser starts drawing the page.

The key metric here is TTFB (Time to First Byte), the time from the start of navigating to a page until the first byte of the response arrives. It includes redirects, the DNS lookup, setting up the connection and TLS, plus the time the server needs to prepare the page. According to web.dev, a TTFB of 0.8 seconds or less for 75% of visitors counts as good, and anything over 1.8 seconds is poor (web.dev).

What hosting affects:

• Server location. The closer the server is to your audience, the less time each round trip takes. For a clinic with patients in Lviv, a server in Ukraine or in a neighbouring European country will give lower latency than a server across the ocean. So looking for hosting in your own country makes sense when your audience is there, but what matters is distance and the quality of the network, not the flag.
• PHP version. WordPress recommends PHP 8.3 or newer, MySQL 8.0+ or MariaDB 10.11+ and HTTPS support (WordPress.org). As of October 2026, PHP 8.0 and 8.1 no longer receive even security fixes, and 8.2 will only receive them until 31 December 2026 (php.net). Hosting that runs an old version by default and won’t let you change it is slower and less safe.
• HTTP/2 and HTTP/3. HTTP/2 lets many files travel over a single connection. HTTP/3 runs on top of the QUIC protocol, speeds up setting up the connection and removes some of the delays on unstable mobile internet (RFC 9114, web.dev).
• Server cache. A ready copy of the page is served without running PHP and the database again. Find out which web server the host uses and whether it has its own cache, because that decides which WordPress caching plugin will make sense.
• CDN. A content delivery network keeps copies of files closer to visitors and noticeably cuts TTFB for people far away. Useful if your audience is spread across countries. A CDN won’t fix a slow backend.

What should make you wary. “Highly reliable SSD servers” without a single word about PHP, caching or where the data centre is.

How to check it yourself. Ask the provider for a test domain or a demo site on the same plan and run it through PageSpeed Insights several times at different times of day. Look at the “Reduce initial server response time” diagnostic. TTFB jumping between day and night shows how overloaded the server is by its neighbours. What to do with WordPress itself once the hosting is fine is covered in the article on how to speed up a WordPress site.

SSL certificate. HTTPS is mandatory for any site today, and especially for a booking form where people leave their name and phone number. You don’t need to pay for a standard certificate: Let’s Encrypt is a free, automated certificate authority (Let’s Encrypt). Its certificates are valid for 90 days, and Let’s Encrypt has already announced a gradual reduction to 45 days by 2028 (Let’s Encrypt, 2025). That’s why it matters that the host renews the certificate on its own, without you. A provider that sells “SSL” as a paid extra for a simple site is making money on what you don’t know.

Account isolation. On shared hosting, hundreds of other people’s sites live next to yours. Ask whether accounts are isolated from each other, that is, whether a hacked neighbouring site can reach your files. A proper answer is specific: separate system users, containers, access restrictions.

Updates. Who updates the operating system, the web server and PHP? On shared and managed WordPress hosting, the provider does. On an unmanaged VPS, you do. Also find out whether there’s protection against password guessing and scanning for malicious code.

Backups. This is where most of the surprises are. Questions you need answers to:

1. How often is a copy made: daily, weekly?
2. How many copies are kept, and for how long?
3. Do the copies include the database and email, not just the files?
4. Where are they stored: on the same server or in another data centre?
5. Can you restore the site yourself from the panel, and how much does it cost through support?

A backup on the same server disappears together with the server. So even if the provider makes copies, keep at least one copy of your own outside the hosting: in cloud storage or on a company drive.

And the main rule: a backup you’ve never restored isn’t a backup. At least once a quarter, restore the site from a copy to a test subdomain and check that the pages open, the booking form works and the photos are in place. It happens a lot that copies were created “successfully” for years, and when you try to restore one, the database inside turns out to be empty or truncated.

Everyone writes “24/7 support”. The real difference only shows when you write to them with a problem. So test the support before you hand over any money.

How to check it yourself. Send the provider’s chat or email a few specific questions and time how long the answer takes. Here’s a sample you can copy:

“Hello, we’re planning to move a WordPress site to you (about 4 GB including email). Could you tell us: 1) what the inode and simultaneous process limits are on plan X; 2) how often backups are made, where they’re stored and whether we can restore the site ourselves; 3) which PHP version is the default and whether we can change it; 4) whether you help with migrating the site and email, and whether that’s free of charge. Thanks!”

Judge three things: how long you waited, whether they answered all four points, and whether the answer is specific. “Our hosting is fully optimised for WordPress” in reply to a question about inodes is a bad sign. Numbers and links to documentation are a good one.

What to look for. Contact channels (chat, tickets, phone), the language of support, and the hours when real people answer. Whether there’s a public knowledge base with guides. Whether support helps with problems at the site level, or only with “the server is running, the rest is yours”.

Repeat the test on a Sunday evening: outages don’t keep office hours.

The price on a provider’s homepage is almost always a promotional one: on condition you pay several years in advance, and only for the first period. Renewal is usually more expensive, sometimes several times over. So compare plans by the full cost over two to three years.

What to look for. The renewal price (it should be stated in the plan or the terms). Whether a domain is included, and if it’s a “free domain”, for how long and what renewing it will cost later. Domain and hosting are separate services, and it’s better to register the domain so that it doesn’t depend on the hosting. Payment methods: card, bank transfer on an invoice for a company or sole trader, automatic renewal. For a company, it matters whether the provider issues proper documents for the accounts.

What should make you wary. A price shown as “from”, with a note in small print. Automatic renewal switched on by default at the full price. No refund for the unused period. Paid SSL, backups or PHP switching that other providers include in the plan.

Cheap hosting isn’t always bad, and expensive hosting isn’t always good. Compare using the list in this article.

Most hosts offer WordPress installation in one click, and for most business sites that’s enough. Check WordPress hosting against the same WordPress.org requirements: PHP version, database, HTTPS. It’s a good sign if the panel has staging (a test copy of the site), so you update plugins there first and not on the clinic’s live site.

If the site won’t run on WordPress but on another CMS or framework, check whether the plan supports the programming language, the database, scheduled tasks (cron), SSH access and Git you need. On managed WordPress hosting, you often can’t install any other software at all.

With website builders, the hosting is part of the platform, and you usually can’t take the site with you. How to choose the platform itself is covered in the article on how to choose a CMS for your website.

Not every provider offers a free trial; more often you get a guarantee that you can have your money back within a certain period. Both are useful if you actually test something during that time.

What to look for in the terms. How many days the trial or the guarantee lasts. Whether the refund covers all services (domains, paid licences and setup are usually not refunded). Whether you have to enter a card, and whether you’ll be charged automatically after the trial.

What to check during the trial:

• deploy a copy of your site and measure TTFB at different hours;
• restore the site from the provider’s backup;
• send and receive email on your domain, and check that messages don’t land in spam;
• write to support with the questions from section 6;
• look at the resource graphs after a few days of running.

If all you did during the trial was install WordPress and admire the control panel, the only thing you tested was the panel’s design.

Providers compete on bonuses. Some of them have real value; the rest just fill a column in the comparison table.

A separate word about email. For the clinic, booking confirmation emails have to reach the inbox. Check whether the host lets you set up SPF, DKIM and DMARC. Otherwise emails from the booking form risk getting lost.

Even hosting you chose well will need to change one day. What gets lost most often in a move is email and the DNS records everyone forgot about.

1. Take an inventory. Export all DNS records for your current domain: A, CNAME, MX (email), TXT (SPF, DKIM, verification for Google and other services). Write down which mailboxes exist.
2. Lower the TTL. A day or two before the move, reduce the caching time of your DNS records so the changes spread faster.
3. Move the site and check it before switching. Open the site on the new host through a temporary address or the hosts file and go through the key pages and the booking form.
4. Move email separately. Create the mailboxes in the new place, transfer the messages, and change the MX records only once everything is ready.
5. Switch DNS and don’t cancel the old plan straight away. Keep it for at least a week while the changes propagate and you check that everything arrived.

If page addresses or the platform change along with the move, SEO questions come in too: redirects, indexing, Search Console. Plan them before you switch DNS, not after the traffic drops.

The last check is about you. The hosting account and the domain registration should be in the name of the company or the owner, with a company email address that several people can access. A contractor can get separate access, but shouldn’t be the only owner.

A typical story: the site lived for years on the developer’s account, the developer disappeared, and with them went access to billing, backups and DNS. What to do if that has already happened, and which access to take back in advance, is covered here: The contractor disappeared. Who controls your website now?. And the article on how to choose a website developer will help you avoid this story at the stage of picking a team.

Web hosting is chosen by the fine print and by how real people in support respond. Before you pay, go through this short list:

• the hosting type suits the site and whoever will administer it;
• the uptime is backed by an SLA, and you’ve connected your own monitoring;
• you’ve found the inode, CPU and process limits in the usage rules;
• the PHP version is current and can be changed in the panel, and there’s HTTP/2 or HTTP/3 and a server cache;
• SSL is free and renews automatically;
• backups are daily, stored separately from the server, and you’ve already restored the site from one once;
• support answered specific questions specifically;
• you know the renewal price for two to three years and the terms for the domain;
• the account and the domain are in the company’s name.

If you’d rather not deal with all this yourself, write to us. We’ll look at your current site and hosting and tell you what on this list is already in order and what’s worth changing. You can start with a free website check, and if you’re only planning a site, take a look at how we approach building websites and online shops.