Publishing a site feels like one big technical act you either know or you do not. It is actually four small, separable pieces; a name, a host, the plumbing that connects them, and a lock. This walks you through all four, from buying the domain to the padlock going green, and explains what each step is really doing so the next time is not a mystery.
Module 01
The four pieces
Myth we'll unpick: "putting a site online is one technical act"
It is four, and they are independent. Muddle them together and it feels like magic; separate them and each one is a single, boring, understandable job.
Think of it as opening a shop
A website going live needs the same four things a shop does. A name over the door so people can refer to you; the premises where the stock actually sits; an entry in the street directory so someone with the name can find the premises; and a lock on the door so people trust it is really your shop and not a copy. Nobody expects the sign-writer, the landlord, the council directory and the locksmith to be the same person. Online they are not either.
Keep that shop in mind. Every step below is one of those four jobs, done by a different service.
The four pieces, and who does each
Why this is good news
Because the four are separate, a problem is never "the website is broken"; it is always one of the four pieces. The name is fine but the directory entry is missing. The premises work but the lock has not been cut yet. That last one is exactly where this guide will leave you, and it is the most common place to think something has gone wrong when nothing has.
So let us buy the name first.
Module 02
The name: buying a domain
Myth we'll unpick: "you buy a domain and own it forever"
You rent it, a year at a time, from a company whose one job is to book that name in your name.
Registrar, registry, and you
There is a single global list of who holds every .com, kept by a registry. You do not talk to the registry; you go through a registrar, a licensed reseller like Namecheap, and pay them a yearly fee to reserve your name and keep it in your account. That is the whole transaction. When Namecheap said your domain was "available", it meant nobody else was currently renting it.
The whole system sits under a non-profit called ICANN, which is why a name bought at any registrar works the same everywhere. You are never locked to Namecheap; a domain can be moved between registrars.
So what did you actually buy?
Not a website. Not storage. Not even a page. Reveal what the money actually bought you.
The exclusive right to point that name wherever you like.A domain on its own shows nothing; it is an address with no building behind it yet. Its power is that you, and only you, get to say which premises it points at. That pointing is Module 04. Everything else you own here follows from it.
Two housekeeping notes worth knowing
First, it renews yearly, and if you let it lapse the name goes back on the market; set it to auto-renew and diarise it. Second, your name and address are attached to a domain by default and can be looked up publicly; most registrars, Namecheap included, offer free WHOIS privacy that hides them behind a proxy. Turn it on.
You have the name. Now it needs premises to point at.
Module 03
The host: GitHub Pages
Myth we'll unpick: "a website needs a hosting company and a server you rent"
For a site that is just files, it does not. GitHub will hold the files and hand them out as a website, for free.
What GitHub actually is
Underneath the jargon, GitHub is a filing cabinet with a time machine. Each project lives in a repository, a folder that also remembers every version of itself, so you can change things fearlessly and roll back. GitHub Pages is a switch on that folder that says "do not just store these files, serve them to the public as a website". Because your site is plain HTML, that is all the hosting it needs.
This is why there is no separate hosting bill and no server to manage. The same account that stores your work also publishes it.
The loop you will use forever
1EditChange the files on your computer, in whatever tool you like. Nothing is live yet; this is just your local copy.
2CommitTell GitHub Desktop "save this set of changes as a version", with a short note. The time machine records a point you can return to.
3PushSend that version up to GitHub. Your online copy now matches your computer.
4DeployPages notices the change and rebuilds the public site within a minute or two. You do nothing; it just happens.
Edit, commit, push. Three moves, and the fourth is automatic.
The one fork in the road: public or private
Pages runs free from a public repository, where anyone can read the source files. Serving from a private one, hidden from view, needs a paid plan. That is the "upgrade or make this repository public" wall people hit. For a site you intend to publish openly anyway, public is the free and sensible choice; just know the source, including any unfinished drafts, is visible to anyone who goes looking in the repository.
The premises are ready. Now connect the name to them.
Module 04
The plumbing: DNS
Myth we'll unpick: "DNS is scary, and it is instant"
It is neither. It is a public address book, and it is the one step that deliberately takes its time.
DNS is the street directory
Your domain name means nothing to a computer; computers find each other by numbers called IP addresses. DNS, the Domain Name System, is the directory that translates the name a human types into the number a machine needs. When you add records at Namecheap, you are writing your domain's entry in that directory: this name lives at these numbers. Until you do, the name points nowhere.
You already did this: the A records and the CNAME. The next screen shows exactly what each one told the directory.
Follow one visitor, hop by hop
StepYou
→
DirectoryDNS
→
PremisesGitHub Pages
→
Your folderThe repo
→
ResultThe page
The records you wrote, and why
Why it is not instant
Directories all over the world keep copies of DNS entries so lookups are fast, and those copies only refresh every so often. When you add a record, you are waiting for that refresh to ripple outwards; this is propagation, and it can take anywhere from minutes to a day. Nothing is stuck; the world is simply catching up to what you wrote.
GitHub's own documentation notes changes can take up to 24 hours. It is usually far quicker, but "up to a day" is the honest promise.
Name, premises, directory: connected. One piece left, the lock.
Module 05
The lock: HTTPS and going live
Myth we'll unpick: "'not eligible for HTTPS' means something is broken"
It almost never does. It means the lock is being cut, and the locksmith cannot start until the directory entry has settled.
What the padlock is
The padlock is a certificate. It does two jobs: it scrambles the traffic between visitor and site so nobody in between can read it, and it proves the site really is yours and not an impostor. GitHub gets you one automatically and free from a service called Let's Encrypt. The catch is that Let's Encrypt will only issue it once it can independently see your domain pointing at GitHub; the proof depends on the DNS you just set.
So the certificate cannot come first. It is the last piece precisely because it verifies all the others.
The order it happens in
1You save the recordsThe A records and CNAME at Namecheap. Done in a moment; this is the only part in your hands.
2DNS propagatesThe world's directories pick up your entry. Minutes to hours.
3GitHub verifiesPages checks that the domain now resolves to its servers. Until this passes, you see "not eligible for HTTPS", which is a status, not a fault.
4The certificate issuesLet's Encrypt mints the lock. Usually within an hour of DNS being visible.
5You tick Enforce HTTPSThe box un-greys itself when ready. Tick it, and every visitor gets the padlock. Live.
If you are reading this while step 3 sits waiting, you are exactly on schedule.
The one thing that is actually a fault
If hours pass and a DNS checker still shows nothing, or shows a registrar parking page instead of GitHub's numbers, that is the real signal to act; and it is almost always one cause. The registrar's default records were not deleted, so its parking entry is still answering for your name and drowning out the ones you added. Remove those, keep only your four A records and the one CNAME, and the wait resumes properly.
That single gotcha accounts for most "it will not go live" cases. Everything else is patience.
Why this matters
You now hold the whole map. A site online is a name you rent, premises that serve your files, a directory that connects the two, and a lock that proves and protects it. Next time nothing will be magic; it will be a four-item checklist, and when something waits, you will know which piece is waiting and why.
Sources used: the GitHub Pages apex A records (185.199.108 to 111 .153), the www CNAME to your username's github.io, the CNAME file behaviour and the "up to 24 hours" propagation note are from GitHub Docs, "Managing a custom domain for your GitHub Pages site" and "Securing your GitHub Pages site with HTTPS", checked 3 August 2026. The free certificate is issued by Let's Encrypt, as GitHub documents. The public-repository-free, private-repository-paid rule for Pages is per GitHub's own settings and documentation. The registrar and registry structure under ICANN, and the default parking-record behaviour of registrars including Namecheap, are standard and widely documented. No figure in this deck is invented; where timing is uncertain it is given as a range.