301 리다이렉트 301 Redirect

301 리다이렉트(301 Redirect)는 페이지가 다른 URL로 영구 이동했음을 브라우저와 검색엔진에 알리는 HTTP 상태 코드입니다. 기존 URL이 쌓아 온 백링크와 색인 신호를 새 URL로 물려주므로, 사이트 리뉴얼이나 도메인 이전 시 검색 순위를 지키는 핵심 수단입니다.

테크니컬 2026. 7. 11 업데이트 By 박혜정

정의 - 무엇이 어떻게 전달되는가

301 리다이렉트는 페이지가 다른 URL로 영구 이동했음을 브라우저와 검색엔진에 알리는 HTTP 응답 코드입니다. MDN 웹 표준 문서는 301을 "요청한 리소스가 Location 헤더의 URL로 영구히 이동했다"는 신호로 정의하고, "이 응답을 받은 검색엔진은 기존 URL을 향하던 링크를 새 리소스에 귀속시켜 순위를 넘긴다"고 설명합니다 MDN 문서. 기존 URL이 쌓아 온 백링크와 순위 신호를 새 URL로 승계하는 공식 통로인 셈입니다.

구글 검색센터도 같은 원리를 안내합니다. 영구 리다이렉트를 만나면 구글은 검색 결과에 새 URL을 노출하고, 색인 파이프라인은 리다이렉트를 "대상 URL이 대표(canonical)가 되어야 한다"는 신호로 사용합니다. 이때 구글은 301을 "강한(strong) 신호"로 분류합니다 Google 공식.

링크 값은 손실되는가 - 공식 입장과 실제 이전 결과

"301을 거치면 링크 값이 새어 나간다"는 흔한 생각은 구글이 공식적으로 아니라고 밝혔습니다. 게리 일리스(Gary Illyes)는 2016년 7월 "30x 리다이렉트는 더 이상 페이지랭크를 잃지 않는다"고 밝혔고, 존 뮬러(John Mueller)는 이것이 새 정책이 아니라 이미 운영 중이던 방침의 확인이라고 덧붙였습니다 Google 일리스. 다만 현장에서 측정한 실제 이전 결과는 조금 다른 이야기를 합니다.

구글 공식 입장	30x 리다이렉트로는 페이지랭크가 사라지지 않으며, 서버 사이드 301은 링크·순위 신호를 새 URL(리다이렉트 대상)에 그대로 모읍니다. 올바르게 구현하면 순위 승계는 리다이렉트 장치 자체에서 새지 않습니다. Google 공식
전문가 실측 결과	리다이렉트를 정확히 걸어도 실제 이전에서는 트래픽 회복이 느립니다. SALT.agency가 도메인 이전 1,052건을 분석한 결과 90일 안에 트래픽을 회복한 사례는 22.8%뿐이었고, 회복 기간 중앙값은 약 304일(약 10개월), 13.9%는 3년 뒤에도 완전히 회복하지 못했습니다(2026). SALT 실측

두 설명이 부딪치는 것처럼 보이지만 사실 측정 대상이 다릅니다. 구글의 "손실 없음"은 리다이렉트라는 장치 하나만 떼어 본 이야기이고, 실측 수치는 이전 전체의 결과 - 구글봇이 수천 개 백링크 출처를 다시 크롤링하고 신호를 다시 모으기까지 걸리는 시간, URL 매핑 누락, 재색인 지연이 모두 합쳐진 값입니다. 실무에서는 "페이지랭크는 안 새지만 회복에는 몇 달이 걸린다"로 읽고, 이전 직후 최소 두세 달의 트래픽 변동을 일정과 기대치에 미리 반영하는 편이 안전합니다.

301과 302의 차이

두 코드의 차이는 "영구"와 "임시"입니다. 구글 리다이렉트 문서는 영구 리다이렉트면 검색 결과에 새 URL을 보여주고 대상 URL을 대표로 처리하지만, 임시(302) 리다이렉트는 원본 URL을 검색 결과에 유지하고 정규화 신호로 쓰지 않는다고 분명히 밝힙니다 Google 공식.

구분	301 (영구 이동)	302 (임시 이동)
검색 결과 노출	새 URL (리다이렉트 대상)	기존 URL (원본 페이지)
정규화 신호	강한(strong) 신호 - 새 URL을 대표로	약한(weak) 신호 - 원본 색인 유지
사용 시점	리뉴얼, 도메인 이전, HTTPS 전환	임시 점검, 단기 이벤트 페이지

영구 이동이라면 처음부터 301로 뜻을 분명히 전하는 편이 안전합니다. 두 URL을 모두 살려 둔 채 대표 주소만 지정해야 하는 상황이라면, 리다이렉트가 아니라 캐노니컬 태그가 맞는 도구입니다.

