Search Console 리디렉션이 포함된 페이지: 숨은 문제 찾기

Search Console의 '리디렉션이 포함된 페이지'(Page with redirect)는 Google이 어떤 URL을 요청했는데 서버가 다른 곳으로 보냈고, 그래서 Google이 목록에 보이는 URL 대신 도착 URL을 색인 후보로 본다는 뜻입니다. 대부분은 HTTPS 전환, www 사용 여부 결정, URL 변경 뒤에 설정한 리디렉션이 의도대로 작동하고 있는 것입니다. 문제가 되는 것은 도착 페이지가 잘못되었거나 색인이 생성되지 않았을 때, 또는 귀하의 사이트맵, 링크, 표준 태그가 계속 Google을 이전 주소로 보낼 때입니다.

Google이 설명하는 이 상태의 의미

Google의 페이지 색인 생성 보고서 문서(2026년 10월 확인)는 이 상태를 "다른 페이지로 리디렉션되는 표준이 아닌 URL"로 설명하고, 이 URL은 "색인이 생성되지 않는다"고 덧붙이며, 대상 URL은 "Google이 그 대상 URL을 어떻게 판단하느냐에 따라 색인이 생성될 수도 있고 생성되지 않을 수도 있다"고 말합니다.

이 설명에서 두 가지가 따라 나옵니다.

• 이 상태는 출발 URL에 관한 것이며, 도착 URL에 관한 것이 아닙니다. 목록에 http://example.com/pricing이 보인다고 해서 https://www.example.com/pricing의 색인 생성 여부를 알 수 있는 것은 아닙니다. 도착 URL은 따로 확인해야 합니다.
• 리디렉션 유형이 중요합니다. Google의 리디렉션 문서(2026년 10월 확인)는 리디렉션을 2개 그룹으로 나눕니다. 영구 리디렉션(HTTP 301 및 308, 0초로 설정한 메타 새로고침 또는 HTTP 새로고침, JavaScript location 리디렉션)은 대상이 표준 URL이어야 한다는 신호로 사용되며, 검색결과에는 대상 URL이 표시됩니다. 임시 리디렉션(302, 303, 307, 지연된 메타 새로고침 또는 HTTP 새로고침)은 따라가기는 하지만 그 신호로는 사용되지 않으므로, 검색결과에는 출발 URL이 표시됩니다. JavaScript 리디렉션은 Google이 페이지를 성공적으로 렌더링한 경우에만 인식됩니다.

이 상태는 '리디렉션 오류'와 다릅니다. '리디렉션 오류'는 Google이 끝까지 따라가지 못한 리디렉션, 즉 루프, 너무 긴 체인, 최대 URL 길이를 초과한 리디렉션 URL, 체인 안의 잘못되었거나 비어 있는 URL에 사용됩니다.

리디렉션되는 URL은 어디서 생기는가

정상적인 사이트라면 이 목록에 있는 URL 대부분은 다음과 같은 정상적인 원인에서 나옵니다.

1. 프로토콜 및 호스트 정규화. http://에서 https://로, 루트 도메인에서 www로 또는 그 반대로 보내는 경우입니다.
2. 후행 슬래시 정규화. 플랫폼이나 서버 기본값에 따라 /blog에서 /blog/로 보내는 경우입니다.
3. 이전(마이그레이션) 및 URL 변경. 새 도메인, 새 경로 체계, 이름이 바뀐 제품 등입니다. 예를 들어 WordPress는 글의 슬러그를 수정하면 이전 슬러그에서 새 고유주소로 301을 보냅니다.
4. 후속 페이지로 통합된 폐기 페이지. 오래된 가이드를 새 가이드에 합친 경우입니다.

문제가 되는 패턴은 모두 귀하의 사이트가 스스로 만드는 것입니다.

