What is web hosting? It is renting space and computing power on an always-on server in a data center that is wired to the internet. Your site's files and database live there, and a web server program such as nginx or Apache sends them to every visitor's browser. The domain is only the name; hosting is the machine behind it.
What is web hosting in plain words
A website is a pile of files: HTML pages, images, stylesheets, scripts, and usually a database plus code in PHP, Python or JavaScript. For anyone other than you to see those files, three things have to be true at the same time.
- A computer that never switches off. A laptop sleeps, loses Wi-Fi and goes on vacation with its owner. A site hosted on it is available exactly that often.
- A permanent address on the network. Home connections usually hand out a dynamic IP, and often an address behind the provider's shared gateway (carrier-grade NAT) that nobody can reach from outside.
- A running web server program. nginx, Apache or Caddy accept the HTTP request and build the response. Files on their own answer nobody — something has to serve them.
Hosting is renting that computer, or a slice of it, together with the operations around it. You pay a provider; the provider keeps the hardware powered, cooled and connected to upstream networks, swaps dead drives, and makes sure all of it still works at night, on holidays and during a power grid failure.
The analogy that mostly holds: a domain is the address on the sign, hosting is the actual room with shelves, lights and a door to the street. You can move the sign to a different room in an evening. The stock has to be physically carried across.
What you are actually renting
"Hosting" is not one service but a bundle of five. The gap between a cheap plan and an expensive one is not "how many megabytes" — it is how many of these are guaranteed versus supplied on a best-effort basis.
| Component | What it is | What limits it in practice |
|---|---|---|
| Disk space | Room for site files, the database, mail and backups | Gigabytes, the number of file records (inodes), drive type — SATA SSD or NVMe |
| CPU and memory | Resources to execute code: PHP, Node.js, database queries | Share of a core, memory ceiling, maximum concurrent processes |
| Bandwidth and IP address | The uplink and the point at which the server is found | Port speed, traffic volume, shared versus dedicated address |
| Software stack | Web server, interpreters, database engine, mail server, control panel | Available PHP and MySQL versions, root access, right to install your own software |
| Operations | Power, cooling, hardware replacement, backups, attack mitigation, support | Stated availability, backup retention depth, support response time |
What is web hosting and how does it work, step by step
Every page view is the same short chain. Knowing the links in it is what lets you tell a hosting problem from a DNS problem or a problem in your own code.
- The visitor types a name. The browser needs an IP address, not
example.com, so it asks a DNS resolver. - DNS answers with the host's address. The domain's name servers return an A record (IPv4) or AAAA record (IPv6) — the address of the server you rent.
- The browser connects to that server. A TCP connection to port 443, then a TLS handshake using the certificate installed on the hosting.
- The web server receives the request. nginx or Apache looks at the requested host name and path and decides which site on the machine it belongs to — one server often carries hundreds of sites on one IP.
- Static files go straight back; dynamic pages run code. An image or a CSS file is read from disk. A WordPress page starts PHP, which queries the MySQL or MariaDB database and assembles the HTML.
- The response travels back. Headers, then the body. The browser discovers more resources in the HTML and repeats steps 3–6 for each one it does not already have.
Everything in steps 3 to 6 is the hosting's job. Steps 1 and 2 belong to DNS, which may or may not be run by the same company. When a site is "down", the first question is which step broke — our guide to the domain-to-hosting connection covers the DNS side of this chain in detail.
What is web hosting with example
Take a small bakery that wants a site at examplebakery.com. The owner buys the domain from a registrar and a shared hosting plan from a host, installs WordPress from the control panel, and points the domain's A record at the IP address shown in the hosting dashboard. From then on the bakery's pages, photos and order form live on a disk in the host's data center; when a customer on a phone opens the site, that server builds the page and sends it. If the bakery later outgrows the plan, it moves the files to a VPS and changes one DNS record — the name and the customers' bookmarks stay the same.
What is web hosting used for
"Website" is only the most visible use. The same rented server capacity runs a range of things people rarely think of as hosting:
- Websites and blogs — company sites, portfolios, landing pages, news sites.
- Online stores — the storefront, the product database, the checkout and the admin panel.
- Web applications and APIs — the backend a mobile app talks to, customer portals, internal tools.
- Email — many shared plans include a mail server for addresses at your domain.
- Databases and file storage — data behind the site, downloadable files, media libraries.
- Staging and test copies — a second copy of the site where changes are tried before they reach real visitors.
Do I really need web hosting?
If you want a website that other people can open at any hour, yes — some server has to store it and answer requests. The real question is whether you need to buy hosting as a separate product, and often you do not:
- Website builders such as Wix, Squarespace or Shopify include hosting in the subscription. You are still hosted — on their servers — you just cannot move the site's code elsewhere as easily.
- Hosted blogging platforms such as WordPress.com work the same way: platform and hosting in one bill.
- Static site platforms such as GitHub Pages, Netlify or Cloudflare Pages host plain HTML, CSS and JavaScript, often at no charge for small projects.
- A social media page needs no hosting at all, but it is not your website: the platform owns the address, the rules and the audience.
You need to rent hosting yourself when you want the self-installed version of a CMS (WordPress from wordpress.org, Joomla, Drupal), custom server-side code, your own database, or full control over where the data lives.
Web hosting vs domain: the difference
This is the beginner's central confusion, so let us settle it early. A domain and hosting are two independent services. One company often sells both on one invoice, but underneath they are renting a name and renting resources, and you can buy them in different places.
| Aspect | Domain | Hosting |
|---|---|---|
| What it is | A name such as example.com | Disk, CPU, memory, bandwidth |
| Who you buy from | A registrar accredited for the zone | A hosting provider or cloud platform |
| Billing period | Usually a year or more | Usually a month or a year |
| Where the record lives | In the registry of the domain zone | On a specific server with a specific IP address |
| If you stop paying | The name is released, the site stops opening by address | Files are deleted after a grace period, the name stays yours |
| Switching supplier | Transfer between registrars | Move the files, repoint the DNS record |
DNS is what ties them together. A domain has NS records telling the world which name servers answer for the zone. Those name servers hold an A record — or AAAA for IPv6 — carrying the IP address of your hosting. The browser asks for the address by name first, then knocks on the address. For how names and zones are built, see what a domain is; for the wiring itself, see how to connect a domain to hosting.
A domain and hosting do not depend on each other. Delete the site from hosting and the domain is still yours. Let the domain lapse and the files stay on the server, but nobody can open the site by name. They carry separate invoices and separate renewal dates — which is why sites usually "disappear" not because of the server but because of a forgotten domain.
Do I need both a domain and hosting?
For a normal public website, yes. Without a domain the site is reachable only by a bare IP address, which nobody remembers, which changes when you switch hosts, and for which a regular publicly trusted TLS certificate is usually not issued. Without hosting, a domain is a name that points nowhere — or at a registrar's parking page. Builders and bundles hide this by selling both together, but both are still there on the invoice.
Does email need separate hosting?
Not strictly, but separating them is wise. Mail on the same box as the site suffers whenever the site is under load, and the sending reputation of a shared IP address depends on your neighbors. Mail is routed by the domain's MX records, independently of the A record that points at the website, so the two can live with different providers. To see where the mail records currently point, use the MX lookup.
Where hosting physically is
The answer to "where is my hosting" is literal: in a building with a street address, security at the door and two independent power feeds.
The data center
This is not a cloud in the figurative sense but an engineering structure. Power arrives from separate substations; between the feeds sit battery-backed uninterruptible supplies and diesel generators that start while the batteries still hold. Cooling systems pull heat out of the racks — the more kilowatts per rack, the more elaborate the scheme. Access to the halls is by badge, and racks lock. Facility resilience is commonly described in Tier levels under the Uptime Institute Tier classification: the higher the tier, the more the engineering infrastructure is duplicated and the more expensive a rack unit becomes.
Rack, server, drive
The hall holds racks roughly two meters tall. Servers slide into them horizontally; the common sizes are 1U and 2U, that is 4.4 or 8.9 centimeters (1.75 or 3.5 inches) in height. Inside are CPUs with dozens of cores, tens or hundreds of gigabytes of RAM, and storage. Drives are grouped into arrays so that one failure does not destroy the data; on modern floors that usually means NVMe SSDs rather than spinning disks. Each server has at least one, normally two, network links to the top-of-rack switches.
How one server becomes hundreds of sites
Your site almost never occupies a whole machine. On shared hosting, hundreds of accounts live on a single operating system, separated by file permissions and resource limits. On a VPS, a hypervisor slices the physical server into virtual machines, each with its own kernel and its own root user. In the cloud, one more layer of abstraction appears: disk, address and compute become separate objects you can resize without taking the service down.
Geography: why the location matters
Light travels through optical fiber roughly a third slower than through vacuum, and every intermediate router adds a fraction of a millisecond. The result is that latency grows with distance and cannot be optimized away in code. The gap between a server in your own country and one on another continent is measured in tens — sometimes well over a hundred — milliseconds per request-response round trip. A page that makes ten sequential calls to the server multiplies that gap by ten.
So you place the server near the audience and push static files through a content delivery network when needed. Region is normally chosen at order time: a site for customers in the US East belongs in a data center there, a site for Germany in a European one, and a global audience is usually served from one region plus a CDN.
Jurisdiction and data residency
Beyond distance there is law. Where a server physically stands decides which legal regime applies to the data on it. Under the GDPR, moving personal data of people in the European Economic Area to a country outside it is only lawful on specific grounds — an adequacy decision or appropriate safeguards such as standard contractual clauses. Several countries go further and require certain categories of data to be stored domestically. The obligation attaches to the server, not to the domain: the name can live in any zone, the database has to sit where the rules say. Check where your provider actually keeps data and backups, not only where its head office is registered.
Types of web hosting: shared, VPS, dedicated, cloud
The difference between the types is where the boundary runs between your responsibility and the provider's. The cheaper the plan, the more the provider does and the less you are allowed to change.
| Type | What you get | Who administers the system | Who it suits |
|---|---|---|---|
| Shared | An account on a common server, a control panel, a ready stack | The provider | Brochure sites, blogs, small shops |
| VPS / VDS | A virtual machine with root, guaranteed cores and memory | You | Custom stacks, several projects, staging environments |
| Dedicated server | A whole physical machine with no neighbors | You | Heavy load, large databases, specific hardware needs |
| Cloud | Resources on demand, pay for consumption, scaling | You, with some layers handled by the platform | Spiky traffic, fault-tolerant designs |
| Managed WordPress | A server tuned for one CMS, core updates and caching done for you | The provider, including the CMS core | WordPress sites whose owners do not want to administer anything |
| Static hosting | File delivery with no server-side code, usually through a CDN | The platform | Documentation, portfolios, sites built by static site generators |
Serverless platforms sit alongside these: you pay per function invocation rather than for machine uptime, and there is no server for you to see at all — only code and a bill.
The full comparison — when a shared account stops being enough and which symptoms mean it is time to move — is in shared hosting vs VPS vs dedicated server. How to pick a provider and what to read in the contract is covered in the guide to choosing hosting. We deliberately do not repeat them here: this article exists to explain what hosting is at all.
What is WordPress hosting
WordPress hosting is not a separate technology. WordPress is a PHP application with a MySQL or MariaDB database, so it runs on any plan that offers PHP, a database and HTTPS — the current minimum versions are listed on the official WordPress requirements page. What a plan labeled "WordPress hosting" usually adds:
- One-click install and a preconfigured database, so you never touch
wp-config.phpby hand. - Automatic core updates, sometimes plugin updates too — convenient, but test them on staging if your site depends on fragile plugins.
- Server-level page caching tuned for WordPress, which is what makes a cheap plan feel fast for anonymous visitors.
- Staging copies and daily backups with one-click restore.
- Restrictions. Managed plans often forbid certain caching or backup plugins because they duplicate what the platform does.
Do not confuse the two WordPresses. WordPress.com is a hosted service: platform and hosting in one subscription, with limits on plugins and themes that depend on the plan. WordPress.org is the free software itself, which you install on hosting you rent. When people search "web hosting for WordPress", they almost always mean the second case.
How much does web hosting cost and what drives the price
Exact figures go stale faster than an article, so the structure is more useful than the numbers: what is the provider actually charging for?
- Hardware depreciation. A server runs for a few years, then it is replaced. Its cost is spread across the months of every customer living on it.
- Power and cooling. The bill covers not only the watts the server eats but the ones spent conditioning the hall around it. Every watt of useful load carries a noticeable share of engineering overhead.
- Rack space and transit. Renting rack units, paying for uplinks and peering, filtering junk traffic at the network edge.
- Licenses. Control panel, commercial operating system, mail antivirus, backup tooling.
- Labor. On-call engineers and support working nights and weekends — the most expensive part of a cheap plan, and the reason genuinely free serious hosting does not exist.
- Backups. Storage for copies and the traffic to create them cost real money, which is why retention depth is almost always a paid option.
The ratios between the types stay stable even when the numbers move: shared hosting is the cheapest option, a VPS of comparable power costs several times more, and a dedicated server another order of magnitude on top. Cloud changes the character of the bill more than its size: instead of a flat fee you get a consumption-based invoice, which can land below the flat one or noticeably above it during a traffic spike.
What to look at besides the headline number
- Renewal price. The first term is often discounted and renewed at full rate. Compare the second invoice, not the first.
- "Free domain" bundles. The gift covers one term. In year two the domain is billed separately, often above what a dedicated registrar charges.
- What costs extra. A dedicated IP address, certificates beyond the free one, daily backups with long retention, additional mailboxes, migration done by the support team.
- Compensation for downtime. If availability is advertised but a breach carries no remedy, that is a marketing number, not an obligation.
- Refund terms. Paying a year upfront beats monthly billing only if the money comes back when you leave early.
Why "unlimited" hosting is not unlimited
No server has an infinite disk. "Unlimited" means the counter was removed from the price list, not from the system. The limits are all still there — they simply live in the acceptable use policy rather than on the plan page.
- File records (inodes). A filesystem stores not only bytes but an entry per file. That count is finite, and a cache of hundreds of thousands of tiny files hits the ceiling long before the gigabytes do.
- CPU time. Shared plans allocate an account a share of a core, a memory ceiling, a process cap and an I/O limit. Going over is not punished with an email but with slowdowns and a "resource limit reached" error.
- What the space is for. The policy nearly always says the disk is meant for a working website, not a file archive, not backups of unrelated projects, and not video distribution.
- Fair use of traffic. "Unlimited bandwidth" is bounded by port speed: even without a counter, you cannot push out more than physically fits down the link.
Read the acceptable use policy and the contract, not the plan page. "Unlimited" on the storefront almost always means "no separate meter in the price list". The real thresholds — inodes, CPU share, process count, maximum single file size — live in the document behind the small link at the bottom of the page.
How close you are to a threshold is visible on the server itself if you have SSH access.
# Inodes used and remaining on this filesystem
df -i .
# Ten heaviest directories in the current folder
du -sh ./* | sort -h | tail -10
# Total number of files in the project
find . -type f | wc -lMore often than not it turns out the space and the inodes went to the CMS cache or to logs, not to content. On shared hosting without SSH, the same figures usually appear in the control panel's resource usage section.
How much disk space does a website really need?
A brochure site or a small blog occupies a few gigabytes including the database and mail. Space is usually eaten not by pages but by unoptimized images, accumulated logs and CMS cache. If a plan fills up on an apparently empty site, look in those three places before upgrading.
How to check which hosting a website uses
The question comes up in two situations: you inherited a project and do not know where it lives, or you are looking at somebody else's site. The method is the same — go from the name to the address, and from the address to the owner of the network.
| What you look up | What it tells you | What it does not tell you |
|---|---|---|
| A / AAAA record | The IP address visitors connect to | Whether that address is the origin server or a CDN in front of it |
| NS records | Who runs the DNS zone | Who stores the site's files |
| IP whois / ASN | Which network the address belongs to | Which reseller or customer the server is rented to |
| Domain whois | The registrar and the expiry date | Anything about the hosting |
| MX records | Where mail for the domain is delivered | Where the website lives |
| Response headers | Web server software, sometimes a panel or CDN | The provider, unless it adds its own header |
Step 1. Find the IP address
DNS turns the domain into an address. While you are there, look at which name servers answer for the zone: on shared hosting they almost always belong to the same provider.
# A record: which address the domain's name servers return
dig +short example.com A
# Which name servers are authoritative for the zone
dig +short example.com NS
# Reverse zone: what the host at that address is called
dig +short -x 93.184.216.34On Windows without dig installed, nslookup -type=A example.com and nslookup -type=NS example.com return the same data.
Step 2. Find who owns the address
Blocks of IP addresses are allocated to organizations and recorded in the regional registry databases. That is where the provider or data center name comes from.
# The organization the address block is delegated to
whois 93.184.216.34 | grep -Ei 'netname|descr|orgname|country'
# Response headers: sometimes reveal the web server, panel or an intermediary
curl -sI https://example.com | grep -Ei '^(server|x-powered-by|via|cf-ray)'Step 3. Do not be fooled
- Behind a CDN you only see the CDN. If the site sits behind a delivery network or an attack-mitigation service, the A record points at the intermediary and the real server address is hidden. That is the design, not a flaw in the method.
- NS records do not always point at the host. Zones are frequently kept apart from files: names at one service, the website at another.
- Domain whois shows the registrar, not the host. Two different questions, two different answers.
- MX records lead to the mail provider. Mail often lives away from the site, and its address says nothing about where the pages are.
A whois lookup on an IP answers "who was this address block delegated to", not "who is the site owner paying for the server". There is often a chain in between: a data center leases a rack to a host, the host sells a VPS to a reseller, the reseller sells to the end customer. The database shows you the top of that chain.
Step 4. Check it with tools
All four steps work without a terminal:
- Whois — who the domain is delegated to and who owns the address block;
- IP lookup — where the address physically sits, which network and autonomous system it belongs to;
- DNS records — A, AAAA, NS, MX and the rest for one domain;
- Response headers — what the web server says about itself;
- Speed test — how fast the server actually answers.
The step-by-step walkthrough with all the edge cases is in how to find a website's hosting and IP address.
Measuring your own server's response
A single curl call shows where the time goes: name resolution, connection setup, the TLS handshake, or the server's own work.
curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.comRead it like this: a wide gap between tls and ttfb means the code or the database on the server is slow. Large connect and tls with a fast ttfb means distance and network, not the host. A large dns points at the name servers, not the site.
Can I run my website without hosting?
Not without a server. What you can skip is a hosting company: the machine can be one you own. A site opened at http://localhost on your laptop works for development, but nobody else can reach it. Making it public means turning your own computer into the hosting — which is possible, with serious caveats.
At home: possible, but not for a production site
Standing up a web server on a home machine is technically easy. The problems start outside the configuration.
- No permanent public address. Residential plans often place you behind the provider's shared gateway, so nothing from outside can connect at all and no amount of router tweaking helps.
- Blocked ports. Inbound connections on 80 and 443 are frequently prohibited by the terms of consumer plans.
- Asymmetric link. Home internet downloads fast and uploads slowly, and a website is pure upload.
- No redundancy. A power cut or a cable dug up in the street takes the site down, and nobody is coming to fix it under an SLA.
- Security is entirely yours. A server exposed to the internet is scanned around the clock from the first minutes. Patching, firewalling and brute-force protection become a standing chore.
For a lab, a home media server or a demo to a colleague, that is fine. For a site real people depend on, it is not.
Your own server instead of a ready-made plan
The realistic way to "build hosting" is to rent a VPS or a dedicated server and assemble the stack yourself. You get root, install the web server, the database and the interpreter, and from then on you own updates, backups and monitoring. A minimal nginx site block looks like this:
server {
listen 80;
server_name example.com www.example.com;
root /var/www/example.com/public;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}Validate and apply with nginx -t && systemctl reload nginx. After that you will need a certificate with automatic renewal, a firewall, scheduled backups and external uptime monitoring — because a server that has fallen over will not report itself.
Hosting as a business
Selling hosting to other people is a different story, and the entry bar is higher than it looks: address space and network agreements, round-the-clock support, billing, a control panel, plus the legal side. Providers carry obligations for what their customers publish, must run an abuse-handling process, and in a growing number of jurisdictions face registration or reporting duties. The usual first step is simpler — reselling, where you repackage somebody else's capacity under your own brand and never touch the hardware.
What happens when you migrate to another host
The key point: the content moves, the name does not. The domain stays with the registrar; only the records that point at an address change. That is exactly why a migration cannot cost you the name.
- Lower the TTL in advance. A day or two before the move, cut the A record's time to live to, say, five minutes. This has to happen before the switch, not with it.
- Move files and the database. A site archive plus a database dump. Check the dump's character set and the database engine version on the new side.
- Bring the site up on the new server and test it before switching. Open it by IP address, or override the name-to-address mapping in your local hosts file.
- Issue the certificate. HTTP-based validation requires the domain to already point at the new server; if it does not yet, use DNS-based validation instead.
- Repoint the A record. And the MX records too, if mail is moving along with the site.
- Wait for caches to expire. Some visitors will keep landing on the old server for a while.
- Keep the old host running for a few days. Do not cancel it on migration day: orders and mail can still settle there.
- Raise the TTL back. Once things are stable, restore it so you are not hammering the name servers.
Lower the TTL ahead of time. If you do it at the same moment you repoint the address, the old value keeps living in resolver caches for exactly as long as the previous TTL said — and for a full day part of your audience will keep hitting a switched-off server no matter what you edit in the panel.
What breaks most often
- Mail leaves with the MX records. Everyone remembers the website; the mailboxes get forgotten. Messages start arriving at a new server where no mailboxes exist yet.
- The database write window. Orders placed between taking the dump and flipping the record land on the old server and vanish. A temporary read-only mode during the copy avoids this.
- Filename case. Linux distinguishes Logo.png from logo.png; some other systems do not. After a move, part of the imagery can simply disappear.
- A different PHP version. The new server is usually newer, and code that ran for years suddenly complains about deprecated constructs.
- Hardcoded paths and URLs. Absolute paths in configuration and the old domain baked into the database are the classic cause of "the site opens but the styles do not load".
Verifying a migration is easiest from outside: DNS records show what the zone is actually publishing, the propagation check shows how far resolvers still disagree, the certificate check confirms TLS came up on the new side, and a speed measurement tells you whether the thing you did all this for actually got faster.
Checklist: what to know about your own hosting
- Who the provider is, under which contract, and until what date the plan is paid.
- What the site's IP address is and which country it sits in.
- Where the DNS zone is kept: with the host, the registrar or a third-party service.
- Which limits the acceptable use policy sets: disk, inodes, CPU time, process count.
- Whether backups run, how far back they go, and — crucially — whether one has ever been restored.
- Whether SSH and FTP access exist, and who else holds the passwords.
- Who issues the TLS certificate and whether renewal is automatic.
- Where the MX records point and where the mail actually lives.
- Whether external uptime monitoring exists and whose phone the alert reaches.
- Exactly what would have to move if you had to change provider tomorrow.
FAQ
Is GoDaddy a web hosting?
GoDaddy is both a domain registrar and a hosting provider, and those are separate products in the same account. Buying a domain there does not give you hosting. To see whether a site actually runs on GoDaddy servers, look up its A record and check who owns that IP address; name servers under domaincontrol.com only mean the DNS zone is at GoDaddy.
What is an example of a web host?
Shared and WordPress hosts such as Bluehost, SiteGround, Hostinger, Namecheap and GoDaddy; cloud platforms such as Amazon Web Services, Google Cloud, Microsoft Azure and DigitalOcean; static site platforms such as GitHub Pages, Netlify and Cloudflare Pages. Website builders like Wix and Squarespace are web hosts too, bundled with the editor.
Can I buy the domain and the hosting from different companies?
Yes, and it is standard practice. Either point the registrar's name server fields at the host, or keep the zone with the registrar and add an A record with the server's address. Splitting them is arguably better: changing hosts never touches the domain, and a dispute with one supplier does not freeze the other service.
Is there such a thing as free hosting?
There is, and it is paid for in another currency: ads on your pages, hard resource limits, no support and no backups, and sometimes a third-level domain that is not yours. Fine for a learning project. Not fine for a site your orders depend on — there is nothing to restore from and nobody to hold accountable.
What happens if I stop paying for hosting?
First the site is suspended but the data is kept — most providers offer a grace period. After it expires, files and database are deleted with no recovery. The domain meanwhile carries on until its own renewal date, because it is a separate bill.
Can visitors see which host a site uses?
Not directly, but almost always indirectly: through the IP address and network owner, response headers, name server names and the reverse DNS entry. Hiding the provider completely requires sitting behind a delivery network or proxy, and even then not from every method.
