리다이렉트 확인

모든 URL과 단축 링크의 리다이렉트를 확인하세요. 각 홉의 상태 코드(301, 302, 307, 308, meta refresh)와 그 의미, 이동 대상, 소요 시간을 브라우저처럼 최대 20홉까지 따라가며 보여 줍니다. Googlebot이 추적을 멈추는 지점과 http/https, www 유무의 네 가지 버전도 함께 확인합니다.

우리 서버에서 호스트별로 연결을 재사용해 요청(브라우저와 동일) · 브라우저와 같은 최대 20홉 · Chrome, iPhone, Googlebot, Bingbot으로 선택 가능 · 결과는 2분간 보관 후 삭제

리다이렉트 확인 도구는 무엇을 보여 주나요?

리다이렉트 확인 도구는 브라우저처럼 URL에 요청한 뒤, 돌아오는 모든 Location 헤더를 한 홉씩 따라가 페이지가 응답할 때까지 추적합니다. 각 홉마다 상태 코드, 이동 대상, 소요 시간, 응답한 네트워크를 확인할 수 있습니다.

이 도구는 모든 홉의 시간을 측정합니다. 새 연결이면 DNS, 연결, TLS, 첫 바이트로 나누고, 브라우저처럼 같은 호스트로 열려 있는 연결을 재사용하는 홉은 첫 바이트만 표시합니다. 브라우저처럼 호스트별로 쿠키를 유지하고, 최종 페이지의 meta refresh, canonical 태그, noindex를 읽으며, Googlebot이 포기할 지점도 표시합니다.

경로 읽기http://google.com · 2026년 10월 24일 기록
경로 · google.comChrome
2 리다이렉트1.30초 합계
영구임시페이지 안오류
DNS연결TLS첫 바이트
  1. 1
    301영구POST가 GET으로 바뀔 수 있음368ms
    http://google.com/
    Google AS15169HTTP/1.1 · TLS 없음
  2. 2
    302임시POST가 GET으로 바뀔 수 있음537ms
    http://www.google.com/
    Google AS15169HTTP/1.1 · TLS 없음
  3. 3
    200최종OK393ms
    https://www.google.com/?gws_rd=ssl
    “Google”
    Google AS15169TLS 1.3 · HTTP/2
  1. 총 소요 시간 페이지가 시작되기 전까지 모든 홉을 합친 시간입니다.
  2. 홉 예산 리다이렉트당 한 칸. Googlebot의 한도는 10, 브라우저는 20입니다.
  3. 각 홉의 사이트 아이콘이 바뀌면 링크가 다른 사이트로 넘어갔다는 뜻입니다.
  4. 상태 종류별 색과 그 의미를 말로 보여 줍니다.
  5. 시간이 쓰인 곳 DNS, 연결, TLS, 첫 바이트를 하나의 시간축으로 보여 줍니다.
페이지에 도달하기까지 리다이렉트 두 번: google.com이(가) 301로 www로 보내고, www가 302로 HTTPS로 보냅니다. 2026년 10월 24일에 홉 단위로 기록했으며, 시간은 기록한 기기 기준입니다.

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의 것으로 표시합니다.

http://google.com 리다이렉트 확인 결과: HTTPS로 가는 301과 302, 모든 홉을 하나의 시간축으로 측정http://google.com 리다이렉트 확인 결과: HTTPS로 가는 301과 302, 모든 홉을 하나의 시간축으로 측정판정URL이 어디에서 끝나는지, 몇 홉인지, 각 홉이 영구인지 임시인지를 말로 보여 줍니다.홉 예산리다이렉트 하나당 한 칸을 종류별 색으로 표시하고, Googlebot의 10홉과 브라우저의 20홉을 기준으로 삼습니다.각 홉의 상태서버가 보낸 코드와 그 의미: 영구인지 임시인지, POST가 어떻게 되는지를 보여 줍니다.시간이 쓰인 곳각 홉의 DNS, 연결, TLS, 첫 바이트를 첫 요청부터 페이지까지 하나의 시간축으로 보여 줍니다.
http://google.com 리다이렉트 검사: 판정, Googlebot의 10홉과 브라우저의 20홉에 대한 홉 예산, 각 홉의 상태와 소요 시간. 번호를 선택하면 각 부분이 무엇을 보여 주는지 확인할 수 있습니다.

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은 항상 바꿉니다.

리다이렉트 유형과 Google의 해석RFC 9110 · Google 검색 센터 · Bing
코드영구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—약함피할 것: 방문자에게 이전 페이지가 먼저 보임
308은 301처럼, 307은 302처럼 처리됩니다. meta refresh 행에는 HTTP Refresh 헤더도 포함됩니다.

리다이렉트 체인은 몇 홉부터 너무 많은 건가요?

