11월 14, 2026 가이드 읽는 시간 2분

리다이렉트 체인 확인 및 수정 방법 (301/302)

리다이렉트 체인은 URL이 목적지로 곧장 이동하지 않고 중간 URL들을 거쳐 가면서 생깁니다. http://example.com/page가 https://example.com/page로 301 리다이렉트되고, 이 URL이 다시 https://www.example.com/page로 301 리다이렉트되어 마침내 200을 반환하는 식입니다. 홉이 하나 늘 때마다 HTTP 왕복이 한 번씩 추가되고, 각 홉은 깨지거나 이동의 성격을 잘못 표시할 수 있는 규칙 하나이기도 합니다. 이 가이드에서는 체인이 SEO를 해치는 이유, 무료 redirect chain checker로 체인을 홉별로 읽는 방법, 그리고 어떤 체인이든 리다이렉트 하나로 평탄화하는 방법을 다룹니다.

리다이렉트 체인이란 무엇인가요?

리다이렉트란 — 정확히는 아무 3xx나 아니라 301, 302, 303, 307, 308 응답 — Location 헤더를 통해 “요청하신 페이지는 이제 여기 있습니다”라고 알려주는 것을 말합니다. 체인은 이런 리다이렉트가 두 개 이상 줄지어 쌓인 상태입니다:

GET http://example.com/old-page
  301 → https://example.com/old-page
  301 → https://www.example.com/old-page
  301 → https://www.example.com/new-page
  200 ← final page

클라이언트는 각 URL을 차례로 요청해야 합니다. 반대로 리다이렉트 루프는 자기 자신으로 되돌아가(A → B → A) 영원히 끝나지 않으며, 브라우저는 ERR_TOO_MANY_REDIRECTS를 표시합니다. 체인이 의도해서 만들어지는 경우는 드뭅니다. 이전(migration)이 쌓이는 겁니다 — 과거의 www 통합 위에 HTTPS 적용, 그다음 사이트 재구축 — 그리고 아무도 앞선 규칙을 정리하지 않으면 그대로 남습니다.

리다이렉트 체인이 SEO를 해치는 이유

지연 시간이 누적됩니다. 홉 하나는 최소한 HTTP 왕복 한 번의 비용을 물립니다 — 홉 수에 방문자의 왕복 시간을 곱해 보세요. 호스트를 넘어가는 홉에는 DNS 조회와 새로운 TCP/TLS 핸드셰이크가 더해지지만, 같은 호스트 안의 홉은 연결을 재사용할 수 있습니다. Google의 사이트 이전 가이드는 “리다이렉트를 연결하면 사용자에게 지연이 추가되며, 모든 사용자 에이전트와 브라우저가 긴 리다이렉트 체인을 지원하는 것은 아니다”라고 경고합니다 — 그리고 페이지 속도는 순위에 사용되는 Core Web Vitals 신호로 이어집니다.

더 이상 존재하지 않는 URL에 크롤 예산이 낭비됩니다. 중간 변형 URL을 따라가는 데 쓴 크롤은 실제 페이지에 쓰이지 못한 크롤입니다. robots.txt로 체인을 해결하려 들지도 마세요: 중간 URL을 disallow하면 리다이렉트 자체가 Googlebot에게 숨겨져서, Googlebot은 홉 대신 차단을 보게 됩니다. robots.txt는 본래 목적인 크롤 지시어에만 한정해서 쓰세요.

체인은 물리기 쉽습니다. 중간의 어느 홉이든 하나라도 깨지면 그 위쪽 전체가 막다른 길이 됩니다 — 원본 URL을 가리키는 백링크까지 포함해서요.

뒤섞인 상태 코드는 뒤섞인 신호를 보냅니다. Google의 리다이렉트 문서는 명확합니다. 301은 “색인 파이프라인이 이 리다이렉트를 리다이렉트 대상이 canonical이어야 한다는 신호로 사용한다”이고, 302는 “리다이렉트를 신호로 사용하지 않으므로” 원본 페이지가 검색 결과에 남습니다. 체인 어디에든 302가 하나 있으면 통합이 늦어지거나 아예 안 될 수 있습니다. Google은 오래 방치된 302도 결국 영구 리다이렉트로 취급된다고 밝힌 바 있습니다 — 다만 더 느리게요. 홉 자체는 아무것도 잃지 않습니다. Google의 사이트 이전 가이드에 따르면 “301 및 기타 영구 리다이렉트는 PageRank 손실을 일으키지 않습니다”.

