HTTPS·커스텀 도메인 DNS 연결 체크리스트

도메인 연결은 “레코드 하나 추가”로 끝나지 않습니다. 서민혁닷컴은 apex(seominhyuk.com)를 대표 주소로 두고, Workers Custom Domain으로 붙였습니다. 겉으로는 단순해 보였는데, DNS·프록시·보안 설정이 겹치면서 “배포는 됐는데 구글이 못 읽는” 상태가 됐습니다.

대표 주소부터 고정

저는 apex를 기준으로 잡았습니다. sitemap, canonical, OG URL, Search Console 모두 https://seominhyuk.com으로 통일합니다. www는 있으면 같은 사이트로 열고, 없으면 나중에 붙여도 됩니다. 중요한 건 문서마다 다른 호스트가 섞이지 않는 것입니다.

workers.dev는 미리보기용으로만 씁니다. 글 안의 절대 URL에 workers.dev를 넣지 않습니다.

Workers용 DNS가 어떻게 생겼는지

Custom Domain을 붙이면 apex에 대략 이런 식이 생깁니다.

AAAA → 100::, Proxied(주황구름)

이건 “내 서버 IP”가 아니라 Cloudflare가 Workers로 라우팅할 때 쓰는 자리표시에 가깝습니다. 예전에 쓰던 A/CNAME이 같은 이름에 남아 있으면 충돌하니, 운영에 안 쓰는 레코드는 지웁니다.

Search Console 도메인 확인용 TXT(google-site-verification=…)는 프록시와 무관하게 apex에 두면 됩니다. 우리 존에는 이미 TXT가 있어서, 콘솔에서 확인만 누르면 되는 상태였습니다.

www를 나중에 붙인 방법

www.seominhyuk.com은 처음엔 DNS조차 없었습니다. Custom Domain API가 계정 토큰 방식 때문에 거절돼서, 대신:

www에 AAAA 100:: Proxied 추가
Workers Route: www.seominhyuk.com/* → warpsense-blog

으로 연결했습니다. 로컬 DNS 캐시 때문에 Could not resolve host가 한동안 날 수 있습니다. dig @1.1.1.1 www.seominhyuk.com AAAA로 전파를 보고, 필요하면 apex와 같은 Cloudflare anycast IP로 --resolve 해서 응답만 먼저 확인했습니다.

HTTPS와 “열리는데 본문이 없는” 함정

자물쇠가 켜져 있어도, Bot Fight / Managed Challenge가 있으면 사람 브라우저만 통과하고 봇은 Just a moment... HTML을 받습니다. DNS·인증서는 정상인데 검수만 실패하는 패턴입니다. 도메인을 붙인 뒤 꼭:

curl -sI -A "AdsBot-Google (+http://www.google.com/adsbot.html)" https://your.domain/

로 cf-mitigated: challenge가 없는지 봅니다.

서브도메인으로 앱·블로그를 나누는 이야기는 서브도메인으로 서비스 나누기에 있습니다. 블로그 apex만 쓸 때도 app. / crawl.을 나중에 붙일 여지를 DNS에 남겨 두면 편합니다.

한 줄로 말하면: 대표 호스트 하나로 문서를 맞추고, Workers용 레코드를 정리하고, HTTPS 다음에 봇 응답까지 확인하면 도메인 작업이 끝납니다.