리디렉션이 있는 페이지가 색인되지 않는 것은 반드시 오류가 아닙니다. 검색엔진은 원본 URL 대신 최종 도착 URL을 색인하려고 하므로, 먼저 어떤 URL을 노출하려는지부터 분명히 해야 합니다.
📌 핵심 5줄 요약
1. 원본 URL이 리디렉션되면 원본 주소는 검색 결과에서 제외될 수 있습니다.
2. 영구 이동은 일반적으로 301, 임시 이동은 302를 목적에 맞게 사용합니다.
3. 최종 도착 URL에 noindex, robots.txt 차단, 오류 상태 코드가 있으면 색인이 어렵습니다.
4. 리디렉션이 여러 번 이어지거나 서로 되돌아가는 구조는 크롤링을 방해합니다.
5. 최종 URL을 내부 링크와 사이트맵에 직접 연결한 뒤 URL 검사를 다시 진행해야 합니다.
📌 목차
01 | 리디렉션 페이지가 색인되지 않는 기본 원리
02 | 원본 URL과 최종 URL의 차이
03 | 301과 302 리디렉션 구분
04 | 최종 URL에 noindex가 있는 경우
05 | robots.txt 차단 확인
06 | 리디렉션 체인과 루프
07 | 최종 페이지의 상태 코드 점검
08 | 캐노니컬 설정 문제
09 | 내부 링크와 사이트맵 수정
10 | 자바스크립트 리디렉션 주의점
11 | 모바일·프로토콜·도메인 이동 점검
12 | 실제 점검 사례
13 | 해결 절차와 재요청 방법
14 | 색인 문제를 예방하는 관리 기준
01 | 리디렉션 페이지가 색인되지 않는 기본 원리
리디렉션은 방문자나 검색엔진을 한 URL에서 다른 URL로 이동시키는 설정입니다. 원본 URL에 301 또는 302 응답이 반환되면 검색엔진은 원본을 완성된 콘텐츠 페이지로 보기보다 이동 안내 주소로 해석할 수 있습니다.
따라서 “리디렉션된 URL이 색인되지 않음”이라는 상태는 원본 URL이 누락됐다는 뜻이 아니라, 최종 URL을 색인 대상으로 선택했다는 의미일 수 있습니다.
02 | 원본 URL과 최종 URL의 차이
예를 들어 /old-page가 /new-page로 이동한다면 색인 여부를 확인해야 할 대상은 대체로 /new-page입니다. /old-page가 검색 결과에 계속 남아 있기를 기대한다면 리디렉션 설정 자체가 목적과 맞지 않을 수 있습니다.
최종 URL이 정상적으로 열리고 독립적인 콘텐츠를 제공한다면, 원본 URL보다 최종 URL의 색인 상태와 대표 URL 지정 여부를 우선 확인해야 합니다.
03 | 301과 302 리디렉션 구분
301 리디렉션은 페이지가 영구적으로 이동했을 때 사용합니다. 주소 변경, 도메인 통합, HTTP에서 HTTPS로의 전환처럼 이전 주소를 장기간 사용하지 않을 때 적합합니다.
302 리디렉션은 일시적인 이동을 나타냅니다. 테스트나 기간성 안내에 사용할 수 있지만, 영구 이동인데 302를 계속 사용하면 검색엔진이 최종 URL을 대표 주소로 확정하는 데 시간이 더 걸릴 수 있습니다.
다만 상태 코드만 바꾸면 해결되는 것은 아닙니다. 최종 URL의 콘텐츠와 색인 지시 설정도 함께 확인해야 합니다.
04 | 최종 URL에 noindex가 있는 경우
원본 URL이 정상적으로 최종 페이지로 이동하더라도, 최종 페이지의 HTML에 noindex가 있으면 검색엔진에 색인하지 말라는 지시가 전달됩니다. 이 경우 원본 리디렉션만 수정해서는 색인이 되지 않습니다.
페이지 소스나 SEO 설정 화면에서 최종 URL의 robots 메타 태그를 확인하세요. 전체 사이트에 적용된 설정, 특정 글 유형에만 적용된 설정, 테스트용 플러그인 설정이 원인일 수 있습니다.
05 | robots.txt 차단 확인
robots.txt에서 최종 URL 경로의 크롤링을 차단하면 검색엔진이 페이지 내용을 충분히 확인하지 못할 수 있습니다. 특히 새 사이트를 공개하는 과정에서 관리자용 폴더나 개발용 경로를 막은 규칙이 실제 게시물 경로까지 포함하는 경우가 있습니다.
robots.txt는 크롤링 허용 여부를 제어하는 파일이지, 일반적인 색인 제거용 설정과 완전히 같은 기능은 아닙니다. 최종 URL이 차단되어 있는지와 페이지의 noindex 설정을 따로 확인해야 합니다.
06 | 리디렉션 체인과 루프
리디렉션 체인은 A에서 B로 이동한 뒤 다시 C로 이동하는 구조입니다. 한 번의 이동으로 최종 URL에 도착하도록 정리하는 것이 좋습니다. 이동 단계가 길어지면 크롤링 효율이 떨어지고 중간 주소의 설정이 서로 충돌할 수 있습니다.
리디렉션 루프는 A가 B로 이동하고 B가 다시 A로 돌아가는 구조입니다. 브라우저에서 페이지가 열리지 않거나 반복 이동 오류가 발생하며, 검색엔진도 최종 페이지를 확인할 수 없습니다.
HTTP와 HTTPS, www와 비www, 슬래시 유무를 각각 강제로 변환하는 규칙이 겹칠 때 체인이나 루프가 자주 생깁니다.
07 | 최종 페이지의 상태 코드 점검
최종 URL은 일반적으로 정상적인 성공 응답을 반환해야 합니다. 최종 도착 후 다시 404, 403, 서버 오류 등으로 끝난다면 검색엔진은 해당 페이지를 안정적인 색인 대상으로 보기 어렵습니다.
브라우저에서 보이는 화면만으로는 상태 코드를 정확히 판단하기 어렵습니다. 브라우저 개발자 도구, 서버 로그, SEO 점검 도구 등으로 다음 흐름을 확인하세요.
원본 URL → 리디렉션 상태 코드 → 최종 URL → 최종 상태 코드
08 | 캐노니컬 설정 문제
최종 페이지의 canonical이 다른 URL을 가리키면 검색엔진은 현재 페이지보다 다른 주소를 대표 URL로 선택할 수 있습니다. 리디렉션 목적지와 canonical 주소가 서로 다르면 색인 대상 판단이 복잡해집니다.
최종 페이지는 일반적으로 자기 자신을 대표 URL로 지정하거나, 실제로 같은 콘텐츠를 대표하는 하나의 주소를 일관되게 가리키도록 구성합니다. http와 https, 매개변수 포함 주소, 슬래시 유무도 일관성을 유지해야 합니다.
09 | 내부 링크와 사이트맵 수정
오래된 URL이 사이트 내부 링크와 XML 사이트맵에 계속 남아 있으면 검색엔진이 불필요한 리디렉션을 반복해서 따라갈 수 있습니다. 링크와 사이트맵에는 가능하면 리디렉션 원본이 아니라 최종 URL을 직접 넣어야 합니다.
메뉴, 본문 링크, 관련 글 영역, 이미지 링크, 구조화 데이터 안의 URL까지 함께 확인하세요. 외부 링크는 즉시 바꾸기 어려워도 사이트 내부 신호부터 최종 주소로 통일하는 것이 좋습니다.
10 | 자바스크립트 리디렉션 주의점
서버가 HTTP 응답으로 처리하는 리디렉션보다 자바스크립트나 메타 새로고침에 의존하는 이동은 검색엔진이 해석하는 방식과 시점이 달라질 수 있습니다. 추적 코드나 사용자 조건에 따라 주소가 바뀌는 구조도 색인 확인을 어렵게 합니다.
가능하다면 서버에서 명확한 리디렉션 응답을 반환하고, 검색엔진과 일반 사용자가 동일한 최종 URL에 도달하도록 구성하세요.
11 | 모바일·프로토콜·도메인 이동 점검
모바일 주소와 데스크톱 주소가 다르거나, HTTP·HTTPS와 도메인 주소가 여러 규칙으로 나뉘면 리디렉션 문제가 발생하기 쉽습니다. 모든 변형 주소가 하나의 정식 URL로 이동하는지 확인해야 합니다.
특히 개발 서버 주소, 임시 도메인, 이전 도메인이 내부 링크에 남아 있으면 새 주소의 색인 신호가 분산될 수 있습니다. 정식 도메인과 프로토콜을 정한 뒤 링크와 canonical, 사이트맵을 같은 기준으로 맞추세요.
12 | 실제 점검 사례
예를 들어 이전 글 주소가 새 글 주소로 301 이동하지만, 새 글에는 noindex가 설정되어 있고 사이트맵에는 이전 주소가 남아 있다고 가정해 보겠습니다. 이때 원본 URL이 색인되지 않는 것은 301 자체보다 최종 URL의 noindex와 잘못된 사이트맵이 함께 작용한 결과일 수 있습니다.
해결하려면 새 글의 noindex를 목적에 맞게 수정하고, 사이트맵과 내부 링크를 새 주소로 교체한 뒤 리디렉션이 한 단계로 끝나는지 확인해야 합니다.
13 | 해결 절차와 재요청 방법
첫째, 색인시키려는 주소가 원본인지 최종 URL인지 결정합니다. 둘째, 원본에서 최종 URL까지의 이동 횟수와 상태 코드를 확인합니다. 셋째, 최종 URL의 noindex, robots.txt, canonical, 로그인 제한, 서버 오류를 점검합니다.
넷째, 내부 링크와 사이트맵을 최종 URL 기준으로 수정합니다. 다섯째, 검색엔진의 URL 검사 도구에서 최종 URL을 확인하고 필요할 때 색인 생성을 요청합니다. 재요청은 설정을 고친 뒤 진행해야 하며, 요청만 반복한다고 문제가 해결되지는 않습니다.
14 | 색인 문제를 예방하는 관리 기준
주소를 변경할 때는 새 URL의 콘텐츠를 먼저 준비하고, 이전 주소에서 새 주소로 직접 한 번만 이동하게 구성하세요. 사이트맵과 내부 링크는 배포 직후 새 주소로 갱신하고, canonical과 리디렉션 목적지가 일치하는지 확인해야 합니다.
또한 테스트 환경에서 사용한 noindex와 크롤링 차단 규칙이 운영 환경에 남지 않았는지 점검하세요. 정기적으로 깨진 링크, 리디렉션 체인, 오류 응답을 확인하면 색인 제외 문제를 조기에 발견할 수 있습니다.
☑ 체크리스트
- 색인 대상이 원본 URL인지 최종 URL인지 결정했는가
- 리디렉션이 한 단계로 끝나고 루프가 없는가
- 최종 URL이 정상 응답을 반환하는가
- 최종 페이지에 noindex가 설정되어 있지 않은가
- robots.txt가 최종 경로를 차단하지 않는가
- canonical이 의도한 대표 URL을 가리키는가
- 내부 링크와 사이트맵이 최종 URL을 사용하고 있는가
📖 자주하는 질문 Q&A
리디렉션된 원본 URL도 반드시 색인되어야 하나요?
아닙니다. 영구적으로 이동한 주소라면 검색엔진은 원본보다 최종 URL을 대표 주소로 선택할 수 있습니다. 색인이 필요한 콘텐츠가 최종 URL에 정상적으로 존재하는지 확인하세요.
301 리디렉션을 설정하면 바로 색인되나요?
바로 색인이 보장되지는 않습니다. 최종 URL의 접근 가능 여부, 콘텐츠 품질, noindex, canonical, 사이트 내부 연결 상태 등을 검색엔진이 함께 판단합니다.
리디렉션을 삭제하면 원본 URL이 색인되나요?
반드시 그렇지는 않습니다. 리디렉션을 제거하면 원본 페이지가 정상 콘텐츠를 제공해야 하며, 다른 차단 설정이나 중복 콘텐츠 문제가 없어야 합니다. 단순히 이동 설정만 제거하는 것은 해결책이 아닐 수 있습니다.
색인 생성 요청을 여러 번 하면 더 빨리 처리되나요?
반복 요청보다 먼저 기술적인 원인을 수정하는 것이 중요합니다. 최종 URL이 정상 상태가 된 뒤 URL 검사에서 한 번 요청하고, 이후 상태 변화를 확인하는 편이 효율적입니다.
📝 마무리
리디렉션 페이지가 색인되지 않는 가장 일반적인 이유는 검색엔진이 원본이 아닌 최종 URL을 색인 대상으로 판단하기 때문입니다. 최종 URL의 상태 코드, 색인 차단 설정, canonical, 리디렉션 구조, 내부 링크와 사이트맵을 순서대로 점검하면 원인을 구체적으로 좁힐 수 있습니다.