What happens when someone types your domain?
A domain name such as northfieldbirds.example is a label you rent from a registrar. Browsers cannot connect to a label; they need a server address. DNS, the Domain Name System, is the public lookup service that turns the label into an address. Your registrar or DNS provider holds the records for your domain, and you edit them in its dashboard.
When a visitor types www.northfieldbirds.example, their computer asks DNS for that name, gets back an address or another name to follow, connects to that server, and asks it for the site. The server must also be configured to answer for that name, which is why hosts ask you to add the domain on their side too.
The .example ending used here is reserved for documentation, so these names will never belong to anyone. Swap in the domain you actually own.
Which DNS records do you need?
Four kinds of record cover nearly every small site. Each has a name (which part of the domain it applies to), a type, and a value.
cat index.html
git log --oneline- An A record maps a name to an IPv4 address such as
185.199.108.153. Use it for the bare domain, written@in most dashboards. Hosts give you the exact addresses; GitHub Pages lists four. - An AAAA record does the same for an IPv6 address. Add them if your host provides them.
- A CNAME record points one name at another name, such as
wwwpointing tonorthfieldbirds.github.io. The visitor's computer then looks up that name in turn. A bare domain usually cannot have a CNAME, which is why it gets A records instead. - TTL, time to live, is how many seconds other computers may cache the answer. While you are setting things up, a short TTL such as 300 seconds means mistakes clear quickly.
www. The CNAME file tells Pages which name to answer for, and HTTPS arrives once the records settle.How do you connect a domain to GitHub Pages?
Add the domain in the repository's Pages settings. GitHub commits a file called CNAME to the published branch containing the domain, such as www.northfieldbirds.example. If you publish from a branch, you can also create that file yourself and push it, which is what the demo does. The file holds only the host name: no https://, no path, no trailing slash.
Then, at your DNS provider, add a CNAME record for www pointing to yourname.github.io (the account or organisation name, without the repository), and A records for @ pointing to the four addresses GitHub lists in its documentation. GitHub also recommends verifying the domain in your account settings, which stops anyone else claiming it for their Pages site.
For a cPanel-style host the idea is the same with different values: the host gives you its server address or nameservers, and you add the domain in its panel so the server knows to answer for it.
git switch -c new-hours
echo "www.northfieldbirds.example" > CNAME
cat CNAME
git statusWhy does a new domain take time to work?
DNS answers are cached all over the internet for as long as the TTL allows, and some resolvers hold on longer. After you change a record, some visitors see the new address within minutes and others keep seeing the old one for a few hours. Mobile data and home broadband can disagree for a while, which is confusing and normal.
Make one change at a time, then wait before deciding it failed. Check the records with an online DNS lookup tool or the dig command on your computer, rather than reloading the site over and over. If the lookup shows the right values, the rest is waiting.
Plan domain moves for a quiet time. Lower the TTL a day ahead, make the switch, confirm it works, and raise the TTL again later.
How does HTTPS get set up?
HTTPS needs a certificate that proves the server is allowed to speak for the domain. GitHub Pages and most modern hosts issue one for free, automatically, once DNS points at them. On Pages, the "Enforce HTTPS" option appears when the certificate is ready, which can take up to a day after DNS settles. Tick it so plain http:// visits are redirected.
On cPanel-style hosts the free certificate usually comes from a feature called AutoSSL. It runs on a schedule and needs the domain to resolve to that server, so it fails if DNS still points elsewhere.
Once HTTPS is on, browsers warn about mixed content: a secure page loading an image or script over http://. Use relative links or https:// everywhere. A site that worked before the switch can look broken until those links are fixed.
How do you ship an update without breaking the live site?
Treat main as the live site and never edit it directly. Start each change on a branch, such as new-hours, and commit there. Pages and the host ignore that branch, so you can make as many commits as you like while the live site keeps working.
When the change is ready, check it: open the files locally in a browser, read git diff main to see exactly what will go live, and fix anything odd. Then switch to main, merge the branch, and push. In the Graph view, main moves forward to the branch's commit in one step.
The routine costs a couple of extra commands and gives you a clear moment of decision before anything is public. On a team, the merge step becomes a pull request, so someone else reads the change before it ships.
git switch -c new-hours
git branch
git diff main
git switch mainWhat if an update breaks the site anyway?
Revert first, investigate second. git revert HEAD followed by git push puts the site back the way it was within a couple of minutes, and the broken commit stays in history for you to study calmly. On a host with deploy buttons, deploy again after pushing.
Avoid rewinding main with a force push. Anyone who pulled the broken version would be left with history that no longer exists on GitHub, and their next push could bring the problem back.
When the fix is ready, make it on a branch like any other update. Writing commit messages that say what changed for visitors, like "Change meeting time to 7:30pm", makes finding the culprit much faster next time.
git log --oneline -3
git reflogField notes
- DNS turns a domain name into the address of a server.
- A and CNAME records tell browsers where your site lives.
- For GitHub Pages, a
CNAMEfile in the branch holds your domain. - Make changes on a branch, then merge into
mainonce they are ready.
Easy to get wrong
The file is read as a host name. A scheme or slash makes the custom domain setting fail.
Caching means results vary for a while. One change at a time tells you which change caused what.
Every push to main is live. A branch gives you a safe place to finish and review the change first.
Questions people ask
Should I use www or the bare domain?
Either works. Many sites set up both, choose one as the main address, and let the other redirect. GitHub Pages does that redirect for you when both are configured.
What are nameservers?
They decide which company's DNS holds your records. If you point nameservers at your host, you edit records in the host's panel instead of the registrar's.
Does the CNAME file affect a cPanel host?
No. It only applies to GitHub Pages. A cPanel-style host learns the domain from its own panel settings.
How long until HTTPS works?
Usually minutes to a few hours after DNS points at the host. If it takes more than a day, check that the records are correct and that no old record still points elsewhere.