Google Search Console에 사이트맵을 제출했는데
“가져올 수 없음”
“Couldn’t fetch”
상태가 표시될 수 있습니다.
이 메시지는 단순히 사이트맵 안의 URL 몇 개에 문제가 있다는 뜻과는 다릅니다.
보통은 Google이 사이트맵 파일 자체를 정상적으로 가져오지 못했거나 처리하지 못한 상태부터 확인해야 합니다.
따라서 XML 안의 개별 URL부터 하나씩 보기보다 먼저
사이트맵 주소가 실제로 열리는지
정상적인 XML을 반환하는지
Googlebot 접근을 막는 설정이 없는지
부터 확인하는 것이 좋습니다.
먼저 현재 증상을 구분하세요
| 현재 증상 | 먼저 확인할 것 |
|---|---|
Couldn’t fetch | 사이트맵 URL 직접 접속 |
| 사이트맵 URL이 404 | 잘못된 주소·rewrite |
| 사이트맵 URL이 403 | 보안·봇 차단 |
| 5xx 오류 | 호스팅·서버 상태 |
| XML 대신 홈페이지가 열림 | 리디렉션·사이트맵 설정 |
| 사이트맵은 열리는데 예전 도메인 표시 | WordPress URL·캐시·DB |
| HTTPS 경고 발생 | SSL 인증서 |
| 사이트맵 성공인데 글이 검색 안 됨 | 개별 URL 색인 상태 |
| 수정 후에도 상태가 그대로 | Google 재처리 대기 |
1. Search Console에 제출한 사이트맵 주소를 직접 열어보세요
가장 먼저 해야 할 일입니다.
Search Console에 제출한 사이트맵 URL을 그대로 복사해 브라우저 주소창에 입력하세요.
WordPress 기본 사이트맵은 일반적으로
https://example.com/wp-sitemap.xml
형태일 수 있습니다.
SEO 플러그인을 사용한다면
https://example.com/sitemap_index.xml
처럼 다른 주소를 사용할 수도 있습니다.
중요한 것은 인터넷에서 본 주소를 무조건 넣는 것이 아니라 내 사이트에서 실제로 생성되고 있는 사이트맵 주소를 확인하는 것입니다.
2. 사이트맵이 정상이라면 실제 XML이 보여야 합니다
사이트맵 주소를 열었을 때
- XML 사이트맵 목록
- Sitemap Index
- 게시물·페이지 URL 목록
중 하나가 보여야 합니다.
반대로 다음 화면이 나타난다면 그 문제부터 해결해야 합니다.
404 Not Found403 Forbidden500,502,503같은 서버 오류- 로그인 화면
- 홈페이지
- 빈 화면
- 인증서 경고
- 리디렉션 반복
이 상태에서 Search Console에 사이트맵을 계속 삭제·재등록해도 근본 원인은 해결되지 않습니다.
3. 사이트맵 URL을 잘못 제출하지 않았는지 확인하세요
WordPress에서는 사이트 환경에 따라 사이트맵 주소가 달라질 수 있습니다.
예를 들어 실제 사이트맵은
/wp-sitemap.xml
인데 Search Console에
/sitemap.xml
을 제출했다면 가져오지 못할 수 있습니다.
반대로 SEO 플러그인이 별도 XML 사이트맵을 제공한다면 기본 WordPress 사이트맵이 아니라 해당 플러그인의 주소를 사용해야 할 수 있습니다.
4. HTML 사이트맵과 XML 사이트맵을 구분하세요
방문자에게 보여주기 위한 일반 페이지와 Search Console에 제출하는 XML 사이트맵은 다릅니다.
예를 들어
이라는 페이지에 사이트 글 목록이 보인다고 해서 Search Console에 제출해야 하는 사이트맵이라는 뜻은 아닙니다.
Search Console에는 검색엔진이 읽을 수 있는 실제 XML 사이트맵을 제출해야 합니다.
5. .xml 주소인데 홈페이지가 열리면 정상 사이트맵인지 확인하세요
예를 들어
https://example.com/sitemap.xml
을 열었는데 사이트맵 XML이 아니라 홈페이지가 표시된다면 주소 자체는 열리더라도 정상적인 사이트맵 응답이라고 보기 어렵습니다.
다음을 확인하세요.
- 사이트맵 기능이 실제로 활성화돼 있는지
- 잘못된 리디렉션이 있는지
- 캐시가 잘못된 응답을 저장했는지
- SEO 플러그인이 다른 사이트맵 주소를 사용하는지
- 서버 rewrite 설정이 정상인지
즉 “주소가 열리는가”뿐 아니라 “무엇을 반환하는가”까지 확인해야 합니다.
6. 사이트맵 URL이 404라면 재제출보다 URL부터 고치세요
사이트맵 자체가 404 Not Found라면 Search Console에서 재제출을 반복할 필요가 없습니다.
먼저 실제 사이트맵 주소를 확인하세요.
WordPress라면 기본적으로
/wp-sitemap.xml
을 확인할 수 있고, SEO 플러그인을 사용한다면 해당 플러그인 설정에서 실제 XML 사이트맵 주소를 확인하세요.
사이트맵 기능은 켜져 있는데 주소만 404라면 퍼머링크나 rewrite 문제일 수도 있습니다.
이 경우 워드프레스 404 오류 해결, 페이지를 찾을 수 없음이 뜰 때 확인 순서와 연결해서 보면 좋습니다.
7. 사이트맵이 403이라면 보안·봇 차단을 확인하세요
사이트맵 URL에서 403 Forbidden이 나타난다면 Googlebot도 같은 방식으로 차단될 수 있습니다.
다음을 확인하세요.
- WordPress 보안 플러그인
- 호스팅 방화벽
- WAF
- CDN 보안 규칙
- 봇 차단
- IP 차단
- 국가별 접근 제한
- 요청 빈도 제한
사이트맵은 로그인 없이 외부에서 정상적으로 접근 가능해야 합니다.
8. 내 브라우저에서 열린다고 Google도 반드시 가져올 수 있는 것은 아닙니다
브라우저에서는 사이트맵이 정상적으로 열리는데 Search Console에서는 Couldn’t fetch가 뜰 수 있습니다.
이 경우에는
- 일반 사용자는 허용하지만 봇은 차단
- 특정 IP 범위 차단
- CDN 봇 보호
- 서버 rate limit
- 간헐적인 5xx
- 과도한 리디렉션
같은 차이를 확인해야 합니다.
즉 내 PC에서 한 번 정상적으로 열렸다는 것만으로 Googlebot 접근까지 보장되지는 않습니다.
9. 최종 응답이 HTTP 200인지 확인하세요
정상적인 사이트맵은 최종적으로 성공 응답을 반환해야 합니다.
가능하다면 개발자 도구나 HTTP 상태 확인 도구로 다음을 확인하세요.
- 최종 상태 코드가
200 403,404,5xx가 아님- 로그인 화면으로 이동하지 않음
- 불필요한 리디렉션이 많지 않음
사이트맵 URL이 화면상 열려 보여도 중간에 여러 번 리디렉션되거나 최종 응답이 이상하다면 도메인·HTTPS 설정부터 점검하는 것이 좋습니다.
10. Search Console 속성과 현재 사이트 도메인을 확인하세요
사이트 이전이나 도메인 변경 이후라면 Search Console 속성과 현재 사이트 기준이 맞는지 확인하세요.
특히 다음 변경이 있었다면 중요합니다.
- 임시 도메인 → 정식 도메인
- HTTP → HTTPS
www→ non-www- non-www →
www - 호스팅 이전
- 스테이징 → 운영 사이트
현재 실제 사이트는
인데 사이트맵은 예전 임시 주소로 생성되고 있다면 Search Console 재제출보다 사이트 설정부터 바로잡아야 합니다.
11. 사이트맵 안의 URL도 현재 도메인인지 확인하세요
사이트맵 파일 자체가 열리더라도 내부 URL이 잘못돼 있을 수 있습니다.
XML을 열어 실제 게시물 주소 몇 개를 확인해보세요.
예를 들어 현재 사이트가
인데 사이트맵에는
같은 주소가 남아 있다면 이전 정보가 완전히 정리되지 않은 것입니다.
이 경우 다음을 확인하세요.
- WordPress 주소(URL)
- 사이트 주소(URL)
- DB에 남은 이전 도메인
- SEO 플러그인
- 캐시
- canonical
12. www와 non-www가 섞여 있다면 정리하세요
예를 들어
- Search Console:
https://example.com - 실제 사이트:
https://example.com - 사이트맵 내부 URL:
https://www.example.com
처럼 섞여 있다면 대표 도메인과 리디렉션·canonical 구성을 확인하세요.
이것이 Couldn’t fetch의 직접 원인이라고 단정할 수는 없지만 사이트 주소 관리가 덜 정리됐다는 신호일 수 있습니다.
13. HTTPS 인증서가 정상인지 확인하세요
사이트맵이 HTTPS 주소라면 인증서도 정상이어야 합니다.
사이트맵 URL을 직접 열었을 때
- 연결이 비공개로 설정되어 있지 않음
- 인증서 만료
- 도메인 불일치
- SSL 프로토콜 오류
같은 경고가 발생하지 않는지 확인하세요.
이 문제가 있다면 SSL 인증서 오류 해결 글에서 먼저 HTTPS 자체를 정상화하는 것이 맞습니다.
14. 사이트맵은 최종 HTTPS 주소로 제출하세요
HTTP 주소가 HTTPS로 정상 리디렉션되는 것은 일반적인 구성이지만 사이트맵 제출 주소는 가능하면 처음부터 최종 URL을 사용하는 편이 깔끔합니다.
예를 들어 실제 대표 사이트맵이
https://example.com/wp-sitemap.xml
이라면 이 주소를 그대로 제출하세요.
http → https → www → non-www
처럼 여러 단계로 이동하거나 반복 리디렉션이 있는 상태는 먼저 정리하는 것이 좋습니다.
15. robots.txt도 확인하세요
브라우저에서
https://example.com/robots.txt
를 열어봅니다.
운영 사이트 전체가 검색엔진에 공개돼야 하는데
User-agent: *
Disallow: /
처럼 되어 있다면 전체 크롤링을 막는 설정입니다.
특히 사이트 제작 중 검색 노출을 막아놓고 운영 전환 후에도 그대로 둔 경우가 있습니다.
robots.txt에는 사이트맵 위치를 적을 수도 있습니다.
Sitemap: https://example.com/wp-sitemap.xml
다만 Search Console에 직접 사이트맵을 제출했다면 robots.txt에 Sitemap: 항목이 반드시 있어야만 제출되는 것은 아닙니다.
16. robots.txt 문제와 사이트맵 파일 접근 문제는 구분하세요
이 부분이 중요합니다.
robots.txt에서 일부 게시물 크롤링을 막는 것과 사이트맵 파일 자체가 403이나 404로 막히는 것은 같은 문제가 아닙니다.
Couldn’t fetch라면 우선
사이트맵 파일 접근 → 사이트맵 처리 → 사이트맵 안 URL 상태 확인
순서로 보는 것이 좋습니다.
즉 사이트맵 자체를 못 읽고 있는데 개별 글의 색인 문제부터 보는 것은 순서가 뒤바뀐 겁니다.
17. WordPress의 검색엔진 차단 설정도 확인하세요
관리자에서
설정 → 읽기
로 이동합니다.
검색엔진의 사이트 색인을 억제하는 옵션이 켜져 있지 않은지 확인하세요.
다만 이것 역시 사이트맵 URL 자체가 404나 403인 문제와는 별개입니다.
사이트맵 자체가 안 열림 → 그 문제부터
사이트맵은 정상 → 그다음 크롤링·색인 설정 확인
순서로 가세요.
18. WordPress 기본 사이트맵이 안 열린다면
WordPress 기본 사이트맵인
/wp-sitemap.xml
이 안 열린다면 다음 순서로 확인하세요.
- 사이트 자체가 정상적으로 열리는지
- 퍼머링크가 정상인지
- SEO 플러그인이 별도 사이트맵을 사용하는지
- 사이트맵 기능을 끈 플러그인이 있는지
- 캐시·보안 플러그인이 영향을 주는지
- 서버 rewrite가 정상인지
SEO 플러그인이 자체 사이트맵을 제공한다면 기본 WordPress 사이트맵을 굳이 동시에 사용할 필요는 없습니다.
19. 사이트맵이 404라면 고유주소를 다시 저장해보세요
WordPress rewrite가 꼬인 것으로 보인다면 관리자에서
설정 → 고유주소
로 이동합니다.
퍼머링크 구조 자체는 바꾸지 말고 변경사항 저장만 눌러보세요.
그다음 사이트맵 주소를 다시 확인합니다.
이 작업으로 rewrite 규칙이 다시 생성되면서 사이트맵 URL이 정상화될 수 있습니다.
20. SEO 플러그인 사이트맵 설정도 확인하세요
SEO 플러그인을 사용하는 경우 해당 플러그인이 자체 사이트맵을 생성할 수 있습니다.
확인할 것은
- XML Sitemap 기능이 켜져 있는지
- 실제 사이트맵 주소가 무엇인지
- 다른 SEO 플러그인이 동시에 사이트맵을 생성하고 있지 않은지
입니다.
사이트맵을 여러 개 만들어 제출한다고 색인이 빨라지는 것은 아닙니다.
현재 사이트가 실제로 사용하는 정상 사이트맵 하나를 기준으로 관리하는 편이 좋습니다.
21. 수정했는데 예전 사이트맵이 계속 보이면 캐시를 확인하세요
사이트맵이나 도메인을 수정했는데 XML 안에 예전 내용이 계속 남는다면 다음을 확인하세요.
- WordPress 캐시 플러그인
- 호스팅 캐시
- CDN 캐시
- 브라우저 캐시
특히 사이트맵 안에 이전 임시 도메인이 계속 남는다면 캐시를 비운 뒤 실제 XML이 갱신됐는지 다시 확인합니다.
다만 캐시를 무조건 먼저 지우기보다 현재 XML에서 무엇이 잘못됐는지 먼저 확인하세요.
22. 사이트맵은 열리는데 Search Console에서 형식 오류가 난다면 XML을 확인하세요
직접 만든 사이트맵이라면 다음 문제가 없는지 확인합니다.
- XML 태그 미종료
- 잘못된 문자
- URL 형식 오류
- HTML 콘텐츠 포함
- 인코딩 문제
- 지원되지 않는 구조
WordPress 기본 사이트맵이나 일반적인 SEO 플러그인 사이트맵을 사용한다면 XML을 직접 고치는 것보다 사이트맵 생성 기능이나 플러그인 문제부터 확인하는 것이 좋습니다.
23. 사이트맵 크기 제한도 있습니다
사이트가 매우 큰 경우 사이트맵을 여러 개로 나눠 Sitemap Index로 관리할 수 있습니다.
Google의 일반적인 단일 사이트맵 한도는
- 압축하지 않은 기준 50MB
- URL 50,000개
입니다.
다만 글이 수십 개 정도인 신규 WordPress 사이트에서 Couldn’t fetch가 나온다면 보통 파일 크기보다
- 잘못된 사이트맵 주소
- 404·403·5xx
- SSL
- 봇 차단
- 도메인 설정
부터 보는 것이 훨씬 중요합니다.
24. 사이트맵 안의 404 URL은 ‘가져오기 성공 후’ 따로 정리하세요
사이트맵 자체를 Google이 가져오는 문제와 사이트맵 내부 URL의 품질은 분리해서 봐야 합니다.
사이트맵 제출이 성공한 뒤에는 다음 URL이 불필요하게 포함되지 않았는지 확인하세요.
- 삭제된 페이지
- 404 페이지
- 이전 주소
- 리디렉션만 존재하는 URL
특히 슬러그를 많이 바꿨다면 현재 사이트맵이 최신 URL을 사용하는지도 확인하세요.
25. canonical과 사이트맵 URL도 일관되게 관리하세요
사이트맵에는 일반적으로 검색엔진에 대표 URL로 알려주고 싶은 주소를 넣는 것이 좋습니다.
예를 들어 사이트맵에는
가 들어 있는데 canonical은
를 가리키는 식으로 대량으로 어긋난다면 사이트 URL 관리 상태를 점검할 필요가 있습니다.
이 문제는 Couldn’t fetch와는 별개지만 사이트맵이 정상화된 뒤 색인 품질 측면에서 정리할 가치가 있습니다.
26. 잘못 제출한 사이트맵은 올바른 주소로 교체하세요
처음에
/sitemap.xml
을 제출했는데 실제 사이트맵이
/wp-sitemap.xml
이라면 틀린 주소를 반복 제출할 필요가 없습니다.
정상 사이트맵 주소를 확인한 뒤 올바른 주소를 제출하세요.
사이트맵을 여러 개 등록한다고 색인이 더 빨라지는 것은 아닙니다.
27. 문제를 고친 직후 Search Console 상태가 바로 바뀌지 않을 수 있습니다
사이트맵 문제를 수정하고 다시 제출해도 바로 성공으로 바뀌지 않을 수 있습니다.
Google이 사이트맵을 다시 가져오고 처리하는 데 시간이 필요할 수 있기 때문입니다.
다음이 모두 정상이라면 잠시 기다렸다가 다시 확인하세요.
- 사이트맵 URL 정상
- HTTP 200
- XML 정상
- HTTPS 정상
- 403 없음
- 도메인 정상
- 과도한 리디렉션 없음
몇 분마다 삭제하고 다시 등록하는 식으로 반복할 필요는 없습니다.
28. 오래된 사이트맵 ping 방식은 사용하지 마세요
예전 글에는 특정 Google ping 주소를 호출해 사이트맵 갱신을 알리는 방법이 남아 있을 수 있습니다.
하지만 Google은 과거의 사이트맵 ping endpoint 지원을 종료했습니다.
현재는
- Search Console 사이트맵 제출
- robots.txt의
Sitemap:항목
같은 정상적인 발견 경로를 사용하면 됩니다.
오래된
google.com/ping?sitemap=...
방식은 사용할 필요가 없습니다.
29. 사이트맵 ‘성공’과 페이지 ‘색인’은 별개입니다
사이트맵 상태가 성공으로 바뀌었다고 해서 그 안의 모든 글이 바로 Google 검색에 등록되는 것은 아닙니다.
사이트맵은 Google이 URL을 발견하고 크롤링 대상을 이해하는 데 도움을 주는 수단입니다.
실제 색인에는
- Googlebot 접근
- 페이지 품질
- 중복
- canonical
noindex- 서버 응답
- 내부링크
- Google의 크롤링·색인 판단
등도 영향을 줍니다.
사이트맵이 성공했다면 중요한 글은 Search Console → URL 검사에서 따로 확인하세요.
30. 신규 사이트에서 URL 수가 적은 것은 그 자체로 문제가 아닙니다
새 사이트라면 사이트맵에 포함된 URL 수가 많지 않을 수 있습니다.
중요한 것은 숫자 자체가 아니라
- 실제 발행한 글이 들어 있는가
- 이전 임시 도메인이 없는가
- 404 URL이 불필요하게 들어 있지 않은가
- 현재 대표 URL이 들어 있는가
입니다.
글이 추가되면 WordPress나 SEO 플러그인이 사이트맵을 자동으로 갱신하는 경우가 일반적입니다.
31. 사이트 이전 직후라면 이전 도메인을 집중적으로 확인하세요
임시 호스팅 주소에서 정식 도메인으로 바꿨다면 다음 위치에 옛 주소가 남아 있지 않은지 확인하세요.
- WordPress 주소
- 사이트 주소
- 사이트맵 XML
- canonical
- 내부링크
- 이미지 URL
- SEO 플러그인
- Search Console 속성
홈 화면은 새 도메인으로 열리는데 사이트맵이나 canonical에는 이전 도메인이 남아 있는 경우가 있습니다.
이 상황에서는 재제출보다 사이트 URL 자체를 먼저 일관되게 정리하는 것이 중요합니다.
32. 계속 Couldn’t fetch가 남는다면 서버의 간헐적 오류도 확인하세요
앞의 항목을 모두 확인했는데도 계속 가져올 수 없음이 표시된다면 다음을 다시 점검하세요.
- 사이트맵 URL을 외부에서 직접 열 수 있음
- 최종 응답이 HTTP 200
- XML 정상
- SSL 오류 없음
- 403·로그인 요구 없음
- CDN·방화벽의 봇 차단 없음
- Search Console 속성과 도메인 일치
- 사이트맵 내부 URL도 현재 도메인 사용
- 서버가 간헐적으로 5xx를 반환하지 않음
특히 사이트맵이 가끔 열리고 가끔 서버 오류가 난다면 Search Console 화면만 반복해서 확인하기보다 호스팅 로그나 서버 상태를 보는 편이 좋습니다.
증상별 빠른 확인표
| 증상 | 먼저 확인할 것 |
|---|---|
Couldn’t fetch | 사이트맵 URL 직접 접속 |
| 사이트맵 404 | 올바른 주소·rewrite |
| 사이트맵 403 | 보안 플러그인·WAF·봇 차단 |
| 사이트맵 5xx | 호스팅·서버 로그 |
| XML 대신 홈페이지 | 리디렉션·사이트맵 설정 |
| 예전 도메인 표시 | WordPress URL·DB·캐시 |
| SSL 경고 | 인증서·HTTPS |
www 주소 혼재 | 대표 도메인·리디렉션 |
| 사이트맵 성공, 글 미색인 | URL 검사 |
| 수정 후 상태 그대로 | Google 재처리 대기 |
WordPress 사이트에서 가장 빠른 확인 순서
- 현재 실제 사이트맵 URL 확인
- 브라우저에서 직접 열기
404,403,5xx여부 확인- XML 사이트맵이 실제로 표시되는지 확인
- 최종 응답이 HTTP 200인지 확인
- Search Console 속성과 현재 도메인 확인
- 사이트맵 내부 URL이 현재 도메인인지 확인
- SSL 인증서 확인
- robots.txt·보안 플러그인 확인
- SEO 플러그인 사이트맵 설정 확인
- 사이트맵이 404라면 고유주소 재저장
- 서버·CDN 캐시 확인
- 정상 사이트맵 주소 다시 제출
- 처리 시간을 두고 상태 확인
사이트맵이 성공한 뒤 확인할 것
사이트맵이 성공으로 바뀌었다면 이제 사이트맵을 계속 만질 필요는 없습니다.
그다음에는 중요한 글 몇 개를 골라 URL 검사에서 확인하세요.
확인할 항목은
- URL이 Google에 등록되어 있는지
- 크롤링 가능 여부
- 색인 생성 허용 여부
- canonical 상태
- 마지막 크롤링 상태
입니다.
Search Console 사이트맵 체크리스트
- 제출한 사이트맵 URL이 실제로 존재하는가
- 브라우저에서 XML이 정상적으로 열리는가
- 최종 응답이 HTTP 200인가
- 404·403·5xx가 없는가
- 로그인 화면이나 홈페이지로 리디렉션되지 않는가
- Search Console 속성과 현재 도메인이 일치하는가
- 사이트맵 내부 URL이 현재 도메인을 사용하는가
www와 non-www가 섞이지 않았는가- HTTPS 인증서가 정상인가
- Googlebot을 막는 보안·CDN 설정이 없는가
- WordPress 검색엔진 차단 설정을 확인했는가
- SEO 플러그인의 사이트맵 주소가 정확한가
- 퍼머링크 rewrite가 정상인가
- 캐시에 이전 사이트맵이 남아 있지 않은가
- XML 형식이 정상인가
- 사이트맵 성공과 개별 URL 색인을 혼동하고 있지 않은가
마무리
Search Console에서 사이트맵이 “가져올 수 없음”으로 표시된다면 가장 먼저 할 일은 사이트맵을 삭제하고 다시 추가하는 것이 아닙니다.
우선
사이트맵 URL 직접 접속 → HTTP 상태 확인 → XML 확인 → 도메인·HTTPS 확인 → 접근 차단 확인
순으로 점검하세요.
WordPress 사이트라면 그다음
SEO 플러그인 → 퍼머링크 → 캐시 → 서버 rewrite
까지 확인하면 됩니다.
그리고 가장 중요한 것은
Couldn’t fetch
와
“사이트맵은 성공했지만 글이 색인되지 않음”
을 서로 다른 문제로 보는 것입니다.
사이트맵 자체를 Google이 못 가져오고 있다면 파일 접근부터 해결해야 하고, 사이트맵이 이미 성공이라면 그때부터는 개별 URL의 색인 상태를 확인하는 것이 맞습니다.
참고자료
- Google Search Console 고객센터, 사이트맵 생성 및 제출 방법: https://support.google.com/webmasters/answer/7451001
- Google Search Console 고객센터, 사이트맵 보고서 및 오류 확인 방법: https://support.google.com/webmasters/answer/7451001?hl=ko
- Google 검색 센터, 사이트맵 기본 가이드: https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview