Search Console에서 sitemap 가져올 수 없음이 뜰 때 확인한 것

Search Console에 sitemap을 넣었는데 “가져올 수 없음”이 떴습니다. 처음에는 sitemap 파일이 깨졌다고 생각했습니다. 솔직히 말하면, 그 순간 바로 설정 파일을 또 고치고 싶었습니다.

그런데 Daejin Lab을 만들면서 배운 게 하나 있습니다. Search Console 화면만 보고 바로 손대면, 원인이 더 섞입니다. 그래서 이번에는 사이트 쪽에서 실제로 열리는지부터 하나씩 봤습니다.

처음에는 파일이 없는 줄 알았다

처음 확인한 주소는 당시 공개 주소였던 pages.dev 쪽 sitemap이었습니다.

https://daejin-lab-blog.pages.dev/sitemap-index.xml

파일 자체는 열렸습니다. 여기서 조금 멈췄습니다. “가져올 수 없음”이라고 해서 파일이 없는 줄 알았는데, 브라우저에서는 보였기 때문입니다.

이 흐름은 파일 유무보다 URL 기준과 대기 판단을 우선하는 검사 순서입니다.

문제는 안쪽 주소였습니다. sitemap index 안에 들어 있는 실제 sitemap 주소가 제가 Search Console에 등록한 주소와 달랐습니다.

https://daejinlab.com/sitemap-0.xml

당시 Search Console 속성은 pages.dev 기준이었는데, sitemap 내부는 daejinlab.com을 가리키고 있었습니다. 파일이 없는 문제가 아니라, 기준 도메인이 섞인 문제였습니다.

고친 파일은 세 개였다

도메인 기준을 맞추기 위해 아래 파일부터 봤습니다.

astro.config.mjs
src/consts.ts
public/robots.txt

정적 블로그에서는 site 값 하나가 생각보다 멀리 갑니다. canonical, sitemap, robots까지 이어집니다. 그래서 한 파일만 보고 끝내지 않았습니다.

당시에는 공개 주소 기준으로 값을 맞춘 뒤 다시 빌드했습니다.

npm run build

빌드가 통과한 뒤에는 dist 안에 생성된 sitemap도 봤습니다. 설정만 바꿨다고 믿지 않고, 실제 결과 파일이 어떤 주소를 품고 있는지 열어봤습니다.

제가 확인한 값들

수정 뒤에는 아래를 봤습니다.

robots.txt 상태: 200 OK
sitemap.xml 상태: 200 OK
sitemap-index.xml 상태: 200 OK
sitemap 안 URL 개수
예전 도메인이 남아 있는지
새 글 URL이 sitemap에 들어갔는지
대표 글 canonical이 현재 도메인인지

여기서 sitemap 파일 하나만 보면 계속 헷갈렸습니다. robots.txt가 어떤 sitemap을 가리키는지, sitemap 안 URL은 어느 도메인인지, 대표 글 canonical은 어디를 가리키는지 같이 봐야 했습니다.

하나만 맞고 나머지가 어긋나면 Search Console 입장에서는 애매한 사이트처럼 보일 수 있습니다.

Search Console 화면은 늦게 바뀔 수 있다

사이트 쪽을 고친 뒤에도 Search Console에는 한동안 “가져올 수 없음”이 남아 있을 수 있습니다. 이 부분이 제일 답답했습니다. 파일은 열리는데 화면은 실패라고 하니까요.

그래서 저는 아래 조건을 기준으로 나눠서 봤습니다.

robots.txt에서 차단하지 않는다
sitemap 파일이 200으로 열린다
XML이 깨지지 않는다
sitemap 안 URL도 200으로 열린다
canonical이 현재 도메인을 가리킨다
noindex가 없다
x-robots-tag가 없다

이 조건이 맞으면, 바로 파일을 또 고치기보다 기다리는 쪽이 낫다고 봤습니다. Search Console 상태 표시가 늦는 것과 사이트 파일이 잘못된 것은 다른 문제였습니다.

30개 글까지 늘린 뒤 다시 본 결과

글을 30개까지 채운 뒤 같은 항목을 다시 봤습니다. 그때도 Search Console 화면은 아직 깔끔하지 않았지만, 공개 사이트 기준으로는 막힌 부분이 보이지 않았습니다.

