GitHub Pages 커스텀 도메인 연결 4단계 — Cloudflare DNS·CNAME·HTTPS 자동·검색엔진 재등록

·#GitHub Pages #커스텀 도메인 #CNAME #DNS #Cloudflare #A record #HTTPS #Lets Encrypt #도메인 migration #SEO

taystudio.github.io 를 taystudios.com 으로 옮긴 작업 후기. 2026-05-09 에 했고, 6/5 시점에 30일 데이터 다 나왔으니 실측까지 같이 정리함.

왜 옮겼나

.github.io 도 잘 굴러간다. 한국 SEO 만 보면 차이도 별로 없음. 그런데 4가지가 걸렸음.

  • 도메인 권위가 0부터 시작 — .github.io 가 Public Suffix List 에 등재돼서 브라우저·검색엔진이 서브도메인 으로 취급. taystudio.github.io 와 someone.github.io 가 서로 영향 안 주게끔 격리됨. 좋은 건데 권위가 누적이 안 됨.
  • AdSense 영어 RPM — 영어권에서 .github.io URL 은 개발자 블로그 인상이라 일반인 CTR 이 낮음. 보통 RPM $1~3 정도. .com 으로 가면 $3~8 까지 봤다는 사례 많음.
  • 언론·매체 백링크 — .github.io 는 인용 자체를 피하는 경향. 진지한 출처로 안 보임.
  • 브랜드 — URL 에 "github" 박혀있는 거 자체가 brand 가 약함.

영어 시장 + AdSense + brand 셋 다 결정적이라 옮기기로 함. 다만 타이밍이 중요. URL 백 개 쌓이고 백링크 박히기 시작하면 옮기는 비용 폭증. 우리 사이트는 그때 100개 정도였어서 지금이 적기였음.

4단계 요약

① Cloudflare DNS 설정    (A 4개 + CNAME www)
② GitHub repo CNAME 파일 (1줄)
③ 사이트 일괄 치환        (canonical·sitemap·robots)
④ 검색엔진 재등록         (GSC·Naver·Bing·Daum)

다운타임 0초. 양쪽 도메인 다 살아있는 상태로 점진 전환됨.

1. Cloudflare DNS 설정

도메인은 Cloudflare Registrar 에서 샀음 (가비아·후이즈 다 가능). DNS 도 Cloudflare 가 가장 빠르고 무료.

UI — 어디서 뭘 누르나

  1. dash.cloudflare.com 로그인 → 사이트 클릭 → 좌측 메뉴 DNS → Records.
  2. Add record 버튼 → 아래 5개 입력:
Type Name Content (Value) Proxy status
A @ 185.199.108.153 DNS only (회색 구름)
A @ 185.199.109.153 DNS only
A @ 185.199.110.153 DNS only
A @ 185.199.111.153 DNS only
CNAME www <본인 username>.github.io DNS only

Name 칸에 @ 치면 자동으로 apex (taystudios.com) 로 변환됨. www 는 그냥 www 만 치면 www.taystudios.com 으로 잡힘.

함정 두 개

  • A record 4개 다 등록. GitHub Pages 가 4 IP 로 load balancing 함. 하나만 박으면 그 IP 다운 시 사이트 다운.
  • Proxy 처음엔 DNS only (회색 구름). 주황 구름 (Proxy ON) 으로 켜면 GitHub Pages 의 Let's Encrypt 인증서가 origin IP 를 못 잡아서 cert 발급 fail. 인증서 발급 끝난 다음에 Proxy 켜기.

확인

dig taystudios.com +short
# 185.199.108.153
# 185.199.109.153
# 185.199.110.153
# 185.199.111.153

dig www.taystudios.com +short
# taystudio.github.io.
# 185.199.108.153
# ...

전 세계 resolver 캐시까지 전파되는 데 보통 30분 ~ 24시간. 한국에서는 1시간 안에 됐음.

2. GitHub repo 의 CNAME 파일

이게 GitHub Pages 에 "이 repo 가 어떤 도메인 받을지" 알려주는 핵심 파일.

파일 만들기

repo 루트에 파일명 정확히 CNAME (확장자 X, 전부 대문자). 안에 한 줄:

taystudios.com

www 없는 apex 도메인. 끝.