3홉을 넘으면 많은 것입니다. 체인은 http://에서 https://로, 다시 www로, 이어서 새 경로로 가는 것처럼 리다이렉트가 연속된 상태를 말합니다. Google은 최종 URL로 바로 링크하거나, 체인을 3홉 이하로 유지하고 어떤 경우에도 5홉 미만으로 하라고 권고합니다(Google 검색 센터).

Googlebot은 최대 10홉까지 따라간 뒤 포기하고, Search Console에 "리디렉션 오류"가 보고됩니다(Google 크롤러 문서). Chrome과 Firefox는 최대 20홉까지 따라가고 그 이상이면 ERR_TOO_MANY_REDIRECTS를 표시합니다. 홉이 하나 늘 때마다 페이지가 시작되기 전에 왕복이 한 번 더 생기므로, 내부 링크는 최종 URL을 가리키도록 수정하세요.

몇 홉부터 너무 많은 걸까요?Google · Chromium · Firefox
  • Google의 권고: 3 이하
  • 따라가긴 하지만 느려짐
  • Googlebot은 여기까지 도달하지 못함: Search Console에 "리디렉션 오류"로 표시
  • 20 초과: ERR_TOO_MANY_REDIRECTS
http://google.com리다이렉트 2회, 그다음 페이지301 · 368302 · 537페이지 · 3931.30초
https://www.google.com/바로 링크페이지 · 393393ms
홉마다 페이지가 시작되기 전에 왕복이 한 번씩 필요합니다. 여기서는 393ms 페이지 앞에 905ms의 리다이렉트가 있습니다. 2026년 10월 24일에 홉 단위로 기록했습니다.

리다이렉트 루프는 어떻게 고치나요?

서로 충돌하는 두 규칙을 찾아 하나의 최종 URL로 통일하세요. 루프는 이미 요청한 URL로 되돌아오는 체인이며, 브라우저는 리다이렉트가 20회가 될 때까지 계속 돌다가 ERR_TOO_MANY_REDIRECTS를 표시합니다.

대부분의 루프는 www를 붙이는 규칙과 떼는 규칙이 충돌하거나, CDN 뒤에서 HTTP와 HTTPS 규칙이 부딪혀 생깁니다. CDN이 http://로 서버에 접속하면 서버가 https://로 리다이렉트하고, CDN이 다시 http://로 요청하는 식입니다. 브라우저는 영구 리다이렉트를 저장해 두므로, 수정 후에는 시크릿 창에서 테스트하세요.

리다이렉트 루프 확인 도구가 루프를 찾는 방법

그 사이 새 쿠키 없이 같은 URL을 두 번째로 요청하면 루프입니다. 경로는 반복되는 홉으로 되돌아가도록 그려지고 거기서 멈추며, 20회까지 돌지 않습니다. 쿠키를 설정하고 자기 자신으로 리다이렉트하는 사이트는 브라우저처럼 그 쿠키를 되돌려 받으므로, 로그인 단계를 루프로 오인하지 않습니다.

리다이렉트 루프가상의 예시

ERR_TOO_MANY_REDIRECTS · 20회 후

호스트 규칙 하나루트 도메인 또는 www 중 하나를 골라, 로그인 페이지를 포함한 모든 규칙이 그곳으로 보내도록 하세요.
쿠키를 읽는 규칙쿠키가 설정될 때까지 리다이렉트하는 규칙은 쿠키를 버리는 모든 클라이언트(크롤러 포함)에서 루프가 됩니다.
캐시된 301 지우기브라우저는 영구 리다이렉트를 저장합니다. 수정 후 시크릿 창에서 테스트하세요.

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 안에 없다는 뜻이지, 아예 없다는 뜻이 아닙니다.

리다이렉트하는 세 가지 방법Google과 이 도구가 각각 처리하는 방식
서버 리다이렉트상태 줄
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new
  • Google: 코드에 따름: 301과 308은 영구, 나머지는 임시
  • 이 도구: 홉 단위로 따라감
meta refresh페이지의 HTML 안
<meta http-equiv="refresh" content="0; URL=https://example.com/new">
  • Google: 0초: 영구, 지연이 있으면 임시
  • 이 도구: 지연 시간과 함께 홉으로 따라감
JavaScript스크립트가 location을 변경
window.location.href = "https://example.com/new";
  • Google: 렌더링이 될 때만: 최후의 수단
  • 이 도구: "이 URL 확인"으로 표시, 실행하지 않음
브라우저의 처리 순서: HTTP 리다이렉트가 먼저, 페이지가 로드되는 동안 실행되는 JavaScript가 다음, 로드가 끝난 뒤 meta refresh가 마지막입니다.

http, https, www, www 없음이 모두 하나의 URL로 가나요?