/robots.txt: 200 OK
/sitemap.xml: 200 OK
/sitemap-index.xml: 200 OK
/sitemap-0.xml: 200 OK
/sitemap.txt: 200 OK
sitemap.xml URL 수: 42개(당시 기준)
sitemap 안 URL: 모두 200 OK
Googlebot User-Agent 기준 접근: 정상

이때부터는 판단이 조금 바뀌었습니다. “Search Console이 실패라고 하니까 뭔가 더 고쳐야 한다”가 아니라, “사이트 쪽 증거가 정상이라면 잠깐 기다린다”에 가까웠습니다.

실제로 볼 때는 브라우저보다 요청 기준이 더 편했습니다.

curl -I -A 'Googlebot/2.1 (+http://www.google.com/bot.html)' \
  https://daejin-lab-blog.pages.dev/sitemap.xml

나중에 운영 도메인을 https://daejinlab.com으로 정리한 뒤에는 같은 확인을 운영 도메인 기준으로 다시 했습니다.

계속 고치지 않기로 한 이유

Search Console 화면이 늦게 바뀌면 뭔가 더 해야 할 것 같은 기분이 듭니다. sitemap.txt도 넣어보고 싶고, robots.txt도 다시 만지고 싶고, canonical도 다시 확인하고 싶습니다.

그런데 이 상태에서 계속 바꾸면 원인을 잃습니다.

그래서 저는 아래 조건이 맞으면 멈추기로 했습니다.

/sitemap.xml 공개 접근 가능
/sitemap-index.xml 공개 접근 가능
robots.txt에서 sitemap 주소 확인 가능
대표 글 URL이 200으로 열림
canonical과 noindex 상태에 문제 없음

이 조건이 맞으면 다음 작업은 sitemap 파일 수정이 아니라 URL 검사, 색인 요청, 콘텐츠 보강입니다. 같은 흐름은 사이트맵이 정상인데 Search Console은 실패할 때 다음에 한 일에 이어서 적었습니다.

커스텀 도메인으로 옮긴 뒤의 기준

이후 Daejin Lab은 production 도메인을 https://daejinlab.com으로 맞췄습니다. 도메인이 바뀌면 sitemap 문제를 다시 볼 수밖에 없습니다. 예전 주소가 남아 있으면 같은 문제가 반복되기 때문입니다.

지금은 아래 순서로 봅니다.

1. 현재 production 도메인이 무엇인지 확인한다.
2. astro.config.mjs와 SITE_URL 기준을 맞춘다.
3. /robots.txt가 현재 sitemap을 가리키는지 본다.
4. /sitemap.xml과 /sitemap-index.xml을 직접 연다.
5. 대표 글 canonical이 현재 도메인인지 확인한다.

이 순서가 맞으면 sitemap 파일을 자꾸 흔들지 않습니다. 그다음은 콘텐츠와 색인 요청 쪽 문제로 분리해서 봅니다. robots.txt와 canonical을 점검하며 확인한 색인 기본 조건도 같은 흐름에서 이어집니다.

지금 남긴 기준

이번 문제의 원인은 sitemap 파일이 없어서가 아니었습니다. 등록한 사이트 주소와 sitemap 내부 주소가 달랐던 것이 핵심이었습니다.

정적 블로그에서는 도메인을 바꿀 때 site 설정, robots, sitemap, canonical이 같이 움직입니다. 하나만 고치면 된다고 생각하면 다시 헷갈립니다.

지금 제 기준은 단순합니다. 공개 URL이 200이고, XML이 파싱되고, 대표 글 canonical이 현재 도메인을 가리키면 파일 수정은 멈춥니다. Search Console 화면은 조금 기다립니다. 그동안에는 sitemap을 계속 만지기보다 글 품질과 내부 링크를 보강하는 쪽이 낫다고 봅니다.

이 글에서 가장 중요한 판단

이 글에서 남기고 싶었던 건 sitemap을 고친 방법보다, 더 고치지 않기로 한 순간이었습니다. Search Console 화면만 보면 계속 수정하고 싶어집니다. 하지만 공개 sitemap이 열리고, robots.txt가 같은 주소를 가리키고, canonical이 production 도메인으로 맞아 있다면 성급한 수정이 오히려 문제를 늘릴 수 있습니다.

