리뉴얼·이전 · 공식 문서
리다이렉트 체인 정리, 몇 번까지 둘지 판단 기준
구글 크롤러는 리디렉션을 10번까지 따라가지만, 구글은 최종 URL로 바로 보내고 어렵다면 3번 이하로 두라고 적었습니다. 체인은 크롤링과 사용자 로딩을 늦추므로, 옛 규칙의 대상을 최종 URL로 고쳐 한 번에 가게 정리합니다.
리뉴얼을 두 번 하면 첫 사이트 URL에서 둘째 사이트로, 다시 지금 사이트로 가는 리디렉션이 쌓입니다. 화면은 잘 열려서 문제를 알아채기 어렵습니다.
체인은 오류가 뜨기 전에도 크롤링과 로딩에 비용을 냅니다. 따라간 횟수를 재면 지금 둘지 이번에 줄일지가 갈립니다.
발견 01
구글 크롤러는 10번까지 따라가지만, 구글은 최종 URL로 바로 보내라고 적었습니다
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. By default, Google's crawlers follow up to 10 redirect hops.
Googlebot 은 여러 리디렉션이 이어진 체인(1페이지에서 2페이지, 다시 3페이지)을 10번까지 따라갈 수 있지만, 최종 목적지로 바로 보내기를 권한다. 구글 크롤러는 기본적으로 리디렉션을 10번까지 따라간다.
한도 안이면 색인은 됩니다. 구글은 영구 리디렉션이 PageRank 를 잃게 하지 않는다고도 적었습니다(원문: 301 and other permanent redirects don't cause a loss in PageRank.)
그래서 체인을 줄이는 이유는 신호 손실이 아니라 크롤링 시간과 사용자 로딩입니다. 한도에 닿기 전에 정리할수록 고칠 규칙이 적습니다.
발견 02
따라간 횟수에 따라 6단계로 둘지 줄일지 가릅니다
| 따라간 횟수 | 어떻게 읽나 | 할 일 | 공식 문서 원문 |
|---|---|---|---|
| 1번(바로 감) | 구글이 권하는 모양입니다 | 그대로 둡니다 | 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.Googlebot은 리다이렉트 체인을 최대 10번까지 따라갈 수 있지만, 최종 도착 URL로 바로 리다이렉트하기를 권한다. |
| 2번 | 크롤링은 되지만, Lighthouse 는 이 페이지를 실패로 표시합니다 | 내부 링크와 사이트맵부터 최종 URL로 고칩니다 | A page fails this audit when it has two or more redirects.리디렉션이 두 번 이상이면 이 Lighthouse 항목에서 실패로 표시된다. |
| 3번 | 구글이 바람직하다고 적은 상한입니다 | 다음 리뉴얼 전에 규칙을 합칠 목록에 올립니다 | If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.바로 보낼 수 없다면 체인의 리디렉션 수를 적게, 가능하면 3번 이하, 5번 미만으로 둔다. |
| 4번 | 구글이 적은 「5번 미만」 안이지만 바람직한 상한은 넘었습니다 | 이번 작업에서 규칙을 합칩니다 | If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.바로 보낼 수 없다면 체인의 리디렉션 수를 적게, 가능하면 3번 이하, 5번 미만으로 둔다. |
| 5번 이상 | 네이버가 넘기지 말라고 적은 횟수에 닿았습니다 | 이번 작업에서 첫 URL이 최종 URL로 바로 가게 고칩니다 | 연속해서 연결되는 리다이렉션 횟수는 최대 5회 이상을 넘기지 않는 것을 추천합니다. |
| 10번 초과 | 구글 크롤러가 따라가는 기본 한도를 넘어 최종 URL에 닿지 못합니다 | 리디렉션 오류로 다룹니다(「리다이렉트 오류」 편) | By default, Google's crawlers follow up to 10 redirect hops.구글 크롤러는 기본적으로 리디렉션을 10번까지 따라간다. |
네이버 「웹 페이지의 이동」은 연속 리디렉션을 5번 넘기지 말라고 적었습니다. 구글과 네이버를 함께 보면 3번 안에서 멈추는 것이 무난합니다.
체인 중간 URL도 수집할 수 있어야 합니다. 네이버는 「특히 여러번 연결된 리다이렉션의 경우, 연결 과정에 있는 모든 주소들은 수집이 가능해야 합니다.」라고 적었습니다.
발견 03
체인은 크롤러보다 사용자 쪽에서 먼저 느려집니다
Chaining redirects adds latency for users, and not all user agents and browsers support long redirect chains. Redirects slow down your page load speed. This additional trip across the network can delay the loading of the resource by hundreds of milliseconds.
리디렉션을 이어 걸면 사용자 쪽 지연이 늘고, 모든 사용자 에이전트와 브라우저가 긴 체인을 지원하지도 않는다. 리디렉션은 페이지 로딩을 늦춘다. 네트워크를 한 번 더 오가는 사이 리소스 로딩이 수백 밀리초 늦어질 수 있다.
| 체인이 시작되는 자리 | 고치는 법 | 공식 문서 원문 |
|---|---|---|
| 사이트 안의 메뉴·본문 링크 | 링크 자체를 최종 URL로 바꿉니다. 리디렉션을 거치지 않게 됩니다 | Internal links: based on the URL mapping you previously created, replace all URLs that pointed to your own pages.내부 링크: 앞서 만든 URL 짝표를 바탕으로, 자기 사이트 페이지를 가리키던 URL을 모두 바꾼다. |
| 사이트맵·캐노니컬 태그 | 최종 URL만 적습니다. 옛 URL이 남아 있으면 크롤러가 체인부터 탑니다 | Each new URL should have a self-referencing rel="canonical" <link> tag.새 URL 마다 자기 자신을 가리키는 rel="canonical" <link> 태그를 둔다. |
| 다른 사이트의 링크·검색 결과 | 우리가 고칠 수 없으니 옛 URL 규칙의 대상을 최종 URL로 바꿉니다. 유입이 많은 링크는 상대에게 수정을 요청합니다 | From users' perspective, consider keeping redirects indefinitely. However, redirects are slow for users, so try to update your own links and any high-volume links from other websites to point to the new URLs. External links: Try to contact the sites in the saved list of sites linking to your current content, asking them to update their links to your new site.사용자 입장에서는 리디렉션을 기한 없이 두는 것도 고려한다. 다만 리디렉션은 사용자에게 느리므로, 자기 링크와 유입이 많은 외부 링크는 새 URL을 가리키게 바꾼다. 외부 링크: 저장해 둔 링크 사이트 목록에 연락해 새 사이트로 링크를 고쳐 달라고 요청한다. |
| 인쇄물·즐겨찾기·QR 코드 | 옛 URL 규칙의 대상을 최종 URL로 바꾸고, 규칙은 오래 둡니다 | Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs.리디렉션은 가능한 한 오래, 일반적으로 최소 1년 유지한다. 그래야 다시 크롤링하고 옛 URL 을 가리키는 다른 사이트의 링크를 다시 연결하는 것을 포함해 구글이 모든 신호를 새 URL 로 넘길 수 있다. |
사이트 안의 링크는 고치는 쪽이 빠릅니다. 리디렉션을 한 번도 거치지 않게 되기 때문입니다.
다른 사이트의 링크와 인쇄물은 손댈 수 없으니 서버 규칙으로 줄입니다. 옛 URL마다 최종 URL을 직접 가리키게 합니다.
발견 04
정리는 옛 규칙의 대상만 고쳐 쓰고, 중간 규칙은 남깁니다
| URL | 정리 전 | 정리 후 | 따라간 횟수(전 · 후) |
|---|---|---|---|
| 첫 사이트 URL(A) | A에서 B로 301 | A에서 C로 301 | 2 · 1 |
| 둘째 사이트 URL(B) | B에서 C로 301 | B에서 C로 301(그대로 둠) | 1 · 1 |
| 지금 URL(C) | 200 | 200 | 0 · 0 |
중간 규칙을 지우면 B URL로 걸린 링크가 404 가 됩니다. 대상만 바꾸면 A와 B 모두 한 번에 C로 갑니다.
정리한 규칙도 구글이 적은 유지 기간 이상 둡니다. 유지 기간 원문은 위 「체인이 시작되는 자리」 표 끝 줄에 있습니다.
발견 05
같은 체인이라도 B2B·B2C·B2G 는 시작되는 자리가 다릅니다
예시 ① 리뉴얼을 세 번 한 장비 제조사의 제품 사이트(B2B)
옛 제품 URL에서 둘째 사이트, 다시 지금 사이트로 가는 체인이 남았습니다. 견적서와 데이터시트 PDF에 첫 사이트 URL이 박혀 있습니다.
인쇄물은 고칠 수 없으니 첫 URL 규칙의 대상을 지금 제품 페이지로 바꿉니다. 둘째 사이트 URL 규칙도 함께 둡니다.
예시 ② http 에서 https, www 를 따로 거는 쇼핑몰(B2C)
http, www 없는 URL, 끝 슬래시 규칙이 따로 걸려 상품 URL마다 세 번을 거칩니다. 광고 클릭도 같은 체인을 탑니다.
세 규칙을 하나로 합쳐 한 번에 최종 URL로 보내고, 광고 랜딩 URL은 최종 URL로 바꿉니다.
예시 ③ 개편마다 게시판을 옮긴 공공기관 누리집(B2G)
공지 게시판 URL이 개편마다 바뀌어, 보도자료에 걸린 옛 URL이 여러 번 거쳐 갑니다. 중간 URL 하나가 robots.txt 로 차단돼 있었습니다.
차단을 풀고, 옛 게시판 URL마다 지금 게시글로 바로 보내는 짝표를 다시 만듭니다.
그럼 지금 쌓인 체인은 어떤 순서로 정리하나요?
- 리뉴얼마다 만든 URL 짝표를 모으고, 서치 콘솔 링크 보고서에서 외부 링크가 많은 옛 URL을 함께 뽑습니다.
- URL마다 끝까지 따라가 따라간 횟수와 최종 URL을 적습니다. 재는 명령은 「리다이렉트 확인 방법」 편에 자세히 적었습니다.
- 위 판단 기준 표에서 줄을 찾아, 이번에 고칠 URL과 다음에 고칠 URL을 나눕니다.
- 옛 규칙의 대상만 최종 URL로 고쳐 씁니다. A에서 B, B에서 C였다면 A에서 C, B에서 C로 둡니다.
- 중간 URL(B)의 규칙도 지우지 않고 남깁니다. B로 걸린 링크와 검색 결과가 아직 있을 수 있습니다.
- 내부 링크, 사이트맵, 캐노니컬 태그가 최종 URL만 가리키게 바꿉니다.
- 다시 재서 옛 URL마다 따라간 횟수가 1인지, 최종 URL이 200으로 열리는지 확인합니다.
조사 방법
- Google Search Central 「How to move a site」 (문서 수정일 2026-08-20) · 최종 확인일 2026-10-25 · https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
- 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
- Chrome for Developers 「Avoid multiple page redirects」 (문서 수정일 2019-05-04) · 최종 확인일 2026-10-25 · https://developer.chrome.com/docs/lighthouse/performance/redirects
- 네이버 서치어드바이저 「웹 페이지의 이동」 · 최종 확인일 2026-10-18 · https://searchadvisor.naver.com/guide/seo-basic-redirect
- 판단 기준 6단계는 위 문서들이 적은 횟수(구글 크롤러 한도, 구글이 바란 상한과 미만, 네이버 권장, Lighthouse 실패 기준)를 따라간 횟수 순으로 묶은 것입니다. 묶는 방식은 편집 판단입니다.
- Lighthouse 문서는 2019-05-04 수정본이며, 문서 머리에 Lighthouse 13 부터 다른 항목으로 옮겼다는 안내가 있습니다.
- 예시 ①②③은 이해를 돕기 위해 만든 가상 상황이며, 실제 기업·기관의 사례가 아닙니다.
- 원문은 영어판(hl=en)이고, 도구·보고서 이름은 같은 문서 한국어판(hl=ko) 표기를 따랐습니다.