301 리다이렉트 검사기: 모든 리다이렉트 체인 추적

리다이렉트 검사기는 링크를 클릭한 순간부터 페이지에 도착하기까지 실제로 어떤 일이 일어나는지 보여 줍니다. 입력한 모든 URL은 자동 리다이렉트를 끈 상태로 Marqly 서버에서 요청되므로 각 응답이 따로 기록됩니다. 상태 코드, 응답이 가리키는 Location 헤더, 걸린 시간, SEO에 중요한 헤더가 그 대상입니다. 이어서 도구는 그 위치를 따라가 같은 과정을 최대 10번의 리다이렉트까지 반복하는데, 이는 Google 크롤러의 기본 한도와 같습니다. 그 결과로 전체 리다이렉트 체인, 최종 URL과 상태, 그리고 루프, 임시 리다이렉트, 느린 단계, 사라진 추적 매개변수, 줄일 만한 체인에 대한 쉬운 말의 경고를 받게 됩니다.

리다이렉트를 확인하는 방법

1. 입력란에 URL을 붙여넣으세요. 일괄 검사는 한 줄에 하나씩 최대 10개의 URL을 붙여넣으면 됩니다.
2. 필요하면 사용자 에이전트를 고르세요. 기본값은 Marqly 검사기로 자신을 밝히며, Chrome, iPhone Safari, Googlebot 스마트폰, Googlebot 데스크톱의 사용자 에이전트를 보내 브라우저, 휴대폰, 크롤러를 다르게 취급하는 규칙을 찾아낼 수도 있습니다.
3. http/https 및 www/non-www 버전도 함께 확인을 선택하면 같은 주소의 네 가지 형태를 한꺼번에 테스트합니다. 사이트에 표준 호스트 이름이 하나뿐이고 모든 변형이 한 번의 이동으로 거기에 도달하는지 가장 빠르게 확인하는 방법입니다.
4. 리다이렉트 검사를 누르세요. URL마다 결론, 힌트, 단계별 체인이 담긴 카드가 따로 생깁니다.
5. 텍스트 보고서는 결과 복사로, 단계마다 한 행씩 담긴 스프레드시트는 CSV 다운로드로 얻을 수 있고, 같은 검사를 다시 실행하는 링크를 보내려면 공유 링크 복사를 쓰세요.

결과를 읽는 방법

각 카드는 최종 상태 코드, 입력한 URL, 리다이렉트 횟수, 총 소요 시간, 최종 URL로 시작합니다. 그 아래의 힌트는 주의가 필요한 부분을 알려 줍니다. 오류(루프, 한도를 넘는 체인, 404로 끝나는 체인), 경고(임시 리다이렉트, meta refresh, https에서 http로의 다운그레이드, 사라진 쿼리 매개변수, 최종 페이지의 X-Robots-Tag: noindex), 참고 사항(끝 슬래시나 www의 변경, 다른 도메인으로의 이동, 느린 단계)이 그것입니다.

체인 표는 모든 요청을 순서대로 나열합니다. 상태는 서버가 돌려준 HTTP 상태 코드입니다. URL은 요청된 주소이고, 그 아래에는 그 단계가 클라이언트를 다음에 보내는 곳이 있으며, 서버가 상대 경로 Location을 보냈다면 이미 절대 주소로 풀어서 보여 줍니다. 시간은 그 단계에서 서버가 헤더를 돌려주기까지 걸린 시간입니다. 아무 행에서나 Headers를 열면 Location, Cache-Control, Content-Type, X-Robots-Tag, Link(canonical을 선언할 수 있는 곳), Strict-Transport-Security, X-Redirect-By(WordPress와 일부 플러그인이 여기에 자신의 이름을 남깁니다), Server를 볼 수 있습니다. 쿠키 값은 절대 표시하지 않고 설정된 개수만 보여 줍니다.

301, 302, 307, 308: 리다이렉트 코드별 의미

HTTP는 리다이렉트 상태 코드를 RFC 9110 15.4절에서 정의합니다. 이 코드들을 가르는 질문은 두 가지입니다. 이동이 영구적인가, 그리고 클라이언트가 리다이렉트를 따라갈 때 요청 메서드를 바꿀 수 있는가(예를 들어 폼의 POST를 GET으로 바꾸는 것)입니다. Google의 HTTP 상태 코드 문서는 크롤러와 색인 시스템이 각 코드를 어떻게 다루는지 설명합니다.

일반 페이지에서는 콘텐츠가 영구적으로 옮겨졌을 때 301을 쓰세요. 슬러그 이름 변경, 글 병합, 도메인 이전, HTTPS 전환이 그 예입니다. 원래 URL이 돌아올 때는 302나 307을 쓰세요. 점검 페이지, 짧은 캠페인, 테스트가 그렇습니다. 메서드가 중요할 때, 예를 들어 API 엔드포인트나 POST 요청을 받는 폼에는 308을 선택하세요. RFC 9110은 301과 302에서는 클라이언트가 리다이렉트된 POST를 GET으로 바꾸는 것을 허용하지만 307과 308에서는 금지하기 때문입니다.

