What is web hosting in simple terms?

Web hosting stores your website’s files and makes them accessible over the internet. A server processes requests and returns pages and other assets to visitors. You pay for resources such as CPU, RAM, storage and bandwidth; whether software setup and server management are included depends on the service.

How do domain, DNS and hosting differ from each other?

A domain is the human-friendly name visitors use. DNS maps that name to the address of the infrastructure serving your site. Hosting provides the resources that store and deliver the website. Domain registration, DNS and hosting can come from different providers, provided their settings work together.

Do I really need SSL for my website?

Use HTTPS to protect data in transit, including logins, forms and checkout information. Modern HTTPS uses TLS, although certificates are still commonly called SSL certificates. A valid certificate helps authenticate the connection, not the trustworthiness of the site’s content. If a CDN terminates TLS, its connection to your hosting server needs separate protection. Check which certificate options your plan supports.

What type of hosting should I choose: shared, VPS or dedicated?

Shared hosting can suit smaller sites whose workloads fit the plan. A VPS offers more control and custom software options, but CPU sharing and management responsibilities vary. A dedicated server gives you an entire physical machine; colocation provides data-center facilities for hardware you own. Choose according to workload, resource headroom and your ability to manage the system—not traffic alone.

Why does my site show DNS or SSL errors after moving servers?

Check that the domain uses the intended nameservers, its A/AAAA records point to the correct addresses, and the destination has a valid certificate for every hostname used. Old DNS answers can remain cached until their TTLs expire. Lowering TTLs sufficiently before a cutover can shorten delays, but does not update every resolver instantly. Also check HTTPS redirects and mixed content.

How Web Hosting Works: Domain, DNS, Server and TLS

What Is Web Hosting, Really?

When people ask “What is web hosting?” they are usually trying to understand one simple thing: how a website they see in a browser is actually stored and delivered from somewhere in the world. You type a domain name, hit Enter, and a few seconds later a complete page appears with text, images, forms, and maybe even a checkout. Behind that simple moment, several layers work together: your domain name, DNS, the web server, and SSL/TLS encryption.

In this article, we will walk through that journey step by step in a visual, down-to-earth way. Think of it as following a single request from a visitor’s browser, through the internet, all the way to your hosting server and back again. You will see where each piece fits, what you actually buy when you purchase “hosting”, and how to avoid common mistakes that cause errors like “site not found” or “Not secure” warnings. By the end, you will be able to look at your own setup and confidently say: I know exactly what is happening under the hood.

How Domain, DNS, Server and SSL Fit Together (The Big Picture)

Before going deep, let us build a simple mental diagram of how everything connects. Imagine four main blocks:

Domain – the human-friendly name (example.com)
DNS – the internet’s phonebook that tells browsers which server to call for that domain
Hosting server – the machine (shared hosting, VPS or dedicated server) that stores your website files and database
SSL/TLS – the encryption layer that protects communication between visitor and server; modern HTTPS uses TLS, though “SSL” remains a common label

For a fresh page load over HTTPS, these four blocks form a simplified pipeline; cached DNS answers, cached content and existing connections can skip some steps:

Browser asks DNS: “Where is example.com?”
DNS replies with the server’s IP address.
Browser connects to that IP.
TLS establishes encryption before the browser asks for a page over HTTPS, protecting the exchanged data against network eavesdropping and tampering.
Server sends back HTML, images, CSS, JavaScript, etc., which the browser renders as your page.

A typical website setup combines a domain registration, DNS configuration pointing to the site’s infrastructure, and hosting. Hosting options include shared hosting, a VPS or a dedicated server; colocation instead supplies facilities for hardware you own. These services need not come from the same provider. TLS protects data in transit over HTTPS, including logins, contact forms and checkouts.

Step-by-Step: What Happens When Someone Visits Your Website

To really understand what web hosting is, it helps to “zoom in” on a single page load. Here is the journey in concrete steps.

1. The Visitor Types Your Domain

A visitor types www.yourbrand.com into their browser. The browser needs a server address (IP) for that name, which it may already have cached.

2. DNS Lookup: Turning Domain into IP

The browser asks the DNS system: “What is the IP address for www.yourbrand.com?” DNS is a distributed database spread across many servers worldwide. Your domain’s DNS records live wherever your nameservers are set – either at your registrar, a DNS provider or at your hosting provider.

For example, you might have an A record:

www.yourbrand.com.  IN  A   203.0.113.10

