사이트맵이 정상인데 Search Console은 실패할 때 다음에 한 일

sitemap이 정상인데 Search Console은 여전히 실패처럼 보일 때가 있습니다. 이때가 제일 헷갈렸습니다. 파일을 더 고쳐야 하는지, 그냥 기다려야 하는지 판단하기 어렵기 때문입니다.

Daejin Lab에서는 이 지점에서 URL 검사를 따로 봤습니다. sitemap 전체 상태와 개별 URL 상태를 나누어야, 어디까지 사이트 문제이고 어디부터 Google 처리 시간인지 구분할 수 있었습니다.

먼저 확인한 상태

이전 점검에서 이미 아래 항목은 통과했습니다.

/sitemap.xml 200 OK
/sitemap-index.xml 200 OK
/sitemap-0.xml 200 OK
robots.txt에서 sitemap 노출
Googlebot User-Agent로 접근 가능
sitemap 안 URL 전부 200 OK

관련 과정은 Search Console에서 sitemap 가져올 수 없음이 뜰 때 확인한 것에 정리해두었습니다.

이 상태라면 바로 코드를 더 고치는 것보다, Search Console의 재처리 시간을 기다리는 쪽이 더 합리적이라고 봤습니다.

계속 재제출하지 않기로 한 이유

sitemap을 삭제하고 다시 제출하는 작업은 심리적으로는 뭔가 하고 있다는 느낌을 줍니다. 하지만 짧은 시간 안에 반복하면 실제 원인 파악에는 도움이 되지 않을 수 있습니다.

특히 파일이 정상이라면 문제 후보는 코드보다 아래 쪽에 가깝습니다.

Search Console의 이전 실패 상태 캐시
신규 사이트에 대한 처리 지연
초기 `pages.dev` 속성의 처리 지연
구글 쪽 크롤링 큐 대기

그래서 같은 sitemap을 계속 제출하기보다, 상태를 고정하고 다른 신호를 쌓기로 했습니다.

URL 검사로 우회하기

다음으로 할 일은 개별 URL 검사입니다. sitemap 전체가 바로 처리되지 않더라도, 중요한 페이지를 하나씩 검사하고 색인 요청할 수 있기 때문입니다.

우선순위는 아래처럼 잡았습니다.

1. 홈: /
2. 글 목록: /blog/
3. 카테고리 목록: /categories/
4. 최신 실전 기록 글
5. Search Console 관련 글

이때도 무작정 모든 URL을 넣기보다, 사이트 정체성을 보여주는 페이지부터 넣는 것이 낫다고 봤습니다. 홈과 글 목록, 카테고리는 새 글들이 연결되는 중심 페이지이기 때문입니다.

색인 전까지 할 일

검색 유입이 아직 없을 때 할 수 있는 가장 좋은 작업은 사이트 내부 구조를 탄탄하게 만드는 것입니다.

그래서 다음 작업은 sitemap 수정이 아니라 콘텐츠와 내부 링크 쪽으로 돌렸습니다.

기존 글에서 연결되는 주제 보강
카테고리 페이지에서 다른 카테고리로 이동 가능하게 만들기
새 글에 관련 기존 글 링크 넣기
로컬 LLM처럼 비어 있던 카테고리 채우기

내부 링크 구조를 먼저 만든 이유는 블로그 글 하단에 관련 글과 내부 링크를 넣은 이유에도 이어집니다.

판단 기준

이런 상황에서는 “Search Console 화면이 아직 실패”와 “사이트가 실제로 실패”를 나눠서 봐야 합니다.

Daejin Lab 기준으로는 아래가 정상이면 일단 사이트 쪽 긴급 수정은 멈추기로 했습니다.

공개 URL 200
canonical이 현재 도메인
noindex 없음
robots.txt 차단 없음
sitemap XML 파싱 가능
sitemap 안 URL이 모두 현재 도메인

robots.txt와 canonical을 점검하며 확인한 색인 기본 조건도 같은 기준에서 작성했습니다.

초기에 실제로 눌렀던 항목

초기 pages.dev 속성에서는 sitemap 제출 화면만 반복해서 새로고침하기보다, URL 검사에서 핵심 페이지를 하나씩 확인하는 편이 낫다고 봤습니다. 당시 우선순위는 아래처럼 잡았습니다.

1. 당시 홈: https://daejin-lab-blog.pages.dev/
2. 시작 글: /blog/start-daejin-lab/
3. Search Console 문제 정리 글: /blog/search-console-sitemap-troubleshooting/
4. 색인 기본 조건 글: /blog/robots-canonical-index-check/

