2000년에 처음 등록된 도메인을 하나 샀습니다. 겉으로 보면 오래된 이력은 오히려 장점처럼 보였습니다. 그런데 새 사이트를 공개하자 제가 만든 적도 없는 페이지로 향하는 요청이 서버 로그를 채우기 시작했습니다.
새 프로젝트에는 존재하지 않는 URL로 하루 1,000건이 넘는 요청이 들어왔습니다. analytics에서는 거의 engagement가 없는 큰 direct traffic 급증으로 보였습니다. 동시에 Yandex crawler도 옛 path를 다시 방문해 404 Not Found를 받았고, Yandex Webmaster에는 하룻밤 사이 900건이 넘는 오류가 쌓였습니다.
처음에는 이렇게 설명했습니다. 예전 bot이 죽은 URL을 계속 두드리고, Yandex가 그 활동을 보고 있어서 계속 crawl한다는 것입니다. 제 입장에서 본 시간 순서는 그렇게 보였습니다. 하지만 제 데이터만으로는 그 인과관계를 증명할 수 없었습니다.
제가 실제로 확인할 수 있었던 것
확인된 사실은 서로 다른 세 가지였습니다. 첫째, 서버는 도메인의 과거에 속한 URL로 많은 요청을 받고 있었습니다. 둘째, 그 traffic은 의미 있는 사용자 engagement로 거의 이어지지 않았습니다. 셋째, Yandex crawler도 옛 path를 요청했고 Webmaster 대시보드에는 한밤중에 900건이 넘는 오류가 나타났습니다.
운영상으로는 충분히 문제였습니다. 로그가 시끄러워지고 불필요한 요청이 늘었으며 webmaster report도 정리가 필요했습니다. 하지만 이 사실만으로 제3자 bot이 Yandex crawl을 유발했다고 증명할 수는 없습니다. 오류가 ranking이나 organic traffic을 직접 떨어뜨렸다고도 말할 수 없습니다. Crawling은 indexing이 아니고, indexing은 ranking이 아니며, 오류 보고서는 penalty의 증거가 아닙니다.
제가 너무 단순하게 이해했던 404와 410
예전에는 404를 “지금은 없을 수도 있음”, 410을 “영구적으로 사라짐” 정도로 이해했습니다. 직관적인 설명으로는 쓸 만하지만 기술적으로 정확하지는 않습니다.
404 Not Found는 서버가 요청된 resource의 현재 representation을 제공할 수 없다는 뜻입니다. 그 상태가 일시적인지 영구적인지는 404 자체만으로 알 수 없습니다. 410 Gone은 더 구체적입니다. 서버가 해당 resource가 더 이상 존재하지 않고 그 상태가 영구적이라고 알고 있을 때 적합합니다.
SEO를 설명할 때도 이 차이가 중요합니다. 검색엔진은 404와 410을 반환하는 URL 모두를 검색에서 제거할 수 있습니다. 그래서 지금은 410을 “404보다 더 강한 SEO status”라고 부르지 않고, 삭제된 모든 페이지에서 404가 틀렸다고도 말하지 않습니다.
그래도 제 경우에는 선택적인 410이 맞았던 이유
문제의 옛 path는 일시적인 장애가 아니었습니다. 도메인의 이전 콘텐츠에 속해 있었고 새 프로젝트에는 대응되는 페이지가 없었습니다. 적어도 제가 대상으로 삼은 URL은 영구적으로 돌아오지 않을 것임을 알고 있었습니다. 그래서 410 Gone이 상태를 정확하게 표현했습니다.
저는 모든 알 수 없는 URL을 410으로 처리하지 않고, 확인된 legacy path에만 선택적으로 410을 반환하도록 했습니다. 그 변경 이후 옛 path를 둘러싼 crawl과 reporting noise가 줄었고 webmaster tools의 상태도 훨씬 깔끔해졌습니다.
다만 인과관계는 조심스럽게 표현합니다. “선택적인 410 적용 뒤 상황이 좋아졌다”, “410이 해당 URL의 상태를 정확히 표현했다”는 말은 할 수 있습니다. 하지만 410 하나만으로 모든 bot이 멈췄다고 증명할 수는 없습니다. 임의의 제3자 bot은 HTTP status의 의미를 무시하고 같은 path를 계속 요청할 수 있습니다.
지금 제가 쓰는 판단 기준
중요한 질문은 “410이 404보다 좋은가?”가 아니라 “이 URL에 실제로 무슨 일이 있었는가?”입니다.
- 명확한 대체 URL이 있다: 실제로 같은 내용을 가리키는 새 URL로
301같은 permanent redirect를 사용합니다. - 기존 resource가 영구적으로 삭제됐고 대체가 없다:
410 Gone이 정확한 선택입니다. - URL이 단순히 알 수 없거나 오타이거나 애초에 존재하지 않았다: 일반적인
404 Not Found가 적절합니다.
반대로 오류를 없애기 위해 모든 죽은 URL을 홈페이지로 redirect하는 방식은 피합니다. resource의 실제 상태를 숨기고 사용자와 crawler 모두에게 더 나쁜 경험을 만들 수 있기 때문입니다.
지금이라면 오래된 도메인을 공개 전에 어떻게 점검할까
다시 이력이 있는 도메인을 쓴다면, 옛 사이트 자체를 옮기지 않더라도 URL history를 migration의 일부로 다룰 것입니다.
- 옛 footprint를 조사합니다. 공개 전에 historical URL과 눈에 띄는 legacy section을 찾습니다.
- 첫날부터 access log를 봅니다. 내가 만든 적 없는 path로 반복 요청이 온다면 도메인이 외부에 아직 기억되고 있다는 증거입니다.
- 사람, search crawler, 임의의 bot을 구분합니다. direct traffic 급증과 crawler error는 서로 다른 signal이며 하나의 인과관계로 묶어서는 안 됩니다.
- 반복되는 dead URL을 분류합니다. 중요한 pattern마다 301, 404, 410 중 무엇이 맞는지 결정합니다.
- 결과를 따로 봅니다. 요청 빈도, crawler report, indexing은 서로 다른 차원입니다. 이를 하나의 모호한 “SEO health” 지표로 합치지 않습니다.
로그와 webmaster tools가 이미 noise로 가득 찬 뒤 원인을 찾는 것보다 훨씬 적은 비용으로 할 수 있는 작업입니다.
410이 해결하지 못하는 것
410은 resource 상태를 알려주는 HTTP 응답입니다. firewall도, rate limiter도, bot 차단 기능도 아닙니다. scraper가 410을 받은 뒤에도 요청을 계속 보내면 서버는 여전히 그 요청을 받아 답해야 합니다. 진짜 문제가 과도한 request volume이라면 이는 별도의 infrastructure 문제입니다.
또한 410은 SEO boost가 아닙니다. 올바른 status는 crawler가 URL의 상태를 이해하도록 도울 뿐이며, 그 자체로 새 사이트의 ranking을 올려주지는 않습니다.
이 경험에서 남은 규칙
놀라웠던 것은 오래된 도메인에 옛 URL이 있었다는 사실이 아닙니다. 보이지 않던 과거가 새 사이트 공개 직후 얼마나 빨리 다시 드러났는지가 놀라웠습니다. 제가 갖고 있지도 않은 페이지로 하루 1,000건이 넘는 요청, 거의 0에 가까운 engagement, 그리고 Yandex Webmaster에 하룻밤 사이 900건이 넘는 오류.
오래된 도메인은 빈 namespace가 아닙니다. 원본 콘텐츠가 사라진 지 몇 년이 지나도 링크, crawler, script, bot은 path를 기억할 수 있습니다. 지금 제 규칙은 간단합니다. 과거를 audit하고, 현실에 맞는 HTTP status를 반환하며, 운영상의 bot traffic과 검색엔진에 대한 추론을 분리합니다.
이력은 자산이 될 수 있습니다. 동시에 여러분이 물려받는 state이기도 합니다.