1. 사이트맵에 리디렉션되는 URL이 들어 있습니다. 2026년 5월부터 10월 사이에 SEOReport가 사이트맵 페이지를 가져온 외부 웹사이트 29곳 중 6곳(21%)이 XML 사이트맵에 다른 곳으로 리디렉션되는 URL을 넣어 두었습니다.
2. 내부 링크, 표준 태그, hreflang 주석이 이전 URL을 가리킵니다. 내비게이션 템플릿, 본문의 오래된 링크, http://로 하드코딩된 표준 태그가 계속 Google에 리디렉션되는 주소를 알려 줍니다.
3. 리디렉션이 엉뚱한 곳으로 갑니다. Google의 사이트 이전 가이드(2026년 10월 확인)는 오래된 URL 여러 개를 홈페이지처럼 관련 없는 페이지 하나로 리디렉션하면 "Soft 404 오류로 처리될 수 있다"고 경고합니다.
4. 리디렉션이 체인으로 이어지거나, 영구여야 할 리디렉션이 임시입니다. 도착 페이지까지 여러 번 거쳐야 하거나, 되돌릴 일이 없는 이전 후에도 302를 그대로 둔 경우입니다.

이 표본에서는 3가지 엇갈린 신호 중 리디렉션이 가장 흔했습니다. 이런 항목 하나하나가, 이미 진짜 URL이 아니라고 Google에 알려 준 URL을 색인해 달라고 요청하는 셈입니다.

문제인가요? 그대로 둘지, 수정할지, 지켜볼지

flowchart TD
    A["리디렉션이 포함된 페이지로 표시된 URL"] --> B{"의도한 리디렉션인가요?"}
    B -->|아니요| C["리디렉션을 제거하거나 페이지를 복원"]
    B -->|예| D{"도착 페이지가 올바른 대체 페이지인가요?"}
    D -->|아니요| E["가장 가까운 대응 페이지로 리디렉션하거나 404 또는 410 반환"]
    D -->|예| F{"한 번에 가는 영구 리디렉션인가요?"}
    F -->|아니요| G["301 또는 308 하나로 합치기"]
    F -->|예| H{"사이트맵, 링크, 표준 태그가 이전 URL을 가리키나요?"}
    G --> H
    H -->|예| I["모든 참조를 최종 URL로 업데이트"]
    H -->|아니요| J{"도착 페이지의 색인이 생성되었나요?"}
    I --> J
    J -->|예| K["그대로 둠"]
    J -->|아니요| L["도착 페이지의 자체 상태 확인"]

어떤 원인인지 확인하는 방법

사이트맵 필터부터 확인합니다. 페이지 색인 생성 보고서 상단의 필터를 '알려진 모든 페이지'에서 '제출된 모든 페이지'로 바꾸고 '리디렉션이 포함된 페이지'를 다시 엽니다. 여기에 남아 있는 URL은 귀하의 사이트맵 중 하나가 제출한, 리디렉션되는 URL입니다. 예시 표는 1,000행까지만 표시되므로, 규모가 큰 사이트라면 아래 방법으로 사이트맵도 직접 테스트하십시오.

URL 몇 개를 검사합니다. Google의 URL 검사 문서에 따르면 색인 생성 결과는 리디렉션 대상이 아니라 입력한 URL 자체에 대한 것입니다. 문제의 출처를 알려 주는 필드는 2개입니다. '참조 페이지'는 Google이 그 URL을 발견하는 데 사용했을 수 있는 페이지를, '사이트맵'은 그 URL이 들어 있는 사이트맵을 보여 줍니다. 참조 페이지가 귀하의 사이트에 있다면 수정해야 할 내부 링크가 있는 것입니다. 다른 사이트에 있다면 리디렉션은 제 역할을 하고 있습니다.

리디렉션 경로를 직접 추적합니다. 같은 문서에 따르면 실시간 테스트('실시간 URL 테스트')는 별도 안내 없이 리디렉션을 따라가며, 실제로 테스트한 최종 URL을 표시하지 않습니다. 터미널에서는 모든 단계를 볼 수 있습니다.

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

301 또는 308 하나 뒤에 200 하나가 오면 깔끔한 리디렉션입니다. 리디렉션 줄이 두 개 이상이면 체인이며, 영구 이전인데 302나 307을 쓰고 있다면 바꿔야 합니다.

