↪️ 리다이렉트 체인 추적
URL을 1홉씩 추적. 상태 코드, 지연 시간, HTTPS 업그레이드/다운그레이드, 루프, 과도한 체인 감지.
완전 무료
가입 불필요
서버 처리
로그 · DB 없음
레이트 리밋
5 개 언어
다크 모드
📚 리다이렉트 모범 사례
• SEO 이상적: ≤3 홉. Google은 5홉 후 추적 중지 가능.
• 영구는 301, 임시는 302 / 307.
• HTTPS → HTTP 다운그레이드 금지.
• 리다이렉트 루프는 즉시 수정해야 할 중대 버그.
📖 이 진단으로 알 수 있는 것
이 진단은 입력된 URL 에서 Location 헤더를 차례로 따라가 각 홉의 상태 코드와 이동처, 최종 도달지를 표시합니다. 실제 사용자가 겪는 홉 수와 일치하지 않을 수 있습니다. HSTS 가 적용된 브라우저에서는 HTTP 에서 HTTPS 로 가는 첫 홉이 네트워크에 나가기 전에 내부 처리로 치환되고, 쿠키나 지역으로 응답을 나누는 사이트에서는 경로 자체가 달라집니다.
| 판정 항목 | 무엇을 보는가 | 걸렸을 때의 대처 |
|---|---|---|
| 301 / 302 와 307 / 308 의 구분 | 301 과 302 는 역사적 경위로 리다이렉트 시 브라우저가 POST 를 GET 으로 바꾸는 것이 허용됩니다. 307 과 308 은 메서드와 요청 본문을 그대로 유지합니다. 폼 전송처나 API 엔드포인트를 301 로 옮기면 body 가 사라진 요청이 도착하는 원인 파악이 어려운 장애가 됩니다. | 항구 이전으로 GET 만 오는 페이지라면 301, POST 를 받는 엔드포인트라면 308 을 돌려줍니다. 일시적인 전환(점검 화면, A/B 테스트)은 302 가 아니라 307 을 고르면 메서드가 바뀌지 않아 사고가 줄어듭니다. |
| 홉이 2단이 되어 있음 | http://example.com → https://example.com → https://www.example.com 처럼 HTTPS 화와 www 정규화를 별개 규칙으로 쓰면 반드시 2홉이 됩니다. 끝 슬래시를 고치는 규칙이 더해지면 3홉입니다. 홉마다 왕복이 발생하므로 모바일 회선에서는 체감될 만큼 느려집니다. |
첫 규칙에서 최종형(스킴 · 호스트 · 끝 슬래시까지 포함한 형태)으로 한 번에 보냅니다. nginx 라면 listen 80 서버 블록에 return 301 https://www.example.com$request_uri; 한 줄이면 됩니다. 개별 리다이렉트를 쌓는 방식은 늘어날수록 순서 의존을 읽기 어려워집니다. |
| 최종 도달지가 canonical 과 다름 | 리다이렉트의 종점과 그 페이지가 선언한 canonical 이 어긋나면 구글은 어느 쪽을 정규로 볼지 스스로 정합니다. 서치 콘솔에 페이지에 리다이렉트가 있습니다, 사용자가 표시한 페이지와 다른 페이지가 정규 페이지로 선택되었습니다가 나란히 뜨는 것이 이 상태입니다. |
종점 페이지의 canonical 이 자기 자신의 URL 을 가리키는지 확인합니다. 끝 슬래시 · 대소문자 · 트래킹 파라미터 유무까지 완전 일치시키세요. 사이트 이전에서는 구 URL → 신 URL 의 1 대 1 이 원칙이며, 한꺼번에 첫 페이지로 보내면 구글은 그것을 404 상당(소프트 404)으로 다룹니다. |
리다이렉트는 지워도 되는 것이 아닙니다. 구 URL 로의 외부 링크와 아직 갱신되지 않은 북마크는 몇 년이나 남습니다. 구글 자신도 사이트 이전 시 리다이렉트를 최소 1년은 유지할 것을 권장합니다. 본 사이트도 구 도메인에서의 301 을 1년 이상 유지하는 방침으로 운영하고 있습니다. 도달지가 404 가 된 리다이렉트가 남아 있지 않은지, 이전 후 몇 달 뒤에 다시 이 진단을 통과시켜 보세요.