Google Search Console 리디렉션 오류: 원인과 해결 방법

Search Console의 리디렉션 오류란?

리디렉션 오류는 Google Search Console 페이지 색인 생성 보고서의 페이지가 색인이 생성되지 않는 이유 표에 나오는 사유 중 하나입니다. Googlebot이 URL의 리디렉션을 따라갔지만 크롤링할 수 있는 대상에 끝내 도달하지 못했을 때 표시되며, 이 경로로는 원래 URL도 대상 URL도 색인되지 않습니다.

"리디렉션이 포함된 페이지"와 혼동하기 쉬우니 분명히 짚고 넘어가겠습니다. 이 상태는 정상입니다. 리디렉션이 작동했다는 뜻으로, URL이 다른 곳을 가리키기 때문에 색인되지 않은 것이며 Google은 대상 페이지를 따로 평가합니다. 반면 리디렉션 오류는 리디렉션 자체가 실패했다는 뜻입니다.

이 상태는 색인 생성 › 페이지에서 확인할 수 있습니다. "리디렉션 오류" 행을 클릭하면 영향을 받는 URL이 표시되고, 내보내기로 전체 목록을 다운로드할 수 있습니다.

리디렉션 오류의 일반적인 원인

Google의 페이지 색인 생성 보고서 문서에는 이 상태의 원인이 되는 네 가지 상황이 나와 있습니다. 실무에서는 두 가지가 더 자주 보입니다.

1. 너무 긴 리디렉션 체인

다른 URL로 리디렉션되는 URL이 하나 생길 때마다 홉이 하나씩 늘어납니다. Google의 크롤링 문서에 따르면 Google 크롤러는 최대 10번의 리디렉션 홉을 따라갑니다. 이를 넘으면 Googlebot은 추적을 포기하고 Search Console에 리디렉션 오류가 표시됩니다. 체인은 보통 시간이 지나면서 길어집니다. HTTP에서 HTTPS로 보내는 규칙, 그다음 www 규칙, 그다음 후행 슬래시 규칙, 그 위에 사이트 이전까지 더해지는 식입니다.

2. 리디렉션 루프

URL A가 URL B로 리디렉션되고, URL B가 다시 URL A(또는 A로 돌아가는 어떤 URL)로 리디렉션됩니다. 체인이 끝나지 않으므로 어떤 페이지에도 도달하지 못합니다. 루프는 후행 슬래시를 강제로 붙이는 규칙과 이를 제거하는 규칙처럼 서로 모순되는 두 규칙에서 생기는 경우가 많습니다.

3. 최대 길이를 초과하는 리디렉션 URL

리디렉션 규칙이 홉마다 매개변수나 경로 세그먼트 같은 것을 URL에 계속 덧붙이면, 주소가 점점 길어져 URL 최대 길이를 넘게 되고 체인이 실패합니다.

4. 체인 안의 잘못되었거나 비어 있는 URL

http:// 대신 htp://로 쓴 오타, 엉뚱한 위치로 해석되는 상대 경로, 비어 있는 Location 헤더가 있으면 해당 홉에서 리디렉션이 끊깁니다.

5. Google이 크롤링할 수 없는 대상

최종 URL이 robots.txt로 차단되어 있으면 Googlebot은 해당 페이지를 가져올 수 없습니다. 모든 리디렉션의 대상이 존재하는지뿐 아니라 크롤링 가능한지도 확인하세요.

6. 여러 곳에서 충돌하는 리디렉션 규칙

CMS, 플러그인, 웹 서버, CDN에 설정한 리디렉션은 서로 겹치거나 충돌할 수 있습니다. 한 계층에 추가한 규칙이 URL을 다른 계층의 규칙으로 되돌려 보낼 수 있으며, 대부분의 체인과 루프는 이렇게 생겨납니다.

리디렉션 오류를 진단하는 방법

Search Console이 표시한 URL에서 시작해, 각 URL을 요청했을 때 무슨 일이 일어나는지 추적하세요.

URL 검사 사용하기

영향을 받는 URL을 Search Console 상단의 검사창에 붙여 넣습니다. 페이지 색인 생성 섹션에서 Google이 마지막으로 크롤링한 시점과 페이지 가져오기의 성공 여부를 확인할 수 있습니다. 보고서는 수정 사항을 늦게 반영할 수 있으므로 실제 URL 테스트를 클릭해 현재 동작을 확인하세요.

리디렉션 경로 전체 추적하기