그래야 합니다. 모든 사이트에는 네 가지 진입 경로가 있고, 각각 같은 최종 URL에 가능하면 한 번의 영구 홉으로 도달해야 합니다. 그렇지 않으면 같은 페이지의 여러 버전으로 링크가 나뉩니다.

예외 하나는 괜찮습니다. 같은 호스트에서 먼저 https://www.로 간다면 http://www.는 두 홉이 될 수 있습니다. hstspreload.org가 바로 그 순서를 요구하며, Mozilla HTTP Observatory는 http://에서의 첫 홉이 다른 호스트로 가면 5점을 감점합니다.

네 가지 진입 경로github.com · 2026년 10월 24일 기록

네 가지 모두 https://github.com/에 도달http://www.github.com은(는) 두 홉: HSTS 프리로드가 요구하는 대로 같은 호스트의 https://를 먼저 거침

http://github.com3012001홉
http://www.github.com3013012002홉
https://github.com200표준 URL 자체
https://www.github.com3012001홉
https://github.com/200 OK

각 진입 경로는 기본 체인과 함께 최대 10홉까지 따라갑니다.

URL이 국가에 따라 다르게 리다이렉트되는 이유는?

서버가 방문자의 IP 주소나 Accept-Language 헤더를 보고 국가 또는 언어 버전을 골라 리다이렉트하기 때문에, 같은 URL이 방문자에 따라 다른 페이지로 끝납니다. www.mozilla.org는 언어로 이를 처리합니다: Vary: Accept-Language와 함께 /en-US/로 가는 상대 경로 302입니다.

Google은 이를 권장하지 않습니다. "사용자를 사이트의 한 언어 버전에서 다른 언어 버전으로 자동 리디렉션하지 마세요"라고 안내하며, Googlebot은 대개 미국에서 크롤링하고 Accept-Language를 보내지 않기 때문입니다(Google 검색 센터). 각 버전에 고유한 URL을 주고 hreflang으로 연결하며, 다른 버전은 배너로 안내하세요.

결과의 11곳에서는 웹사이트 다운 확인 도구의 전 세계 프로브에서 체인을 따라가므로, 국가별 리다이렉트는 서로 다른 도착지로 나타납니다. 이 프로브들은 자체 사용자 에이전트로 최대 5회까지 리다이렉트를 따라갑니다.

11곳에서 본 하나의 URLshop.example
가상의 예시

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/만 보게 됩니다.

각 지점은 자체 DNS와 주소로 요청합니다. 프로브는 자체 사용자 에이전트로 최대 5회까지 리다이렉트를 따라갑니다.

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이 한 번만 나와야 합니다.

코드를 쓰지 않을 때 각 플랫폼이 보내는 값각 플랫폼의 공식 문서 · 2026년 10월 24일
플랫폼작성 방식보내는 값
nginxreturn URL;302 임시
ApacheRedirect /old /new302 임시
IISaction type="Redirect"301 영구
Cloudflare_redirects302 임시
Vercelvercel.json redirects308 영구
Netlify_redirects301 영구
Expressres.redirect(path)302 임시
일곱 중 네 곳은 임시 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 · Chrome DevTools
$ 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
네트워크☑ 로그 보관
이름상태유형
www.google.com307Internal
?gws_rd=ssl200document

307 Internal Redirect는 서버에서 온 것이 아닙니다. Chrome이 이미 해당 사이트가 HTTPS 전용임을 알고 만든 것이며, 이유는 Non-Authoritative-Reason: HSTS에 표시됩니다. 서버 측 확인 도구는 서버가 보낸 것만 보여 줍니다.

리다이렉트 확인: 자주 묻는 질문

302 리다이렉트는 SEO에 나쁜가요?

그 자체로는 아닙니다. 302는 Google에 이동이 임시라고 알리므로 이전 URL을 계속 표시할 수 있지만, 이동 대상도 처리합니다. 영구적인 이동이라면 301이나 308로 바꿔서, Google이 새 URL을 색인할 URL로 처리하고 브라우저가 리다이렉트를 캐시할 수 있게 하세요. Bing도 이틀 미만의 변경에만 302를 사용하라고 안내합니다.

Googlebot은 리다이렉트를 몇 번까지 따라가나요?

URL당 최대 10홉입니다. 그 이후에는 멈추고 Search Console에 해당 페이지의 리디렉션 오류가 보고됩니다. Google의 권고는 체인을 3홉 이하로, 어떤 경우에도 5 미만으로 유지하고 가능한 한 최종 URL로 바로 링크하라는 것입니다. 브라우저는 더 멀리 가서, Chrome과 Firefox는 최대 20회까지 따라간 뒤 포기합니다.

Googlebot이나 iPhone으로 리다이렉트를 테스트하려면?