301 vs 302 vs 307 vs 308: 하나를 정하면 그 의미를 지키세요

301 (Moved Permanently) — 영구 이동입니다. 사이트 이전, URL 재작성, http→https 전환, www 통합의 기본 선택입니다.
302 (Found) — 임시 이동이며 기존 URL이 canonical로 남습니다. A/B 테스트, 짧은 프로모션, 지역 타기팅용입니다.
307 / 308 — 더 엄격한 임시/영구 코드입니다: 동일한 메서드와 본문을 그대로 재전송해야 합니다.

문제는 섞일 때 시작됩니다. 몇 년 전에 /old-lp를 /spring-campaign로 301 리다이렉트했고, 올해 마케팅 팀이 “그냥 캠페인일 뿐”이라며 /spring-campaign을 새 페이지에 302로 연결했다고 합시다. 이 301 → 302 체인은 영구성을 반쯤만 주장합니다. 한 번만 정하세요: 영구라면 모든 홉을 301로, 임시라면 원본 URL에서 302 하나로.

리다이렉트 체인 단계별 확인 방법

무료 Redirect Chain Checker는 크롤러가 보는 그대로 체인을 따라갑니다. 각 홉은 새로운 HTTP GET입니다 — 캐시도, 쿠키도, JavaScript도, HSTS 업그레이드도 없이 — user agent는 GeoToolsBot/1.0으로 요청합니다.

1단계: 검사할 가치가 있는 URL 모으기

추측이 아니라 출처에서 모으세요: 현재와 과거의 사이트맵, 서버 접근 로그, 외부 링크가 달린 페이지를 볼 수 있는 Search Console의 링크 보고서 — Google의 사이트 이전 가이드가 권장하는 바로 그 출처들입니다 — 에 더해 상위 페이지의 http:// 버전과 non-www 변형, 백링크 내보내기 파일까지요.

2단계: 검사 실행하기

redirect chain checker에 URL을 붙여넣고 Check redirects를 누르세요. 도구는 리다이렉트를 비활성화한 상태로 URL을 요청하고, Location을 읽고, 해석한 뒤 다시 반복합니다 — 최대 여섯 홉까지, 매 단계에서 루프를 감지합니다. 모든 홉의 상태 배지, URL과 대상, 최종 랜딩 페이지와 콘텐츠 유형을 얻습니다. 저희가 테스트한 건강한 기준 사례 http://github.com: 301 한 번, 이어 200.

3단계: 문제 목록 읽기

검사기는 또한 해가 되는 것들을 표시해 줍니다. 홉이 세 개를 넘는 체인 — 체인을 “이상적으로는 3개 이하, 5개 미만”으로 유지하라는 Google의 조언과 같은 기준입니다; 첫 홉 이후에도 여전히 평문 http://에 머무는 홉 — HTTPS 업그레이드가 늦어진다는 뜻입니다; 영구 코드와 임시 코드의 혼용; 도메인을 넘어가는 홉 — 등록 도메인(등록하는 단위인 example.com을 말하며 shop.example.com이 아님)을 벗어나는 홉으로, Google은 이를 주소 변경(Change of Address) 도구가 포함된 자체 체크리스트가 있는 사이트 이전으로 취급합니다; PDF 같은 비 HTML 최종 페이지; 그리고 4xx/5xx로 끝나는 경우. 빙글빙글 도는 URL은 체인 대신 루프 오류를 반환합니다.

4단계: 엔지니어를 위한 스팟 체크 방법

curl -sI http://github.com          # first hop only
# HTTP/1.1 301 Moved Permanently
# Location: https://github.com/

curl -sIL http://www.apache.org     # headers for EVERY hop
# HTTP/1.1 301 Moved Permanently
# Location: https://www.apache.org/
# HTTP/2 200

curl -s -o /dev/null -w 'status=%{http_code} redirects=%{num_redirects} final=%{url_effective}n' -L http://github.com
# status=200 redirects=1 final=https://github.com/

