리다이렉트 체인: 발생 원인, 비용, 평탄화 방법

리다이렉트 체인은 초록불 뒤에 숨겨진 드문 기술적 결함입니다. URL을 입력하고 페이지를 가져오면 상태 200이 반환됩니다 — 모든 일반 테스트가 통과합니다. 모든 일반 HTTP 클라이언트는 전체 체인을 조용히 따라가며 도착한 위치만 보고합니다. 중간 홉은 존재하며, 각 패처마다 청구됩니다. 브라우저에는 몇 개가 있었는지 알려주는 기능이 없습니다.

유용한 리다이렉트 찾기는 진입점 URL, 중간 목적지 및 최종 페이지를 보여줍니다. 이 기록은 책임 팀이 원본 요청을 직접 의도한 목적지로 보내야 할 규칙을 결정하도록 합니다. 수리 후 관찰은 쉽게 검증할 수 있습니다: 시퀀스를 다시 검사하고 저장된 경로와 비교합니다.

4-홉 체인은 4 개의 별도 올바른 결정으로 구성됩니다

체인은 한 층씩 쌓이며, 각 층은 도착 시 자리를 얻습니다:

1. TLS가 도착합니다. 누군가 http://을 https://으로 보내는 edge 규칙을 추가합니다. 의도한 목적지는 이제 HTTPS를 사용합니다.
2. 표준 호스트가 선택됩니다. 팀은 www을 표준화하여 정점이 그곳으로 리다이렉트합니다. 형제 호스트 이름은 동일한 의도한 목적지로 이어져야 합니다.
3. Trailing slash가 정규화됩니다. 프레임워크 또는 CDN 기본값이 최종 슬래시를 추가하거나 제거하는 규칙을 추가합니다. 게시된 링크와 사이트맵 항목은 일관되게 의도한 스타일을 사용해야 합니다.
4. 국제화가 배포됩니다. 루트 경로가 locale 접두어로 라우팅을 시작합니다, /blog/에서 /en/blog/으로. 현지화된 페이지는 별도의 안정적인 URL이 필요합니다. 루트에서 리다이렉트하는 것은 사이트 디자인 선택입니다.

이것은 4개의 올바른 규칙이며, 이제 http://example.com/blog은 4개의 리다이렉트를 통해 목적지에 도달합니다. 콘텐츠 관리 시스템 마이그레이션이 /blog/*을 /articles/*로 재작성하면 첫 번째 4개를 건드리지 않고 5번째를 추가합니다. 이는 애플리케이션에서 구현되며 나머지는 엣지, 웹 서버, 라우터에 존재합니다. 규칙은 요청이 스택을 통과할 때의 순서대로 실행되며, 이는 URL을 가장 빨리 해결하는 순서와 다릅니다. 누군가가 구성을 소유하지 않습니다.

이는 우리 데이터에서 http‑to‑https 결과가 신중히 읽혀야 하는 이유이기도 합니다. 2026년 5월 23일부터 8월 31일까지, HTTP‑to‑HTTPS 정규화가 171개의 평가 중 44%에서 표시되었지만 48개의 별도 사이트 중 8%에만 해당했습니다. 사이트 수준의 8%는 유병률 수치이며, 평가 수치는 우리의 관찰을 설명하며 웹을 나타내지 않습니다. 검사는 감사가 실행될 때마다 평가되므로 결함이 지속되는 동안 반복적으로 감사된 몇몇 사이트가 각기 많은 실패 평가를 기여하고, 이는 평가율을 영향을 받은 사이트 비율보다 훨씬 높게 끌어올립니다. 44%를 "44% of sites"라고 인용하면 유병률이 5 배 이상 과대평가됩니다.

Google은 최대 10 홉까지 추적하고 5 이하로 유지하도록 권고합니다