URL 입력란 아래의 As 행에서 Googlebot, iPhone, Bingbot, Chrome 중 하나를 고른 뒤 URL을 확인하세요. 모든 홉에 해당 에이전트의 사용자 에이전트 문자열을 보내므로, 크롤러나 휴대폰을 다른 곳으로 보내는 사이트는 체인에 그대로 나타납니다. Google의 실제 IP 주소는 사용할 수 없어서, 사용자 에이전트가 아닌 주소를 확인하는 사이트는 다르게 응답할 수 있습니다.

이 301 리다이렉트 확인 도구는 무료인가요? 여러 URL을 한 번에 확인할 수 있나요?

네, 계정 없이 무료입니다. 일괄로 전환해 한 줄에 URL 하나씩 최대 50개를 붙여넣으세요. 선택한 사용자 에이전트로 각각 최대 20홉까지 따라가며, 표에 홉 수, 최종 상태, 최종 URL, 판정이 나옵니다. CSV로 내려받아 사이트 이전을 점검하세요. 단일 검사는 서비스의 공정한 이용을 위해 방문자당 분당 20회로 제한됩니다.

Chrome이 서버가 보내지 않은 307을 보여 주는 이유는?

Chrome은 HSTS나 DNS HTTPS 레코드를 통해 사이트가 HTTPS 전용임을 이미 알면, 아무것도 보내기 전에 요청을 업그레이드하며 "307 Internal Redirect"를 만듭니다. 응답의 Non-Authoritative-Reason 헤더에 그 이유가 나옵니다. 이 도구 같은 서버 측 확인 도구는 그 단계를 보지 못하고 서버가 직접 보내는 리다이렉트만 보여 주며, 이는 다른 브라우저와 크롤러가 받는 것과 같습니다.

301 리다이렉트는 얼마나 오래 유지해야 하나요?

최소 1년, 가능하면 더 오래 유지하세요. Google의 사이트 이전 가이드는 리다이렉트를 가능한 한 오래, 보통 최소 1년 유지하라고 안내하며, 방문자를 위해 무기한 유지하는 것도 고려하라고 합니다. 오래된 링크, 북마크, 이메일이 계속 이전 URL로 사람들을 보내기 때문입니다. 이전 URL마다 가장 가까운 새 페이지로 연결하세요. 모두 홈페이지로 보내면 소프트 404로 처리될 수 있습니다.

이 링크는 어디로 가나요? 열어도 안전한가요?

클릭하기 전에 여기에 붙여넣으세요. 우리 서버가 링크를 따라가므로 도착지는 사용자의 주소를 알 수 없습니다. 모든 홉, 추적 매개변수가 붙은 최종 URL, 경로상의 호스트가 Cloudflare의 악성코드 또는 성인 콘텐츠 목록에 있는지 여부를 확인할 수 있습니다. 깨끗하다는 결과가 보장은 아니므로, 무언가를 입력하기 전에 최종 도메인 자체를 직접 판단하세요.

ERR_TOO_MANY_REDIRECTS가 나오는 이유는?

브라우저가 페이지에 도달하지 못한 채 20번 리다이렉트를 따라갔기 때문이며, 거의 항상 루프가 원인입니다. 예를 들어 www를 붙이는 규칙과 떼는 규칙이 URL을 서로 되돌려 보내거나, CDN은 http://로 요청하는데 서버가 https://를 고집하는 경우입니다. 여기서 URL을 확인해 반복되는 홉을 찾고 규칙을 고친 다음, 사이트 쿠키를 지우거나 시크릿 창을 사용하세요.

HTTP는 301로 HTTPS에 리다이렉트해야 하나요?

네. http://에서 https://로 가는 영구 301 또는 308은 RFC 6797이 HSTS 사이트에 권장하는 방식이며, 같은 호스트로의 첫 홉은 hstspreload.org와 Mozilla Observatory의 리다이렉트 테스트가 확인하는 것입니다. 302도 방문자에게는 작동하지만 검색엔진에는 이동이 임시라고 알립니다. 301만으로는 브라우저가 다음번에 먼저 HTTPS를 시도하게 되지 않으며, 그것은 Strict-Transport-Security 헤더의 역할입니다.

301 리다이렉트는 링크 가치를 전달하나요?

Google은 수치를 공개하지 않지만, 문서에서 301이나 308은 이동 대상이 검색결과에 표시되는 표준 URL이 되어야 한다는 신호이고 302, 303, 307은 그렇지 않다고 설명합니다. 따라서 페이지의 평가를 새 URL로 옮기려면 영구 리다이렉트가 맞는 방법입니다. 임시 리다이렉트도 이동 대상은 처리되며(Google 크롤러 문서상 약한 신호), 다른 표준화 신호가 이동 대상을 가리키면 색인이 생성될 수도 있습니다.