Migrating logansmith.us off Wix to GitHub Pages (without breaking email)
My personal site lived on a paid builder for years. It was fine — but it was also $204/year for what is essentially a handful of static pages. I'm a security engineer with a GitHub habit and a homelab; paying subscription pricing to host flat HTML started to feel silly. So I moved it to GitHub Pages for $0, kept my domain exactly where it was, and — most importantly — never dropped a single email along the way.
Here's the playbook, including the gotchas that bit me.
The key insight: hosting and email are separate
The thing that makes a migration like this safe is realizing your domain does three independent jobs:
- Registration — who you renew the name with (for me, the registrar, untouched).
- Website hosting — what serves the pages (this is the only thing changing).
- Email routing — the
MXand related records that deliver mail.
Website hosting is controlled by a couple of DNS records (A for the apex, CNAME for www). Email is controlled by completely different records (MX, SPF/TXT, DKIM). As long as you only touch the first set, email keeps working as if nothing happened. That was my hard rule for the whole project.
Step 1 — Build and publish first, point DNS last
The cardinal rule of a cutover: never repoint the domain at an empty destination. I built the new static site, pushed it to a public repo, and enabled GitHub Pages so it was already live at the *.github.io URL. Only once I'd confirmed it rendered did I touch DNS.
Step 2 — Connect the custom domain
In the repo, GitHub Pages lets you set a custom domain, which writes a CNAME file into the repo. For an apex domain like logansmith.us, GitHub publishes a set of A records to point at:
185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153
And www becomes a CNAME to <username>.github.io. Crucially, this all stays at my existing DNS host — no nameserver migration, so the email records never move.
Step 3 — Change exactly two records
At the DNS host I changed the apex A record(s) to the GitHub IPs and the www CNAME to my GitHub Pages target. I left everything else — the MX records, the SPF TXT, and the mail-provider verification records — completely alone. A quick way to prove email is safe before and after:
dig +short logansmith.us MX
dig +short logansmith.us A
If the MX answer is identical before and after your change, your mail path is untouched.
The gotchas
Browser/OS DNS caching. Right after the change, my browser still showed the old site. That's not a failure — recursive resolvers and your own machine cache the old records until the TTL expires. Querying an authoritative nameserver directly (or a public resolver like 1.1.1.1) shows the truth immediately.
HTTPS certificate timing. GitHub only requests a TLS certificate after your DNS resolves to them. So for a little while you'll see a certificate-name mismatch. If it seems stuck (because an earlier attempt failed while DNS still pointed elsewhere), the reliable fix is to remove the custom domain in the Pages settings and re-add it — that re-triggers a fresh certificate request now that DNS checks out.
HSTS surprises. If your old host set HSTS, your browser will refuse plain HTTP and demand a valid cert — which makes that cert-provisioning window look scarier than it is. It clears itself the moment the certificate lands.
The result
- Same domain, same email, zero downtime that any real visitor would notice.
- Hosting cost went from $204/year to $0.
- The site is now a plain, fast, version-controlled static site I fully own — and rebuilding it became a fun weekend project instead of a chore.
If you've been paying builder pricing to host static pages, this is one of the highest-leverage afternoons you can spend. Just remember the one rule: touch the website records, never the mail records.