리다이렉트 체인(Redirect Chain)은 한 URL을 요청했을 때 최종 페이지에 도달하기까지 A에서 B로, B에서 다시 C로 이어지는 식으로 리디렉션을 두 번 이상 거치는 상태다. 리디렉션 체인, 연쇄 리디렉션이라고도 부른다.
리디렉션 한 번은 정상이다. 문제는 한 번으로 끝낼 수 있는 이동을 여러 번에 나눠 처리하는 데 있고, 구글은 사이트 이전 가이드에서 “체인 리디렉션을 사용하지 않습니다”라고 못 박는다 (Google 검색 센터, URL이 변경되는 사이트 이동).
홉마다 요청과 응답이 한 번씩 더 오가서 사용자와 크롤러 모두 느려지고, 길면 크롤러가 끝까지 따라가지 않기 때문이다. 흔히 말하는 “홉마다 페이지랭크가 깎인다”는 구글이 부정한 주장이다.
| 영향 | 근거 |
|---|---|
| 사용자 지연 | 리디렉션 하나가 네트워크 왕복을 추가해 “리소스 로딩이 수백 밀리초 지연될 수 있다”. Lighthouse는 리디렉션이 2개 이상인 페이지를 감사 실패로 표시한다 (Chrome for Developers, 여러 번의 페이지 리디렉션 피하기) |
| 크롤링 한도 | 구글 크롤러는 “기본적으로 최대 10개의 리디렉션 홉”만 따른다 (Google 크롤링 인프라, HTTP 상태 코드가 Google 크롤러에 미치는 영향) |
| 크롤 버짓 | 구글은 크롤링 예산 최적화 항목에 “긴 리디렉션 체인 사용하지 않기. 크롤링에 부정적인 영향을 미칩니다”를 넣어 두었다 (Google 크롤링 인프라, 크롤링 예산 최적화) |
| 호환성 | 구글은 “일부 사용자 에이전트와 브라우저에서는 긴 리디렉션 체인을 지원하지 않습니다”라고 적는다 (Google 검색 센터, URL이 변경되는 사이트 이동) |
링크 신호 손실은 여기 들어가지 않는다. 구글은 같은 사이트 이전 문서에서 “301 및 기타 영구 리디렉션으로 인해 PageRank가 손실되는 일은 없습니다”라고 밝힌다. 체인을 줄여야 하는 이유는 페이지랭크가 아니라 속도와 크롤링이다.
기술적 한도는 10홉, 권장은 3홉 이하다. 구글은 Googlebot이 “최대 10개의 홉을 지원할 수 있으나, 최종 도착 페이지로 리디렉션하는 것이 좋습니다”라고 적고, 한 번에 처리할 수 없다면 “3개 이하가 적당하며 최대 5개까지”라고 기준을 준다 (Google 검색 센터, URL이 변경되는 사이트 이동).
10홉을 넘으면 구글은 최종 페이지를 가져오지 못하고, 서치콘솔 페이지 색인 생성 보고서에 리디렉션 오류로 잡힌다. 1홉이 이상적이고, 3홉을 넘기면 고쳐야 할 대상으로 본다.
리디렉션 종류는 체인 판정과 무관하다. 구글은 301과 308을 강한 신호, 302와 307을 약한 신호로 쓰지만 홉 수 계산은 어느 쪽이든 같다 (Google 크롤링 인프라, HTTP 상태 코드가 Google 크롤러에 미치는 영향). 체인 안에 302가 섞여 있으면 최종 URL이 표준 URL로 잡히지 않을 수 있으므로, 영구 이동이면 전부 301이나 308로 맞춘다.
규칙을 하나씩 따로 추가하고 예전 규칙을 지우지 않기 때문이다. 대부분 서로 다른 시점에 다른 목적으로 넣은 리디렉션이 겹치면서 생긴다.
| 원인 | 체인 예시 |
|---|---|
| HTTP에서 HTTPS 전환과 www 통일을 따로 처리 | http://example.com → https://example.com → https://www.example.com |
| 사이트 개편을 거듭하며 이전 규칙 위에 새 규칙 추가 | /blog/post → /articles/post → /insights/post |
| 후행 슬래시, 대소문자 정규화 규칙이 별도로 작동 | /Page → /page → /page/ |
| 홈 리디렉션이 특정 경로로 다시 이동 | / → /main → /main/recommend |
| 플랫폼 이전 후 예전 URL을 새 플랫폼의 중간 URL로 연결 | 예전 CMS URL → 새 CMS 임시 URL → 최종 URL |
첫 번째 유형이 가장 흔하다. HTTPS 전환 규칙과 www 통일 규칙을 서버 설정에서 각각 한 줄씩 넣으면, http 비www 주소로 들어온 요청이 두 규칙을 차례로 타게 된다.
2026년 10월 8일 네이버, 다음, 쿠팡, 11번가, G마켓, 조선일보, 중앙일보, 한겨레, 나무위키, 무신사, 컬리, 예스24, 한국경제, 매일경제, 동아일보, 올리브영, SSG, 다나와, 인벤, 디시인사이드와 이 사이트의 http://도메인/ 주소를 데스크톱 브라우저 유저 에이전트로 요청해 최종 응답까지의 리디렉션 횟수를 셌다.
| 리디렉션 횟수 | 사이트 수 | 예 |
|---|---|---|
| 0회 (http 요청에 바로 200 응답) | 6곳 | 네이버, 11번가, 한겨레, 컬리, 동아일보, 서치폴라리스 |
| 1회 | 5곳 | 조선일보, 중앙일보, 한국경제, 다나와, 인벤 |
| 2회 | 8곳 | 다음, 쿠팡, G마켓, 나무위키, 매일경제, 올리브영, SSG, 디시인사이드 |
| 3회 | 2곳 | 무신사, 예스24 |
2회 이상인 10곳은 대부분 “HTTPS 전환 → www 붙이기” 두 단계였고, 3회인 두 곳은 거기에 홈을 특정 경로로 보내는 세 번째 홉이 붙어 있었다. 무신사는 301, 302, 308이 한 체인에 섞여 있었다.
이 사이트도 예외가 아니다. 예전 블로그 주소 http://www.searchpolaris.com/blog/geo/를 요청하면 https 전환, www 제거, /blog/에서 /wiki/로의 이동이 차례로 일어나 3홉 만에 최종 페이지에 닿는다. 위키 분리 때 추가한 규칙이 기존 도메인 정규화 규칙 뒤에 붙은 결과이고, 고칠 대상으로 기록해 둔다.
URL 하나는 명령줄로, 사이트 전체는 크롤러로 확인한다.
curl -sIL URL을 실행하면 홉마다 상태 코드와 Location 헤더가 찍히므로, HTTP 상태 줄의 개수에서 1을 빼면 리디렉션 횟수다. -w "%{num_redirects}" 옵션으로 횟수만 받을 수도 있다.모든 시작 URL이 최종 URL로 한 번에 가도록 규칙을 다시 쓰고, 중간 URL을 가리키는 링크를 최종 URL로 바꾼다.
오래된 리디렉션을 지울 때는 주의한다. 외부 사이트가 여전히 링크하고 있는 예전 URL의 리디렉션을 없애면 404가 되므로, 규칙을 삭제하는 것이 아니라 목적지를 최종 URL로 바꾸는 방식으로 정리한다. 301 리디렉션은 한 번 걸었으면 최종 URL이 바뀌지 않는 한 유지한다.
체인은 A → B → C처럼 끝이 있는 연속 이동이고, 루프는 A → B → A처럼 시작점으로 되돌아와 끝나지 않는 이동이다. 루프는 브라우저가 “리디렉션이 너무 많습니다” 오류를 내고 크롤러는 페이지를 가져오지 못하므로, 체인보다 심각하고 즉시 고쳐야 한다.
HTTPS 페이지에 닿는 체인의 중간 홉 가운데 http://로 시작하는 URL이 있다는 뜻이다. 그 홉을 지나는 동안 요청이 암호화되지 않아 보안 등급 평가 도구가 경고하며, 모든 홉이 HTTPS 주소로만 이어지도록 규칙을 고치거나 체인 자체를 없애면 해결된다.
서치폴라리스가 AI 검색 가시성을 진단하고 GEO 실행까지 대행합니다.