GitHub Pages 사이트맵이 3개월간 '가져올 수 없음'이던 진짜 이유 — 크롤링 통계가 답이었다

github.io 블로그의 sitemap.xml이 3개월간 Search Console에서 '가져올 수 없음'이었다. 기술 SEO는 만점, 서버 응답은 200, 그런데 색인은 홈 1페이지뿐. 크롤링 통계 보고서에서 원인을 찾고 커스텀 도메인으로 해결하기까지, 실패한 시도까지 전부 기록했다.

게시 2026/09/15

90일간 크롤링 요청 48건 중 신규 발견 목적은 2%뿐임을 보여주는 그래프

By riririb

조회 15 분읽는 시간

GitHub Pages 사이트맵이 3개월간 '가져올 수 없음'이던 진짜 이유 — 크롤링 통계가 답이었다

문제

블로그를 6월에 열고 글을 28개 썼다. 그런데 구글 검색에는 홈페이지 하나만 잡혔다.

Search Console의 사이트맵 상태는 3개월 내내 똑같았다.

/sitemap.xml    상태: 가져올 수 없음    발견된 페이지: 0

이상한 건 빙(Bing)에서는 같은 사이트가 20페이지 넘게 정상 색인되고 있었다는 점이다. 사이트가 망가진 게 아니라는 뜻이었다.

원인을 찾기까지 — 실패한 시도들

같은 증상으로 검색해 들어온 분을 위해, 효과가 없었던 것부터 적는다. 이걸 먼저 알았다면 두 달은 아꼈다.

① 기술 SEO 점검 — 전부 통과 (원인 아님)

구글 공식 SEO 스타터 가이드의 항목을 하나씩 실측으로 대조했다.

항목	결과
robots.txt가 CSS·JS를 막고 있나	안 막음, 리소스 전부 200
글마다 고유한 title·description	28개 중복 0건
canonical	전부 자기 자신으로 정확
이미지 alt	누락 0건
홈에서 글로 가는 링크	HTML에 실재 (JS 렌더링 아님)
사이트맵 XML 유효성	`xmllint` 통과

PageSpeed Insights의 SEO 점수도 100점이었다. 고칠 게 없었다.

② 사이트맵 품질 정리 — 개선은 됐지만 해결은 아님

사이트맵 135개 URL을 뜯어보니 92개(68%)가 태그 목록 페이지였다. 그중 68개는 글이 딱 1개뿐인 페이지였다. 저가치 URL이 실제 글보다 많은 구조였다.

플러그인으로 태그·카테고리 페이지를 사이트맵에서 빼고 noindex, follow를 붙여 135개 → 38개로 줄였다. 사이트맵 품질은 확실히 좋아졌지만, 상태는 여전히 “가져올 수 없음”이었다.

③ XML 헤더 최소화 — 헛다리

Chirpy 이슈에 “jekyll-sitemap의 긴 urlset 헤더를 GSC가 파싱 못 한다”는 가설이 있었다. 구글 문서의 최소 형태로 바꿔봤다.

  
<!-- 이전 -->
<urlset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="... sitemap.xsd"
        xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<!-- 이후 -->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

8일을 기다렸지만 변화 없음. 나중에 정상 색인되는 같은 테마 블로그를 확인해 보니 그쪽은 긴 헤더를 그대로 쓰고 있었다. 애초에 원인이 아니었다.

④ RSS·Atom을 사이트맵으로 제출 — 역시 실패

구글은 RSS 2.0과 Atom 1.0 피드를 사이트맵으로 받아준다. 생성 경로가 완전히 다른 파일이니 sitemap.xml만의 문제라면 우회될 거라 봤다.

rss.xml(글 20개), feed.xml(글 5개)을 추가로 제출했다. 셋 다 똑같이 “가져올 수 없음”이었다. 이 시점에 “파일이 문제”라는 가설군은 전부 기각됐다.

⑤ 색인 요청 28건 · 백링크 — 무효

글 28개를 URL 검사에서 하나씩 색인 요청했다. 2주 뒤에도 색인은 1페이지 그대로였다.