도착 URL은 따로 검사합니다. 최종 URL을 URL 검사에 붙여 넣습니다. 색인이 생성되지 않았다면 문제는 그 페이지에 있으며, 그 페이지의 상태가 어디를 봐야 할지 알려 줍니다. 도착 페이지에 noindex가 있다면 URL이 'NOINDEX'로 표시됨에서, Google이 가져갔지만 색인하지 않았다면 크롤링됨 - 현재 색인이 생성되지 않음에서 다룹니다.

내 파일 중 어디에 아직 이전 URL이 남아 있는지 찾기

Search Console은 발견 경로의 일부 표본만 보여 줍니다. 귀하의 파일에는 전부가 들어 있습니다. 사이트맵에 있는 모든 URL을 테스트해서 200으로 응답하지 않는 URL을 출력합니다.

curl -s https://www.example.com/sitemap.xml \
  | grep -o '<loc>[^<]*</loc>' | sed -e 's/<loc>//' -e 's/<\/loc>//' -e 's/&amp;/\&/g' \
  | while read -r url; do
      code=$(curl -s -o /dev/null -w '%{http_code}' "$url")
      [ "$code" != "200" ] && echo "$code $url"
    done

출력에 301, 302, 307, 308이 있으면 리디렉션되는 항목입니다. 파일이 사이트맵 색인 파일이라면 그 안에 나열된 하위 사이트맵마다 같은 반복문을 실행하고, .xml.gz 파일은 먼저 압축을 풉니다. 그다음 모든 페이지가 공유하는 템플릿을 확인합니다. 헤더 링크 하나가 모든 URL에서 반복되기 때문입니다.

curl -s https://www.example.com/ \
  | grep -oE '(href|content)="[^"]+"' \
  | grep -E 'http://|//example\.com'

마지막 패턴은 귀하가 떠나 온 이전 프로토콜, 호스트, 경로로 바꾸십시오. WordPress에서는 오래된 절대 URL이 대개 글 본문에 남아 있으며, WP-CLI로 변경 전에 개수를 셀 수 있습니다.

wp search-replace 'http://example.com' 'https://www.example.com' --dry-run

실제로 실행할 때는 먼저 데이터베이스를 백업하고 --skip-columns=guid를 추가해 글의 GUID가 원래 값을 유지하도록 하십시오.

원인별 해결 방법

사이트맵 항목. 최종 URL만으로 사이트맵을 다시 생성합니다. 각 항목은 200으로 응답하고 자기 자신을 표준 URL로 선언해야 합니다. Google의 사이트맵 문서(2026년 10월 확인)는 검색결과에 표시되기를 원하는 URL을 넣으라고 하는데, 리디렉션되는 URL은 여기에 해당하지 않습니다. Google의 표준화 문서는 사이트맵에 나열된 모든 페이지가 표준 URL 후보로 제안된다고 덧붙입니다. 깔끔한 사이트맵의 나머지 조건은 XML 사이트맵 가이드에서 다룹니다.

내부 링크, 표준 태그, hreflang. 도착 URL로 업데이트합니다. Google의 표준화 문서(2026년 10월 확인)는 중복 URL이 아니라 표준 URL로 링크하라고 권장하며, 리디렉션되는 URL을 가리키는 표준 태그는 페이지가 없는 주소로 신호를 모아 달라고 Google에 요청하는 것과 같습니다. 이 신호들이 어떻게 합쳐지는지는 표준 태그 가이드에서, 호스트와 프로토콜 변형이 아예 리디렉션되지 않는 경우는 사용자가 선택한 표준이 없는 중복 페이지에서 설명합니다.

잘못된 도착 페이지. 오래된 URL마다 가장 가까운 대응 페이지로 연결합니다. 후속 페이지가 없다면 404나 410이 정직한 응답이며, Google이 관련 없는 페이지로의 리디렉션에 대해 설명하는 Soft 404 처리도 피할 수 있습니다.

체인과 임시 리디렉션. 진입 URL에서 최종 URL로 곧장 가는 규칙 하나를 301 또는 308로 작성합니다. 리디렉션 체인: 생기는 이유와 정리하는 방법은 4단계 예시로 설명하고, 리디렉션 및 URL 정규화 가이드는 프로토콜, 호스트, 슬래시 규칙을 함께 다룹니다.