AdSense 신청 전에도 이 판단을 남겨두고 싶었습니다. 심사 전에 사이트 구조를 계속 흔들면, 제가 무엇을 검증했는지 설명하기 어려워집니다. 그래서 이 글은 오류 해결기이면서 동시에 “기술 SEO를 과하게 만지지 않는 선”을 보여주는 글로 두었습니다.

고치고 싶은 마음을 잠깐 멈췄다

sitemap 오류를 처음 봤을 때는 바로 설정을 뜯어고치고 싶었습니다. 그런데 공개 URL에서 XML이 열리고, robots.txt가 같은 주소를 가리키고, canonical도 맞다면 이야기가 달라집니다. 그 다음부터는 코드 수정이 아니라 기다림과 개별 URL 확인의 영역일 수 있었습니다.

2026-05-23 기준으로 다시 확인한 공개 값

AdSense 등록을 마친 뒤 이 글을 다시 읽으면서, 예전 Search Console 화면보다 지금 공개 사이트에서 직접 열리는 값이 더 중요하다고 봤습니다. 그래서 계정 화면을 캡처하지 않고, 공개 URL만 다시 확인했습니다.

2026-05-23 KST 기준 공개 URL 확인값입니다. Search Console 속성명이나 계정 정보는 넣지 않았고, 외부에서 누구나 볼 수 있는 경로만 적었습니다.

이 확인을 넣은 이유는 단순합니다. Search Console 화면은 늦게 바뀔 수 있지만, 공개 URL은 제가 직접 열어볼 수 있습니다. 둘을 섞으면 계속 설정을 고치고 싶어집니다.

내가 직접 확인할 수 있는 것: robots, sitemap, 대표 URL, canonical, noindex 여부
Google 화면에서 기다려야 하는 것: 처리 상태, 발견/색인 반영, 보고서 갱신

robots, sitemap, canonical을 한 줄로 보지 않기

예전에는 sitemap 하나만 보려고 했습니다. 지금은 흐름을 나눠서 봅니다.

Daejin Lab에서 쓰는 색인 기본 확인 흐름입니다. 이 흐름이 맞으면 Search Console 보고서가 늦는 동안 sitemap 파일을 계속 흔들지 않습니다.

확인한 자료와 기록

이 글을 보강하면서 참고한 공식 문서는 아래입니다.

공식 문서에서 확인한 것은 “sitemap 제출/URL 검사/robots 계열 신호는 서로 다른 확인 지점”이라는 점입니다. 제 판단은 그다음입니다. 공개 파일이 정상이라면, 바로 코드를 다시 고치지 않고 콘텐츠 품질과 내부 링크를 먼저 봅니다.

자주 묻는 질문

sitemap이 200이면 Search Console 오류는 무시해도 되나요?

무시라기보다 분리해서 봅니다. sitemap이 200이고 XML이 정상이어도 Search Console 보고서가 바로 바뀌지 않을 수 있습니다. 다만 robots 차단, noindex, canonical 불일치가 있으면 별도 문제입니다.

sitemap을 여러 번 다시 제출하면 빨리 해결되나요?

저는 그렇게 보지 않았습니다. 같은 파일을 계속 다시 제출하기보다, 공개 URL·robots·canonical·대표 글 접근을 확인한 뒤 기다리는 쪽이 원인 추적에 더 안전했습니다.

이 글에서 아직 확인하지 않은 것은 무엇인가요?

Google 내부 처리 시간은 제가 확인할 수 없습니다. 그래서 이 글은 “Google이 언제 반영한다”가 아니라 “내가 사이트 쪽에서 어디까지 확인했고, 어디서 멈췄는지”를 남긴 기록입니다.

FAQ

sitemap이 200이면 Search Console도 바로 성공해야 하나요?

항상 그렇지는 않습니다. 서버에서 열리는 것과 Search Console이 가져가고 처리하는 것은 다른 단계입니다.

언제까지 기다려야 하나요?

정확한 보장 시간은 없습니다. Daejin Lab에서는 공개 URL, robots, canonical, sitemap을 확인한 뒤 같은 조작을 반복하지 않고 날짜를 남깁니다.

사이트가 기술적으로 접근 가능한지, 운영자가 어떤 기준으로 문제를 확인하는지 보여주는 대표 글이기 때문입니다.