리다이렉트 확인
모든 URL과 단축 링크의 리다이렉트를 확인하세요. 각 홉의 상태 코드(301, 302, 307, 308, meta refresh)와 그 의미, 이동 대상, 소요 시간을 브라우저처럼 최대 20홉까지 따라가며 보여 줍니다. Googlebot이 추적을 멈추는 지점과 http/https, www 유무의 네 가지 버전도 함께 확인합니다.
도메인만 입력하면 https://로 시작합니다. HTTP에서 HTTPS로 가는 홉도 테스트하려면 http://를 붙여 입력하세요.
리다이렉트 확인 도구는 무엇을 보여 주나요?
리다이렉트 확인 도구는 브라우저처럼 URL에 요청한 뒤, 돌아오는 모든 Location 헤더를 한 홉씩 따라가 페이지가 응답할 때까지 추적합니다. 각 홉마다 상태 코드, 이동 대상, 소요 시간, 응답한 네트워크를 확인할 수 있습니다.
이 도구는 모든 홉의 시간을 측정합니다. 새 연결이면 DNS, 연결, TLS, 첫 바이트로 나누고, 브라우저처럼 같은 호스트로 열려 있는 연결을 재사용하는 홉은 첫 바이트만 표시합니다. 브라우저처럼 호스트별로 쿠키를 유지하고, 최종 페이지의 meta refresh, canonical 태그, noindex를 읽으며, Googlebot이 포기할 지점도 표시합니다.
- 13301영구POST가 GET으로 바뀔 수 있음4368mshttp://google.com/
- 2302임시POST가 GET으로 바뀔 수 있음537mshttp://www.google.com/
- 3200최종OK393mshttps://www.google.com/?gws_rd=ssl“Google”
- 1총 소요 시간 페이지가 시작되기 전까지 모든 홉을 합친 시간입니다.
- 2홉 예산 리다이렉트당 한 칸. Googlebot의 한도는 10, 브라우저는 20입니다.
- 3각 홉의 사이트 아이콘이 바뀌면 링크가 다른 사이트로 넘어갔다는 뜻입니다.
- 4상태 종류별 색과 그 의미를 말로 보여 줍니다.
- 5시간이 쓰인 곳 DNS, 연결, TLS, 첫 바이트를 하나의 시간축으로 보여 줍니다.
301 리다이렉트는 어떻게 확인하나요?
위 입력란에 URL을 붙여넣고 리다이렉트 확인을 선택하면, 도구가 URL에 요청해 최종 페이지까지 모든 리다이렉트를 따라가고 각 홉의 상태를 알려 줍니다. 301과 308은 영구로 초록색, 302, 303, 307은 임시로 주황색으로 표시됩니다. 도메인만 입력하면 https://로 시작하며, HTTP에서 HTTPS로의 홉까지 검사하려면 http://를 직접 입력하세요.
판정은 체인을 말로 요약하고, 남색 열은 각 홉을 하나의 시간축으로 그리며, 체인 보기는 각 홉의 요청, 상태 줄, 전송된 그대로의 Location과 해석된 주소(상대 경로도 허용), 모든 헤더를 나열합니다.
URL 리다이렉트 확인: 링크 하나, 모든 홉
모든 URL과 단축 링크를 최대 20홉까지 따라가며 각 홉의 네트워크, TLS 버전, HTTP 버전을 보여 주고, http/https와 www 유무의 네 가지 진입 경로도 함께 확인합니다.
리다이렉트 일괄 확인: 최대 50개 URL
일괄로 전환해 이전 목록을 한 줄에 URL 하나씩 붙여넣으세요. 홉 수, 최종 상태, 최종 URL, 판정이 표로 나오며 CSV로 내려받을 수 있습니다.
Googlebot, iPhone, Bingbot으로 리다이렉트 테스트
입력란 아래에서 사용자 에이전트를 고르세요. 크롤러나 휴대폰을 다른 곳으로 보내는 사이트가 있으며, 체인에는 해당 에이전트가 받은 결과가 그대로 표시됩니다.
모든 홉의 HTTP 상태 확인
각 상태 코드를 브라우저와 Google에 어떤 의미인지와 함께 말로 설명합니다. 봇 차단벽은 깨진 페이지가 아니라 차단으로 표시하고, Cloudflare 자체의 52x 오류는 Cloudflare의 것으로 표시합니다.