meta refresh와 JavaScript 리다이렉트

Google의 리다이렉트 가이드는 가능한 한 영구적인 서버 측 리다이렉트를 권장합니다. 즉시 실행되는 meta refresh는 영구 리다이렉트로, 지연이 있는 것은 임시 리다이렉트로 취급하며, JavaScript 리다이렉트는 서버 측 리다이렉트도 meta refresh도 쓸 수 없을 때만 권하는데, 렌더링이 실패할 수 있기 때문입니다. 이 검사기는 meta refresh 태그와 Refresh 헤더를 따라가며 표시해 주지만 JavaScript는 실행하지 않습니다.

리다이렉트 체인이란 무엇이고 왜 문제일까요?

리다이렉트 체인은 이동이 한 번을 넘는 모든 경로입니다. http://example.com/page →https://example.com/page → https://www.example.com/page →https://www.example.com/page/ 같은 식입니다. 체인은 의도적으로 시작되는 일이 드뭅니다. 사이트가 HTTPS로 옮겨 가고, www 선호를 정하고, CMS를 바꾸고, 섹션 이름을 바꾸면서 오래된 리다이렉트를 고쳐 쓰는 대신 그 위에 또 리다이렉트를 얹는 과정에서 쌓입니다. 각 계층은 혼자서는 문제없이 작동하지만, 합쳐지면 부담이 커집니다.

• 속도. 단계가 하나 늘 때마다 페이지가 로딩되기 전에 완전한 요청이 한 번 더 필요하고, 새 호스트 이름으로 가는 단계는 DNS 조회와 TLS 핸드셰이크까지 더합니다. 시간 열에서 각 단계의 비용을 볼 수 있습니다.
• 크롤링. Google은 크롤러가 기본적으로 최대 10번의 리다이렉트를 따라간다고 밝히며, 페이지 색인 생성 보고서는 너무 긴 리다이렉트 체인, 리다이렉트 루프, 체인 안의 잘못되었거나 비어 있는 URL을 리다이렉트 오류로 나열합니다. Google의 사이트 이전 가이드는 최종 목적지로 곧바로 리다이렉트하라고 조언하며, 체인은 지연을 늘리고 모든 사용자 에이전트와 브라우저가 긴 체인을 지원하는 것은 아니라고 설명합니다.
• 다른 클라이언트. RFC 9110은 초기 HTTP 규격이 최대 다섯 번의 리다이렉트를 권장했고 일부 클라이언트는 지금도 그런 고정 한도를 적용할 수 있다고 언급하므로, Googlebot이 견디는 체인도 다른 소프트웨어에서는 끊어질 수 있습니다.
• 취약성과 데이터 손실. 단계 하나하나가 편집되거나 삭제되거나 다른 규칙에 가려질 수 있는 또 하나의 규칙입니다. URL을 다시 만드는 단계는 쿼리 문자열을 조용히 떨어뜨릴 수 있고, UTM 태그가 분석 도구에 닿기도 전에 사라지는 것이 바로 그런 경우입니다. 검사기는 원래 URL의 매개변수가 최종 URL에 없으면 경고합니다.

리다이렉트 체인을 고치는 방법

1. 최종 URL을 찾으세요. 이전 URL을 검사기에 넣고 체인의 마지막 URL을 복사합니다.
2. 첫 번째 리다이렉트가 최종 URL을 가리키게 하세요. A가 B로, B가 C로 리다이렉트한다면 A의 규칙을 곧바로 C로 가도록 바꾸고, 아직 B를 가진 사람을 위해 B → C는 유지합니다. 리다이렉트 맵이나 플러그인에서 대상이 다른 규칙의 출발점이기도 한 규칙을 검색해 보세요.
3. 프로토콜과 호스트 이름 규칙을 합치세요. 가장 흔한 체인은 http → https 다음에 non-www → www가 이어지는 것입니다. 아래 nginx 예시처럼 모든 변형을 한 번에 표준 형태로 보내는 규칙 하나를 작성하세요.

# One hop from every variant to https://www.example.com
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate lines omitted
    return 301 https://www.example.com$request_uri;
}

4. 원천에서 링크를 갱신하세요. 내부 링크, canonical 태그, hreflang 주석, XML 사이트맵을 최종 URL로 바꾸세요. Google의 사이트 이전 가이드도 내부 링크를 새 URL로 갱신하라고 요구합니다. 리다이렉트는 다른 곳에서 들어오는 옛 링크를 받아 내는 용도여야 하며 자신의 탐색 메뉴를 떠받치는 용도가 아닙니다.
5. 리다이렉트는 유지하세요. Google은 리다이렉트를 가능한 한 오래, 보통 최소 1년은 유지하라고 권합니다. 체인을 합친다는 것은 대상을 다시 지정하는 것이지 옛 규칙을 삭제하는 것이 아닙니다.
6. 다시 테스트하세요. 같은 URL을 다시 실행하되, 가급적 변형 옵션을 선택하고 모두 한 번의 이동으로 200 페이지에 도달하는지 확인하세요.

리다이렉트 루프 고치기

