If you own a single domain but want to run two separate things on it — say, a static landing page on GitHub Pages at the root domain, and a blog on Blogger at a subdomain — you'll quickly discover that the actual mechanics of DNS, custom domain verification, and HTTPS certificate provisioning are scattered across three different systems that don't talk to each other and don't always explain their errors clearly.
This post documents the full setup, end to end: what records you need, what each provider actually requires, and the specific errors you're likely to hit along the way (all of which I hit myself while setting this up).
The goal, concretely:
example.com(the apex/root domain) → a static site hosted on GitHub Pagesblog.example.com(a subdomain) → a Blogger blog, with its originalxxxx.blogspot.comaddress redirecting to itwww.example.com→ optionally also works, redirecting to the apex
I'll use bojankomazec.com as the running example, since that's the domain I set this up on.
1. The Big Picture: Three Systems, One Domain
Before touching any settings, it helps to understand the three layers involved and what each one owns:
| Layer | What it controls | Where you configure it |
|---|---|---|
| DNS registrar (e.g. GoDaddy, Namecheap, Cloudflare) | Which records exist for your domain — A, CNAME, MX, etc. This is the actual "phone book" that tells the internet where to send traffic. | Your registrar's DNS management panel |
| GitHub Pages | Which domain(s) it will accept and serve your static site for, and whether it issues an HTTPS certificate for them | Repository → Settings → Pages |
| Blogger | Which domain(s) it will accept and serve your blog for, and whether it issues an HTTPS certificate for them | Blogger → Settings → Publishing |
The critical thing to understand: DNS records alone are not enough. Both GitHub Pages and Blogger require you to also tell them, inside their own settings, which custom domain you're using. If DNS points to them but their own settings don't know about your domain, you'll get connection errors — not because DNS is wrong, but because the receiving service doesn't recognize the incoming hostname and refuses it.
This is the single most common source of confusion in this kind of setup: DNS can be 100% correct and the site can still fail to load, because DNS and application-level domain configuration are two separate steps that both have to be done.
2. DNS Records You'll Need
Here's the full set, using bojankomazec.com as the example domain, blog as the subdomain, and bojankomazec as the GitHub username (so the Pages repo is bojankomazec.github.io).
Apex domain → GitHub Pages
DNS doesn't allow a CNAME record at the apex/root of a domain (technically, because the apex must also hold other record types like SOA and often MX, and a hostname can't mix CNAME with anything else). So GitHub Pages publishes a fixed set of IP addresses, and you point the apex at those directly with A records:
Type: A Host: @ Value: 185.199.108.153
Type: A Host: @ Value: 185.199.109.153
Type: A Host: @ Value: 185.199.110.153
Type: A Host: @ Value: 185.199.111.153(@ is the conventional way most DNS panels represent "the apex/root domain itself.") If your provider supports IPv6 and you want dual-stack support, GitHub also publishes AAAA records:
Type: AAAA Host: @ Value: 2606:50c0:8000::153
Type: AAAA Host: @ Value: 2606:50c0:8001::153
Type: AAAA Host: @ Value: 2606:50c0:8002::153
Type: AAAA Host: @ Value: 2606:50c0:8003::153Important: check whether your registrar auto-created a placeholder A record for @ when the domain was registered (many do, often pointing to a parking page). If so, delete it — a leftover default record will conflict with the four you're adding.
www subdomain → GitHub Pages (optional)
If you also want www.example.com to work (redirecting to the apex once GitHub verifies both), add:
Type: CNAME Host: www Value: bojankomazec.github.io.Note this points to your GitHub Pages hostname (<username>.github.io), not to a URL, and not to the repo's github.com page. A CNAME value is always a hostname, never a full URL with https:// or a path.
Blog subdomain → Blogger
Type: CNAME Host: blog Value: ghs.google.com.This is the one that trips people up: it's tempting to point this directly at your xxxx.blogspot.com address, since that's "where the blog lives." Don't do that. Blogger's custom-domain routing works through a shared Google endpoint (ghs.google.com) that inspects the incoming hostname and routes it to the correct blog based on what's configured in your Blogger account. Pointing the CNAME straight at your blogspot address sends the request to blogspot-specific infrastructure that doesn't know how to handle a request arriving under a different hostname — the connection gets abruptly closed rather than serving anything (ERR_CONNECTION_CLOSED in Chrome).
Blogger domain verification CNAME
Separately from the routing CNAME above, Blogger needs to confirm you actually own the subdomain before it'll accept it. When you enter your custom domain into Blogger's settings, it will generate a unique verification CNAME — something like:
Type: CNAME Host: <random-string> Value: gv-<random-string>.dv.googlehosted.com.This value is generated per-domain and per-account — you can't predict or reuse it, you have to copy it exactly from Blogger's settings screen after entering your custom domain. Add it as its own DNS record alongside the routing CNAME.
Gotcha: if you ever change which subdomain Blogger is using (e.g. you originally set it up as www.example.com and later switch to blog.example.com), the old verification CNAME becomes stale and should be deleted — Blogger will issue a new one specific to the new subdomain when you re-save.
Full example record set
A @ 185.199.108.153
A @ 185.199.109.153
A @ 185.199.110.153
A @ 185.199.111.153
CNAME www bojankomazec.github.io.
CNAME blog ghs.google.com.
CNAME <verify> gv-xxxxxxxxxxxx.dv.googlehosted.com.3. The GitHub Pages Side
- In your
<username>.github.iorepository, go to Settings → Pages. - Under Custom domain, enter your apex domain (e.g.
bojankomazec.com— nowww, nohttps://). - Save. GitHub will write a file literally named
CNAME(no extension) into the root of your repository, containing just the domain name. This file is how GitHub Pages knows which domain to serve your content for — DNS alone doesn't tell it this. - GitHub will attempt to verify your DNS. If your
Arecords are already correct, this usually succeeds quickly. If you see aDNS valid for primarymessage alongside a separatewww.example.com is improperly configuredwarning — that's normal. Thewwwcheck is a secondary, automatic check GitHub runs to see if it can also offerwwwsupport and a unified certificate; it doesn't block your primary domain from working. If your primary domain error clears and only thewwwone remains, your site is live. - Once verified, tick Enforce HTTPS (this option is often greyed out until GitHub finishes issuing a certificate — see the HTTPS section below).
4. The Blogger Side
- In Blogger, go to Settings → Publishing.
- Under Custom domain, enter your blog subdomain (e.g.
blog.bojankomazec.com). - Save. Blogger will likely reject the save the first time and show you the verification CNAME described above. Copy it exactly.
- Add both the routing CNAME (
ghs.google.com) and the verification CNAME to your DNS. - Wait for propagation (see below), then go back and save again in Blogger. It should now accept the domain.
- Check the Redirect domain setting on the same page carefully — see the dedicated warning about this below, it's a common trap.
- Look for an HTTPS availability toggle further down the page. It usually reads "Status: Unknown" for a while after you first set up the domain — this is Blogger's certificate issuance still in progress, not an error (see HTTPS section).
The "Redirect domain" trap
Blogger's Publishing settings include a "Redirect domain" option, something like "Redirect example.com to blog.example.com." This setting, if enabled, makes Blogger redirect your apex domain to your blog. If your apex domain is meant to serve something else entirely (like a GitHub Pages landing page, as in this setup), this option will silently hijack it — visitors to example.com will get redirected to your blog instead of seeing your landing page, even though your DNS and GitHub Pages configuration are both completely correct.
This setting can also change target without obviously telling you: if you initially set up Blogger's custom domain as www.example.com and later switch it to blog.example.com, the "Redirect domain" checkbox may still be checked, just silently re-pointed at whatever your current custom domain is. If you don't want your apex domain touched by Blogger at all, make sure this is switched off, and re-check it any time you change Blogger's custom domain setting.
5. HTTPS and Certificates: Why It Takes a While
Both GitHub Pages and Blogger use automated certificate issuance (GitHub uses Let's Encrypt; Google's infrastructure handles Blogger's) that kicks in after your domain passes DNS verification — not before, and not instantly.
What this means in practice:
- Your site can be fully reachable over plain
http://whilehttps://still fails, sometimes with a confusing certificate error, for anywhere from a few minutes to around 24–48 hours after you first set up or change a custom domain. - The specific error you'll likely see in Chrome during this window is something like:
Your connection is not private
net::ERR_CERT_COMMON_NAME_INVALID
This server could not prove that it is www.example.com;
its security certificate is from *.github.ioThis happens because the connection is reaching GitHub's infrastructure, but GitHub hasn't yet issued a certificate specifically covering your hostname, so it falls back to serving its generic wildcard certificate — which your browser correctly flags as invalid for your domain.
- Don't repeatedly remove and re-add the custom domain while waiting — each change can reset the certificate issuance queue and make the wait longer, not shorter.
- Once issuance completes,
https://starts working with no further action needed on your part.
A red herring worth knowing about: antivirus HTTPS scanning
If you inspect your site's certificate in Chrome and see something unexpected — like the certificate authority being your antivirus software (Avast, Kaspersky, and others do this) rather than Let's Encrypt or Google — this is not a sign of a compromised or misconfigured site. Many antivirus suites include an "HTTPS scanning" or "Web Shield" feature that intercepts encrypted connections locally, decrypting and re-encrypting them with a certificate the antivirus generated and installed into your system's trust store, in order to scan traffic for threats.
This substitution happens for every HTTPS site you visit, not just yours, so it's not diagnostic of anything wrong with your setup. To see the actual certificate your host issued, either temporarily disable the antivirus's HTTPS scanning feature, or check from an external tool that doesn't go through your local machine at all — such as SSL Labs' SSL Test, which queries your server directly.
6. Troubleshooting Toolkit
A handful of tools make this whole process far less guess-and-check:
dig <domain> <record-type>(Mac/Linux, or Windows via WSL) — queries DNS directly and shows you exactly what's published, bypassing any local caching. E.g.dig bojankomazec.com Aordig blog.bojankomazec.com CNAME.nslookup <domain>— similar, built into Windows natively.- dnschecker.org — checks DNS propagation across many resolvers worldwide simultaneously, which is invaluable for figuring out whether a record change has actually rolled out everywhere yet, or is still mid-propagation.
- SSL Labs SSL Test — inspects a site's actual certificate chain independent of your local browser/antivirus interference.
General debugging approach when something doesn't load:
- Confirm the DNS record itself is correct and propagated (dnschecker.org).
- Confirm the receiving service (GitHub Pages / Blogger) has the domain configured in its own settings, not just DNS.
- Try plain
http://beforehttps://— this isolates whether the problem is routing/configuration (affects both) or just certificate issuance (only affects https). - If a certificate error shows an unexpected issuer (like an antivirus name instead of Let's Encrypt/Google), suspect local HTTPS interception before suspecting your DNS setup.
7. Common Errors and What They Actually Mean
| Error | What it usually means |
|---|---|
InvalidCNAMEError (GitHub) | The named subdomain's CNAME doesn't point where GitHub expects, or DNS hasn't propagated to the resolver GitHub's checker used yet. Verify with dnschecker.org before assuming misconfiguration. |
NotServedByPagesError (GitHub) | DNS looks fine, but the domain isn't yet resolving to GitHub Pages from GitHub's own check — often transient/propagation-related. |
ERR_CERT_COMMON_NAME_INVALID | The connection reached the right server, but no certificate has been issued for this specific hostname yet — a provisioning delay, not a misconfiguration. |
ERR_CONNECTION_CLOSED (on a Blogger subdomain) | Usually means the CNAME points somewhere that doesn't recognize the incoming hostname — most often, pointing directly at a .blogspot.com address instead of ghs.google.com. |
| A domain unexpectedly redirecting somewhere else entirely | Check Blogger's "Redirect domain" setting — it may be silently redirecting your apex domain to your blog. |
| Certificate issuer shown as an antivirus company | Local HTTPS scanning/interception by your antivirus software — check via an external tool instead. |
8. Summary Checklist
- Four
Arecords for the apex domain, pointing at GitHub Pages' published IPs - (Optional)
CNAMEforwwwpointing at<username>.github.io -
CNAMEfor your blog subdomain pointing atghs.google.com(not directly at your.blogspot.comaddress) - Blogger's unique verification
CNAME, copied exactly from its settings screen - Custom domain entered in GitHub Pages settings (creates the repo's
CNAMEfile) - Custom domain entered in Blogger's Publishing settings
- Blogger's "Redirect domain" setting switched off, unless you deliberately want your apex redirected to your blog
- Patience for HTTPS certificate issuance (minutes to ~48 hours) on both platforms
- Verify using
http://first, thenhttps://, and cross-check unexpected certificate issuers against local antivirus software before assuming a server-side problem
Once all of this settles, you end up with a clean split: your apex domain serving whatever static site or landing page you want full control over, and a subdomain serving your blog — both fully on their own custom domains, both secured with HTTPS, and both surviving independently of where the underlying content is actually hosted.
