Help

Use your own domain

Most people point a purchased apex domain at the site — for example open site A at example.com and site B at another.com. Subdomains (blog.example.com) and extra labels work too. In settings, fill the name visitors actually open.

① Tell GitPress the new address first

Links, images, and stylesheet paths are written in at compile time. If you open the site at example.com, that is the address to save in settings (same for subdomains: fill the name visitors actually open). Change DNS only and skip this step: the page may load, but images and CSS still point at the old github.io URL.

② Add the domain at the host

Compiled pages live in the public site repo (not the one ending in -data). Whichever static host you use, add the domain in that host’s dashboard. GitPress does not manage Cloudflare or Vercel DNS for you. Use the buttons below for the matching steps.

Pick a level first

Apex is recommended; subdomains and extra labels are just more prefixes. The steps are the same.

Address you want	What it’s called	Fill in settings
example.com	Apex domain (recommended)Use the name you bought as the site URL	example.com
blog.example.com	SubdomainA label in front of the apex; www counts	blog.example.com
docs.blog.example.com	Extra labelsMore prefixes; the steps are the same	docs.blog.example.com

Several sites: each gets its own apex

Site A uses example.com, site B uses another.com. On GitHub Pages the DNS value can be identical (both point at Pages). GitHub cares which site repo registered that name, not a repo name written into DNS. Do not put the repo name in the record.

Pick a host and follow its steps

Don’t point the same name at two hosts at once.

Keep using the GitHub Pages host created with the site. GitPress can register the domain with GitHub for you.

Admin → Settings → Site URL, choose GitHub Pages, fill the visitor URL (most people use example.com), and save.
Add records at your DNS host using the table. Apex and subdomain records differ.

Apex domain (recommended)

Host record @. Most DNS hosts do not allow a CNAME on the apex; use A / AAAA pointing at GitHub Pages:

Type	Host	Value
A	@	185.199.108.153
A	@	185.199.109.153
A	@	185.199.110.153
A	@	185.199.111.153
AAAA	@	2606:50c0:8000::153
AAAA	@	2606:50c0:8001::153
AAAA	@	2606:50c0:8002::153
AAAA	@	2606:50c0:8003::153

Subdomains

One CNAME is enough. Host record is the prefix(es) before the apex; value is <github-username>.github.io, without the repo name.

Type	Host	Value
CNAME	blog	<github-username>.github.io
CNAME	www	<github-username>.github.io
CNAME	docs.blog	<github-username>.github.io

That is blog.example.com, www.example.com, docs.blog.example.com. Check with dig +short CNAME blog.example.com

Cloudflare must be DNS only (grey cloud)

If the zone is on Cloudflare, records that point at Pages must be DNS only (grey cloud). With the orange proxy on, GitHub cannot issue a certificate.

Common pitfalls

You changed DNS but not the visitor URL

The page opens, but assets still point at /repo-name/.... Go back to settings, save the domain, and wait for that build to finish.

Apex set as a CNAME

Most DNS hosts do not allow a CNAME on @. Use A / AAAA for the apex; CNAME is for subdomains.

Pages and another host fighting over the same name

Unregister Pages in settings first, then add the domain on Vercel / Cloudflare. Two GitPress sites should not register the same domain either.

DNS is correct but the site is still 404

The rebuild probably hasn’t finished. Check GitPress Build on the data repo’s Actions tab.

Open the dashboard