리디렉션 체인 검사

리디렉션 체인은 브라우저나 크롤러가 콘텐츠가 있는 페이지에 도달하기까지 따라가야 하는 일련의 리디렉션입니다. /old-page에서 /new-page로 가는 것처럼 홉이 하나라면 정상입니다. 체인은 수년에 걸쳐 규칙이 쌓이면서 길어집니다. HTTP에서 HTTPS로 보내는 규칙에 www 규칙, 후행 슬래시 규칙, 마지막 리뉴얼 때 추가한 규칙까지 차례로 더해지는 식입니다. 아래 체인은 한 번이면 충분한 리디렉션을 네 번이나 거칩니다.

http://example.com/shop          301
https://example.com/shop         301
https://www.example.com/shop     301
https://www.example.com/shop/    302
https://www.example.com/store/   200

• 속도: 홉마다 별도의 요청이 발생하며, 대개 DNS 조회와 TLS 핸드셰이크도 따로 거칩니다. 모바일 네트워크에서는 페이지가 로드되기 시작하기 전에 홉 하나당 수백 밀리초가 더해질 수 있습니다.
• 크롤링: Googlebot은 최대 10홉까지 따라간 뒤 리디렉션 오류를 보고합니다. 대규모 사이트에서는 불필요한 홉 하나하나가 실제 페이지에 돌아갈 수 있었던 크롤링 용량을 소모합니다.
• 안정성: 홉이 하나 늘 때마다 실패하거나, 루프에 빠지거나, 만료될 수 있는 서버, 규칙, 인증서도 하나씩 늘어납니다.
• 신호: 체인 어딘가에 임시 리디렉션 코드가 하나만 있어도 검색엔진에 전달하려는 영구 이전 신호가 약해집니다.

각 행이 하나의 홉입니다. 상태는 리디렉션의 종류를 나타냅니다. 301과 308은 영구 리디렉션이고, 302, 303, 307은 임시 리디렉션입니다. 메서드를 보면 브라우저가 301, 302, 303 이후에 하듯 POST가 GET으로 바뀐 지점을 알 수 있습니다. 가공하지 않은 Location 값은 서버가 보낸 내용을 그대로 보여 주므로 상대 경로, 빠진 슬래시, 불필요한 쿼리 문자열을 찾는 데 도움이 됩니다. meta refresh 또는 JavaScript로 표시된 홉은 Location 헤더가 아니라 페이지 HTML(또는 Refresh 헤더)에서 발견된 클라이언트 측 리디렉션입니다.

체인은 네 가지 중 하나로 끝납니다. 최종 URL의 정상 응답, 리디렉션 루프, 최대 홉 수 제한, 또는 DNS 실패, 시간 초과, 인증서 문제처럼 특정 홉에서 발생한 오류입니다.

1. 체인이 최종적으로 도착해야 할 URL을 확인해 두세요.
2. 첫 번째 리디렉션 규칙이 한 번의 301 또는 308로 해당 최종 URL을 바로 가리키도록 수정하세요.
3. 서버나 CDN에서 스킴, 호스트, 슬래시 규칙을 하나로 합쳐 http://example.com/page가 https://www.example.com/page/로 바로 이동하게 하세요.
4. 내부 링크, canonical 태그, 사이트맵을 최종 URL로 업데이트해 방문자와 크롤러가 리디렉션을 아예 거치지 않게 하세요.
5. 여기서 예전 URL을 다시 검사해 체인이 홉 하나로 줄었는지 확인하세요.