GitHub UI 에서 설정

  1. repo 페이지 → 상단 Settings 탭.
  2. 좌측 메뉴 Pages.
  3. Custom domain 입력란에 taystudios.com 치고 Save.
  4. 잠시 후 (5~30분) ✓ DNS check successful 메시지 뜸.
  5. 그 아래 Enforce HTTPS 체크박스가 활성화되면 체크.

Custom domain 에 입력하면 GitHub 가 자동으로 repo 루트에 CNAME 파일 만들어줌. 위 1번처럼 직접 만들어도 똑같음.

Let's Encrypt 인증서

GitHub 가 Let's Encrypt 에서 SSL 자동 발급. 5분 ~ 30분. 발급되면 Enforce HTTPS 체크박스가 회색에서 클릭 가능한 상태로 바뀜.

90일마다 자동 갱신. 비용 0원. 설정 0개.

→ 발급 끝난 다음에 Cloudflare 로 돌아가서 Proxy 켜도 됨 (선택).

3. 사이트 일괄 치환

migration 에서 SEO 적으로 제일 중요한 부분. 옛 도메인 가리키는 URL 이 어디 하나라도 남아있으면 Google 이 옛 도메인을 canonical 로 인식해서 권위 이전이 안 됨.

바꿔야 할 곳

영역 변경
<link rel="canonical"> taystudios.com/...
<meta property="og:url"> 동일
<link rel="alternate" hreflang> 동일
sitemap.xml 의 <loc> 동일
robots.txt 의 Sitemap: URL 동일
llms.txt (있다면) 동일
schema.org JSON-LD 의 @id·url 동일
내부 절대 경로 link taystudio.github.io → taystudios.com
IndexNow key file URL 동일

우리 처리

build script (blog/scripts/build.py) 가 site.json 의 siteUrl 하나만 보고 전부 자동 갱신하게 짜여있어서 한 줄 바꾸고 빌드 한 번 돌리니 끝났음.

build script 안 쓰는 경우 sed 로:

# 옛 도메인 → 새 도메인 일괄 치환
grep -rl "taystudio.github.io" . | xargs sed -i '' 's|taystudio.github.io|taystudios.com|g'

(macOS sed 는 -i '', Linux 는 -i)

치환 후 GitHub 에 push 하면 자동 deploy.

4. 검색엔진 재등록

.com 은 Google·Naver·Bing·Daum 입장에서 신규 도메인. 옛 property 에 쌓인 데이터가 자동 이전되지 않으니 새로 등록.

Google Search Console

  1. search.google.com/search-console → 좌상단 속성 추가.
  2. URL 접두어 선택 → https://taystudios.com 입력.
  3. 소유권 확인 — HTML 태그 방법이 제일 쉬움. <meta name="google-site-verification" content="..."> 한 줄 받아서 <head> 에 박고 빌드 → 확인.
  4. 좌측 Sitemaps → sitemap.xml 입력 → 제출.
  5. URL 검사 → 우선 페이지 (홈·인기 글) URL 넣고 색인 생성 요청. 일 10개 한도.

→ Bing Webmaster 는 GSC sitemap 자동 import 기능 있음. GSC 만 하면 Bing 도 같이 잡힘.

  1. searchadvisor.naver.com 로그인 → 우상단 사이트 관리.
  2. 사이트 등록 → https://taystudios.com 입력.
  3. 소유권 확인 — HTML 파일 다운로드 받아서 사이트 루트에 업로드. 빌드 → 확인.
  4. 좌측 요청 → 사이트맵 제출 → sitemap.xml.
  5. 요청 → 웹페이지 수집 → 개별 URL 한 줄씩 (일 50건).

→ 한국 트래픽은 Naver 가 80% 받쳐주기 때문에 GSC 보다 Naver 가 더 급함.

Bing Webmaster

  1. bing.com/webmasters → Microsoft 계정 로그인.
  2. 사이트 추가 → GSC 에서 자동 import 권장.
  3. 옛 도메인 property 에서 사이트 이동 (Site Move) 기능 사용 가능. 명시적 신호 전달.

Daum 웹마스터 도구

(이름이 SearchAdvisor 아님. UI 상 메뉴는 여전히 "웹마스터 도구". URL 은 webmaster.daum.net)

  1. webmaster.daum.net → 카카오 로그인.
  2. 사이트 등록 → https://taystudios.com.
  3. 소유권 확인 — meta 태그 or 인증 토큰을 robots.txt 첫 줄에 추가.
  4. 사이트맵 메뉴 → sitemap.xml 제출.
  5. 수집 요청 → 개별 URL.

