Guides / Hosting & Website Infrastructure
Decision guide
Hosting & Website Infrastructure
Where your website runs, and who is responsible when it breaks, matters more than the headline price. This guide explains the main hosting models, gives you a two-step framework for choosing between them, and lists what to check before you commit or move.
- Five situationsEach with a way into Solutions
- About 17 minutes11 sections, jump to any
- Informational guideNot personalised advice
The short answer
There is no best hosting type, only a best fit for what the site does and who will look after it. Start with the closest match below, then use the framework that follows to confirm it.
A small business site that rarely changes
Shared or managed hosting is usually enough. Put dependable backups, easy restores and a clear renewal price ahead of raw capacity.
A WordPress site that earns leads or publishes regularly
Managed WordPress hosting takes updates, caching and restores off your plate. A well-supported managed VPS or cloud plan is the alternative.
An online shop
Choose for checkout reliability and support response time, not just page speed. Managed ecommerce hosting, cloud or an actively managed VPS fit, with load tested before big campaigns.
A custom application, or a team with technical staff
VPS, cloud infrastructure or a platform-as-a-service give you control. Someone must own patching, backups and monitoring.
You are not sure
Prefer the option where the provider’s responsibilities are written down, you can restore backups yourself, and you can leave with a full copy of your files and database.
What hosting and website infrastructure cover
Hosting is the computing and storage that keeps a website available. At its simplest a web server is a computer running software that answers browser requests. A static setup sends files as they are; a dynamic setup adds an application server and a database that build pages on demand. Website infrastructure is everything around that:
- the server or platform that runs your site
- domain registration and DNS
- HTTPS certificates
- security controls and monitoring
Show 3 more
- backups and restore tools
- caching and content delivery
- email, which is usually a separate service (see Migration)
Providers bundle very different amounts of this, which is why two plans at the same price can differ sharply in who does the work. This guide is for owners and managers of company sites, online shops and content sites who need to choose, compare or move hosting without becoming systems administrators. It is general guidance and does not replace advice from your own developer or a provider’s documentation.
Choosing a hosting model: a two-step framework
Step 1 narrows the field by what the site does for the business. Step 2 decides how much of the operational work you want to carry yourself. Read together they show which models fit and where responsibility sits.
Step 1: match the situation
Show the table
| Situation | What usually matters most | Models to consider first | Watch out for |
|---|---|---|---|
| Simple brochure or company site | Low maintenance, reliable uptime, easy backups | Shared or managed hosting; managed WordPress if the site runs on WordPress | Paying for capacity you do not need; weak restore options; renewal price jumps |
| WordPress publishing or content site | Performance under caching, updates, security, staging | Managed WordPress, or a well-supported managed VPS or cloud plan | Plugin-heavy sites on minimal plans; unclear responsibility for updates and backups |
| Online shop | Checkout reliability, peak-traffic capacity, security, support response time | Managed ecommerce or WordPress hosting, cloud, or an actively managed VPS | Traffic spikes; caching that breaks carts; “unlimited” plans with hidden limits |
| Higher-traffic commercial site | Scalability, CDN, monitoring, predictable performance | Cloud or scalable managed platforms; dedicated servers for specific needs | Scaling that is possible but not automatic; cost surprises under load |
| Custom application | Control of runtime and stack, deployment workflow, databases, observability | VPS, cloud infrastructure or a platform-as-a-service | Underestimating operational work; no plan for patching and backups |
| Agency or multiple-site environment | Isolation between sites, bulk management, billing structure, client transfers | Managed multi-site plans, or cloud/VPS with a management layer | One compromised site affecting others; unclear terms for handing sites to clients |
Step 2: decide who carries the work
Every model divides the same jobs differently. This table shows the typical split: Provider means the host normally does it, You means you or your developer must. “Managed” and “cloud” are used loosely across the industry, so confirm each row in the provider’s written terms.
Show the table
| Job | Shared | Managed | Managed WordPress | VPS (unmanaged) | Cloud infrastructure | Dedicated (unmanaged) |
|---|---|---|---|---|---|---|
| Hardware and data centre | Provider | Provider | Provider | Provider | Provider | Provider |
| Operating-system and server-software patching | Provider | Provider | Provider | You | You | You |
| Website software updates (CMS, plugins) | You | Varies | Provider for core, You for plugins | You | You | You |
| Security monitoring and firewall | Provider (basic) | Provider | Provider | You | You, using provider tools | You |
| Backups and restores | Varies | Provider | Provider | You | You | You |
| Caching and performance tuning | You, limited controls | Provider | Provider | You | You | You |
| Handling a traffic spike | Upgrade or move | Plan upgrade | Plan tier | You resize or move | You configure scaling | You; fixed hardware limits |
| What support covers | Server and account | Server and platform | Server, platform and WordPress basics | Infrastructure only | Infrastructure only | Hardware only |
How to use the two tables
Shortlist two or three models from Step 1, then read those columns in Step 2. If you would not want to do a row yourself, choose a model where it says Provider and get that promise in the contract, not just on the sales page.
Where this shows up in Solutions
Six common models and their trade-offs
The labels are used loosely across the industry. Ask any provider to say exactly what is included and who is responsible for what.
Shared hosting
Many websites share one server’s resources, and the provider looks after the server.
Suits: small, low-traffic sites and tight budgets
Trade-off: performance can depend on neighbouring sites; limited configuration; resource caps described as “fair use”.
Managed hosting
The provider handles server maintenance and security patching, and often backups and monitoring.
Suits: businesses that do not want to run servers
Trade-off: higher price and less flexibility; the scope of “managed” varies, so check what is actually included.
Managed WordPress hosting
Managed hosting tuned for WordPress, typically with platform-level caching, automatic core updates, staging and WordPress-specific support.
Suits: business sites and publishers on WordPress
Trade-off: restrictions on plugins and configuration; no help for non-WordPress sites; pricing often tied to visits or number of sites.
VPS (virtual private server)
A dedicated allocation of a server’s resources with administrator-level control.
Comfortable managing a server yourself? See when a self-managed server makes sense.
Suits: custom setups and teams with systems-administration skills
Trade-off: someone must secure, patch and back it up unless the plan is a managed VPS.
Cloud hosting
Resources are drawn from a pool of infrastructure that can scale. It ranges from simple managed platforms to raw infrastructure.
Suits: variable traffic, growth and custom architecture
Trade-off: costs can vary with usage; more complexity; “cloud” is used loosely, so check what scales automatically and what does not.
Dedicated server
A whole physical server for one customer.
Suits: specific performance, compliance or isolation requirements
Trade-off: cost; responsibility for hardware and management unless managed; scaling is slower.
Where this shows up in Solutions
Two plans at the same price can differ sharply in who does the work.
What to evaluate: twelve questions
These questions separate providers more usefully than headline specifications. Apply them to any option you are considering, and record the answers in writing.
Reliability and uptime
Look for a stated uptime commitment, how and over what period it is measured, and what remedy applies if it is missed. The remedy, the exclusions and any public status history tell you more than the percentage. See “Reading an uptime promise” below.
Support
Check hours, channels and who answers: frontline staff or engineers. Find out whether support covers your application or only the server. A technical pre-sales question is a fair test of what you will get later.
Backups and restoration
Ask how often backups run, how long they are kept, where they are stored and whether you can restore them yourself. A backup that has never been restored is a hope, not a plan. See Backups and recovery.
Security
Look for a web application firewall, malware scanning, isolation between accounts, HTTPS certificates and a clear split of who patches what. Turn on two-factor authentication for the hosting account itself, and check that the software version you run is still supported.
Performance
Server hardware and software stack, server-side caching, current runtime versions and distance to your visitors all matter. Test real pages, not just the home page. See Measuring performance.
CDN and edge delivery
A content delivery network stores copies of static files on servers closer to visitors and takes load off your own. Check whether one is included and how its rules treat dynamic pages such as carts and logins.
Scalability
Find out what happens when traffic doubles: does the plan scale automatically, need a manual upgrade, or require a migration? Ask about resource limits and overage charges.
Staging and deployment
A staging copy lets you test updates before customers see them. Check whether it is included and how changes are moved to the live site.
Data-centre location
Location affects speed for your visitors and can matter for data-protection duties. Check where site data and backups are stored, and read the provider’s data-processing terms. Data-protection laws in many countries regulate how personal data is handled, and some restrict where it can be stored or transferred; take qualified advice on what applies to you.
Pricing and renewals
Compare the renewal price and term, not just the introductory rate. Note any charges for backups, certificates, migration or extra resources. See How hosting costs are structured.
Contract, exit and portability
Check the term, refund conditions and notice periods, and how easily you can export a full copy of files and database. Standard technology stacks are easier to move than proprietary ones.
Migration assistance
Some providers migrate sites for free, some charge, and some only supply instructions. Ask what is covered, who does the testing and what downtime to expect.
Reading an uptime promise
An uptime percentage sounds precise but hides how much downtime it permits. This is simple arithmetic on a 365-day year; providers often measure monthly and exclude scheduled maintenance, so read the terms.
Show the table
| Stated uptime | Downtime allowed per year | Roughly per month |
|---|---|---|
| 99% | about 3.65 days | about 7.3 hours |
| 99.9% | about 8.8 hours | about 44 minutes |
| 99.99% | about 53 minutes | about 4.4 minutes |
Measuring performance, and staying current
Hosting influences how quickly a server starts to respond, and that is only one part of how fast a page feels. Google’s web.dev defines Time to First Byte (TTFB) as the time from starting navigation to the first byte of the response arriving. It treats 0.8 seconds or less as good, 0.8 to 1.8 seconds as needing improvement, and more than 1.8 seconds as poor. TTFB matters more for some site architectures than others, and it sits inside the three Core Web Vitals that measure the whole experience: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, judged at the 75th percentile of real visits.
Show the table
| Hosting can change | Hosting usually cannot change |
|---|---|
| Server response time and caching | Oversized images and video |
| Runtime version and server configuration | Heavy third-party scripts and tags |
| Distance to visitors, through location and CDN | Slow theme or plugin code |
| Capacity under load | Layout that shifts as the page loads |
Test the pages that earn money, not only the home page, and repeat the test from where your visitors are. Also check the software version your plan runs. As of 30 September 2026 the PHP project lists PHP 8.4 and 8.5 as actively supported, 8.2 and 8.3 as receiving security fixes only, and 8.0 and 8.1 as no longer supported, while WordPress.org recommends PHP 8.3 or greater. These dates move, so check the current lists rather than relying on this page.
A content delivery network can help with distance and load. MDN describes one as a group of geographically distributed servers that store copies of data and answer from the location nearest the user. It also lists the trade-offs: a third-party dependency, a possible attack path if the CDN is compromised, and extra connections that can cost speed.
How hosting costs are structured
Price lists change constantly, so this guide gives no figures. What lasts is the structure of what you pay for:
- Base plan. Often discounted for a first term, then charged at a higher renewal rate.
- Limits that trigger upgrades. Visits, storage, bandwidth, CPU or number of sites.
- Add-ons. Backups, staging, CDN, malware removal, extra email or higher support tiers may cost extra.
- Usage-based charges. Common on cloud infrastructure, where traffic spikes change the bill.
- Your time or a contractor’s. Self-managed models trade a lower fee for patching, monitoring and restore work.
- The cost of leaving. Migration effort, contract terms and proprietary features.
To compare two options fairly, price each over three years, at renewal rates, with the add-ons you actually need, and include the hours someone will spend running it.
Online shops raise the stakes
An online shop turns hosting problems into lost revenue, so several of the criteria above carry more weight. This section covers the hosting side; the Ecommerce Platforms & Infrastructure guide covers platform choice, payments and operations.
- Checkout reliability. Cart, checkout and payment steps are dynamic and cannot be served from a simple page cache. Ask how the platform behaves for these pages under load.
- Traffic spikes. Campaigns and seasonal peaks can multiply traffic. Understand the capacity, any throttling and the cost when traffic surges, and consider a load test before a major launch.
- The cost of downtime. A rough figure for what an hour offline costs you helps decide how much better support or redundancy is worth.
- Caching rules. Page and object caching help, but rules must exclude cart, checkout and account pages, and they need testing after each change.
- Security. Stores hold customer accounts and order data. Look for a firewall, prompt patching, an isolated environment and protection for the admin area.
- Card-payment rules. Card data is governed by PCI DSS. Using a provider-hosted payment page can reduce how much falls on you, but responsibilities remain, so confirm them with your payment provider and acquirer. This page is not compliance advice.
Where this shows up in Solutions
Backups and recovery
The US Cybersecurity and Infrastructure Security Agency’s guidance for small and medium businesses is a good baseline: keep three copies of important files, on two different types of storage, with one copy off-site. Back up automatically and regularly, protect the copies with encryption and physical security, keep some offline, and test that you can restore both everything and individual files, including rolling back at least seven days.
For a website, put that into questions for your provider and yourself:
- Where are backups stored? A copy in the same account as the site is not an off-site copy.
- How often do they run, and how long are they kept?
- Can you restore a single file, a database or the whole site yourself, and how long does that take?
- Who has tested a restore, and when?
- What does restoring cost, if anything?
Migration planning
Moving a site is mostly planning. A calm, tested move takes little time; a rushed one is where most problems appear.
- Take stock. List the site files, databases, domain and DNS records, third-party integrations, scheduled jobs and certificates.
- Choose the timing. Pick a quiet period, and pause content changes and orders during the cutover.
- Build and test the copy first. Check the new environment before it goes live, using a temporary address or a preview method your provider supports.
- Plan the switch deliberately. Where the website’s DNS records must change, agree who changes them and when. Expect a short period when some visitors still reach the old site.
- Verify. Test forms, checkout, redirects, HTTPS and performance on the new host before you announce anything.
- Keep the old environment for a fallback period before cancelling it.
If your URLs change during the move, Google’s site-move guidance applies: map every old URL to its new one, use permanent server-side redirects (301 or 308), remove any noindex or crawl blocks used during development, keep the redirects for at least a year, and monitor for errors afterwards.
Website hosting and email are separate systems
Your website’s hosting and your business email are usually handled by different services, even when one provider sells both. Moving a website should not require changing where email is delivered. DNS records that control email should be left as they are unless you are deliberately moving email, which is its own project with its own testing. If you are unsure which records affect email, ask your provider or IT adviser before changing anything.
When managed hosting may make sense
A managed service tends to earn its price when one or more of these is true:
- An hour of downtime costs the business more than the price difference.
- There is no in-house technical capacity for updates, security and restores.
- You need backups, security monitoring and performance tuning that you would rather not run yourself.
- Traffic and performance requirements are growing.
- Maintenance is consuming time better spent elsewhere.
Managed is not automatically better. If you have technical staff, specific software requirements, or a stable low-risk site, a lightly managed or unmanaged option can fit well. The deciding question is who is responsible, and how quickly, when something breaks.
Common mistakes and warning signs
- Choosing on introductory pricing alone. The renewal price is what you will pay for most of the relationship.
- A weak or unclear backup policy, or no practical way to restore quickly.
- Assuming “unlimited” means unlimited. Read the fair-use terms and limits on CPU, memory, processes and files.
- Support that is hard to reach or excludes the application you actually run.
Show 4 more
- An unplanned migration, with no test copy and no fallback.
- No monitoring, so problems are found by customers first.
- Running software versions that are no longer supported.
- Mixing website and email migration. Treat them as separate projects.
Frequently asked questions
Is more expensive hosting always faster?
No. Price reflects support, management and capacity as well as raw speed. Real-world performance depends on the software stack, caching, page weight and where your visitors are. Measure your own site rather than relying on plan names.
Do I need a CDN?
Not always. A content delivery network helps most when visitors are spread across regions, pages carry heavy images or downloads, or traffic is spiky. Many hosts include a basic one. Check how it treats dynamic pages before relying on it.
What is the difference between backups and staging?
Backups are copies you restore after something goes wrong. Staging is a test copy you use before changes go live. They solve different problems, and ideally you have both.
How often should backups run?
It depends on how often your data changes. A rarely edited brochure site may be fine with daily backups. A shop taking orders may need more frequent database backups. Keep at least one copy outside the hosting account.
Can I move hosts without downtime?
Often with very little visible downtime if you prepare, but a guarantee of none is unrealistic. Plan for a short cutover window and verify everything afterwards.
What does “managed” actually mean?
It varies by provider. Ask for a specific list of what they manage, such as operating-system patching, application updates, security monitoring, backups, restores and performance tuning, and what remains your responsibility.
Should hosting, domain and email come from the same provider?
It is convenient, but keeping them separate can make changes and recovery simpler. Whatever you choose, know where your domain registration and DNS are managed, and who has access to each.
How often is this guide updated?
We review it when material information changes, and the review date is shown at the top. See How We Evaluate for the approach.
Ready to compare available providers?
This guide explains the decision. When you are ready to shortlist by business need, see Hosting Solutions.
Sources and method
Sources and how we work (9 sources)
This guide is based on public documentation, standards and published sources, and on general industry practice. Provider claims, public documentation, published sources and our own observations are kept distinct, and where we have directly tested or used something, we say so explicitly. This guide names no products as recommendations. Facts that change, such as software support dates, are dated where they appear. Sources used:
- MDN Web Docs: What is a web server? Static and dynamic servers; what hosting provides.
- MDN Web Docs: CDN Definition, benefits and downsides.
- web.dev: Time to First Byte Definition and thresholds.
- web.dev: Web Vitals Core Web Vitals metrics and thresholds.
- php.net: Supported versions Active and security-only support status, checked 30 September 2026.
- WordPress.org: Requirements Recommended PHP version and hosting notes, checked 30 September 2026.
- CISA: Back up business data The 3-2-1 approach, protection and restore testing.
- Google Search Central: Site moves with URL changes Redirects, testing and monitoring.
- OECD: Privacy principles Internationally recognised principles for handling personal data.
Read How We Evaluate for our criteria and the limits of what we claim. If you spot an error or an omission, please email info@kybervega.com.