리디렉션 자체는 유지합니다. Google의 사이트 이전 가이드는 리디렉션을 가능한 한 오래, 일반적으로 최소 1년 동안 유지하라고 권장합니다. 귀하의 사이트 내부 참조를 모두 정리한 뒤에도 외부 링크와 북마크는 오랫동안 이전 URL로 들어옵니다.

수정 결과를 확인하는 방법

1. 사이트맵 반복문을 다시 실행합니다. 아무것도 출력되지 않아야 합니다.
2. 이전 URL 몇 개로 추적을 다시 실행합니다. 영구 리디렉션 한 번 뒤에 200이 오고, 올바른 페이지에 도착해야 합니다.
3. 사이트맵을 다시 제출합니다. Search Console의 Sitemaps 보고서에서 Google에 다시 읽어 달라고 요청합니다.
4. '제출된 모든 페이지' 필터를 지켜봅니다. Google이 사이트맵을 다시 읽고 해당 URL을 다시 크롤링하면 리디렉션되는 URL이 이 필터에서 빠져야 합니다. Google의 재크롤링 문서에 따르면 크롤링에는 며칠에서 몇 주가 걸릴 수 있으며, 일정은 귀하가 아니라 Google이 정합니다.
5. '수정 결과 확인'은 제거한 리디렉션에만 사용합니다. 확인 절차는 영향을 받은 URL을 다시 크롤링해 각 URL에 문제가 남아 있는지 검사하는데, 의도한 리디렉션은 설계상 계속 리디렉션됩니다. Google 문서에 따르면 확인에는 보통 최대 약 2주가 걸리며, 경우에 따라 훨씬 더 오래 걸립니다.

Search Console은 어떤 URL이 리디렉션되는지 알려 줍니다. SEOReport 전체 진단은 사이트 자체를 감사해, 외부에 알리지 말아야 할 리디렉션을 짚어 냅니다. 사이트맵에 나열된 페이지 중 리디렉션되는 URL과 각각의 도착 URL, 리디렉션되는 홈페이지 표준 URL 대상이나 대체 언어 대상, 그리고 제출한 주소가 여러 번 거쳐 갈 때의 모든 단계가 포함됩니다. 내부 링크의 리디렉션은 테스트하지 않으므로, 내부 링크는 위의 템플릿 확인 방법으로 점검하십시오.

자주 묻는 질문

리디렉션되는 URL은 언젠가 보고서에서 사라지나요?

'알려진 모든 페이지' 보기에는 오랫동안 남아 있을 수 있습니다. Google은 다른 사이트가 링크하는 URL을 포함해 이미 알고 있는 URL을 계속 다시 크롤링하기 때문입니다. 리디렉션이 의도된 것이고 도착 페이지의 색인이 생성되어 있다면 이것이 올바른 최종 상태입니다. 줄어들어야 하는 것은 귀하의 사이트맵이 제출하는 그런 URL의 수입니다.

홈페이지가 '리디렉션이 포함된 페이지'로 표시됩니다. 문제인가요?

대개 목록에 있는 URL은 http://example.com/ 같은 변형이며, 선호하는 https://www.example.com/으로 리디렉션됩니다. 선호하는 홈페이지 URL을 검사해 보십시오. 색인이 생성되어 있다면 변형은 올바르게 동작하고 있습니다. 선호하는 URL 자체가 목록에 나타난다면 홈페이지가 의도하지 않은 곳으로 리디렉션되고 있는 것이므로 수정해야 합니다.

리디렉션 대신 표준 태그를 써야 하나요?

이전 URL이 더 이상 누구에게도 자체 페이지를 보여 주지 않아야 한다면 리디렉션을 사용합니다. 같은 제품 목록의 필터링된 보기처럼 두 URL이 모두 계속 작동해야 한다면 표준 태그를 사용합니다. 계속 접속 가능하면서 표준 태그로 다른 URL을 가리키는 URL은, Google이 그 표준 URL을 받아들이면 대개 '적절한 표준 태그가 포함된 대체 페이지'로 보고되며 조치가 필요 없습니다.