The complete guide

How to host a website

What web hosting actually is, the four things every hosted site needs, and how to get a real site online today — written by engineers who run shared hosting.

Ben Johnson · last checked 2026-08-02 · 8 min read

Most explanations of web hosting start with a metaphor about renting land. That metaphor is where the confusion begins, because it implies hosting is one thing you buy. It isn’t. It’s three separate jobs that happen to be sold together, and once you can see the three jobs, every decision that follows becomes obvious.

The three jobs

1. Storing your files. Your website is a folder of files — HTML, CSS, images, and often PHP or another language. They have to sit on a machine that is switched on all the time.

2. Answering requests. When someone types your address, a program on that machine (the web server — Apache, nginx or LiteSpeed) receives the request, finds the right file, and sends it back. If your site uses PHP, the server runs the code first and sends the result.

3. Being findable. A domain name has to point at the machine’s IP address, so browsers know where to send the request in the first place. This is DNS, and it is a completely separate system from the first two — a fact that explains a large proportion of “my site is broken” problems.

A hosting provider sells you jobs 1 and 2. Job 3 you configure, usually once, and then forget about until it breaks.

What kind of hosting you need

The honest answer for most people reading this is shared hosting, and the rest of the options are worth understanding mainly so you can recognise when you have outgrown it.

Two things people get wrong here:

You probably don’t need a VPS. A VPS is not “better hosting”, it’s less hosting — you get an empty Linux machine and you become the system administrator. Security updates, web server configuration, PHP, MySQL, TLS certificates and backups are now your job. That’s a reasonable trade if you want the control. It’s a bad trade if you just want a website.

Static hosting is underrated. If your site has no server-side code, you do not need a server. Static hosts are faster, essentially unbreakable, and free at small scale. If you’re building a portfolio or a documentation site, start here and skip the rest of this page.

Getting a site online

The steps below are the same everywhere; only the panel screenshots differ.

1. Get hosting

Create an account with a provider. You’ll be given three things — keep all of them:

• Control panel access — where you manage the account
• FTP credentials — host, username, password, for uploading files
• A temporary address — usually a free subdomain, so you can work before your domain is ready

If you want to follow along without paying for anything, a free account gives you PHP, MySQL and a subdomain. It is genuinely enough to complete this guide.

2. Upload your files

Your files go in the web root — the one directory the server actually serves. It’s called htdocs, public_html or www depending on the host. Anything outside it is invisible to the internet, which is exactly where you want configuration files and credentials to live.

Connect with an FTP client (FileZilla is free and fine) or your host’s file manager, and upload the contents of your site folder into the web root — not the folder itself. Uploading mysite/ into htdocs/ puts your homepage at /mysite/ rather than at /, which is the most common first-day mistake.

Three rules that prevent most early problems:

• Your homepage must be named index.html or index.php, in lower case. Linux servers are case sensitive; Index.html will not be found.
• Use 755 for directories and 644 for files. Never 777 — on most shared hosts it makes PHP refuse to run the file at all.
• Upload in binary mode. Ancient advice, still occasionally relevant, and text mode corrupts images.

Load your temporary address. Your site should appear. If you get a 403 error, you have almost certainly uploaded to the wrong directory or named the file wrong.

3. Set up the database, if you need one

Static HTML needs no database. WordPress and most PHP applications do.

In the control panel, create a database and a database user, then note four values — you will need all of them:

• Database name
• Username
• Password
• Hostname

That last one catches nearly everyone. Every tutorial says localhost, and on shared hosting it usually isn’t — the database lives on a different machine, and you need the hostname your host assigned, something like sql203.example.com. Getting this wrong produces Error establishing a database connection, the single most common WordPress failure there is.

4. Point your domain at the host

Buy a domain from a registrar, then tell it where your site lives. Two ways:

Change the nameservers (simpler). Your host gives you two or more nameserver addresses; you enter them at the registrar. The host now manages all DNS for that domain. Allow up to 48 hours, though it’s usually much faster.

Point individual records (more control). Keep your existing DNS provider and add an A record for the root pointing at your server’s IP, plus a CNAME for www. Use this when your email is already configured elsewhere and you don’t want to move it.

Either way, check what the world actually sees rather than what your own machine sees — your computer caches DNS aggressively. The DNS propagation checker queries several independent resolvers at once so you can tell the difference between “not propagated yet” and “not configured correctly”.

The full walkthrough is in Point a domain at your host.

5. Turn on HTTPS

Not optional in 2026. Browsers mark plain HTTP as insecure, and Google treats it as a ranking signal.

Every competent host now issues free certificates through Let’s Encrypt, usually with one click in the control panel. Issue the certificate, wait a few minutes, then force HTTPS — in exactly one place:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP:X-Forwarded-Proto} !=https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

That second condition matters if you use Cloudflare or any other proxy. Without it you get ERR_TOO_MANY_REDIRECTS — the proxy and your server each insisting the other should handle TLS, forever.

And genuinely only one place: if you enable an HTTPS redirect in the control panel and add this rule, you have built the same loop by a different route.

What free hosting can and cannot do

We run a free tier, so treat this section with appropriate suspicion — and then check it against any other free host’s documentation, because it’s accurate for all of them.

Free hosting works well for: learning, personal projects, portfolios, prototypes, school assignments, and small sites with modest traffic. If that’s you, free is not a compromise. It’s the right tool.

Free hosting is the wrong choice for: anything commercial where downtime costs money, sites that need to send email reliably, applications needing cron jobs or SSH, and anything where you cannot tolerate the account being suspended for exceeding a limit.

The constraint people hit first is almost never disk space. It’s concurrent processes — how many PHP requests can run at once. Free plans cap this in the region of ten. An uncached WordPress site taking two seconds per page hits that ceiling at around five simultaneous visitors, and everyone else gets a 508.

Caching fixes this almost entirely, and it’s free. That’s why the first thing we tell people is to enable it, not to upgrade.

The second constraint is outbound email. Nearly every free host blocks SMTP outright, because free hosting is a spam magnet and open mail relays get entire IP ranges blocklisted. mail() will not work. Use an HTTP email API — Resend, SendGrid and Mailgun all have free tiers and all work over port 443, which isn’t blocked.

After it’s live

• Take your own backups. Free plans generally don’t back up your data, and paid plans back it up less reliably than you’d hope. Download a copy of your files and a database export monthly. If your site matters, this is the only item on this list that is genuinely non-negotiable.
• Turn on caching before you need it. It’s the difference between a site that handles a traffic spike and one that returns errors during it.
• Keep software updated. Outdated WordPress plugins are the most common way shared hosting accounts get compromised, by a wide margin.
• Watch your resource usage. Most panels show a graph. Learning to read it turns mysterious intermittent errors into obvious ones.

Where people get stuck hosting a website

In rough order of how often our support desk sees them:

Every one of those has a page with the actual fix. The full error library has the rest.

The rest of this series