[구글 SEO 11] 유령 사이트맵과 크롤 예산 낭비

사이트맵을 정리하다 이상한 걸 발견했다. 예전에 잠깐 썼다가 지운 사이트맵 주소로 구글봇이 여전히 꾸준히 찾아오고 있었다. 분명히 지웠는데도 구글은 그 지도가 아직 어딘가 있는 줄 알고 계속 문을 두드리고 있던 것이다. 나는 이걸 유령 사이트맵이라고 부른다. 이번 편은 이 유령이 왜 생기고, 어떻게 크롤 예산을 갉아먹으며, 어떻게 완전히 떠나보내는지에 대한 이야기다.

앞 편들에서 크롤 예산 이야기를 계속했는데, 유령 사이트맵은 그 예산이 새는 대표적인 구멍이다. 죽은 글 주소가 새는 구멍이라면, 유령 사이트맵은 지도 자체가 새는 구멍이다. 규모는 작아 보여도 신생 도메인의 빠듯한 예산에선 무시할 수 없다.

1. 유령 사이트맵이란 무엇인가

유령 사이트맵은 과거에 구글이 알게 된, 지금은 존재하지 않는 사이트맵 URL을 말한다. 초기에 이런저런 사이트맵 구조를 실험하다가 경로를 바꾸거나, 테스트용 사이트맵을 잠깐 제출했다가 지우거나, 플러그인을 갈아치우면서 옛 사이트맵 주소가 죽는다. 사람은 지웠다고 생각하지만 구글의 기억 속엔 그 주소가 남는다.

문제는 구글이 한 번 알게 된 사이트맵 URL을 스스로 잘 잊지 않는다는 점이다. 죽은 글 주소를 계속 재방문하는 것과 똑같은 이유다. 혹시 그 지도가 다시 살아나 새 URL을 담고 있지 않을까 하고 주기적으로 다시 가져오려 시도한다. 그렇게 존재하지 않는 지도를 향한 헛걸음이 반복된다.

내 경우 GSC 사이트맵 화면에 내가 제출한 적도 기억도 없는 사이트맵 주소가 몇 개 남아 있었고, 상태는 가져올 수 없음으로 떠 있었다. 이게 유령의 흔적이다. 내가 만든 게 아니라 옛날의 내가 남기고 간 잔재였다.

구체적으로 내 경우엔 초기에 자동 생성 사이트맵을 잠깐 쓰다가 직접 만든 사이트맵으로 갈아탄 이력이 있었다. 그 옛 도구가 만들던 주소가 그대로 유령으로 남았다. 이렇게 도구를 바꾸거나 프레임워크를 옮길 때 옛 사이트맵 경로가 유령이 되는 경우가 가장 흔하다. 마이그레이션 체크리스트에 옛 사이트맵 정리를 반드시 넣어야 하는 이유다.

용어를 조금 정리하면, 여기서 말하는 유령은 악성 코드나 해킹 같은 게 아니라 순전히 관리상의 잔재다. 나쁜 의도 없이 그저 과거의 설정이 구글의 기억에 남아 계속 소환되는 것뿐이다. 그래서 겁낼 건 없지만, 방치하면 조용히 예산을 축내니 한 번은 반드시 손봐야 하는 대상이다.

2. 왜 스스로 사라지지 않는가

가장 답답한 점은 방치해도 알아서 안 없어진다는 것이다. 구글의 관점에서 사이트맵은 사이트가 자기 URL을 알려주는 중요한 통로라, 한번 인지한 사이트맵은 꽤 오래 목록에 두고 관리한다. 그래서 그냥 두면 몇 주, 길게는 몇 달씩 유령이 남는다.

여기에 사이트맵 인덱스 구조가 얽히면 더 질겨진다. 옛 인덱스가 옛 하위 사이트맵들을 가리키고 있었다면, 구글은 그 인덱스를 기억하는 한 하위들도 계속 확인하려 든다. 하나를 지워도 상위가 살아 있으면 다시 소환되는 식이다. 그래서 유령은 개별로 지우기보다 구조 전체를 정리해야 확실히 사라진다.

또 하나, 옛 사이트맵 주소가 robots.txt나 어딘가에 아직 적혀 있으면 그게 유령을 계속 살려낸다. 지도를 지웠는데 그 지도로 가는 안내판을 안 뗀 격이다. 그래서 청소는 항상 안내판까지 함께 떼는 게 원칙이다.

게다가 외부에서 옛 사이트맵을 링크해 둔 곳이 있으면 유령은 더 끈질기다. 다른 사이트나 옛 게시물이 내 옛 사이트맵 주소를 참조하고 있으면 구글은 그 링크를 타고 다시 그 주소를 발견한다. 내가 아무리 지워도 바깥에서 계속 소환하는 셈이다. 이런 경우엔 링크를 통제할 수 없으니 서버 응답으로 확실히 끝내주는 수밖에 없다.

3. 크롤 예산이 새는 메커니즘

유령 사이트맵이 왜 문제인지는 크롤 통계를 보면 드러난다. 구글봇의 하루 요청 중 일부가 존재하지 않는 사이트맵 주소를 가져오려는 시도에 쓰인다. 그 요청은 대개 404나 오류로 끝나고, 그만큼의 예산이 새 글을 크롤하는 데 쓰이지 못한 채 증발한다.

규모가 크지 않아 보일 수 있지만, 신생 도메인은 애초에 하루 예산이 수십 건 수준이라 몇 건의 헛걸음도 비율로는 크다. 게다가 사이트맵을 가져오려다 실패하는 일이 반복되면, 구글이 이 사이트의 사이트맵 인프라 자체를 덜 신뢰하게 될 여지도 있다. 지도를 자꾸 못 찾는 사이트로 학습되는 것이다.

