"색인이 안 되는 페이지가 있어서 사이트맵을 다시 제출했다"는 이야기를 자주 듣습니다. 그런데 재제출 후 "효과가 있었는지"를 제대로 측정하는 경우는 의외로 드뭅니다. 사이트맵 재제출은 색인을 강제하는 버튼이 아니라 "이 URL들을 확인해 달라"는 신호에 가깝습니다. 언제 효과가 있고 언제 없는지, 재제출 후 서치콘솔에서 무엇을 며칠 간격으로 봐야 하는지, 그리고 재제출로도 안 될 때 무엇을 점검해야 하는지 실무 순서로 정리합니다.
사이트맵 재제출이 실제로 하는 일
사이트맵은 "이 사이트에 이런 URL들이 있다"고 알려주는 목록입니다. 재제출은 그 목록을 다시 크롤러에게 안내하는 행위이지, "이 페이지를 색인하라"는 명령이 아닙니다.
구글은 사이트맵을 색인 여부를 결정하는 여러 신호 중 하나로 참고할 뿐입니다. 그래서 재제출이 도움이 되는 상황은 "구글이 아직 URL의 존재를 모르거나, 발견이 늦은 경우"에 가깝습니다. 이미 크롤은 됐는데 색인이 보류된 페이지는 재제출만으로 잘 바뀌지 않는 경우가 많습니다.
재제출로 해결되는 경우 vs 안 되는 경우
서치콘솔의 색인 상태에 따라 재제출의 효과가 갈립니다.
- 효과가 있는 편 — 새로 만든 페이지, 내부 링크가 약해 아직 발견되지 않은 페이지, 사이트맵에서 빠져 있던 URL. 즉 "발견 자체가 안 된" 상태.
- 효과가 약한 편 — 서치콘솔에 "크롤링됨 - 색인되지 않음" 또는 "발견됨 - 색인되지 않음"으로 이미 잡힌 페이지. 이건 발견이 아니라 품질·중복·구조 판단의 문제라 재제출로 잘 안 바뀝니다.
재제출 전에 이 분류부터 확인하지 않으면, 효과가 없을 상황에 재제출을 반복하며 시간을 쓰게 됩니다.
재제출 전에 먼저 확인할 것
재제출 버튼을 누르기 전에 두 가지를 확인하는 게 순서입니다.
- URL 검사 도구로 문제 페이지의 현재 상태를 봅니다. "색인 생성 가능"인데 아직 안 된 건지, noindex·canonical·차단 같은 기술적 이유가 있는지 구분합니다.
- 사이트맵에 그 URL이 실제로 들어 있는지, 그리고 사이트맵 자체가 200 응답에 최신 상태인지 확인합니다. 오래된 URL·404가 섞인 사이트맵은 신뢰도를 떨어뜨립니다.
기술적 차단이 원인이라면 재제출이 아니라 그 원인을 먼저 풀어야 합니다.
효과 측정 — 무엇을 며칠 간격으로 볼까
재제출 후 하루 만에 결과를 기대하면 대개 실망합니다. 색인은 며칠에서 몇 주까지 걸릴 수 있습니다. 실무에서는 다음 간격으로 보는 편이 현실적입니다.
- 재제출 직후~3일 — 사이트맵 리포트에서 "읽음" 상태와 마지막 읽은 날짜만 확인. 색인 수 변화를 기대할 시점은 아닙니다.
- 1~2주 — "페이지" 리포트에서 색인된 페이지 수, 그리고 문제 URL의 상태 변화를 봅니다.
- 3~4주 — 색인이 안 됐다면 재제출이 아니라 페이지 자체의 문제로 방향을 바꿉니다.
서치콘솔 지표 읽는 순서
측정할 때 보는 순서를 정해두면 헷갈리지 않습니다.
- 사이트맵 리포트 — 사이트맵이 정상 처리됐는지, 발견된 URL 수가 맞는지.
- 페이지(색인 생성) 리포트 — 색인됨/색인 안 됨 추이와 "색인 안 됨" 사유별 분포.
- URL 검사 — 개별 문제 페이지의 최신 상태를 직접 확인.
전체 숫자만 보지 말고 "색인 안 됨" 사유가 어떻게 이동하는지를 함께 봐야 합니다. 사유가 "발견됨"에서 "크롤링됨"으로 옮겨갔다면 최소한 진전이 있는 것입니다.
재제출해도 색인 안 될 때의 다음 단계
2~4주가 지나도 색인이 안 된다면 재제출은 원인이 아니었다는 신호입니다. 이때는 페이지 쪽을 점검합니다.
- 본문이 얇거나 다른 페이지와 내용이 거의 겹치지 않는지(중복·저품질 판단)
- 내부 링크가 거의 없어 사이트 안에서 고립돼 있지 않은지
- canonical이 다른 URL을 가리키고 있지 않은지
- 사이트 전체의 크롤링 예산이 부족해 우선순위에서 밀리지 않는지
재제출은 "발견" 단계의 도구입니다. 발견이 아니라 판단·구조의 문제라면 사이트맵을 몇 번 더 눌러도 바뀌지 않습니다. 원인을 색인 단계별로 나눠 보는 게 결국 가장 빠른 길입니다.