리뉴얼·이전 · 공식 문서
리다이렉트 확인 방법, 상태 코드와 최종 URL 점검 순서
curl -I 로 첫 응답의 상태 코드와 Location 을 보고, -L 로 끝까지 따라가 최종 URL과 횟수를 확인합니다. 그다음 브라우저 개발자 도구와 서치 콘솔 URL 검사로 같은 결과를 다시 봅니다.
리디렉션은 걸어 둔 것과 실제로 나가는 응답이 다를 때가 많습니다. 설정 화면이 아니라 응답의 상태 코드와 최종 URL을 직접 봐야 확인이 끝납니다.
네이버도 리디렉션 문제는 눈으로 확인하기에 한계가 있으니 개발자 도구를 쓰라고 적었습니다. 확인하는 도구별로 무엇이 보이고 무엇이 안 보이는지 공식 문서로 정리했습니다.
발견 01
리디렉션 점검은 7단계이고, 서버 응답부터 보고 서치 콘솔은 뒤에 봅니다
| 순서 | 단계 | 하는 법 | 볼 것 | 공식 문서 원문 |
|---|---|---|---|---|
| 1 | 첫 응답 확인 | curl -I https://example.com/old | 첫 줄의 상태 코드(301·302·307·308)와 Location 헤더의 URL | Fetch the headers only. The server SHOULD generate a Location header field in the response containing a preferred URI reference for the new permanent URI.헤더만 받는다(curl). 서버는 응답에 새 영구 URI 를 가리키는 Location 헤더를 넣어야 한다(HTTP 표준). |
| 2 | 끝까지 따라가기 | curl -sIL https://example.com/old | 응답마다 찍힌 상태 코드와 Location. 마지막 응답이 200인지 | (HTTP) If the server reports that the requested page has moved to a different location (indicated with a Location: header and a 3XX response code), this option makes curl redo the request to the new place. If used together with --show-headers or --head, headers from all requested pages are shown.서버가 Location 헤더와 3XX 응답으로 페이지가 옮겨졌다고 알리면, 이 옵션은 새 위치로 다시 요청한다. --head 와 함께 쓰면 거친 모든 페이지의 헤더가 보인다. |
| 3 | 횟수와 최종 URL 한 줄로 보기 | curl -sL -o /dev/null -w "%{num_redirects} %{response_code} %{url_effective}\n" https://example.com/old | 따라간 횟수, 마지막 상태 코드, 최종 URL | Number of redirects that were followed in the request. The numerical response code that was found in the last transfer (formerly known as "http_code"). The URL that was fetched last. This is most meaningful if you have told curl to follow location: headers.요청에서 따라간 리디렉션 횟수, 마지막 전송의 응답 코드, 마지막으로 받은 URL. 마지막 값은 location 헤더를 따라가게 했을 때 가장 뜻이 있다. |
| 4 | 브라우저 개발자 도구로 다시 보기 | 네트워크 패널에서 「로그 보존」과 「캐시 사용 중지」를 켜고 옛 URL을 엽니다 | Status 열의 코드, Initiator 열의 Redirect, 헤더 탭 「일반」의 상태 | To save requests across page loads, check the Preserve log checkbox on the Network panel. To emulate how a first-time user experiences your site, check the Disable cache checkbox.페이지가 바뀌어도 요청 기록을 남기려면 네트워크 패널의 로그 보존을 켠다. 처음 온 사용자처럼 보려면 캐시 사용 중지를 켠다. |
| 5 | 최종 URL의 상태 보기 | 최종 URL과 중간 URL이 robots.txt 차단·noindex 없이 200으로 열리는지 봅니다 | 중간 URL 전부와 최종 URL이 수집 가능한지 | 이동하는 과정 및 최종 랜딩 URL은 수집 가능한 정상적인 페이지이어야 합니다. 특히 여러번 연결된 리다이렉션의 경우, 연결 과정에 있는 모든 주소들은 수집이 가능해야 합니다. |
| 6 | 서치 콘솔 URL 검사 | 옛 URL을 검사하고 「페이지 색인 생성 > 색인 생성」의 검사 버튼으로 대상 URL을 봅니다 | 색인된 결과의 리디렉션 표시와 「Google에서 선택한 표준 URL」 | If the URL redirects to another URL, the results reflect the tested URL in the index, not the redirect target in the index. To see the indexing results for the canonical of a redirected page, click the INSPECT button in the Page indexing > Indexing section.URL이 다른 URL로 리디렉션되면 결과는 리디렉션 대상이 아니라 검사한 URL의 색인 상태다. 리디렉션된 페이지의 표준 URL 결과를 보려면 페이지 색인 생성 > 색인 생성 섹션의 검사 버튼을 누른다. |
| 7 | 페이지 색인 생성 보고서 | 「리디렉션 오류」와 「리디렉션이 포함된 페이지」 상태의 URL 목록을 엽니다 | 체인·루프·빈 URL 같은 오류가 사이트 전체에 몇 건인지 | Google experienced one of the following redirect errors: A redirect chain that was too long · A redirect loop · A redirect URL that eventually exceeded the max URL length · A bad or empty URL in the redirect chain구글이 다음 리디렉션 오류 중 하나를 겪었다. 너무 긴 리디렉션 체인, 리디렉션 루프, 끝내 최대 URL 길이를 넘은 리디렉션 URL, 체인 속 잘못되었거나 빈 URL. |
서버 응답을 먼저 보는 이유는 서치 콘솔 URL 검사가 리디렉션 경로를 다 보여 주지 않기 때문입니다. 실시간 테스트는 리디렉션을 따라간 뒤 대상 페이지만 테스트해서, 결과 화면에는 경로가 빠져 있습니다.
curl -I 는 본문 없이 헤더만 받습니다. HTTP 표준은 HEAD 요청에도 GET 과 같은 헤더를 보내라고 적었지만, 결과가 이상하면 -I 없이 3단계 명령으로 다시 봅니다.
The test first follows any redirects implemented by the page, then tests the page. However, the test does not indicate that it has followed a redirect, nor will it display the final URL that was tested.
실시간 테스트는 페이지의 리디렉션을 먼저 따라간 뒤 테스트한다. 그러나 리디렉션을 따랐다는 표시도, 최종으로 테스트한 URL도 보여 주지 않는다.
발견 02
3단계 명령 한 줄이 따라간 횟수, 마지막 상태 코드, 최종 URL을 함께 보여 줍니다
| curl 이 보여 주는 값 | 뜻 | curl 공식 문서 원문 |
|---|---|---|
| num_redirects | 따라간 리디렉션 횟수 | Number of redirects that were followed in the request.요청에서 따라간 리디렉션 횟수. |
| response_code | 마지막 응답의 상태 코드 | The numerical response code that was found in the last transfer (formerly known as "http_code").마지막 전송에서 받은 응답 코드(예전 이름 http_code). |
| url_effective | 마지막으로 받은 URL(최종 URL) | The URL that was fetched last. This is most meaningful if you have told curl to follow location: headers.마지막으로 받은 URL. location 헤더를 따라가게 했을 때 가장 뜻이 있다. |
| --max-redirs | 따라가는 횟수의 한도 | By default the limit is set to 50 redirects.기본 한도는 리디렉션 50번이다. |
| 따라간 횟수의 기준 | 원문 |
|---|---|
| 구글: 크롤러가 따라가는 한도 | By default, Google's crawlers follow up to 10 redirect hops.구글 크롤러는 기본적으로 리디렉션을 10번까지 따라간다. |
| 구글: 권하는 횟수 | While Googlebot can follow up to 10 hops in a "chain" of multiple redirects (for example, Page 1 > Page 2 > Page 3), we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.Googlebot 은 여러 리디렉션이 이어진 체인(예: 페이지 1 > 2 > 3)을 최대 10번까지 따라가지만, 최종 목적지로 바로 리디렉션하라고 권한다. 어렵다면 체인 속 리디렉션 수를 적게, 되도록 3개 이하·5개 미만으로 유지한다. |
| 네이버: 권하는 횟수 | 연속해서 연결되는 리다이렉션 횟수는 최대 5회 이상을 넘기지 않는 것을 추천합니다. |
| 구글: 처리하는 내용 | Any content Google receives from the redirecting URL is ignored, and the final target URL's content is processed instead.리디렉션하는 URL에서 받은 내용은 무시하고, 최종 도착 URL의 내용을 처리한다. |
횟수가 0이면 리디렉션이 걸리지 않은 것이고, 1이면 최종 URL로 바로 보내는 상태입니다. 2 이상이면 중간 URL을 건너뛰고 첫 URL에서 최종 URL로 바로 보내도록 설정을 고칩니다.
발견 03
확인 중 자주 나오는 오류는 6가지이고, 서치 콘솔에도 상태로 남습니다
| 오류 | 점검에서 보이는 모습 | 공식 문서 원문 |
|---|---|---|
| 체인(여러 번 거침) | 따라간 횟수가 2 이상. http → https → www 처럼 단계마다 한 번씩 거칩니다 | While Googlebot can follow up to 10 hops in a "chain" of multiple redirects (for example, Page 1 > Page 2 > Page 3), we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.Googlebot 은 여러 리디렉션이 이어진 체인(예: 페이지 1 > 2 > 3)을 최대 10번까지 따라가지만, 최종 목적지로 바로 리디렉션하라고 권한다. 어렵다면 체인 속 리디렉션 수를 적게, 되도록 3개 이하·5개 미만으로 유지한다. |
| 루프(돌고 돎) | curl 이 한도까지 따라가다 멈추고, 브라우저는 페이지를 열지 못합니다 | 또한, 프로그램 문제로 자기 자신을 무한해서 반복해서 리다이렉션도 존재하는데요 이 경우에도 검색로봇이 수집하지 않습니다. |
| 최종 URL 오류 | 마지막 상태 코드가 404·500이거나, 최종 URL이 robots.txt로 차단됩니다 | 사이트 개편 등의 사유로 인하여 정상적인 콘텐츠를 담고 있는 URL 주소가 변경되었다면 변경 전과 변경 후에 URL이 올바르게 리다이렉션으로 연결되어 있는지 확인이 필요합니다. |
| 중간 URL 차단 | 처음과 끝은 열리지만, 가운데 URL 하나가 robots.txt 로 차단됩니다 | robots.txt 설정 등에 착오가 있어, 중간에 수집이 불가능한 URL이 섞여있는 경우, 처음과 최종 URL이 수집 가능하다고 하더라도 수집이 안되는 경우가 발생할 수 있으므로 주의해 주십시오. |
| 관련 없는 페이지로 몰아 보내기 | 옛 URL 여러 개의 최종 URL이 모두 홈입니다 | Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error.옛 URL 여러 개를 새 사이트 홈페이지처럼 관련 없는 URL 하나로 리디렉션하지 말라. 사용자를 혼란스럽게 하고 soft 404 오류로 처리될 수 있다. |
| 자바스크립트 리디렉션 | 서버 응답이 200이라 상태 코드 확인에서는 일반 페이지로 보입니다 | Only use JavaScript redirects if you can't do server-side or meta refresh redirects. This means that if you set a JavaScript redirect, Google might never see it if rendering of the content failed.서버 측이나 meta refresh 리디렉션을 쓸 수 없을 때만 JavaScript 리디렉션을 쓴다. 콘텐츠 렌더링이 실패하면 구글이 그 리디렉션을 끝내 보지 못할 수도 있다. |
Google experienced one of the following redirect errors: A redirect chain that was too long · A redirect loop · A redirect URL that eventually exceeded the max URL length · A bad or empty URL in the redirect chain
구글이 다음 리디렉션 오류 중 하나를 겪었다. 너무 긴 리디렉션 체인, 리디렉션 루프, 끝내 최대 URL 길이를 넘은 리디렉션 URL, 체인 속 잘못되었거나 빈 URL.
발견 04
개발자 도구와 URL 검사는 curl 이 못 보는 것을 하나씩 보여 줍니다
가능한 연속된 리다이렉트의 사용은 최소화를 부탁드리며, 리다이렉션 문제는 여러분이 사용하는 브라우저에서 눈으로 확인하기에는 한계점이 존재하므로 브라우저에서 제공하는 개발자 도구를 활용하거나 사이트의 기술담당자와 같이 문제를 해결하는 것을 권장합니다.
| 도구 | 보이는 것 | 공식 문서 원문 |
|---|---|---|
| 개발자 도구: 네트워크 패널 | 응답마다의 상태 코드 | HTTP status code, for example, 200 or 404.HTTP 상태 코드. 예를 들어 200, 404. |
| 개발자 도구: Initiator 열 | 이 요청을 부른 것이 리디렉션인지 | Redirect. An HTTP redirect.Redirect. HTTP 리디렉션이 부른 요청. |
| 개발자 도구: 헤더 탭 | 상태 코드와 상태 메시지 | In the General section, DevTools shows you human-readable status message next to the received HTTP status code.일반 섹션에서 DevTools 는 받은 HTTP 상태 코드 옆에 읽기 쉬운 상태 메시지를 보여 준다. |
| 서치 콘솔: 색인된 결과 | 구글이 색인한 옛 URL의 리디렉션 | The indexed report will show redirections. To see information about the request, including the HTTP request and response, and the returned HTML, click View crawled page.색인된 결과 보고서에는 리디렉션이 보인다. HTTP 요청과 응답, 받은 HTML 을 보려면 크롤링된 페이지 보기를 누른다. |
| 서치 콘솔: 검사할 수 있는 URL | 현재 연 속성 안의 URL, 하루 한도 안 | The URL must be in the currently opened property. There is a daily limit of inspection requests for each property that you own.URL은 현재 연 속성 안에 있어야 한다. 속성마다 하루 검사 요청 한도가 있다. |
브라우저는 301 응답을 저장해 두었다가 서버에 묻지 않고 바로 이동할 수 있습니다. HTTP 표준이 301을 캐시할 수 있는 응답으로 적었기 때문이며, 그래서 「캐시 사용 중지」를 켜고 봅니다.
구글 크롤링 인프라 문서는 검사 도구가 리디렉션을 따르지 않는다고 적어, URL 검사 도움말과 표현이 다릅니다(원문: For example, Googlebot generally follows 10 redirect hops when crawling for general web content, but Google Inspection Tools doesn't follow redirects.) 상태 코드와 경로는 curl 과 개발자 도구로 확정합니다.
A 301 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).
301 응답은 메서드 정의나 명시적인 캐시 제어가 달리 정하지 않는 한, 경험적으로 캐시할 수 있는 응답이다.
발견 05
같은 점검 순서라도 B2B·B2C·B2G 사이트에서 먼저 보는 URL이 다릅니다
예시 ① 문의형 기업 사이트의 https 전환(B2B)
http 와 www 없는 URL을 https://www 로 모은 경우입니다. 3단계 명령을 http://example.com 에 돌려 횟수가 2로 나오면, http 에서 https 를 거쳐 www 로 가는 체인입니다.
서버 설정을 고쳐 네 가지 URL 변형이 모두 한 번에 https://www 로 가게 한 뒤, 같은 명령으로 횟수 1을 다시 확인합니다.
예시 ② 리뉴얼한 쇼핑몰의 상품 URL(B2C)
상품 수천 개를 모두 열어 볼 수는 없으니, 카테고리마다 옛 상품 URL 몇 개를 골라 3단계 명령을 돌립니다. 최종 URL이 홈으로 나오는 상품이 있으면 짝표가 빠진 것입니다.
로그인·장바구니처럼 조건에 따라 보내는 URL은 루프가 생기기 쉬워서 개발자 도구로 다시 봅니다.
예시 ③ 공공기관 누리집 게시판 이전(B2G)
개편으로 게시판 URL이 바뀌었는데 새 게시판 경로가 robots.txt 에 차단된 경우입니다. 리디렉션 응답이 정상이어도 최종 URL은 크롤러의 수집 대상에서 빠집니다.
5단계에서 최종 URL의 경로를 robots.txt 와 대조하고, 공개 1주 뒤 페이지 색인 생성 보고서를 다시 엽니다.
그럼 리디렉션을 건 날 무엇부터 확인하나요?
- 바꾼 URL 목록에서 홈·주요 카테고리·트래픽이 많은 페이지의 옛 URL을 골라 둡니다.
- 옛 URL마다 3단계 명령을 돌려 횟수 1, 상태 코드 200, 맞는 최종 URL인지 적습니다.
- 횟수가 2 이상이거나 최종 URL이 홈인 줄은 서버 설정이나 짝표를 고치고 다시 돌립니다.
- 브라우저 개발자 도구에서 「로그 보존」과 「캐시 사용 중지」를 켜고 몇 개를 다시 엽니다.
- 서치 콘솔 URL 검사와 페이지 색인 생성 보고서는 며칠 뒤에 봅니다. 네이버도 반영에 시간이 걸릴 수 있다고 적었습니다. 코드를 고르는 기준은 「301 302 리다이렉트 차이」 편에 자세히 적었습니다.
조사 방법
- Search Console Help 「URL Inspection tool」 · 최종 확인일 2026-10-25 · https://support.google.com/webmasters/answer/9012289
- Chrome for Developers 「Network features reference」 (문서 수정일 2024-07-16) · 최종 확인일 2026-10-25 · https://developer.chrome.com/docs/devtools/network/reference
- curl 「curl man page」 · 최종 확인일 2026-10-25 · https://curl.se/docs/manpage.html
- IETF 「RFC 9110 HTTP Semantics」 (문서 수정일 2022-06) · 최종 확인일 2026-10-25 · https://www.rfc-editor.org/rfc/rfc9110
- Google Crawling Infrastructure 「How HTTP status codes affect Google's crawlers」 (문서 수정일 2026-02-04) · 최종 확인일 2026-10-25 · https://developers.google.com/crawling/docs/troubleshooting/http-status-codes
- Google Search Central 「Redirects and Google Search」 (문서 수정일 2026-04-14) · 최종 확인일 2026-10-25 · https://developers.google.com/search/docs/crawling-indexing/301-redirects
- 네이버 서치어드바이저 「웹 페이지의 이동」 · 최종 확인일 2026-10-25 · https://searchadvisor.naver.com/guide/seo-basic-redirect
- Search Console Help 「Page indexing report」 · 최종 확인일 2026-10-18 · https://support.google.com/webmasters/answer/7440203
- Google Search Central 「How to move a site」 (문서 수정일 2026-08-20) · 최종 확인일 2026-10-18 · https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
- 점검 7단계와 흔한 오류 6가지는 위 문서들이 확인 방법과 오류로 적은 것을 순서 단위로 묶은 것입니다. 묶는 방식은 편집 판단입니다.
- 네이버 반영 시간 원문: 사이트 개편 등으로 리다이렉션을 새로 설정하거나 변경하는 경우, 검색 결과 반영에 시간이 걸리는 경우가 있습니다.
- 예시 ①②③은 이해를 돕기 위해 만든 가상 상황이며, 실제 기업·기관의 사례가 아닙니다.
- 원문은 영어판(hl=en)이고, 도구·보고서 이름은 같은 문서 한국어판(hl=ko) 표기를 따랐습니다. 서치 콘솔 도움말·curl·네이버 가이드는 페이지에 수정일이 없습니다.