This illustrative record maps www.yourbrand.com to 203.0.113.10. That IP is reserved for documentation; use your actual server address in a live record. If you want a deeper dive into all the record types, you can read our guide DNS records explained like a friend: A, AAAA, CNAME, MX, TXT, SRV and CAA.

3. Browser Connects to Your Hosting Server

Now the browser knows the IP, so it connects to your hosting server or an intermediary such as a CDN. The hosting server behind the site could be:

A server providing shared hosting
A VPS you manage yourself or have managed under a separate service arrangement
A full dedicated server or a colocation machine you own in a data center

Web server software (usually Apache, Nginx or LiteSpeed) commonly listens on port 80 for HTTP and 443 for HTTPS. For HTTPS, TLS is established before the browser sends the HTTP request.

4. SSL/TLS Handshake: Setting Up Encryption

If your site is https://www.yourbrand.com, the browser expects a secure, encrypted connection. It starts a TLS handshake:

Browser says “Hello, I want to talk securely. Here are the encryption methods I support.”
Server replies with its SSL certificate and chooses compatible encryption methods.
Browser verifies that the certificate is valid, signed by a trusted Certificate Authority (CA), and matches the domain.
They agree on keys and establish an encrypted tunnel.

A successful handshake establishes the protected connection used by HTTPS. The browser’s connection indicator varies; it does not establish that the site’s content is trustworthy. For fundamentals around certificates, you can also check our article what an SSL certificate is and ways to secure your website.

5. HTTP Request: Asking for a Page

Once encryption is in place (for HTTPS), the browser sends an HTTP request like:

GET /products HTTP/1.1
Host: www.yourbrand.com
User-Agent: ...

The Host header is important because many domains can share the same IP on a shared hosting or even VPS. The web server uses this to decide which website configuration to use.

6. Server Response: PHP, Database, Files and Caching

Your web server processes the request. What happens depends on your stack:

Static sites: server simply reads HTML/CSS/JS files from disk and returns them.
PHP apps (WordPress, PrestaShop, Laravel, etc.): the web server passes requests needing PHP execution to a PHP handler, such as PHP-FPM; PHP may query the database, load templates, and render HTML.
Caching layers: Nginx FastCGI cache, LiteSpeed Cache or a CDN may serve a cached version without running PHP every time.

These workloads explain the resources you pay for when you buy hosting: CPU, RAM, storage (often SSD/NVMe) and bandwidth. A software stack processes the requests; whether the provider installs and manages it depends on the service, particularly for unmanaged servers. If you want to go deeper into how server optimisations affect speed, our article on server-side secrets that make WordPress fly is a good follow-up.

7. Browser Renders the Page

The server sends back an HTTP response with HTML, and the browser loads the needed assets (CSS, JS, images, fonts). Some may already be cached or deferred until needed. Assets fetched over the network use further requests, reusing an existing connection where possible. The visitor sees your site and interacts with it, unaware of all the moving parts.

Deeper Look at Each Piece

Now that you have seen the flow, let us zoom in on each part – domain, DNS, server and SSL – and clarify what you actually configure and pay for.

Domain Name: Your Human-Friendly Address

Your domain is the brand label that people remember and type. When you register a domain, you are essentially renting the exclusive right to use that name for a period (usually one year at a time, renewable).

Key points about domains:

Registrar vs registry: a registrar handles registrations with the registry responsible for a top-level domain, such as .com or a country-code extension. A domain seller may instead be a reseller working through a registrar.
Expiration: if you forget to renew, your site can go offline and the domain may eventually become available to others.
Multiple domains: you can point several domains to the same website with redirects or parked domains.

If you want to see what to do right after buying a domain, including DNS and SSL steps, have a look at our checklist for the first 30 days after buying a domain.

DNS: The Phonebook That Knows Where Your Site Lives

DNS (Domain Name System) maps names like www.yourbrand.com to IP addresses. In practice, when you log into your panel or DNS manager, you manage records like:

A – IPv4 address of your server
AAAA – IPv6 address
CNAME – alias that points one name to another
MX – mail servers for your domain
TXT – verification, SPF, DKIM and other text data

Where DNS lives depends on your nameserver settings. You can:

Use your hosting provider’s nameservers and DNS panel, if DNS hosting is included.
Use external DNS and point A/AAAA records to your hosting server’s IPv4/IPv6 addresses, as applicable.

