Search Console 사이트맵 ‘성공’만 보면 놓칩니다: 새 URL 포함 여부 확인법

핵심만 먼저

Search Console에서 사이트맵 상태가 ‘성공’이어도 오늘 만든 URL이 그 파일에 들어 있다는 뜻은 아닙니다. 성공은 Google이 제출한 파일을 가져와 해석할 수 있었다는 신호이며, 개별 URL의 크롤링이나 색인을 보장하지 않습니다. 제출 전에 운영 RSS와 XML을 직접 열어 새 글 ID 또는 canonical URL이 모두 포함됐는지 확인해야 합니다.

사이트맵 성공은 무엇을 뜻하나요

사이트맵은 사이트의 URL과 변경 정보를 검색엔진에 알려주는 파일입니다. Google 공식 문서는 사이트맵 제출을 ‘힌트’라고 표현합니다. Google이 파일을 성공적으로 읽더라도 모든 URL을 방문하거나 색인한다는 약속은 아닙니다. 반대로 사이트맵이 없다고 검색이 절대 불가능한 것도 아닙니다.

Search Console의 성공 상태는 제출한 주소에서 파일을 가져왔고, 형식을 처리하는 과정에 치명적인 오류가 없었다는 뜻에 가깝습니다. 발견된 페이지 수 역시 제출 시점의 파일 내용과 Google의 처리 결과를 반영하므로, 데이터베이스의 전체 글 수와 항상 같지는 않습니다.

오늘 이슈와 근거

운영 사이트는 데이터베이스, 애플리케이션 캐시, CDN 캐시가 서로 다른 시점의 결과를 내보낼 수 있습니다. 새 글 상세페이지는 열리는데 sitemap.xml은 한 시간 전 목록을 반환하는 상황도 가능합니다. 이때 오래된 XML을 Search Console에 다시 제출하면 제출 상태는 성공이지만 새 URL의 발견 신호는 전달되지 않습니다.

Google은 XML 사이트맵뿐 아니라 RSS 2.0과 Atom 1.0 피드도 사이트맵으로 지원합니다. RSS는 최근 글만 포함하는 경우가 일반적이고, XML은 사이트 전체 URL을 포괄하는 데 적합합니다. 따라서 발행 직후에는 RSS에 새 글이 모두 들어왔는지 확인해 빠른 발견 신호로 제출하고, XML의 캐시가 갱신된 뒤 다시 제출하는 이중 확인이 실무적으로 유용합니다.

또한 `lastmod`는 실제로 중요한 내용이 바뀐 날짜에만 정확하게 써야 합니다. 모든 URL의 날짜를 매일 오늘로 바꾸면 신뢰할 수 있는 변경 신호가 되지 못합니다. 페이지 생성일, 실제 수정일, 피드 생성 시각을 구분해야 합니다.

사장님 실무 적용 6단계

1. 새 글의 canonical URL과 고유 ID 목록을 만듭니다. 제목만으로 세지 말고 변하지 않는 식별자를 함께 기록합니다.
2. 각 상세 URL이 HTTP 성공을 반환하고 정확한 제목·본문·대표이미지를 보여주는지 확인합니다.
3. `/rss.xml`을 열어 RSS 2.0 형식인지, 새 ID가 전부 포함됐는지 셉니다. 8편을 발행했다면 8/8이어야 합니다.
4. `/sitemap.xml`에서도 같은 ID를 셉니다. 0/8이면 Search Console의 기존 성공 상태와 무관하게 아직 새 신호가 전달되지 않은 것입니다.
5. RSS가 완전하면 Search Console에 RSS 주소를 제출하고 상태·유형·제출일·마지막 읽은 날짜를 기록합니다.
6. XML이 갱신된 뒤에만 XML을 다시 제출합니다. 제출 뒤에는 페이지 색인 보고서나 URL 검사를 별도로 확인하되 즉시 색인을 약속하지 않습니다.

예를 들어 상세 8개와 RSS 8개가 정상인데 XML이 0개라면 발행 실패와 발견 신호 실패를 구분해야 합니다. 글은 공개됐지만 전체 사이트맵 캐시가 뒤처진 상태입니다. 이 경우 RSS 제출은 진행할 수 있고, XML은 실제 포함을 확인할 때까지 성공으로 보고하면 안 됩니다.

흔한 실수

• Search Console의 초록색 성공 표시를 개별 URL 색인 완료로 해석합니다.
• 파일 안의 URL을 세지 않고 같은 사이트맵 주소만 반복 제출합니다.
• RSS와 XML이 같은 캐시 경로라고 가정합니다.
• 새 글의 상세페이지가 404인데 사이트맵 제출부터 합니다.
• 내용이 바뀌지 않은 모든 URL의 `lastmod`를 매일 갱신합니다.

제스토코스트의 판단

사이트맵 운영의 핵심 지표는 ‘제출 버튼을 눌렀는가’가 아니라 ‘제출한 바이트 안에 발견시키려는 URL이 있었는가’입니다. 이 차이를 놓치면 대시보드는 성공인데 신문 배달 봉투는 비어 있는 상황이 됩니다.

발행 자동화에는 상세, 목록, RSS, XML, 구조화 데이터 검증을 각각 독립된 체크로 두는 편이 좋습니다. 하나가 성공했다고 다른 하나를 추정하지 마세요. 특히 캐시가 있는 사이트라면 응답 헤더와 실제 URL 포함 수를 기록해야 다음 장애의 위치를 빨리 찾을 수 있습니다.

자주 묻는 질문

사이트맵 상태가 성공이면 색인된 것 아닌가요?

아닙니다. 성공은 파일을 가져와 처리했다는 뜻이며, Google 공식 문서도 사이트맵을 크롤링·색인의 보장이 아닌 힌트로 설명합니다.

RSS와 XML을 둘 다 제출해도 되나요?

Google은 RSS 2.0과 XML 사이트맵을 모두 지원합니다. RSS는 최근 URL의 빠른 발견, XML은 전체 URL 관리에 보완적으로 사용할 수 있습니다.

새 글이 XML에 없으면 반복 제출하면 해결되나요?

아닙니다. 먼저 운영 XML이 왜 오래된 응답을 내는지 확인해야 합니다. 캐시나 생성 데이터가 갱신되지 않았다면 같은 파일을 다시 제출해도 새 URL이 전달되지 않습니다.

출처

• Google Search Central: 사이트맵 만들기와 제출
• Google Search Console 고객센터: 사이트맵 보고서

CTA

오늘 Search Console의 성공 배지보다 먼저 운영 RSS와 XML을 열고, 최근 발행 URL이 각각 몇 개 들어 있는지 숫자로 기록해 보세요.

편집 고지: 이 글은 공식 자료 조사와 초안 정리에 자동화 도구를 활용했으며, 공개 전 출처·표현·실무 적합성을 검수합니다.