velog에 글을 써서 dofollow 백링크도 만들었다. velog 글이 구글에 색인된 것까지 확인했는데도, Search Console 링크 보고서의 외부 링크는 0개였다. 심지어 내부 링크도 0개였다. 글끼리 서로 링크가 잔뜩 걸려 있는데도.

이때 감이 왔다. 구글이 링크를 못 찾는 게 아니라, 이 사이트의 링크 관계를 집계조차 안 하고 있다.

⑥ 이미 폐지된 방법에 시간 쓰기

검색하면 아직도 많이 나오는 조언이 있다.

https://www.google.com/ping?sitemap=https://example.com/sitemap.xml

직접 호출해 봤다.

HTTP 404
<TITLE>Sitemaps ping is deprecated.</TITLE>

2023년 6월에 폐지됐다. 구글이 404와 함께 안내 문구를 돌려준다. 블로그 글이나 AI 답변에서 이 방법을 권하면 그건 오래된 정보다.

원인 — 크롤링 통계에 답이 있었다

그동안 한 번도 안 열어본 보고서가 있었다. 설정 → 크롤링 통계다.

숫자가 전부 설명해 줬다.

항목	값
총 크롤링 요청(90일)	48건 (하루 0.5건)
목적: 새로고침	98%
목적: 검색(신규 발견)	2% ← 48건의 2% = 약 1건
응답 성공(200)	96%
호스트 상태	최근 90일간 문제 없음
파일 형식	이미지 48%, JS 23%, HTML 15%

구글은 90일 동안 “새 글을 찾으러 오는 크롤링”을 사실상 1건 했다. 나머지 98%는 이미 아는 홈페이지와 이미지를 다시 확인한 것뿐이다. HTML 페이지는 3개월 통틀어 7건쯤 가져갔다.

여기서 구조 문제라는 가설이 완전히 기각된다. 구조가 나빴다면 4xx·5xx가 뜨거나, 크롤은 하는데 색인을 거부해야 한다. 그런데 응답은 96%가 200이고 호스트 문제도 없다. 애초에 요청을 안 한다.

문을 두드린 적이 없으니 집 구조가 문제일 수가 없었다.

증상이 전부 이 하나로 설명된다.

사이트맵 “가져올 수 없음” → 사이트맵 가져오기 자체가 발견 작업인데 예산이 없음
외부·내부 링크 0개 → 페이지를 안 긁으니 링크를 볼 기회가 없음
색인 1페이지 → 홈만 새로고침 대상으로 유지

해결 — 커스텀 도메인

Chirpy 테마 저장소의 이슈 #2658에 같은 증상이 여러 건 있었다. 해결 보고는 두 사람, 방법은 같았다.

“도메인을 빌렸더니 GSC가 문제없이 받아들입니다. Sitemap processed successfully.”

“몇 달을 기다렸고 Googlebot으로 fetch 검증까지 다 해봤지만 실패했습니다. 도메인을 등록하고 DNS로 소유확인하니 — 호스팅은 GitHub Pages 그대로인데 — 사이트맵이 즉시 제출됐습니다.”

Cloudflare Registrar에서 .com 도메인을 샀다. 연 $10.46, 갱신도 같은 값이다(원가 판매라 마크업이 없다). 환율 1,342원 기준 약 14,000원.

DNS 설정

GitHub Pages IP는 dig로 실측해서 넣었다.

dig +short <username>.github.io A
# 185.199.108.153 ~ 185.199.111.153

유형	이름	값
A	`@`	185.199.108.153
A	`@`	185.199.109.153
A	`@`	185.199.110.153
A	`@`	185.199.111.153
CNAME	`www`	`<username>.github.io`

주황색 구름(프록시)을 켜면 안 된다. Cloudflare 프록시가 켜져 있으면 GitHub이 HTTPS 인증서를 발급하지 못한다. 전부 DNS only(회색 구름) 로 둬야 한다.

레코드 5개는 BIND 존 파일로 한 번에 넣는 게 빠르다.

example.com.        1  IN  A      185.199.108.153
example.com.        1  IN  A      185.199.109.153
example.com.        1  IN  A      185.199.110.153
example.com.        1  IN  A      185.199.111.153
www.example.com.    1  IN  CNAME  <username>.github.io.

순서를 지켜야 하는 이유

DNS를 먼저 넣고, 그다음에 GitHub Pages 커스텀 도메인을 설정해야 한다. 순서를 바꾸면 위험하다. 커스텀 도메인을 등록하는 순간 GitHub이 <username>.github.io → 새 도메인으로 리다이렉트를 걸어버리는데, DNS가 준비 안 됐으면 블로그가 통째로 접속 불가가 된다.

DNS 전파를 확인한 뒤 저장소에 CNAME 파일과 _config.yml의 url을 바꾸고 Pages 설정을 걸었다. 인증서는 authorization_created → authorized → approved로 1분쯤 걸렸고, 그다음 HTTPS 강제를 켰다.

핵심 — GSC는 ‘도메인’ 속성으로 새로 만든다

기존 URL 접두어 속성이 아니라 도메인 속성(sc-domain:) 을 새로 만들어야 한다. 이게 DNS 소유확인을 쓰는 유일한 방식이고, 이슈에서 해결한 사람들이 공통으로 언급한 부분이다.

인증 단계에서 구글이 “Cloudflare 계정에 접근 허용”을 권하는데, 드롭다운을 “모든 DNS 제공업체” 로 바꾸면 수동 TXT 방식이 나온다. 계정 권한을 넘기지 않고도 된다.

TXT  @  google-site-verification=...

결과

사이트맵을 제출하자마자였다.

	3개월간	도메인 연결 직후
상태	가져올 수 없음	성공
발견된 페이지	0	46
마지막으로 읽은 날짜	비어 있음	당일

3개월 동안 사이트맵·RSS·Atom 세 가지를 아무리 제출해도 안 되던 것이, 도메인을 바꾸자 첫 제출에서 46페이지를 전부 읽어갔다.

기존 주소는 GitHub이 자동으로 301 리다이렉트를 걸어준다. 인스타그램·velog에 뿌려둔 기존 링크는 그대로 살아 있다.

🧭 기획자·사업자라면 무료 인프라의 비용은 0이 아니다. 연 14,000원짜리 도메인을 아끼려다 3개월과 여러 날의 작업 시간을 썼다. 무료 서비스의 제약은 보통 “기능 제한”으로 표시되지만, 실제로는 플랫폼이 당신을 어떻게 취급하는가로 나타난다 — 이 경우엔 크롤 예산이었다. 그리고 “로그가 깨끗하다”가 “정상”은 아니다. 3개월간 에러가 하나도 없었지만 그건 잘 돌아가서가 아니라 아무 일도 일어나지 않아서였다. 성과가 없을 때는 실패 로그가 아니라 활동량 지표를 봐야 한다. 마케팅이든 운영이든 같다.

사용한 기술

Google Search Console 크롤링 통계 — 설정 → 크롤링 통계. 총 요청 수, 목적(새로고침/발견), 응답 코드, 파일 형식, 호스트 상태. 색인이 안 될 때 가장 먼저 볼 보고서다.
Cloudflare Registrar — 도메인 원가 판매(마크업 0), 갱신가 동일, WHOIS 프라이버시 무료. 단 네임서버를 Cloudflare로 써야 한다.
GitHub Pages 커스텀 도메인 — 저장소 루트 CNAME 파일 + Pages 설정. gh api -X PUT repos/OWNER/REPO/pages -f cname=...로 CLI에서도 된다.
GSC 도메인 속성(sc-domain) — DNS TXT 소유확인. 하위 도메인·프로토콜 전부 한 속성으로 묶인다.
dig — 실제 IP와 전파 상태 확인. 문서의 IP를 믿지 말고 dig +short <username>.github.io A로 확인하는 게 안전하다.

정리

색인이 안 될 때 크롤링 통계의 “목적: 검색(발견)” 비율을 먼저 봐라. 이게 바닥이면 사이트맵을 몇 번 제출하든 소용없다.
응답이 전부 200이고 호스트 문제가 없는데 색인이 안 된다면, 문제는 사이트가 아니라 크롤 예산 배정이다.
*.github.io에서 이 증상이 나오면 커스텀 도메인이 현재까지 확인된 해법이다. 연 1.4만 원이고, 기존 링크는 301로 유지된다.

개발, 트러블슈팅