판정URL이 어디에서 끝나는지, 몇 홉인지, 각 홉이 영구인지 임시인지를 말로 보여 줍니다.홉 예산리다이렉트 하나당 한 칸을 종류별 색으로 표시하고, Googlebot의 10홉과 브라우저의 20홉을 기준으로 삼습니다.각 홉의 상태서버가 보낸 코드와 그 의미: 영구인지 임시인지, POST가 어떻게 되는지를 보여 줍니다.시간이 쓰인 곳각 홉의 DNS, 연결, TLS, 첫 바이트를 첫 요청부터 페이지까지 하나의 시간축으로 보여 줍니다.301과 302 중 어떤 리다이렉트를 써야 하나요?
페이지가 영구적으로 옮겨졌다면 301(또는 308)을, 다시 돌아올 때만 302(또는 307)를 사용하세요. 이 코드는 브라우저와 검색엔진이 어느 URL을 유지할지 알려 줍니다(RFC 9110 §15.4).
Google에게 301과 308은 이동 대상이 표준 URL, 즉 검색결과에 표시할 URL이어야 한다는 신호이지만 302, 303, 307은 그렇지 않으므로 검색결과에 이전 URL이 남습니다(Google 검색 센터). 302가 무시되는 것은 아닙니다. Google은 302를 따라가며 이를 이동 대상을 처리해야 한다는 약한 신호로 사용합니다(Google 크롤러 문서). 다른 표준화 신호가 이동 대상을 가리키면 이동 대상의 색인이 생성될 수도 있습니다. Bing은 이틀 미만의 변경에만 302를 사용하라고 안내합니다.
브라우저는 301과 308을 기본적으로 캐시하므로, 취소한 영구 리다이렉트가 방문자 브라우저에 남아 있을 수 있습니다. 307과 308은 요청 메서드를 유지하지만, 301과 302는 POST를 GET으로 바꿀 수 있고 303은 항상 바꿉니다.
| 코드 | 영구 | POST일 때 | 브라우저 캐시 | Google의 신호 | 용도 |
|---|---|---|---|---|---|
| 301Moved Permanently | 영구 | GET으로 바뀔 수 있음 | 예 | 강함 | 영구적으로 옮겨진 페이지 |
| 308Permanent Redirect | 영구 | 유지 | 예 | 강함 | 영구적으로 옮겨진 폼 또는 API |
| 302Found | 임시 | GET으로 바뀔 수 있음 | 아니요 | 약함 | 단기간의 이동(Bing: 2일 미만) |
| 303See Other | 임시 | 항상 GET | 아니요 | 약함 | 폼 전송 후 보여 줄 페이지 |
| 307Temporary Redirect | 임시 | 유지 | 아니요 | 약함 | POST를 유지해야 하는 임시 이동 |
| meta 0즉시 meta refresh | 영구 | GET | — | 강함 | 서버에서 리다이렉트할 수 없을 때 |
| meta 5지연 meta refresh | 임시 | GET | — | 약함 | 피할 것: 방문자에게 이전 페이지가 먼저 보임 |
Refresh 헤더도 포함됩니다.리다이렉트 체인은 몇 홉부터 너무 많은 건가요?
3홉을 넘으면 많은 것입니다. 체인은 http://에서 https://로, 다시 www로, 이어서 새 경로로 가는 것처럼 리다이렉트가 연속된 상태를 말합니다. Google은 최종 URL로 바로 링크하거나, 체인을 3홉 이하로 유지하고 어떤 경우에도 5홉 미만으로 하라고 권고합니다(Google 검색 센터).
Googlebot은 최대 10홉까지 따라간 뒤 포기하고, Search Console에 "리디렉션 오류"가 보고됩니다(Google 크롤러 문서). Chrome과 Firefox는 최대 20홉까지 따라가고 그 이상이면 ERR_TOO_MANY_REDIRECTS를 표시합니다. 홉이 하나 늘 때마다 페이지가 시작되기 전에 왕복이 한 번 더 생기므로, 내부 링크는 최종 URL을 가리키도록 수정하세요.
- Google의 권고: 3 이하
- 따라가긴 하지만 느려짐
- Googlebot은 여기까지 도달하지 못함: Search Console에 "리디렉션 오류"로 표시
- 20 초과:
ERR_TOO_MANY_REDIRECTS
리다이렉트 루프는 어떻게 고치나요?
서로 충돌하는 두 규칙을 찾아 하나의 최종 URL로 통일하세요. 루프는 이미 요청한 URL로 되돌아오는 체인이며, 브라우저는 리다이렉트가 20회가 될 때까지 계속 돌다가 ERR_TOO_MANY_REDIRECTS를 표시합니다.
대부분의 루프는 www를 붙이는 규칙과 떼는 규칙이 충돌하거나, CDN 뒤에서 HTTP와 HTTPS 규칙이 부딪혀 생깁니다. CDN이 http://로 서버에 접속하면 서버가 https://로 리다이렉트하고, CDN이 다시 http://로 요청하는 식입니다. 브라우저는 영구 리다이렉트를 저장해 두므로, 수정 후에는 시크릿 창에서 테스트하세요.
리다이렉트 루프 확인 도구가 루프를 찾는 방법
그 사이 새 쿠키 없이 같은 URL을 두 번째로 요청하면 루프입니다. 경로는 반복되는 홉으로 되돌아가도록 그려지고 거기서 멈추며, 20회까지 돌지 않습니다. 쿠키를 설정하고 자기 자신으로 리다이렉트하는 사이트는 브라우저처럼 그 쿠키를 되돌려 받으므로, 로그인 단계를 루프로 오인하지 않습니다.
ERR_TOO_MANY_REDIRECTS · 20회 후
meta refresh 리다이렉트와 JavaScript 리다이렉트를 Google이 따라가나요?
조건부로 따라갑니다. Google은 즉시 meta refresh(content="0; URL=…")를 영구 리다이렉트로, 지연된 것을 임시로 처리하며, HTTP Refresh 헤더도 똑같이 취급합니다(Google 검색 센터). JavaScript 리다이렉트는 Google이 페이지를 렌더링할 때만 작동하므로 최후의 수단으로만 사용하세요.
0초 meta refresh도 페이지가 완전히 로드된 뒤에야 실행되므로(HTML Standard) 방문자에게 이전 페이지가 먼저 보일 수 있습니다. 이 도구는 meta refresh와 Refresh 헤더를 지연 시간과 함께 별도의 홉으로 따라갑니다. 페이지 안의 단순한 JavaScript 리다이렉트는 찾아서 이 URL 확인을 제공하지만 스크립트는 실행하지 않습니다. "찾지 못함"은 HTML 안에 없다는 뜻이지, 아예 없다는 뜻이 아닙니다.
HTTP/1.1 301 Moved Permanently Location: https://example.com/new
- Google: 코드에 따름: 301과 308은 영구, 나머지는 임시
- 이 도구: 홉 단위로 따라감
<meta http-equiv="refresh" content="0; URL=https://example.com/new">
- Google: 0초: 영구, 지연이 있으면 임시
- 이 도구: 지연 시간과 함께 홉으로 따라감
window.location.href = "https://example.com/new";
- Google: 렌더링이 될 때만: 최후의 수단
- 이 도구: "이 URL 확인"으로 표시, 실행하지 않음
http, https, www, www 없음이 모두 하나의 URL로 가나요?
그래야 합니다. 모든 사이트에는 네 가지 진입 경로가 있고, 각각 같은 최종 URL에 가능하면 한 번의 영구 홉으로 도달해야 합니다. 그렇지 않으면 같은 페이지의 여러 버전으로 링크가 나뉩니다.
예외 하나는 괜찮습니다. 같은 호스트에서 먼저 https://www.로 간다면 http://www.는 두 홉이 될 수 있습니다. hstspreload.org가 바로 그 순서를 요구하며, Mozilla HTTP Observatory는 http://에서의 첫 홉이 다른 호스트로 가면 5점을 감점합니다.
네 가지 모두 https://github.com/에 도달http://www.github.com은(는) 두 홉: HSTS 프리로드가 요구하는 대로 같은 호스트의 https://를 먼저 거침
각 진입 경로는 기본 체인과 함께 최대 10홉까지 따라갑니다.
URL이 국가에 따라 다르게 리다이렉트되는 이유는?
서버가 방문자의 IP 주소나 Accept-Language 헤더를 보고 국가 또는 언어 버전을 골라 리다이렉트하기 때문에, 같은 URL이 방문자에 따라 다른 페이지로 끝납니다. www.mozilla.org는 언어로 이를 처리합니다: Vary: Accept-Language와 함께 /en-US/로 가는 상대 경로 302입니다.
Google은 이를 권장하지 않습니다. "사용자를 사이트의 한 언어 버전에서 다른 언어 버전으로 자동 리디렉션하지 마세요"라고 안내하며, Googlebot은 대개 미국에서 크롤링하고 Accept-Language를 보내지 않기 때문입니다(Google 검색 센터). 각 버전에 고유한 URL을 주고 hreflang으로 연결하며, 다른 버전은 배너로 안내하세요.
결과의 11곳에서는 웹사이트 다운 확인 도구의 전 세계 프로브에서 체인을 따라가므로, 국가별 리다이렉트는 서로 다른 도착지로 나타납니다. 이 프로브들은 자체 사용자 에이전트로 최대 5회까지 리다이렉트를 따라갑니다.
Ahttps://shop.example/10곳이 여기서 끝남
- 나가장 가까운 곳20041ms
새너제이SJC200152ms
애시번IAD20096ms
런던LHR20022ms
스톡홀름ARN20031ms
싱가포르SIN200168ms
시드니SYD200290ms
상파울루GRU200201ms
케이프타운CPT200170ms
뭄바이BOM200121ms
Bhttps://shop.example/ja-jp/다름
오사카KIX302200486ms
오사카만 받은 응답
HTTP/1.1 302 Found Location: /ja-jp/ Vary: CF-IPCountry
2026년 10월 24일에 기록: www.mozilla.org은(는) 언어에 따라 리다이렉트합니다
HTTP/1.1 302 Found location: /en-US/ Vary: Accept-Language
Googlebot은 주로 미국에서 크롤링하고 Accept-Language를 보내지 않으므로 https://shop.example/만 보게 됩니다.
이 링크는 어디로 가나요? 단축 링크 펼치기
단축 링크나 추적 링크를 위에 붙여넣으면, 열기 전에 어디로 끝나는지 볼 수 있습니다. 각 홉의 호스트, 도중에 추가된 모든 매개변수를 포함한 최종 URL, 응답하는 네트워크를 보여 줍니다. 단축 링크, QR 코드, 뉴스레터 링크 모두에 리다이렉트 추적기로 쓸 수 있습니다.
링크는 브라우저가 아니라 우리 서버가 열기 때문에, 도착지는 사용자의 주소나 쿠키를 알 수 없습니다. 경로상의 각 호스트는 Cloudflare의 악성코드 및 성인 콘텐츠 필터에서도 조회됩니다. 목록에 오른 호스트는 빨간색으로 표시되고 열 수 있는 링크가 제공되지 않으며, 문제가 없는 호스트에는 "Cloudflare의 악성코드·성인 목록에 없음"이라고 표시됩니다. 사이트가 안전하다는 보장은 아니므로, 이 링크 리다이렉트 확인 도구는 여러 점검 중 하나로 사용하세요.
단축 링크
https://youtu.be/jNQXAC9IVRw
303 See Other · 260ms도착지
https://www.youtube.com/watch?v=jNQXAC9IVRw&feature=youtu.be
200 OK · 768ms- AS15169Google · 응답하는 네트워크
- TLS 1.3두 홉 모두 암호화됨
- 우리 서버브라우저가 아니라 서버가 열었음
feature=youtu.be을(를) 추가합니다. 클릭하기 전에 최종 URL에서 추적 매개변수를 볼 수 있습니다.nginx, Apache, Cloudflare에서 301 리다이렉트는 어떻게 설정하나요?
서버에서 리다이렉트하고 301을 명시하세요. nginx는 return 줄, Apache는 .htaccess의 Redirect 줄, IIS는 web.config의 규칙, Cloudflare나 Netlify는 _redirects 파일의 한 줄, Vercel은 vercel.json의 항목, Express는 함수 호출입니다. 아래에서 사용하는 플랫폼을 고르고 스니펫을 복사하세요.
기본값에 주의하세요. 코드를 쓰지 않으면 nginx, Apache, Express, Cloudflare의 _redirects는 임시 302를 보내고, Vercel은 Google이 301처럼 처리하는 308을 보냅니다. 배포 후에는 여기서 이전 URL을 확인하세요. 새 URL로 곧바로 가는 301이 한 번만 나와야 합니다.
| 플랫폼 | 작성 방식 | 보내는 값 |
|---|---|---|
| nginx | return URL; | 302 임시 |
| Apache | Redirect /old /new | 302 임시 |
| IIS | action type="Redirect" | 301 영구 |
| Cloudflare | _redirects | 302 임시 |
| Vercel | vercel.json redirects | 308 영구 |
| Netlify | _redirects | 301 영구 |
| Express | res.redirect(path) | 302 임시 |
location = /old-page {
return 301 /new-page;
}사이트의 server { } 블록 안에 넣고 nginx를 다시 불러옵니다. 코드 없이 `return URL;`만 쓰면 302입니다.
Chrome이나 curl로 리다이렉트를 확인하는 방법
Chrome에서는 DevTools(F12)를 열고 네트워크로 이동해 로그 보관를 체크한 뒤 URL을 불러오세요. 각 홉이 상태와 함께 한 행으로 나타납니다. curl에서는 curl -sIL이 리다이렉트를 따라가며 모든 응답 헤더를 출력합니다.
둘 다 사용자 기기에서 실행되므로 내 쿠키와, 브라우저가 기억하는 HTTPS 전용 사이트 정보가 영향을 줍니다. 그래서 Chrome이 서버가 보내지 않은 307 Internal Redirect를 보여 줄 때가 있습니다. 요청을 HTTPS로 스스로 업그레이드한 것이며, 이유는 Non-Authoritative-Reason에 표시됩니다(Chromium 소스). Chrome 115부터는 입력한 http:// 주소도 먼저 HTTPS로 시도하므로, 서버 자체의 HTTP 리다이렉트가 보이지 않을 수도 있습니다.
$ curl -sIL http://google.com | grep -iE '^(HTTP|location)' HTTP/1.1 301 Moved Permanently Location: http://www.google.com/ HTTP/1.1 302 Found Location: https://www.google.com/?gws_rd=ssl HTTP/2 200
307 Internal Redirect는 서버에서 온 것이 아닙니다. Chrome이 이미 해당 사이트가 HTTPS 전용임을 알고 만든 것이며, 이유는 Non-Authoritative-Reason: HSTS에 표시됩니다. 서버 측 확인 도구는 서버가 보낸 것만 보여 줍니다.
리다이렉트 확인: 자주 묻는 질문
302 리다이렉트는 SEO에 나쁜가요?
Googlebot은 리다이렉트를 몇 번까지 따라가나요?
Googlebot이나 iPhone으로 리다이렉트를 테스트하려면?
이 301 리다이렉트 확인 도구는 무료인가요? 여러 URL을 한 번에 확인할 수 있나요?
Chrome이 서버가 보내지 않은 307을 보여 주는 이유는?
301 리다이렉트는 얼마나 오래 유지해야 하나요?
이 링크는 어디로 가나요? 열어도 안전한가요?
ERR_TOO_MANY_REDIRECTS가 나오는 이유는?
HTTP는 301로 HTTPS에 리다이렉트해야 하나요?
301 리다이렉트는 링크 가치를 전달하나요?
관련 웹사이트 도구
HTTP 헤더 검사
HTTP 응답 헤더 분석 및 보안 헤더 등급 평가
링크 분석
dofollow/nofollow 감지 및 HTTP 상태 확인으로 페이지 내 링크 분석
사이트 접속 확인
모두에게 다운됐나요, 나만 안 되나요? 11개 지역과 내 연결에서 사이트를 확인하고 실시간 스크린샷을 봅니다
SSL 인증서 확인
SSL 인증서 유효성 및 보안 세부 정보 검증
DNS 조회
도메인 자체 네임서버의 모든 DNS 레코드를 Google·Cloudflare 캐시와 나란히 확인
호스팅 확인 도구
모든 웹사이트의 호스팅 업체 확인: 호스트, CDN, CMS, 이메일 제공업체, 등록 대행자, SSL 발급 기관
서브도메인 검색
도메인의 모든 서브도메인 발견
WHOIS 조회
RDAP로 도메인 등록 정보, 등록기관, 소유자 세부 정보 조회