구현 - 서버 사이드 리다이렉트가 최우선

구글 리다이렉트 문서는 구현 방식을 선호 순서대로 나열합니다 - (1) 서버 사이드 리다이렉트(HTTP 301·308), (2) meta refresh, (3) 자바스크립트 location, (4) 링크 안내. 자바스크립트 방식은 렌더링에 실패하면 구글이 리다이렉트를 인식하지 못할 수 있어 "서버 사이드나 meta refresh를 쓸 수 없을 때만 사용하라"고 못박습니다 Google 공식. 아래는 웹서버(nginx) 레벨의 구현 예시입니다.

# 1) 도메인 이전 - 경로를 그대로 보존해 1:1 이동
server {
    listen 443 ssl;
    server_name old-domain.com www.old-domain.com;
    return 301 https://new-domain.com$request_uri;
}

# 2) 개별 URL 이동
location = /old-page/ {
    return 301 /new-page/;
}

# 3) 경로 구조 변경 - 패턴 일괄 이동
rewrite ^/blog/(.+)$ /insights/$1 permanent;

핵심은 1번 예시의 $request_uri입니다. 이것이 빠지면 구 도메인의 모든 페이지가 새 도메인 홈으로 뭉쳐 들어갑니다. 구글 사이트 이전 가이드는 "많은 구 URL을 새 사이트의 홈페이지처럼 무관한 단일 URL로 리다이렉트하지 말라"고 경고합니다 Google 공식.

사이트 이전 체크리스트 - 구글 공식 가이드 기준

구 URL 모두 모으기와 1:1 매핑 - 구글 사이트 이전 가이드는 구 URL 목록을 먼저 확보한 뒤 각 URL이 어디로 리다이렉트될지 결정하라고 안내합니다. http/https, www 유무, 트레일링 슬래시 같은 변형 URL도 매핑에 포함합니다. Google 공식
경로 보존 - 각 페이지를 짝이 되는 새 페이지로 보냅니다. 존 뮬러는 대응 페이지가 없으면 홈으로 보내지 말고 404 또는 410을 반환하라고 권고했습니다. Google 뮬러
체인 최소화 - 구글은 크롤러가 기본적으로 최대 10홉까지만 리다이렉트를 따라간다고 안내합니다. 어떤 주소에서 출발해도 최종 URL에 한 번에 도착하도록 규칙 순서를 설계합니다. Google 공식
내부 링크·사이트맵 갱신 - 새 사이트의 내부 링크를 구 URL이 아닌 새 URL로 바꾸고, 새 사이트맵을 서치 콘솔에 제출합니다.
배포 후 검증 - curl -I로 상태 코드와 Location 헤더를 확인하고, 도메인이 바뀌는 이전이면 서치 콘솔의 주소 변경(Change of Address) 도구를 제출합니다. HTTP에서 HTTPS로의 전환에는 이 도구가 필요 없습니다. Google 공식
최소 1년 유지 - 구글은 리다이렉트를 "가능한 한 오래, 일반적으로 최소 1년" 유지하고, 사용자 경험 관점에서는 기한 없이 계속 두는 것도 고려하라고 안내합니다. Google 공식

자주 하는 실수

전 페이지를 홈으로 리다이렉트 - 존 뮬러는 대응 없는 대량 리다이렉트를 "대부분 소프트 404로 취급한다"고 밝혔습니다. 링크 자산이 이어지지 않습니다. Google 뮬러
리다이렉트 체인 그냥 두기 - 구글 크롤러의 기본 추적 한도는 10홉입니다. 홉이 늘수록 크롤링 낭비와 로딩 지연이 커집니다. Google 공식
영구 이동에 302 사용 - 302는 약한 신호라 원본 URL이 검색 결과에 남고 색인 교체가 늦어질 수 있습니다. Google 공식
meta refresh나 자바스크립트 리다이렉트로 대체 - 구글이 명시한 선호 순위에서 서버 사이드보다 하위이며, 자바스크립트 방식은 렌더링 실패 시 인식되지 않을 수 있습니다.
리다이렉트만 걸고 내부 링크는 방치 - 구글 사이트 이전 가이드는 내부 링크와 사이트맵을 새 URL로 함께 갱신하라고 안내합니다. Google 공식

구글 사이트 이전 가이드의 순서 자체가 말해 주듯, 리다이렉트 설계는 오픈 직전의 마감 작업이 아니라 URL 매핑부터 시작하는 사전 준비 작업입니다. 새 URL 구조가 확정되는 시점에 매핑 표를 만드는 것이 공식 문서가 안내하는 첫 단계입니다.