Guide

How to host a static website

Plain HTML sites are the easiest and fastest thing to host, and usually the cheapest. Here's how to put one online and why it beats a CMS for most small sites.

Ben Johnson · last checked 2026-08-04 · 4 min read

There’s a habit of reaching for WordPress whenever someone needs a website. For a portfolio, a restaurant menu, a documentation site, or a small business page, that’s usually the wrong tool.

A static site is just files. The server finds the file and sends it. Nothing runs, nothing queries a database, nothing can be exploited through an outdated plugin — because there are no plugins.

What “static” actually means

When someone visits a WordPress page, the server runs PHP, queries a database, assembles the HTML, and sends it. That takes a second or two, every single time.

When someone visits a static page, the server finds about.html and sends it. That takes a few milliseconds.

The difference matters more than it sounds:

That third row is worth sitting with. Almost every hacked small website is hacked through an outdated plugin. Remove the plugins and you remove the category.

Building one

You have three reasonable options.

Write the HTML yourself. For a handful of pages this is genuinely fine. An index.html, a style.css, some images. No tooling, no build step, nothing to learn beyond HTML.

Use a site generator. Eleventy, Hugo, Astro and Jekyll take content files and produce finished HTML. You get templates and a shared layout without a database. Good when you have more than a few pages, or a blog.

Export from a builder. Many visual builders can export static HTML. Fine as a starting point, though the output tends to be bloated.

Whichever you pick, the result is the same: a folder of files.

Putting it online

1. Get hosting. Any shared host works, and free plans are more than enough — a static site uses almost no resources. If you want to follow along, a free subdomain takes about a minute.

2. Find your web root. It’s the directory the server actually serves — htdocs, public_html or www depending on the host. Files anywhere else are invisible to the internet.

3. Upload the contents. Connect with FileZilla or the file manager, and upload the contents of your site folder, not the folder. Putting mysite/ inside htdocs/ serves your site at /mysite/ rather than at /.

4. Load your address. It should appear immediately. If you get a 403, your files are in the wrong place or your homepage isn’t named index.html in lower case.

Three rules that prevent most first-day problems:

• Name the homepage index.html, lower case. Linux servers care about capitals — Index.html won’t be found.
• Use forward slashes in links, and keep paths relative: css/style.css, not C:\Users\me\site\css\style.css.
• Use 755 for directories and 644 for files.

Then point your domain

Once the site works on the temporary address, connect your real domain. That’s covered step by step in point a domain at your host.

After DNS resolves, issue the free SSL certificate from your control panel and force HTTPS. Browsers now mark plain HTTP as insecure, and it’s a ranking signal besides.

The one real limitation

Static sites can’t do anything server-side. No user accounts, no comments stored on your server, no contact form that emails you by itself.

For most small sites that’s not a problem, because the common needs have external services that plug straight into a static page:

• Contact forms — Formspree, Web3Forms and similar accept a normal HTML form post and email you the result. Change one action attribute.
• Comments — Giscus or Disqus, both a script tag.
• Search — Pagefind builds a search index at the same time as your site and runs entirely in the browser.
• Analytics — any hosted analytics is a script tag.

If you find yourself needing several of these, that’s a fair signal a CMS would suit you better. One or two is normal.

Keeping a static site healthy

There isn’t much to do, which is the point. But two things are worth setting up once:

Cache headers. Tell browsers to keep your images and CSS rather than re-downloading them on every visit. The .htaccess generator will produce the rules.

A real 404 page. Broken links happen. A 404 that offers navigation beats a blank server error.

When a static website is the right call

Ask one question: does anything need to be different for different visitors?

If the answer is no — everyone sees the same pages — you want a static site. Portfolios, brochures, menus, documentation, event pages, landing pages, CVs. It’ll be faster than the alternative, it won’t need updating, and it won’t get hacked.

If the answer is yes — logins, dashboards, user content, a shop — you need something that runs code, and WordPress or a custom application is the better starting point.

Most people asking how to build a website are in the first group and don’t realise it.