If you want to run your own nameservers on a VPS or dedicated server, we explain the process step-by-step in our friendly guide to private nameservers and glue records.

Web Hosting Server: Where Your Site Actually Lives

Web hosting is the service of storing your website files and making them accessible over the internet, with the aim of continuous availability. Common hosting arrangements include:

Shared hosting – multiple websites share a single server; ideal for small to medium sites.
VPS (Virtual Private Server) – your own isolated virtual server with allocated resources; whether CPU capacity is shared or dedicated depends on the plan; suitable for more control and higher traffic.
Dedicated server – an entire physical server dedicated to you.
Colocation – you bring your own hardware to a data center that supplies rack space, power, cooling and network connectivity.

The core job of your hosting is to:

Store your code, media, and database safely.
Serve content fast when visitors request pages.
Stay online with high uptime, monitored and maintained.

Our article what a data center is and why it matters for web hosting explains the physical side: power redundancy, cooling, network connectivity and security – all of which directly affect your hosting quality.

SSL/TLS: Protecting Data in Transit with HTTPS

TLS, the modern successor to SSL, encrypts data on the connection between the browser and the TLS endpoint, such as your server or a CDN. Ordinary HTTP sends submitted data in plain text. Properly configured HTTPS protects that data from passive interception on the encrypted connection; if a CDN terminates TLS, its connection to your server needs separate protection.

An SSL certificate contains:

Information about your domain (and sometimes your organisation).
The public key used to authenticate the server during the TLS handshake.
The issuer’s digital signature, which browsers validate as part of checking the certificate’s trust chain.

When choosing hosting, check whether the plan lets you:

Use free, automated SSL certificates (for example via ACME/Let’s Encrypt), including for e‑commerce sites that need domain validation.
Install commercial DV/OV/EV certificates when you need a vendor’s support or a particular level of identity validation, rather than stronger encryption merely because a certificate is paid.

For a deeper comparison between free and paid options, see our guide comparing Let’s Encrypt and commercial SSL for e‑commerce and enterprise.

Common Real-World Setups (And Which One You Actually Need)

Now let us translate the theory into illustrative hosting scenarios.

Scenario 1: Simple Business Site on Shared Hosting

This is a common starting point:

You register yourbrand.com with a registrar.
You select a DNS provider, set its nameservers at the registrar, and create or verify the A record pointing to the shared hosting server.
Your website runs on WordPress or a similar CMS.
You configure a valid TLS certificate and enable HTTPS; free certificate automation is an option if supported by the plan.

This setup can suit small businesses, portfolio sites, blogs and landing pages, depending on traffic and application demands. The provider manages the shared server infrastructure; site owners still need to manage content, application updates and any other tasks not covered by the plan.

Scenario 2: Growing Project on a VPS

Later, you may move to a VPS when you need more control or custom software. Size the plan for your workload rather than assuming a VPS guarantees predictable performance. In that case:

Domain: stays the same and can remain at the current registrar.
DNS: your A/AAAA records are updated to the VPS IP instead of the shared hosting IP.
Server: you configure the web server (Nginx/Apache), PHP, database and TLS yourself, or arrange server management under a separate or included service.

The domain and DNS do not fundamentally change – they just start pointing to a new “home”. Our article on moving from shared hosting to a VPS with zero downtime describes the process in detail.

Scenario 3: Separate Hosting and DNS Provider

For example, you might host your site on a VPS or dedicated server, but keep DNS elsewhere (for example, at a DNS-only provider or an external service). In that case, you:

Set your domain’s nameservers to the external DNS provider.
Create A/AAAA records there, pointing to the hosting server’s IPv4/IPv6 addresses, as applicable.
Still manage hosting, SSL and server configuration through the hosting panel or directly on the server.

This is perfectly valid, but it adds an extra panel to manage. Consolidating domain, DNS and hosting with one provider can simplify administration; keeping them separate can give you more flexibility when changing hosts.

Scenario 4: Multi-Site or Multi-Brand Architecture

Agencies and larger businesses often run multiple sites on one or more servers. For example:

One appropriately sized VPS hosting, for illustration, 10–20 client WordPress sites; capacity depends on each site’s workload.
Each client has their own domain, sometimes registered at different registrars.
DNS for each domain points to the same server IP. The web server’s virtual-host configuration selects the site, while TLS configuration supplies a certificate valid for the requested hostname.

When you understand the domain → DNS → server → SSL chain, managing dozens of sites feels less mysterious. Our hosting architecture guide for agencies illustrates this kind of setup.