IndexNow (덤)

Bing·Yandex·Naver·Seznam 동시 ping. key 1번만 발급받아서 robots.txt 에 박아두면 됨.

curl "https://api.indexnow.org/IndexNow?url=https://taystudios.com/&key=<your-key>"

DNS·CNAME 이 뭔지

migration 하다 보면 이게 다 뭔 소린가 싶어서 정리. 알면 위 4단계가 왜 그렇게 생긴 건지 보임.

DNS = 전화번호부

사람은 이름 (taystudios.com) 기억, 컴퓨터는 IP (185.199.108.153) 만 인식. DNS 가 이름 → IP 통역.

브라우저가 IP 찾는 5단계

(resolver 캐시가 다 비었을 때)

브라우저
  → ISP DNS (KT·SKB 8.8.8.8 등)
  → Root nameserver (".")
  → TLD nameserver (".com")
  → 도메인 nameserver (Cloudflare)
  → A record 응답 (185.199.108.153)

실제로는 resolver 가 TTL (기본 1시간) 동안 캐시하기 때문에 매번 root 까지 안 감. 도메인 처음 사거나 DNS record 바꾸면 전 세계 resolver 캐시 비어서 5단계 다 돌아야 함 = DNS 전파 (propagation).

A vs CNAME

A record — 도메인 → IP 직접:

taystudios.com   A   185.199.108.153

CNAME — 도메인 → 다른 도메인 (alias):

www.taystudios.com   CNAME   taystudio.github.io

resolver 가 CNAME 받으면 "그 다른 도메인 A 를 다시 조회" 함. 한 단계 더 거치지만 앞 도메인 IP 바뀌어도 자동 따라가는 게 장점.

apex (zone root) 엔 CNAME 못 씀 — RFC 1912

taystudios.com 자체 = CNAME X. 다른 record (MX·NS) 와 충돌 나서 표준상 금지. www.taystudios.com·blog.taystudios.com = CNAME OK.

→ 그래서 apex 는 A 4개, www 는 CNAME 으로 잡는 거. Cloudflare 는 "CNAME flattening" 으로 apex CNAME 가능하지만 GitHub Pages 공식 권장은 A 4개.

Host header

GitHub Pages IP 4개 (185.199.108~111.153) 는 수백만 사이트 공유. 어떻게 내 사이트만 찾아오나?

HTTP/1.1 GET /
Host: taystudios.com   ← 이게 핵심

브라우저가 보내는 Host 헤더 + GitHub 내부에서 CNAME 파일 == "taystudios.com" 인 repo 찾아서 매핑. → 그래서 repo CNAME 파일 1줄이 결정적.

우리 실측 — sandbox 30일

5/9 migration 직후 30일 동안 데이터:

시점 GSC 노출 Naver 노출
5/9 (migration) 0 (옛 도메인 잔여)
5/14 (Week 1) 450 peak spike 시작
5/24 (Week 3) 10 (dip) 7,600 peak
6/2 (Week 4) ~0 2,000-3,000/일 안정

Google 은 sandbox 진입 명확. 6-12주 expected. Naver 는 sandbox 없어서 즉시 회복. 자세한 회고는 Google sandbox 한 달 실측 글에 따로 정리.

같은 작업 할 사람한테

  1. URL 적을 때 옮기기. 백링크 박히기 전이 제일 싸다. 100+ URL 쌓이면 redirect·canonical 작업 비용 폭증.
  2. 다운타임 0 — 양쪽 도메인 동시 작동함. 사용자가 옛 도메인으로 와도 GitHub 가 새 도메인으로 자동 redirect (단, 옛 repo 의 CNAME 파일 비워두기).
  3. canonical 일관성 — sed 든 build script 든 한 번에 일괄 치환. 하나라도 옛 도메인 남으면 권위 이전 fail.
  4. Google 만 보고 패닉 X — sandbox 라 한 달 노출 거의 0 됨. Naver·Bing·Cloudflare 합쳐서 보면 사이트 정상 돌아감이 보임.

도메인 옮기는 거 자체는 1시간이면 끝. 권위 이전만 1-3개월 기다리면 됨.

관련 글

관련 글

이 글 공유𝕏f

댓글