“Sitemap couldn't fetch”는 사이트맵 파일 자체가 틀렸다는 뜻처럼 보이지만, 실제로는 응답 문제인 경우가 많다. 사이트맵 내용은 맞아도 live URL, robots 규칙, 배포 호스트 응답이 틀어져 있으면 같은 메시지가 뜬다.

후속 점검 글은 검색 유입형 웹 운영 유닛 페이지를 기준으로 인덱싱, 메타, CTR, Search Console 흐름으로 이어가면 된다. 운영 기본선이 먼저 필요하면 검색 유입형 웹 운영 기준 글부터 본다.

1. live sitemap을 먼저 연다

추측부터 하지 말고 실제 live sitemap URL을 먼저 열어야 한다. 진짜 XML이 응답되는지, 상태 코드는 정상인지부터 확인하는 게 첫 번째다.

2. 응답과 redirect 경로를 같이 본다

사이트맵 URL이 중간에 redirect되거나, HTML을 내보내거나, 다른 호스트로 가면 Search Console은 가져오기 실패로 본다. 로컬에서 정상인 것과는 별개다.

기본선은 단순하다. live sitemap이 `200 OK`, 실제 XML, 그리고 실제 운영 호스트명으로 응답해야 한다.

• `200 OK`와 실제 XML: 정상 기준
• `301`, `302`: 무조건 오류는 아니지만 최종 도착 URL을 확인해야 한다
• `403`, `404`: 사이트맵 문법보다 호스트, 접근 권한, 라우팅 문제일 가능성이 높다

3. robots.txt를 그다음 본다

robots는 sitemap 건강 상태의 일부다. sitemap 경로를 참조하고 있고, 크롤러가 볼 때 자연스러운 응답을 주고 있는지 같이 확인해야 한다.

4. fetch 실패와 인덱싱 지연을 구분한다

가져오기 실패는 크롤러가 sitemap을 제대로 못 읽는 상태다. 그와 별개로 sitemap은 정상인데 인덱싱 반영이 늦은 경우도 있다. 두 상태를 섞으면 진단이 꼬인다.

즉 sitemap이 `200 OK`와 실제 XML로 열리는데도 검색 반영이 안 된다면, 그때부터는 fetch 문제가 아니라 인덱싱, canonical, 콘텐츠 품질 쪽으로 넘어가야 한다.

무엇부터 시작할까

체크리스트는 다섯 개면 충분하다. live XML, 상태 코드, 최종 URL, robots.txt, 호스트 일치 여부다. 이 다섯 가지가 통과하면 그다음부터는 sitemap 파일이 아니라 인덱싱 단계 문제를 보면 된다.