홉 예산은 문서화되어 있으며 전설이 아닙니다. Google의 크롤링 문서는 기본적으로 크롤러가 최대 10개의 리다이렉트 홉을 따라가며, 개별 제품이 다를 수 있음을 언급합니다 — Google의 자체 검사 도구는 리다이렉트를 전혀 따르지 않습니다. 사이트 마이그레이션 가이드는 더 구체적입니다: Googlebot은 최대 10 홉을 따라갈 수 있지만, "최종 목적지로 직접 리다이렉트하도록 권장합니다. 가능하지 않다면 체인 내 리다이렉트 수를 낮게 유지하고, 이상적으로 3 이하이며 5 이하로 유지하십시오." 크롤링 예산 문서는 한 줄로 요약합니다: 긴 리다이렉트 체인을 피하십시오, 이는 크롤링에 부정적인 영향을 미칩니다.

비용은 3 부분으로 나뉘며, 이들은 불균형한 가중치를 가집니다:

크롤 효율성. 각 홉은 Google의 크롤러가 콘텐츠를 받지 않고 소비하는 요청이며 — 문서는 리다이렉트되는 URL에 의해 반환된 콘텐츠는 무시되고 최종 대상의 콘텐츠만 처리된다고 명시합니다. 몇 백 개의 URL이 있는 사이트에서는 이것이 잡음입니다. 체인이 URL 패턴에 있을 때, 내부 링크마다 사용되므로 전체 크롤에 걸쳐 곱해져 같은 호스트가 이미 적용받는 크롤 용량 한계와 경쟁합니다.

캐시되지 않은 모든 가져오기에서의 지연. 홉은 완전한 왕복입니다: DNS는 이미 따뜻할 수 있지만, 연결 재사용은 홉이 호스트를 바꾸는 순간 끝나며, 이는 example.com에서 www.example.com 단계가 정의대로 수행합니다. 사용자는 한 번 느끼고 나면 멈추며, 브라우저는 영구 리디렉션을 캐시합니다. 차가운 상태에서 가져오는 기계는 따뜻한 캐시 없이 매번 느낍니다.

신호 통합, 바로 전설이 존재하는 곳. 옛 주장에 따르면 각 홉은 링크 평등의 일부를 흘려보낸다고 합니다. Google은 2016년 7월 공개적으로 이를 반박했으며, Gary Illyes는 30x 리디렉션이 PageRank를 잃지 않는다고 단호히 밝혔고, 이는 John Mueller가 그 해 초에 http‑to‑https 이동에 대해 이미 말한 내용을 명확히 했습니다. 우려의 지속 가능한 버전은 더 좁고 여전히 현실적입니다: 301는 가장 강력한 가용 정규화 신호이며, 리디렉션의 가치는 하나의 목적지를 모호 없이 지정한다는 것입니다. 체인은 여전히 하나의 목적지를 지정하므로 평등 논증은 3 이유 중 가장 약합니다. 크롤 효율성과 지연이 사건을 지지합니다.

AI 가져오기 프로그램과 에이전트는 브라우저보다 체인을 덜 관대하게 처리합니다

브라우저는 사이트가 테스트될 때 가장 관대한 리디렉션 클라이언트입니다. 그들은 긴 체인을 주석 없이 따라가고, 영구 리디렉션을 적극적으로 캐시하며, 목적지를 마치 URL이 요청한 것처럼 제시합니다. 프로그래밍 클라이언트 — AI 어시스턴트, 검색 파이프라인, 에이전트가 실제로 가져오는 계층 — 은 브라우저 테스트가 드러낼 수 없는 방식으로 다릅니다.

curl는 -L 없이는 전혀 따르지 않으며, 체인은 빈 301과 빈 본문을 반환합니다. 라이브러리 HTTP 클라이언트는 각각 자신만의 홉 한계와 전혀 따를지 여부의 기본값을 선택하며, 그 기본값은 가져오기 코드를 작성한 사람이 설정하고, 사이트가 설정하지 않습니다. 사양 준수 클라이언트는 리디렉션이 출처를 교차할 때 자격 증명을 버립니다. 이는 apex‑to‑www 홉이 수행하는 정확한 동작입니다. 메서드 의미도 바뀝니다: 301와 302는 POST를 GET으로 재작성하는 오랜 역사를 가지고 있으며, 307와 308는 원래 메서드를 보존합니다 — 이는 에이전트가 읽는 대신 제출할 때 순간적으로 중요한 구분입니다.

