죽은 사이트맵 자동 감지해 GSC 제출 실패 줄임

사이트맵을 검색 엔진에 제출하는 작업을 자동화했을 때, 문제가 하나 있었다. 옛날에 삭제했거나 리다이렉트된 사이트맵을 여전히 제출 대상에 포함해서, 매번 제출 실패 로그가 쌓이는 거다. 이번에는 제출 전에 그 사이트맵이 정말 살아 있는지 미리 체크하고, 죽은 것들은 자동으로 건너뛰는 기능을 _lib/gsc_submit.py 에 추가했다.

왜 죽은 사이트맵이 문제가 되는가

서비스를 운영하다 보면 옛 URL 구조를 버리고 새로운 구조로 이전하거나, 특정 섹션을 완전히 폐기하는 일이 생긴다. 그러면 해당 사이트맵도 더 이상 필요 없어진다. 보통은 서버에서 그 URL을 404 Not Found 로 반환하거나, 다른 페이지로 301 Redirect 를 시킨다.

문제는 자동 제출 스크립트가 이런 상황을 감지하지 못하면, 계속 죽은 사이트맵을 제출 대상 리스트에 넣어둔다는 것이다. 매번 제출할 때마다 실패하고, 에러 로그가 누적되고, 결국 모니터링 신호가 잡음(noise)이 되어버린다. "어느 제출이 진짜 문제인지" 구분하기 어려워진다.

또한 검색 엔진 입장에서도 존재하지 않는 사이트맵을 계속 받으면, 우리 서비스의 신뢰도가 살짝 떨어질 수 있다. 관리가 느슨하다는 신호로 받아들여질 수도 있다.

HEAD 가드로 제출 전 사전 검증

해결책은 간단했다. 제출하기 직전에 HEAD 요청을 던져서, 그 사이트맵 URL이 실제로 접근 가능한지 확인하는 것이다. HTTP 상태 코드가 200~299 범위면 살아있는 것, 301/302/404/410 같은 에러 상태면 죽은 것으로 판단한다. 그리고 죽은 것들은 제출 리스트에서 자동으로 제거한다.

이렇게 하면 몇 가지 이점이 생긴다:

이런 자동화 패턴의 일반성

실은 이런 "사전 검증 후 건너뛰기"는 꽤 흔한 패턴이다. 데이터 파이프라인에서 자주 등장한다:

• API 호출 전 엔드포인트 헬스체크: 목표 서버가 응답 가능한지 먼저 체크하고, 다운되면 Skip
• 로그 수집 전 소스 검증: 파일이 정말 존재하는지, 읽기 권한이 있는지 먼저 확인
• 배치 잡 실행 전 입력 검증: 필수 데이터가 있는지 확인하고, 없으면 단계를 건너뜀

HEAD 요청은 이 중에서 가장 가벼운 도구다. GET 요청처럼 전체 본문을 받지 않으면서도, 헤더(상태 코드, Content-Type, 마지막 수정 시간 등)는 얻을 수 있다. 따라서 네트워크 부담도 적고, 응답 속도도 빠르다. 단 HEAD를 지원하지 않는 서버들도 있으니(가끔 Apache나 프록시 레이어에서 HEAD를 비활성화하는 경우), fallback으로 GET을 쓰거나 타임아웃을 짧게 설정하는 것도 좋은 전략이다.

배운 점과 앞으로

이 작업을 하면서 한 가지 깨달은 건, "자동화 = 완벽하게 끝내기"가 아니라는 것이다. 자동화의 진짜 가치는 반복적인 수동 작업을 줄이고, 그 과정에서 생기는 실수나 누락을 방지하는 데 있다.

이번 경우, 사이트맵 제출 자체는 이미 자동화되어 있었다. 하지만 "그 대상이 정말 유효한가"를 검증하는 단계가 없었던 거다. 이제 그 검증 단계를 추가했으니, 파이프라인이 한 단계 더 견고해졌다.

팀 입장에서도 좋은데, 이제 제출 로그를 볼 때 진짜 문제인 경우만 신경 쓰면 된다. 모니터링 알림도 더 정확해지고, 온-콜 엔지니어의 야간 호출도 줄어들 거다. 그리고 이런 "사전 검증"의 패턴을 팀 내에서 다른 데이터 파이프라인에도 적용할 수 있다. 코드 리뷰할 때 "여기도 HEAD 가드 먼저 넣어볼까?" 하는 식으로 제안하기 좋다.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.