실제 URL 테스트가 통과하면 색인 생성 요청을 누르고, 그 뒤에는 sitemap 파일을 수정하지 않습니다. 기다리는 동안 할 일은 블로그 글 하단에 관련 글과 내부 링크를 넣은 이유처럼 내부 연결과 대표 글 보강을 늘리는 것입니다.

지금 진행하는 우회 흐름

sitemap이 정상인데 Search Console이 계속 “가져올 수 없음”을 보여줄 때는, 바로 코드를 더 복잡하게 만들 필요는 없습니다.

Daejin Lab에서는 sitemap-index.xml 제출 상태 유지 → URL 검사로 핵심 페이지 색인 요청 → 콘텐츠와 내부 링크 보강 순서로 진행하기로 했습니다. 이 단계는 색인을 기다리는 동안 사이트의 실질적인 품질을 올리는 작업에 가깝습니다.

커스텀 도메인 전환 후의 URL 검사 순서

이 글을 처음 쓸 때는 pages.dev 주소를 중심으로 URL 검사 우선순위를 잡았습니다. 지금은 production 기준이 https://daejinlab.com으로 바뀌었기 때문에, 같은 흐름을 현재 도메인 기준으로 다시 봐야 합니다. 특히 Search Console 속성과 sitemap 내부 URL이 서로 다른 도메인을 가리키면 예전 문제가 반복될 수 있습니다.

현재 기준의 우선순위는 아래가 더 맞습니다.

1. 홈: https://daejinlab.com/
2. 시작 글: /blog/start-daejin-lab/
3. sitemap 문제 정리 글: /blog/search-console-sitemap-troubleshooting/
4. 색인 기본 조건 글: /blog/robots-canonical-index-check/
5. 운영 원칙 글: /blog/daejin-lab-operation-principles/

URL 검사에서 중요한 것은 모든 글을 한 번에 요청하는 것이 아닙니다. 대표 흐름이 정상인지 확인하고, 색인 요청 제한이 나오면 멈추는 것입니다. 그 사이에는 Search Console 색인 요청 일일 할당량 초과 후 한 일처럼 기다리는 동안 할 일을 정리하고, 사이트 쪽에서는 robots.txt와 canonical을 점검하며 확인한 색인 기본 조건을 다시 확인합니다.

sitemap 다음에 보는 것

sitemap이 정상이라면 다음은 개별 URL입니다. 대표 글이 열리는지, canonical이 맞는지, 색인 요청이 가능한지 확인합니다.

이 과정을 거치면 무작정 sitemap을 다시 만들지 않게 됩니다. 파일이 정상인데 계속 고치면 원인이 흐려집니다. 지금은 URL 검사와 콘텐츠 보강을 다음 단계로 보고 있습니다.

정상인데 실패처럼 보이는 시간이 있다

이 단계가 제일 애매했습니다. 사이트에서는 정상인데 Search Console 화면은 아직 실패처럼 보였습니다. 그래서 같은 sitemap을 계속 재제출하기보다, 대표 글 몇 개를 URL 검사로 확인하고 나머지는 기다리는 쪽으로 정했습니다.

2026-05-31에 다시 본 URL 검사 이후 행동

URL 검사 도구에서 결과를 보면 바로 다음 버튼을 누르고 싶어집니다. 하지만 Daejin Lab에서는 검사 결과를 보고 할 일을 나누는 쪽이 더 안전했습니다. sitemap에 들어갔는지, 글 목록에서 연결되는지, 마지막 수정일이 반영됐는지, 기다릴 상태인지 따로 봐야 합니다.

이 카드는 URL 검사 이후 바로 반복 요청하지 않고 다음 행동을 나누는 흐름입니다.

참고한 공식 문서

확인하지 않은 것

이 글은 Search Console 내부 화면을 공개하지 않습니다. 계정 속성과 검사 결과 상세는 민감할 수 있어 공개 글에는 판단 흐름만 남깁니다.

FAQ

URL 검사에서 문제가 없으면 바로 색인되나요?

바로 색인된다고 보장할 수 없습니다. 검사는 상태 확인이고, 색인은 Google의 별도 처리입니다.

다음에 가장 먼저 볼 것은 무엇인가요?

sitemap 포함 여부, 내부 링크, live URL 응답, 마지막 수정일입니다.

왜 날짜 기록이 필요한가요?

언제 요청했고 언제 반영됐는지 알아야 불필요한 반복 요청을 줄일 수 있습니다.