실제 실행에서 얻은 주의 사항 두 가지: -I는 HEAD 요청을 보내는데, 일부 서버는 HEAD를 다르게 취급합니다 — 저희 실행에서 github.com은 멈춰 섰고 GET은 순조롭게 통과했습니다. 그리고 최종 응답이 403이라고 해서 항상 고장 난 것은 아닙니다. 집필 시점에 stackoverflow.com은 깔끔한 301 다음에 봇에게 403을 반환했습니다. “고장 난” 최종 페이지는 먼저 브라우저에서 다시 확인하세요.

체인을 홉 하나로 평탄화하는 방법

목표는 하나입니다: 리다이렉트되는 모든 URL이 최종 목적지를 직접 가리키게 하는 것. 중간자는 없애는 겁니다.

먼저 체인을 그리세요. 무엇이든 손대기 전에 정확한 홉과 상태 코드를 적어 두세요.
첫 홉을 다시 쓰세요. nginx에서는 80번 포트에서 수신하는 server 블록(또는 이전 호스트의 블록)에 return 301 https://www.example.com/new-page;를 넣습니다. Apache에서는 Redirect 301 /old-page https://www.example.com/new-page가 mod_alias를 필요로 하며 vhost나 .htaccess에 들어갑니다. 이 지시어는 경로 세그먼트 전체를 매칭하므로 /old-page는 /old-page/sub까지 잡습니다 — 정확히 일치시키려면: RedirectMatch 301 ^/old-page$ https://…/new-page. WordPress에서는 Redirection 플러그인이 데이터베이스에서 이 매핑을 관리합니다.
중간 홉을 제거하거나 방향을 바꾸세요. 규칙을 삭제하기 전에 실제로 그곳을 가리키는 것이 없는지 확인하세요: 백링크 내보내기 파일을 점검하고 접근 로그를 grep하세요. 외부 링크가 아직 중간 URL로 들어오나요? 그 URL도 방향을 바꾸세요.
내부 링크를 고치세요. 리다이렉트는 바꿀 수 없는 URL — 남의 백링크 — 를 위한 것입니다. 자기 사이트의 링크는 최종 URL을 가리키게 하세요. 내부 링크가 체인의 가장 큰 단일 원인인 경우가 많습니다.
다시 검사하고 사이트맵을 업데이트하세요. Redirect Chain Checker로 상태 코드가 올바른 한 홉인지 확인하세요. 그다음 사이트맵을 재생성해 최종 URL만 남기고 Search Console의 사이트맵 보고서에 제출하세요. 생성은 무료 XML Sitemap Generator가 처리합니다.

http와 www를 통합하고 있나요? 반쪽짜리 역할을 하는 규칙 두 개가 아니라 홉 하나로 끝내세요 — http://example.com이 https://www.…로 가기 전에 https://example.com을 강제로 거치게 되고, 순서가 틀린 force-TLS/force-www 규칙은 전형적인 루프의 원인입니다:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

한 가지 함정이 더 있습니다. 일부 규칙은 쿼리 문자열을 조용히 버립니다. Apache mod_alias의 Redirect는 GET 파라미터를 그대로 넘기지만, 대상에 자체 ?가 들어 있는 RewriteRule은 [QSA]를 붙이지 않는 한 원래 쿼리 문자열을 버립니다([QSD]는 일부러 버리는 플래그입니다). /?utm_source=newsletter처럼 파라미터가 벗겨진 캠페인 URL은 애널리틱스를 망칩니다 — UTM builder로 링크를 만들고 파라미터가 살아남는지 확인하세요.

피해야 할 흔한 실수

이전 쌓기. http→https, 그다음 www, 그다음 사이트 재구축 — 각각이 앞선 리다이렉트 위에 또 한 겹을 쌓습니다.
영구 이동에 302 사용하기 — CMS 기본값이었기 때문에.
브라우저를 테스트 도구로 믿기. 브라우저는 301을 적극적으로 캐시하고, HSTS는 첫 요청 전에 http를 https로 업그레이드합니다 — 브라우저에는 실제보다 적은 홉이 보일 수 있습니다.
첫 홉만 고치기. 중간 홉은 여전히 오래된 백링크로부터 링크 에쿼티를 받고 있습니다.
“크롤 예산을 아끼려고” robots.txt에서 중간 URL 차단하기 — Googlebot은 리다이렉트를 아예 보지 못합니다.
대응하는 페이지가 아니라 아무거나 있는 곳으로 리다이렉트하기 — 고쳐진 게 아니라 그냥 짧아진 것입니다.

