블로그로 돌아가기
2025년 10월 3일Sergei Solod5 분 읽기

Yandex가 /en 없이 내 블로그를 크롤링했다. 308 리디렉션이 404를 막아줬다

sitemap에 약 3,000개의 /en/blog/... 페이지를 추가한 뒤 Yandex가 대응되는 /blog/... 경로를 시도하는 것을 봤습니다. 미리 설정해 둔 308 리디렉션 덕분에 해당 요청은 404로 끝나지 않았습니다. 핵심은 Yandex가 sitemap을 “망가뜨렸다”는 이야기가 아니라, 정확한 리디렉션 계층이 URL 구조를 얼마나 견고하게 만들 수 있는지였습니다.

SEOYandexSitemap308 리디렉션테크니컬 SEO크롤링

/en/blog/... 아래에 약 3,000개의 새 페이지를 넣은 sitemap 업데이트를 배포했습니다. 얼마 지나지 않아 Yandex Webmaster에서 예상하지 못한 패턴을 확인했습니다. Yandex가 /en 접두사가 없는 대응 경로 /blog/... 를 크롤링하려고 했습니다.

이 URL들이 그대로 404를 반환했다면, 존재하지 않는 경로로 향하는 불필요한 crawl 요청이 수천 건 생길 수 있었습니다. 다행히 저는 언어 접두사가 없는 route에서 실제 영어 URL로 보내는 영구 308 리디렉션을 이미 설정해 둔 상태였습니다.

이 작은 방어적 routing 계층은 예상보다 훨씬 유용했습니다.

제가 실제로 확인한 것

  1. /en/blog/... 구조의 새 페이지 약 3,000개를 포함한 sitemap을 배포했습니다.
  2. 그 뒤 Yandex Webmaster에서 Yandex가 대응되는 /blog/... URL을 크롤링하려는 것을 확인했습니다.
  3. 이 대체 경로들은 이미 308 리디렉션으로 처리되고 있었습니다.
  4. 따라서 요청은 404로 끝나지 않고 의도한 /en/blog/... URL로 이동했습니다.

원래 글의 표현에는 중요한 수정이 필요합니다. 저는 Yandex가 “sitemap을 잘못 파싱했다”고 증명할 수 없습니다. sitemap 업데이트 뒤에 예상 밖 경로를 본 것은 사실이지만, 시간 순서만으로 내부 원인을 확정할 수는 없습니다. 검색엔진은 여러 signal과 과거 source를 통해 URL을 발견할 수 있습니다. 더 강한 증거가 없다면 정확하게 말할 수 있는 것은 Yandex가 제가 예상하지 못한 경로를 크롤링했다는 정도입니다.

이 구분은 중요합니다. 크롤러가 이상한 URL을 요청한 것은 관찰입니다. 왜 그 URL을 선택했는지를 설명하는 것은 별도의 주장입니다.

308 리디렉션이 왜 도움이 됐는가

제 redirect logic은 짧은 경로를 localized URL의 영구 alias처럼 다뤘습니다.

/blog/example-post  -> 308 ->  /en/blog/example-post

그래서 crawler가 예상 밖 URL로 들어와도 결국 제가 실제로 제공하려던 페이지에 도달했습니다.

308 Permanent Redirect는 request method와 body를 유지하는 영구 HTTP 리디렉션입니다. 일반적인 crawler GET request에서는 method 보존 자체가 핵심은 아닙니다. 이번 경우에는 이 redirect가 명시적으로 permanent라는 점이 중요했습니다. 현재 Yandex Webmaster 문서도 301308을 모두 영구 리디렉션으로 분류합니다.

Yandex Webmaster의 리디렉션 공식 문서.

그렇다고 SEO에서 308이 301보다 항상 낫다는 뜻은 아닙니다. 제 경우에는 308이 이미 있었고 필요한 역할을 했습니다. 예상하지 못한 URL이 막다른 길이 되지 않았습니다.

리디렉션은 safety net이지 sitemap 수정이 아니다

리디렉션은 피해를 줄였지만, 불필요한 crawl 자체를 바람직하게 만들지는 않습니다. redirect 하나마다 request와 hop이 하나씩 늘어납니다. 너무 넓은 rule은 잘못된 URL의 출처를 더 이상 조사하지 않을 경우 URL 생성 bug를 숨길 수도 있습니다.

sitemap 자체에 오래된 URL이나 redirect되는 URL이 있다면 올바른 해결은 sitemap을 수정해 final URL을 넣는 것입니다. Redirect는 과거 경로, 대체 경로, 우연히 발견된 경로를 안전하게 처리해야지 부정확한 URL 데이터를 정당화하는 용도가 아닙니다.

제 경우 sitemap은 이미 /en/blog/...을 사용하고 있었습니다. 308은 crawler가 /blog/...로 들어왔을 때 사이트를 더 견고하게 만들어준 계층이었습니다.

지금 같은 일이 생기면 무엇을 확인할까

  1. 실제로 배포된 sitemap을 엽니다. generator 코드만 믿지 않고 최종 파일과 여러 실제 URL을 확인합니다.
  2. 최종 response를 확인합니다. index하려는 URL은 가능하면 불필요한 redirect chain 없이 목적 페이지에 바로 도달해야 합니다.
  3. 예측 가능한 대체 경로를 테스트합니다. 오래된 URL이나 prefix 없는 URL에 영구 목적지가 있다면 mapping을 명확한 1:1로 둡니다.
  4. redirect chain을 피합니다. A -> B -> C보다 A -> C가 이해하고 검증하기 쉽습니다.
  5. 가능하면 crawler report와 서버 측 evidence를 비교합니다. Webmaster tool은 유용하지만 URL이 처음 어디서 발견됐는지 항상 알려주지는 않습니다.
  6. crawling만 보고 ranking을 추론하지 않습니다. Crawling, indexing, ranking, traffic은 서로 다른 단계입니다.
curl -I https://example.com/blog/example-post

HTTP/2 308
location: https://example.com/en/blog/example-post

위 코드는 설명용 예시입니다. 핵심은 routing rule이 동작할 것이라고 가정하지 말고 정확한 status와 destination을 확인하는 것입니다.

제가 말할 수 있는 것과 말할 수 없는 것

미리 있던 308 리디렉션이 예상 밖 /blog/... request를 404로 끝나지 않게 하고 의도한 URL로 보냈다는 것은 확인할 수 있습니다.

반면 Yandex의 sitemap parser가 원인이었다고는 확인할 수 없습니다. ranking 상승, indexing 개선, 구체적인 양의 traffic을 “구했다”는 측정도 하지 않았습니다. 그런 주장은 제가 가진 근거보다 강합니다.

제가 얻은 결론은 더 좁고 더 실용적입니다. URL architecture는 시스템 경계에서 발생할 수 있는 예측 가능한 실수를 견딜 수 있어야 합니다. 깨끗한 sitemap이 첫 번째 방어선이고, 정확한 permanent redirect layer가 두 번째입니다.

둘 다 있다면 예상 밖 crawler path 하나가 수천 개의 dead URL로 번질 가능성은 훨씬 낮아집니다.