· No.19
410 은 Search Console 의 404 칸을 비우지 못한다 — 채운다
옛 주소 15건을 410 Gone 으로 응답하게 바꿨다. 근거는 「410 이면 크롤러가 확실히 지운다」는 통념이었다. 배포 이틀 뒤 크롤링에서 그 15건이 전부 404 로 집계됐다. 없어진 페이지는 한 건도 없었고 정본 주소는 전부 200 이었다 — 우리가 스스로 만든 오류였다. 301 로 되돌리는 과정에서 상태코드만 보던 테스트에 홉 수 측정을 넣은 이야기.
사이트의 오류 보고에 404 가 15건 떠 있었다. 사이트가 고장 난 것처럼 보인다. 확인해 보니 없어진 페이지는 한 건도 없었다. 15건 전부 옛 형식의 주소였고 각각에 대응하는 정본 주소가 살아 있었다. 직접 재 보면 200 이 나온다.
그 15건은 우리가 일부러 만든 것이었다.
처음 판단 — 「깔끔하게 지운다」
주소 체계를 바꾸면서 옛 주소를 어떻게 할지 정해야 했다. 두 선택지가 있었다.
- 301 — 새 주소로 영구 이동. 링크 가치가 넘어간다.
- 410 — 이 자원은 사라졌고 다시 안 온다. 404 보다 강한 선언이다.
410 을 골랐다. 근거는 이랬다. 410 은 404 와 달리 「확실히 없다」는 뜻이므로 크롤러가 더 빨리 지우고 오류 목록에서도 빠진다. 이 설명은 여기저기서 볼 수 있고 그럴듯하다. 그때 문서에 그렇게 적어 뒀다.
그 전제가 실측으로 뒤집혔다
410 을 배포한 것이 24일이다. 그 뒤인 26~29일 크롤링 결과에서 그 15건이 404 칸에 들어가 있었다.
색인 도구는 410 을 별도 칸으로 분리하지 않는다. 「없음」 계열로 같이 집계한다. 즉 410 은 404 칸을 비우는 수단이 아니라 채우는 수단이다.
여기서 두 가지가 동시에 확인됐다. ① 우리가 근거로 삼은 통념이 우리 환경에서는 성립하지 않았다. ② 우리는 그것을 문서에 결론처럼 적어 뒀다. 다음 사람이 그 문서를 읽으면 같은 선택을 한다.
그런데 그 판단에는 원래 다른 목적이 있었다
410 을 고른 진짜 이유는 따로 있었다. 광고 심사를 앞두고 「중복 콘텐츠로 보일 여지를 없애자」는 것이었다. 옛 주소와 새 주소가 같은 내용을 서빙하면 심사에서 불리할 수 있다는 판단이다.
그 심사에서 떨어졌다. 410 을 유지할 유일한 근거가 없어졌다.
이 지점이 중요하다. 실측이 전제를 깨뜨렸을 때 곧바로 뒤집지 않은 이유는 「그래도 다른 이득이 있다」였는데 그 이득이 사라지자 판단이 한 줄로 정리됐다. 남아 있는 근거가 0이면 되돌린다.
되돌리면서 알게 된 것 — 상태코드만 보는 테스트는 체인을 못 본다
410 을 끄고 301 로 바꿨다. 15건 전부 200 에 도달했고 410 은 0건이 됐다.
그런데 여기서 기존 테스트의 한계가 드러났다. 우리 테스트는 최종 상태코드가 200 인지를 본다. 그 사이에 리디렉션이 몇 번 일어나는지는 안 본다. 200 이면 통과다.
리디렉션이 여러 번 겹치면 검색 엔진 쪽에서 손해가 난다. 그리고 우리 규칙은 조건이 여럿이라 겹치기 쉽다 — 슬래시 정규화, 확장자 제거, 호스트 정규화가 각각 따로 걸려 있다. 규칙 순서가 어긋나면 조용히 두 번, 세 번 돈다. 결과는 여전히 200 이므로 테스트는 계속 초록이다.
홉 수를 세는 측정을 새로 넣었다. 28건을 재서 전부 통과했고 최대 1홉이다. 가장 나쁜 조합(비암호화 + www + 확장자)까지 1홉이다.
그러다 5건이 2홉으로 나왔다. 원인은 우리 코드가 아니라 앞단 인프라의 규칙이었다. 계정 설정 영역이라 손대지 않고 기록만 남겼다. 이건 고칠 수 없어서 남긴 게 아니다. 우리 코드를 아무리 봐도 안 나오는 것이라 다음 사람이 코드에서 원인을 찾다가 시간을 쓰지 않게 적어 둔 것이다.
색인 오류 2건 중 하나는 결함이 아니었다
같은 보고에 색인 관련 항목이 2건 있었다. 하나는 RSS 파일이었다. 그건 원래 색인되면 안 되는 파일이다. 결함이 아니라 분류 실패였다 — 색인 대상이 아닌 파일에 그 표시를 안 해 뒀기 때문에 도구가 「색인 못 함」으로 집계했다.
표시를 넣어서 해결했다. 파일을 고친 게 아니다. 파일의 성격 선언을 고쳤다.
그리고 아무것도 안 누른 것
색인 도구에는 「검사 요청」 버튼이 있다. 리디렉션되는 주소로 그 검사를 돌리면 원리적으로 통과할 수 없다 — 검사 대상 주소가 최종 주소가 아니기 때문이다. 누르면 실패 기록만 쌓인다.
그래서 안 눌렀다. 대신 그 칸의 숫자가 앞으로 늘어난다는 것을 미리 적어 뒀다. 301 이 정상 동작할수록 「리디렉션이 포함된 페이지」 항목은 커진다. 그건 오류가 아니라 제외다. 늘어나는 게 맞다.
숫자가 늘어나는 것을 보고 다음 사람이 「고장 났다」고 판단하는 것 — 이번 15건이 정확히 그렇게 시작됐다.
배포 문서도 같이 고쳤다
조사 중에 배포 문서의 예시 주소가 www 붙은 형태인 것을 발견했다. 그 문서를 그대로 따르면 사이트맵의 모든 주소가 리디렉션 대상이 된다. 이번 사고와 같은 계열이다 — 문서에 적힌 잘못된 예시가 다음 사고를 예약한다.