루프는 이미 방문한 URL로 되돌아오는 체인이라 끝나지 않으며, 브라우저에는 리다이렉트가 너무 많다는 오류가 표시됩니다. 보통은 두 계층이 서로 어긋나서 생깁니다. CDN은 HTTP로 오리진과 통신하는데 오리진은 HTTPS를 강제하는 경우, 웹 서버의 끝 슬래시 규칙이 애플리케이션의 반대 규칙과 맞서는 경우, www 규칙이 DNS 수준의 포워딩과 사이트 양쪽에 모두 설정된 경우가 그렇습니다. URL이 다시 되돌아가는 단계를 보세요. 그 단계의 Server와 X-Redirect-By 헤더가 어느 계층이 보냈는지 알려 주는 경우가 많습니다. 일부 루프는 쿠키가 없을 때만 생기며(동의나 로그인 리다이렉트) 이미 쿠키가 있는 방문자에게는 영향이 없습니다. 검사기는 쿠키를 보내지 않으므로 이런 루프도 드러냅니다.

리다이렉트 일괄 검사

한 줄에 하나씩 최대 10개의 URL을 붙여넣으면 한 번에 검사하며, 중복은 제거되고 URL마다 자체 결과가 나옵니다. CSV 내보내기는 입력 URL을 반복해 단계마다 한 행씩 담으므로 상태별로 거르거나 단계 수로 정렬하거나 리다이렉트 규칙을 관리하는 사람에게 파일을 넘길 수 있습니다. 오래된 북마크나 문서에 있는 링크 목록이라면 먼저 북마크 파일 뷰어로 URL을 추려 내고, 한 번에 25개의 URL을 받는 깨진 링크 검사기로 단순히 죽은 링크가 어느 것인지 확인하세요. 사이트 전체라면 크롤러나 서버 로그로 리다이렉트되는 URL을 찾은 다음, 중요한 것들을 Googlebot 사용자 에이전트로 여기서 표본 점검하세요.

HTTPS, www, 끝 슬래시

대부분의 사이트는 프로토콜과 호스트 이름의 조합 단 하나에서만 응답해야 하고, 나머지 모든 형태는 영구적으로 한 번의 이동으로 그곳에 리다이렉트되어야 합니다. 변형 옵션은 같은 경로로 http://example.com, https://example.com, http://www.example.com, https://www.example.com을 확인하고 네 가지가 모두 같은 URL에서 끝나는지, 각각 몇 단계가 걸리는지 보고합니다. 힌트는 체인 후반에 일어나는 HTTPS 업그레이드, www와 non-www 사이를 두 번 이상 오가는 체인, 끝 슬래시만 더하거나 빼거나 대소문자만 바꾸는 단계를 짚어 주며, 이런 것들은 첫 번째 리다이렉트에 합치기 쉽습니다.

결과가 브라우저와 다를 수 있는 이유

브라우저가 다른 곳에 도착한다면 보통은 무언가를 기억하고 있기 때문입니다. RFC 9110은 301을 캐시할 수 있게 허용하므로 브라우저가 옛 리다이렉트를 건너뛰거나 이미 제거한 리다이렉트를 계속 따라갈 수 있습니다. 브라우저가 한 사이트의 HSTS 헤더를 한 번 보면(또는 그 사이트가 HSTS 프리로드 목록에 있으면), 어떤 요청도 컴퓨터를 떠나기 전에 내부적으로 http://를 https://로 올립니다. 쿠키, 언어, 위치도 각자의 리다이렉트를 일으킬 수 있습니다. 검사기는 매번 깨끗한 상태에서 시작해 서버가 보내는 내용을 보고하며, 이것이 크롤러와 처음 방문하는 사람에게 의미 있는 시각입니다.

검사기의 작동 방식

각 단계는 Cloudflare 위의 Marqly 서버에서 리다이렉트를 수동으로 설정해 보내는 GET 요청이므로, 검사기가 기록하기 전에는 아무것도 따라가지 않습니다. 모든 호스트 이름은 해석되어 공개 주소를 가리켜야 하며, 사설 네트워크, localhost, 클라우드 메타데이터 주소는 체인 중간의 리다이렉트가 그곳을 가리키는 경우를 포함해 거부됩니다. 단계마다 6초 타임아웃이 있고, 전체 체인은 20초 또는 10번의 리다이렉트 뒤에 멈추며, 페이지 본문은 최종 HTML 페이지의 처음 64 KB만 남기고 버려지는데 이 부분은 meta refresh를 찾기 위해 검사됩니다. 아무것도 저장되지 않으며 결과는 브라우저 탭에만 존재합니다.

리다이렉트나 링크 단축 서비스를 거친 링크를 공유하기 전에 URL 정리기로 추적 매개변수를 제거하세요. 캠페인 링크를 만든다면 UTM 빌더로 만들고 이 검사기로 매개변수가 모든 단계에서 살아남는지 확인할 수 있습니다. 최종 페이지가 로드되면 Open Graph 검사기로 그 페이지가 제공하는 제목, 설명, 소셜 미리보기를 살펴보세요.