자주 묻는 질문

리다이렉트 체인에 리다이렉트가 몇 개면 너무 많은가요?

Google의 사이트 이전 가이드에 따르면 Googlebot은 최대 10홉까지 따라가지만, 목적지로 곧장 연결하고 체인은 “이상적으로는 3개 이하, 5개 미만”으로 유지하라고 권합니다. 검사기도 같은 기준입니다 — 세 홉을 넘으면 표시하고, 여섯 홉에서 멈춥니다.

301 리다이렉트는 PageRank를 잃게 하나요?

아니요 — Google의 사이트 이전 문서는 “301 및 기타 영구 리다이렉트는 PageRank 손실을 일으키지 않는다”고 명시하고, Google의 Gary Illyes도 2016년 트윗에서 같은 말을 했습니다. 그래도 체인은 지연 시간, 크롤 예산, 물리기 쉬운 규칙, 통합을 늦추는 임시 코드의 비용을 물립니다.

리다이렉트 체인과 리다이렉트 루프의 차이는 무엇인가요?

체인은 결국 실제 페이지에 도달합니다: A → B → C → 200. 루프는 자기 자신으로 되돌아갑니다 — A → B → A — 그리고 영원히 끝나지 않으며, 브라우저는 ERR_TOO_MANY_REDIRECTS를 표시합니다. 해결법도 다릅니다: 루프는 홉 하나를 다시 가리키는 게 아니라 충돌하는 규칙을 찾아 끊어야 합니다.

브라우저와 검사기가 서로 다른 체인을 보여주는 이유는 뭔가요?

두 가지 메커니즘 때문입니다. 첫째, 브라우저는 리다이렉트를 캐시하는데 특히 301이 가장 강하게 캐시됩니다 — Chrome은 규칙이 바뀌고 한참 뒤에도 캐시된 리다이렉트를 계속 따라갑니다. 둘째, HSTS입니다: Strict-Transport-Security 헤더를 본 적이 있으면(또는 preload 리스트를 통해) 브라우저가 첫 요청 전에 http를 https로 업그레이드하면서 해당 홉을 감춥니다. 검사기는 HSTS 목록 없이 매 URL을 새로 요청합니다.

WordPress에서 리다이렉트 체인은 어떻게 고치나요?

대부분은 플러그인 리다이렉트, .htaccess/nginx 규칙, HTTPS/www 재작성이 겹겹이 쌓인 결과입니다. 모든 출처를 조사하세요 — Redirection 플러그인의 리다이렉트 목록과 로그 화면, 서버 설정, SEO 플러그인의 리다이렉트까지 — 그다음 각 항목을 다시 써서 원본 URL이 301 하나로 최종 목적지에 닿게 하세요. 내부 링크를 업데이트하고 검사기로 다시 확인하세요.

Google이 수정된 리다이렉트를 반영하는 데 얼마나 걸리나요?

재크롤링은 URL별로 Googlebot의 속도에 맞춰 진행됩니다 — 중소 사이트는 보통 몇 주, 대형 사이트는 더 오래 걸립니다. Search Console의 URL 검사(URL Inspection) 도구로 색인을 요청하고 업데이트된 사이트맵을 제출하면 빨라집니다. 재처리 과정에서 등락이 있는 것은 정상입니다.

오래된 301 규칙은 얼마나 오래 유지해야 하나요?

Google은 신호가 이전되고 외부 사이트들이 링크를 업데이트할 시간을 주기 위해 리다이렉트를 최소 1년 — 이상적으로는 더 오래 — 유지하라고 권합니다. 제거하기 전에 남은 백링크가 없는지(링크 내보내기 확인), 접근 로그에 실제 트래픽이 없는지 확인하세요.

리다이렉트 체인을 일괄 확인할 수 있나요?

무료 검사기는 한 번의 실행에 URL 하나를 처리합니다. 사이트 전체 점검을 하려면 Google의 이전 가이드가 추천하는 Screaming Frog 같은 데스크톱 크롤러로 크롤링한 뒤, 모든 3xx 응답을 내보내고, 규칙을 다시 쓰기 전에 가장 심한 URL들을 검사기에 넣어 확인하세요.