URL을 요청하고 모든 홉을 따라가 보세요. 터미널에서는 다음과 같이 실행합니다.

curl -sIL https://example.com/old-page | grep -iE "^(HTTP|location)"

출력에는 각 상태 코드와 Location 헤더가 순서대로 나열됩니다. 홉이 두 개 이상인지, 같은 URL이 두 번 나오는지(루프), Location 형식이 잘못되었는지, 마지막 응답이 200이 아닌지 확인하세요.

터미널을 쓰고 싶지 않다면 SEOcrawl AI Crawler 페이지의 무료 SEO 감사로 어떤 URL이든 리디렉션 홉 수를 확인할 수 있습니다. 또한 SEOcrawl AI MCP 서버의 fetch_url 도구는 최종 URL, 상태 코드, 전체 리디렉션 체인을 Claude, ChatGPT, Cursor에서 바로 반환합니다.

최종 응답 코드 확인하기

경로의 마지막 URL이 또 다른 3xx나 4xx, 5xx가 아니라 200을 반환하는지 확인하세요. 체인이 오류로 끝난다면 문제는 대상 페이지에 있습니다. 찾을 수 없음(404) 및 기타 4xx 문제로 인해 차단됨 가이드를 참고하세요.

원인별 해결 방법

해결의 핵심은 거의 언제나 같습니다. 원래 URL을 깔끔한 한 번의 홉으로 최종 대상에 보내는 것입니다.

• ›체인이 너무 긺: 첫 URL이 200을 반환하는 최종 URL을 바로 가리키게 하고 중간 홉을 제거하세요. 여러 이전 URL이 같은 체인으로 이어진다면 모두 업데이트해야 합니다.
• ›리디렉션 루프: 서로를 가리키는 두 규칙을 찾아 하나를 삭제하거나 수정해서, 경로가 실제 페이지에서 끝나도록 하세요.
• ›URL이 너무 긺: URL에 계속 덧붙이는 규칙을 수정한 다음, 대상 페이지가 로드되는지 확인하세요.
• ›대상이 잘못되었거나 비어 있음: 오타나 비어 있는 Location 값을 수정하고 절대 URL을 사용하세요.
• ›대상이 robots.txt로 차단됨: 대상 페이지의 크롤링을 허용하거나, 차단되지 않은 URL로 리디렉션하세요.
• ›규칙 충돌: 리디렉션을 한곳에서 관리해 CMS, 서버, CDN이 서로 덮어쓰지 않게 하세요.

그다음 내부 링크를 업데이트해 리디렉션되는 URL이 아니라 최종 URL을 가리키게 하고, XML 사이트맵에도 최종 URL만 넣으세요. Crawler는 3xx를 반환하는 내부 링크와 리디렉션되는 URL이 포함된 사이트맵, 두 경우를 모두 사이트 전체에서 찾아냅니다. 사이트맵만 따로 확인하려면 무료 사이트맵 검사기를 사용하세요. 사이트맵에 포함된 모든 URL의 상태 코드와 리디렉션 체인을 검증해 줍니다.

리디렉션 모범 사례

몇 가지 습관만 지켜도 대부분의 리디렉션 오류는 미리 막을 수 있습니다.

• ›올바른 상태 코드를 사용하세요. 301 리디렉션(또는 308)은 대상 페이지를 색인해야 한다는 강한 신호이므로 영구 이전에 사용하세요. 302 리디렉션(또는 307)은 원래 URL을 검색 결과에 남기는 약한 신호이므로 일시적인 이전에만 사용하세요.
• ›서버 측 리디렉션을 우선하세요. Google은 즉시 실행되는 meta refresh와 JavaScript 리디렉션도 따라가지만, JavaScript는 서버 측 리디렉션이나 meta refresh를 사용할 수 없을 때만 쓰라고 권장합니다.
• ›체인을 짧게 유지하세요. 한 번의 홉이 가장 좋습니다. 홉이 하나 늘 때마다 사용자의 대기 시간이 길어지고, 크롤링 예산이 소모되며, 실패 지점이 하나 더 생깁니다.
• ›항상 200을 반환하는 URL로 리디렉션하고, 또 다른 리디렉션으로 보내지 마세요.
• ›내부 링크와 사이트맵을 최종 URL로 업데이트해, Google과 방문자가 리디렉션을 아예 거치지 않게 하세요.
• ›사이트 이전이나 CMS, 서버, CDN 규칙을 변경할 때마다 다시 확인하세요. 새로운 체인과 루프는 바로 그때 생깁니다.

