Web Hosting Choices, Explained Honestly

Hosting is the part of a website budget that gets the least thought and produces the most regret. It is bought once, on price, usually during a rush to launch, and then renewed silently for years.

The market makes this harder than it needs to be. The same word — “hosting” — covers arrangements costing two pounds a month and four hundred, and the marketing pages describe both using identical vocabulary about speed and reliability.

What you are actually paying for

Strip away the branding and every hosting product is a bundle of five things in different proportions.

A slice of a machine. Processor time, memory and disk. On cheap plans this is shared with a large number of other sites, and the limits are enforced quietly.

Software management. Who patches the operating system, the web server, the PHP or Node runtime, and the database. On unmanaged plans, that is you.

Operational safety nets. Backups, one-click restores, staging environments, monitoring.

Support. Whether a human answers, how quickly, and whether they are permitted to look at your application or only at the server.

Network delivery. How close the machine is to your visitors, and whether a content delivery network sits in front.

Most price differences come down to the middle three. You are rarely paying for raw hardware. You are paying for someone else to be responsible when something breaks at eleven at night.

The main options, and who each suits

Shared hosting. Your site lives alongside many others on one machine. Cheap, adequate for low-traffic brochure sites, and genuinely fine for a great many small businesses. The drawbacks are noisy neighbours consuming resources you were nominally promised, limited control, and support that is optimised for volume rather than depth. Suitable when the site is simple and downtime for a few hours would be annoying rather than costly.

Managed platform hosting. A provider that specialises in one application — most commonly WordPress — and takes over updates, caching, security rules and backups. You pay several times the shared price and get back time and a smaller failure surface. It typically comes with restrictions: banned plugins, enforced caching behaviour, no arbitrary server-level configuration. Those restrictions are the product working as intended. Suitable when the site earns money and nobody internally wants to be a systems administrator.

Virtual private server. A guaranteed allocation of resources with root access. You can configure anything. You are also responsible for everything, including security updates, and an unmanaged VPS run by someone who does not maintain it is less safe than shared hosting. Suitable when you have a genuine technical requirement or someone competent to look after it.

Static and edge hosting. For sites built as static files — a Hugo, Astro or similar build deployed to a global network — there is no server application to patch and effectively nothing to compromise on the server side. Cheap, extremely fast, and a poor fit if you need server-side functionality that cannot be handled by an external service or a small function.

Cloud platforms. Infrastructure from the large providers is powerful and priced by consumption. Without someone watching the meter, small businesses regularly find that convenient defaults produce an uncomfortable invoice. It is a poor first choice for a brochure site.

Where the cheap deals make their money

An advertised price of a pound or two a month is a customer acquisition cost, not a business model. The margin is recovered in predictable places, and it is worth knowing them before you buy.

The introductory rate usually applies to the first term only, and renewal can be several times higher. Check the renewal price, not the headline, and check it for the term length you actually intend to buy.

Backups are often an add-on rather than an inclusion, and “we take backups” sometimes means “for our own disaster recovery”, which is not the same as being able to ask for yours.

Domain registration bundled free for a year can come with an inflated renewal, and moving a domain away later is occasionally made tedious.

Email hosting bundled with web hosting is common and rarely a good idea, because it ties two unrelated services together and complicates any future move.

None of this is dishonest, and cheap hosting is a legitimate product for a site that does not need more. It becomes a problem when a business assumes it bought resilience it never paid for.

Questions worth asking before you commit

• Can I get a full copy of my site and database whenever I want, without asking permission?
• What is the renewal price at the end of the introductory period?
• Is there a staging environment, and does it cost extra?
• What is the support channel and what hours does it cover? Is there a response commitment?
• Where are the servers physically located, and does that suit where my customers are?
• Can I add a content delivery network, or is one included?
• What happens if I exceed the resource limits — throttling, an overage charge, or a suspension?
• How do I leave? Is there a migration service, and what does it cost?

That last question is the most revealing one, and the answer often tells you more about the provider than anything on the sales page.

Signals that you have outgrown your plan

You do not need to move because a faster plan exists. You need to move when specific things start happening.

Time to first byte is consistently poor while the front end is already optimised, which points below the browser to the server itself. Traffic spikes — a campaign, a press mention, a busy Monday — cause errors or timeouts. You cannot get a staging copy to test changes safely. Support cannot help with anything beyond restarting the server. Or the site is now generating revenue that makes an outage genuinely expensive, which changes the arithmetic entirely.

Any one of those is a reason. Marketing copy about speed is not.

Moving without breaking anything

Migrations go wrong in predictable ways, and every one of them is avoidable.

Lower your DNS time-to-live a day or two before the switch so the change propagates quickly. Copy files and database first and test thoroughly on the new host using a temporary address before changing DNS. Keep the old environment running for at least a week rather than cancelling immediately. Handle email separately and deliberately, since MX records are not tied to web hosting and the classic migration disaster is a company losing mail for a day.

Preserve every URL exactly. If any address changes, map old to new with permanent redirects before launch, not afterwards. Then reissue certificates, confirm HTTPS across the whole site, and check that search engines can still crawl it — a staging site’s blocking directives being carried into production is a genuinely common and expensive mistake.

Choosing and moving hosting sensibly is part of website development, and the crawl and redirect side of a migration belongs with SEO services. If you are unsure whether your current plan is holding you back, get in touch.