Getting It on the Internet
A folder of HTML files is a website the moment somebody else can open it, and for a static page that is free and takes about five minutes. Then the three checks worth doing before you send anyone the link.
A folder of HTML files is a website the moment somebody else can open it, and for a static page that is free and takes about five minutes. Then run three checks before you send anyone the link.
A static site needs no server you manage
What you built is a static site: files that are sent exactly as they are, identical for every visitor. No database, no server-side code, nothing to run.
That is the easiest possible thing to host, which is why every option below is free at the scale you need.
Static — what you have
HTML, CSS, images, maybe some JavaScript. The server hands over files. Fast, cheap, almost nothing to attack, and it will still work in ten years with no maintenance.
Dynamic — what you do not
A program builds each page per request, usually against a database. Needed for accounts, user content, and anything personalised. More power, and a thing you now have to keep running and patched.
GitHub Pages is a repository with a switch
If your files are in a GitHub repository — and after this site's Git and GitHub track they can be — publishing is a settings toggle.
- 1
Push the folder to a repository
index.html must be at the root of it, not inside a subfolder. This is the step people get wrong.
- 2
Settings → Pages
Under Build and deployment, set Source to "Deploy from a branch", pick main and the / (root) folder, and save.
- 3
Wait a minute
The page shows a URL: https://yourname.github.io/repository-name/. First publish takes a minute or two; later pushes are faster.
- 4
Push to update
Every push to that branch republishes automatically. There is no separate deploy step.
One naming detail: a repository called yourname.github.io publishes at that bare domain rather than in a subfolder — which is both tidier and avoids the path problem in the section below.
Netlify and Vercel take a dragged folder
Two alternatives, both free for a personal site, with a drag-a-folder-onto-a-page option that needs no Git at all.
app.netlify.com/drop — drag the folder onto the page and it is live in seconds on a random subdomain you can rename. The fastest way to put something on the internet, full stop.
Connect a repository and it rebuilds on every push. Also gives you Netlify Forms, which receives a form submission with no server — the missing half of chapter 9.
Good for frameworks, and perfectly happy with a folder of HTML.
Also free, and fast internationally.
All of them give you HTTPS automatically, on a certificate they renew themselves. That matters because it used to be an annual chore with a fee.
A custom domain is a small yearly fee from any registrar, and it points at your host with one DNS record. Chapter 1 explains why the change takes a while to appear everywhere.
Root paths and case sensitivity break on deploy
Two bugs account for nearly every "it worked on my laptop" report, and both are created weeks earlier by habits from chapter 3.
Case sensitivity
macOS and Windows treat Photo.JPG and photo.jpg as the same file. Most Linux web servers do not. So a mis-cased path works perfectly locally and 404s the instant you publish.
Root-relative paths
/styles.css means the site root. Published to yourname.github.io/my-site/, the root is yourname.github.io — so it looks one level too high and finds nothing.
<link rel="stylesheet" href="styles.css"> relative — works anywhere<img src="images/photo.jpg" alt="…"> relative — works anywhere <link rel="stylesheet" href="/styles.css"> root — breaks in a subfolder<img src="/images/Photo.JPG" alt="…"> root AND mis-cased — twice brokenThe fix for both: lowercase, hyphenated filenames everywhere, and relative paths unless you are publishing at a bare domain. If you must use root-relative paths, publish to a yourname.github.io repository or a custom domain so the root is the root.
Three checks before you send the link
Publishing is the easy part. These are the three that catch the things you cannot see from your own machine.
- 1
Open the published URL, not localhost
In a private window, which avoids your normal profile's cookies and cache. Click every link, load every image, submit the form. This is where a mis-cased path shows up.
- 2
Open it on an actual phone
Not the device toolbar — a real one. Real touch targets, real text size, real connection. Send yourself the link.
- 3
Run Lighthouse on the live URL
The devtools tab audits performance, accessibility, best practices, and SEO in one click. Read the accessibility and SEO sections in particular; they point to specific fixes.
The launch checklist
- ✓Every page has a unique <title> and a meta description
- ✓The viewport meta tag is present — check it once more, it is the one that ruins a phone
- ✓Every image has an alt and has been resized for the web
- ✓No 404s in the network tab on any page
- ✓It works in a private window, on a phone, on somebody else's connection
- ✓Tab through it once on the live site
- ✓The HTML validates at validator.w3.org
- ✓A favicon exists, so the tab is not a blank page icon
- ✓No API keys, no personal data, nothing in a comment you would not publish
<!-- Relative paths, so they survive a project subfolder --><link rel="icon" href="favicon.ico" sizes="any"><link rel="icon" href="icon.svg" type="image/svg+xml"><link rel="apple-touch-icon" href="apple-touch-icon.png"> <!-- The preview card when somebody pastes your link into a chat. og:image and og:url must be full https:// addresses. --><meta property="og:title" content="Priya Raman — student and maker"><meta property="og:description" content="Second-year student. I build small tools."><meta property="og:image" content="https://example.com/og.png"><meta property="og:url" content="https://example.com/"><meta name="twitter:card" content="summary_large_image">Key takeaways
- What you built is a static site: files sent as they are, with nothing to run and nothing to maintain.
- GitHub Pages publishes a repository from Settings → Pages, and republishes on every push.
- index.html must be at the root of the repository, and free Pages requires a public one.
- A repository named yourname.github.io publishes at the bare domain instead of a subfolder.
- Netlify Drop takes a dragged folder and is live in seconds with no Git at all.
- Netlify Forms receives form submissions with no server — the missing half of chapter 9.
- Every one of these gives you HTTPS automatically.
- Linux servers are case-sensitive and your laptop is not, so Photo.JPG works locally and 404s live.
- Root-relative paths break when published into a subfolder. Use relative paths, or publish at a bare domain.
- The network tab finds both of those in five seconds.
- Check the live URL in a private window, on a real phone, and with Lighthouse before sending the link.
- Do not skip the favicon and the og: tags — they are the first thing anyone sees of the link.
Before you move on
Quick check
Answer these to unlock the next chapter: 3 of 4 to pass. You can retake it anytime.
Make a free account to read on
Every chapter is free — an account lets your course progress follow you from your laptop to your phone. No payment, no trial.