수정 사항 검증 방법

리디렉션이 한 번의 홉으로 200 페이지에 도달하게 되면 다음을 진행하세요.

1. ›영향을 받는 URL에 URL 검사를 실행하고 실제 URL 테스트를 클릭해 Google이 이제 대상 페이지에 도달하는지 확인합니다.
2. ›가장 중요한 URL은 색인 생성 요청을 클릭합니다.
3. ›페이지 색인 생성 보고서에서 리디렉션 오류 문제를 열고 수정 결과 확인을 클릭해 Google이 영향을 받는 모든 URL을 다시 크롤링하도록 합니다.
4. ›검증 상태를 지켜보세요. 며칠에서 2주 정도 걸릴 수 있으며, URL은 다시 크롤링되는 대로 문제 목록에서 빠집니다.

리디렉션 오류를 미리 잡아내세요

리디렉션 오류는 스스로 존재를 알리지 않습니다. 페이지 색인 생성 보고서에 나타날 뿐이고, 규모가 큰 사이트에서는 트래픽이 떨어질 때까지 아무도 모르고 지나칠 수 있습니다. 모든 속성의 Search Console을 직접 확인하는 일은 시간이 많이 들고 건너뛰기 쉽습니다.

SEOcrawl AI의 Indexation 보기는 URL을 Search Console 커버리지 상태별로 묶어 보여주므로, 어떤 URL이 오류 상태에 있는지 확인하고 그 수가 시간에 따라 어떻게 변하는지 추적할 수 있습니다. 영향을 받는 URL에는 규칙이나 수동으로, 또는 MCP 서버를 통해 태그를 붙이고, 하나씩 해결될 때까지 처리할 수 있습니다. AI 어시스턴트와 함께 일한다면 Google Search Console 감사로 프롬프트 하나만으로 색인 커버리지를 점검하고, 수정할 항목마다 작업을 만들 수 있습니다.

자주 묻는 질문

Google Search Console에서 리디렉션 오류가 발생하는 원인은 무엇인가요?

Google은 네 가지 원인을 제시합니다. 너무 긴 리디렉션 체인, 리디렉션 루프, 결국 URL 최대 길이를 초과하는 리디렉션 URL, 체인 안의 잘못되었거나 비어 있는 URL입니다. 어느 경우든 Googlebot은 정상적으로 작동하는 최종 페이지에 도달하지 못합니다.

리디렉션 오류는 어떻게 해결하나요?

원래 URL을 한 번의 홉으로 최종 대상에 보내세요. 중간 리디렉션을 제거하고, 루프를 끊고, 마지막 URL이 200 상태를 반환하는지 확인합니다. 내부 링크가 최종 대상을 가리키도록 업데이트한 다음, URL 검사를 실행하고 페이지 색인 생성 보고서에서 수정 결과 확인을 클릭하세요.

리디렉션 체인과 리디렉션 루프는 무엇인가요?

리디렉션 체인은 URL A가 B로, B가 C로 이동하는 식으로 최종 페이지에 도달하기 전까지 리디렉션이 연속되는 것입니다. 리디렉션 루프는 URL끼리 서로를 가리키기 때문에 끝나지 않는 체인입니다. 둘 다 Google이 색인할 페이지에 도달하지 못하게 만들 수 있습니다.

301과 302 중 무엇을 사용해야 하나요?

영구 이전에는 301(또는 308)을 사용하세요. Google은 이를 대상 페이지를 색인하라는 강한 신호로 받아들입니다. 302(또는 307)는 일시적인 이전에만 사용하세요. 원래 URL을 검색 결과에 남겨 두고 싶을 때입니다.

'리디렉션이 포함된 페이지'와 리디렉션 오류는 같은 것인가요?

아니요. '리디렉션이 포함된 페이지'는 리디렉션이 제대로 작동했다는 뜻입니다. 해당 URL은 다른 페이지를 가리키기 때문에 색인되지 않은 것입니다. 리디렉션 오류는 Google이 리디렉션을 따라가려 했지만 정상적인 페이지에 끝내 도달하지 못했다는 뜻입니다.

리디렉션 오류가 해결되기까지 얼마나 걸리나요?

수정 결과 확인을 클릭하면 Google이 이후 며칠, 길게는 최대 2주에 걸쳐 영향을 받는 URL을 다시 크롤링합니다. 각 URL이 처리될 때마다 상태가 업데이트되므로 모든 URL에 대해 직접 색인 생성을 요청할 필요는 없습니다.