예산 제약을 추가합니다. 시간 제한 아래에서 페이지를 처리하는 요약기 또는 에이전트는 콘텐츠를 반환하지 않는 홉에 일부 시간을 할애하며, 내부 홉 한계를 초과하는 가져오기는 사이트가 다운된 것처럼 보입니다. 체인은 자신을 체인으로 보고하지 않으며, 빈 결과로 보고합니다. 이는 우리의 색인 가능성 데이터에서 지시문 충돌과 동일한 실패 형태입니다 — 사이트는 사람들에게는 작동하지만 기계에는 조용히 작동을 거부합니다.

4 단계에서 평평하게 만듭니다: 재고, 압축, 재링크, 지도 유지

1. 실제 홉 수를 재고합니다. 측정하고, 구성을 추론하지 마십시오. 단일 URL에 대해:

curl -sIL -o /dev/null -w '%{num_redirects} hops -> %{url_effective}\n' http://example.com/blog
curl -sILD - -o /dev/null http://example.com/blog | grep -iE '^(HTTP/|location)'

첫 번째 줄은 수를 제공하고, 두 번째 줄은 경로를 제공합니다. http:// 및 https:// 양식, apex 및 www에 대해, 뒤에 슬래시가 있든 없든, 각 템플릿에서 대표적인 URL에 대해 실행합니다 — 체인은 일반적으로 페이지가 아니라 패턴에 존재합니다. 감사는 홈페이지, 정규 대상, 대체 호스트에서 같은 순회를 수행하고 추적된 경로를 증거로 보고합니다.

2. 각 체인을 단일 301로 압축합니다. 엔트리 URL과 인벤토리에서 최종 목적지를 가져와 첫 번째를 마지막으로 직접 매핑하는 규칙을 작성합니다. 두 개를 모두 볼 수 있는 가장 바깥쪽 계층(보통 엣지 또는 CDN)에서 작성합니다. 그런 다음 체인으로 구성된 중간 규칙을 새 규칙 뒤에 두지 말고 폐지합니다. 영구 이동에는 301를, 방법이 살아남아야 할 때는 308를 사용합니다. 대상은 자신을 정규로 선언하는 200이어야 합니다; 정규가 다른 곳을 가리키는 페이지에 리디렉션이 도착하면 모호성이 다른 어휘에서 재시작됩니다. 이는 우리의 정규 태그 안내가 작동하는 상호작용입니다.

3. 내부 링크를 최종 URL로 지정합니다. 평면화된 규칙은 여전히 ​​이름이 바뀐 URL을 가리키는 모든 내부 링크에 대해 홉을 발생시킵니다. 사이트맵, 탐색, hreflang 주석, 정규 태그 및 본문 링크는 모두 목적지를 직접 참조해야 하므로 리디렉션은 외부 인바운드 링크와 오래된 북마크에만 존재합니다. 이 단계가 구성 수정을 크롤링 효율성 향상으로 전환합니다.

4. 체인 맵을 유지합니다. 폐지된 모든 규칙, 그 엔트리 URL, 최종 목적지를 하나의 파일에 기록하고 인프라 구성과 함께 보관합니다. 체인은 재구성됩니다. 다음 사람이 로케일 접두사를 추가하거나 경로 스킴을 마이그레이션할 때 이미 요청 경로에 있는 4개의 규칙을 볼 수 없기 때문입니다. 맵은 5 계층을 배포하는 사람에게 구성을 가시화시키는 것이며, 다음 인벤토리의 입력이 됩니다. 전체 체크별 처리 방법은 우리의 리디렉션 및 URL 정규화 가이드에 있습니다.

평면화된 리디렉션 계층은 콘텐츠 종속성, 순위 지연이 없고 단일 명령으로 확인할 수 있는 몇 안 되는 기술적 개선 중 하나입니다. 많은 사이트에서 여전히 고장난 이유는 사람이 직접 실행하는 테스트가 홉을 보고하지 않기 때문입니다. 추적이 감사의 일부가 되면 4 팀의 올바른 결정 사이의 솔기가 경로, 홉별 상태 및 하나의 규칙을 작성하는 결과물로 전환됩니다.