죽은 글 주소, 리다이렉트 체인, 파라미터 중복에 이어 유령 사이트맵까지, 결국 다 같은 이야기다. 봇의 한정된 시간을 살아 있는 콘텐츠가 아니라 죽은 것들을 확인하는 데 쓰게 만드는 모든 요소를 하나씩 걷어내는 게 신생 SEO의 핵심이다.

크롤 통계에서 이걸 확인할 때는 사이트맵 관련 요청과 응답 코드를 눈여겨본다. 사이트맵 유형의 요청이 꾸준한데 응답이 404나 오류로 잡히면 유령이 살아 있다는 신호다. 반대로 정리가 잘되면 이 헛요청이 시간이 지나며 줄어드는 게 그래프로 보인다. 청소의 효과를 눈으로 확인할 수 있는 지점이라 추적할 값어치가 있다.

한 가지 실측 팁은 서버 로그를 사이트맵 요청 기준으로 필터링해 보는 것이다. sitemap이라는 문자열이 든 요청만 뽑아 보면 봇이 어떤 사이트맵 주소들을 두드리고 있는지 한눈에 나온다. 거기에 내가 안 만든 주소가 있으면 그게 유령이다. GSC 화면보다 로그가 더 빠르고 정직하게 유령의 실체를 보여준다.

4. 유령을 떠나보내는 법

청소는 세 갈래로 한다. 먼저 GSC 사이트맵 화면에서 내가 쓰지 않는 옛 사이트맵 항목을 삭제한다. 이 삭제는 GSC에서 그 사이트맵을 더 이상 추적하지 말라는 신호를 주는 것이라 유령을 지우는 첫걸음이다.

다음으로, 그 옛 사이트맵 주소가 실제로 요청됐을 때 서버가 무엇을 돌려주는지를 정한다. 영구히 없앨 주소라면 404보다 410으로 응답하게 해서 구글이 빨리 포기하게 만든다. 죽은 글에 410을 주던 것과 같은 원리를, 죽은 지도 주소에도 적용하는 것이다.

마지막으로 robots.txt와 코드 어디에도 옛 사이트맵 경로가 남아 있지 않은지 확인한다. Sitemap 지시문에는 현재 살아 있는 인덱스 하나만 남긴다. 안내판을 정리해야 유령이 다시 소환되지 않는다. 이 세 가지를 함께 해야 완전히 떠난다.

삭제 후에도 바로 사라지진 않는다는 점은 미리 알아두는 게 좋다. GSC에서 지우고 서버에서 410을 줘도 구글이 그 상태를 여러 번 확인하고 나서야 완전히 목록에서 뺀다. 며칠에서 몇 주가 걸릴 수 있으니 한 번 정리했으면 조급해하지 말고 크롤 통계로 추세가 꺾이는지만 지켜보면 된다.

5. 애초에 안 생기게 하려면

가장 좋은 건 유령을 만들지 않는 것이다. 그러려면 사이트맵 URL 구조를 처음에 확정하고 안 바꾸는 게 최선이다. 글 URL을 함부로 안 바꾸는 원칙과 똑같다. 사이트맵도 하나의 안정적인 인덱스 주소를 정해두고, 내부 구성만 바뀌더라도 바깥에 노출되는 주소는 고정하는 것이다.

테스트용 사이트맵을 만들 때도 조심해야 한다. 개발 중에 임시로 제출한 사이트맵이 그대로 유령이 되는 경우가 많다. 테스트는 검색엔진에 제출하지 않는 별도 환경에서 하고, 프로덕션에는 확정된 것만 올리는 습관이 유령을 예방한다.

정리하면 유령 사이트맵은 과거의 실험이 남긴 청구서 같은 것이다. 지금 당장 큰 사고는 아니지만 조용히 예산을 갉아먹으니, 한 번 날 잡아 GSC 삭제와 410 응답, robots 정리로 깔끔히 떠나보내자. 다음 편에서는 이 사이트맵과 크롤을 통제하는 또 다른 축, robots.txt와 IndexNow를 정리한다.

예방의 관점에서 사이트맵은 버전이 아니라 고정된 엔드포인트로 관리하는 게 좋다. 내부 구조를 아무리 바꿔도 바깥에 노출되는 인덱스 주소 하나는 절대 안 바꾸는 것이다. 그러면 구조를 리팩터링해도 유령이 안 생긴다. 결국 URL을 함부로 안 바꾼다는 이 시리즈의 큰 원칙이 사이트맵 주소에도 똑같이 적용되는 셈이다.

결국 이 편의 교훈도 시리즈 전체와 같다. 과거에 뿌린 것이 미래에 청구서로 돌아온다는 것. 그래서 무언가를 만들 때 이게 나중에 어떻게 사라질지까지 생각해두는 습관이 신생 사이트 운영자에겐 큰 자산이 된다. 유령 사이트맵은 그 습관의 부재가 남긴 작은 흔적일 뿐이다.

한 가지 더 실무 조언을 남기면, 사이트맵 관련 변경은 반드시 이력을 남겨두는 게 좋다. 언제 어떤 사이트맵 구조를 썼고 언제 바꿨는지를 기록해두면, 나중에 유령이 나타났을 때 그 출처를 바로 추적할 수 있다. 기록이 없으면 내가 언제 이런 걸 만들었지 하며 한참을 헤매게 된다. 인프라의 변경일수록 흔적을 남겨두는 습관이 훗날의 나를 구한다.