Practical Checklist Before You Launch or Migrate a Site

Here is a short, practical checklist you can adapt for your own launches or migrations.

1. Domain and Registrar

Is the domain registered and not about to expire?
Do you have access to the registrar panel and email address on file?

2. Nameservers and DNS

Are the domain’s nameservers set to the intended DNS provider? Moving hosting alone does not require changing nameservers. If you also move DNS hosting, prepare the necessary records at the new DNS provider before changing delegation.
Are A/AAAA records pointing to the correct server IP? Publish an AAAA record only when IPv6 access is configured, and verify that the site works over IPv6 as well as IPv4.
Do you have any legacy or conflicting records that could cause problems (old IPs, wrong CNAMEs)?
If email stays with its current provider, have you preserved its MX records, the address records used by those MX targets, and email authentication records? Leaving MX unchanged alone may not preserve email service.

If you are planning a cutover from an old server to a new one, lower the relevant DNS TTLs in advance and allow the previous TTLs to expire before switching addresses. This can shorten cache-related delays, but does not make every resolver update instantly. Our article the TTL playbook for zero-downtime migrations walks through this.

3. Hosting Plan and Server Resources

Does your chosen plan (shared, VPS, dedicated, colocation) match expected traffic and complexity?
Is there clear headroom in CPU, RAM and disk IO for peaks or future growth?
Is backup configured (daily/weekly, plus offsite if needed)?
Who installs and updates the operating system, web server, application runtime and database? On unmanaged servers, you or your administrator must complete this setup and configure the firewall.
Before changing public DNS, have you installed or transferred the application and database, configured the domain’s virtual host and document root, and tested the destination? Use the provider’s preview method or a local name-resolution override on your test device to check the intended hostname, required services and core application functions. This does not replace the HTTPS checks below.
For a migration, keep the old and new servers ready during the transition and plan content synchronization. Lower TTLs alone do not guarantee an uninterrupted cutover.

4. SSL Certificate and HTTPS

Is an SSL certificate installed and valid for all domains and subdomains you will use? Meet the certificate provider’s domain-validation requirements and establish a renewal method.
Have you verified HTTPS access before enabling automatic HTTP-to-HTTPS redirects (301 redirects)?
Have you checked for mixed content (HTTP images/scripts on HTTPS pages)?
When migrating, prepare and test the production-domain certificate on the destination before the DNS cutover where possible. A certificate valid only for a staging hostname may not cover the live domain. If advance setup is not possible, account for the resulting availability risk in the migration plan; complete HTTPS checks before announcing a new site to visitors.

If you are moving a site from HTTP to HTTPS, follow our full HTTPS migration guide with 301 redirects and HSTS to reduce migration-related SEO risks.

5. Application and Database

Is your CMS or application configured with the correct domain and database credentials?
Have you set appropriate PHP limits (memory, execution time, upload size) for your app?
Is caching enabled (page cache, object cache, opcode cache) to reduce server load?

For PHP-based sites, our article on choosing the right PHP memory_limit, max_execution_time and upload_max_filesize gives concrete starting values and trade-offs.

6. Monitoring and Security Basics

Do you have uptime monitoring configured (so you know if the site goes down)?
Is a basic firewall in place, and are admin panels protected (strong passwords, 2FA where available)?
Are automatic updates or at least update notifications enabled for your CMS and plugins?

Bringing It All Together

Web hosting is not just “somewhere in the cloud”. It is a very concrete chain of components that have to line up perfectly: a domain name people can remember, DNS records that correctly map that name to the right IP, a reliable hosting server in a solid data center, and an SSL/TLS layer that protects data in transit between the browser and the TLS endpoint. When any link in this chain is misconfigured or missing, you see familiar problems: the domain does not resolve, the wrong server answers, or the browser shows a big “Not secure” or certificate warning.

When you understand the big picture above, you can describe the issue more precisely to support: “I think this is a DNS issue” or “My SSL is installed but HTTP is not redirecting.” These distinctions can help support narrow down the cause.

If you are planning a new project or a migration, feel free to treat this article as a checklist. Start with the question “What exactly is hosting for this site?” and trace the full line from domain to DNS, to server, to SSL. Once those four pieces are in place and monitored, you have a stable foundation to grow on – whether you are running a simple business site, a busy WooCommerce store, or a custom application on a VPS or dedicated server.