301 리다이렉트(301 redirect)는 요청받은 주소의 콘텐츠가 새 주소로 영구히 옮겨졌다고 서버가 알리는 HTTP 응답 코드다. 방문자의 브라우저와 검색엔진 크롤러 모두 새 주소로 따라 이동한다.
구글은 301 같은 영구 리디렉션을 “리디렉션 대상이 표준이어야 한다는 신호”로 쓰고, 검색 결과에 옛 주소 대신 새 주소를 표시한다 (구글 검색 센터, 리디렉션 및 Google 검색).
영구냐 임시냐의 차이이고, 그 차이가 검색 결과에 어느 주소를 남길지를 결정한다.
301은 새 주소를 검색 결과에 올린다. 302는 옛 주소를 그대로 검색 결과에 남긴다.
구글 문서의 표현이 명확하다. 영구 리디렉션은 “검색결과에 새 리디렉션 대상을 표시”하고, 임시 리디렉션은 “검색결과에 소스 페이지를 표시”한다.
색인 파이프라인이 두 코드를 다루는 무게도 다르다.
| 상태 코드 | 의미 | 구글이 다루는 방식 |
|---|---|---|
| 301 (moved permanently) | 영구 이동 | 리디렉션 대상이 처리돼야 한다는 강력한 신호 |
| 302 (found) | 임시 이동 | 리디렉션 대상이 처리돼야 한다는 약한 신호 |
| 307 (temporary redirect) | 임시 이동 | 302와 같음 |
| 308 (moved permanently) | 영구 이동 | 301과 같음 |
이 표는 구글이 직접 공개한 분류다 (구글 검색 센터, HTTP 상태 코드, 네트워크 오류, DNS 오류).
표준 주소를 정하는 신호 중에서는 리디렉션이 가장 세다. 구글은 표준화 방법을 영향력 순으로 나열하면서 리디렉션을 “리디렉션 대상이 표준 URL이 되어야 하는 강력한 신호”로 맨 위에 올렸다 (구글 검색 센터, URL 표준화란 무엇인가요?).
선택 기준은 간단하다. 옛 주소를 되살릴 계획이 있으면 302, 없으면 301이다.
구글도 같은 기준을 제시한다. “리디렉션을 되돌리지 않는다고 확신하는 경우에 영구 리디렉션을 사용”하라는 것이 문서의 안내다.
점검 중이라 잠시 안내 페이지로 보내는 경우가 302의 전형적인 용도다. 이때 301을 걸면 검색 결과에서 원래 주소가 사라진다.
요청 메서드를 바꾸면 안 되는 상황에서 쓴다. 301과 302에는 오래된 흠이 하나 있기 때문이다.
HTTP 표준은 301과 302에 대해 “역사적 이유로 사용자 에이전트가 후속 요청에서 요청 메서드를 POST에서 GET으로 바꿀 수 있다”고 명시한다. 원하지 않으면 각각 308과 307을 쓰라는 안내가 규격에 함께 붙어 있다 (IETF, RFC 9110 HTTP Semantics).
307은 반대로 메서드 변경을 금지한다. 규격은 사용자 에이전트가 요청 메서드를 “바꾸면 안 된다”고 못 박는다.
폼 전송이나 API 호출처럼 POST 본문이 살아 있어야 하는 경로라면 307이나 308이 정답이다. 문서 주소를 옮기는 일반적인 상황에서는 301로 충분하다.
308이 덜 쓰이는 데는 이유가 있다. 규격 자체가 “이 상태 코드는 형제 코드들보다 훨씬 어리며(2014년 6월) 따라서 모든 곳에서 인식되지 않을 수 있다”고 경고한다.
구글은 301과 308을 같게 다루지만 다른 클라이언트까지 그렇다고 보장하지 않는다. 구글 문서도 “다른 클라이언트(예: eBook 리더기, 기타 검색엔진)가 리디렉션을 활용할 수 있도록 리디렉션에 적합한 상태 코드를 사용하세요”라고 덧붙인다.
서버가 응답 헤더로 상태 코드와 이동할 주소를 함께 내보내면 된다. 구글은 가능하면 서버 측 리디렉션을 쓰라고 권한다.
구글이 정리한 방법의 우선순위는 이렇다. 위로 갈수록 구글이 올바르게 해석할 가능성이 높다.
location 변경자바스크립트 방식은 마지막 수단이다. 구글은 렌더링이 실패하면 “그 리디렉션을 절대 알아채지 못할 수 있다”고 경고한다.
서버별 설정은 한 줄이면 끝난다. 아파치는 mod_alias로 처리한다.
Redirect permanent "/old" "https://example.com/new"NGINX는 return으로 상태 코드를 직접 지정한다.
location = /service {
return 301 https://example.com/about/service;
}PHP처럼 서버 설정 파일에 손댈 수 없는 환경에서는 코드로 헤더를 보낸다.
header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/newurl');
exit();설정한 뒤에는 반드시 실제 응답을 확인한다. 서치 콘솔 URL 검사 도구로 하나씩 보거나, 명령줄에서 curl -I로 상태 코드와 Location 헤더를 직접 읽는다.
신호는 넘어가지만 즉시 넘어가지 않는다. 이 시차가 도메인 이전에서 가장 자주 오해받는 지점이다.
구글은 리디렉션으로 신호가 이전된다고 명시하되 조건을 붙인다. “리디렉션을 최대한 오랫동안 유지”해야 하며 “일반적으로 최소 1년”이라는 것이다 (구글 검색 센터, 사이트 이동 방법).
왜 1년인지도 같은 문서에 적혀 있다. 그 기간이 있어야 구글이 “이전 URL로 연결되는 다른 사이트의 링크를 다시 크롤링하고 재할당하는 등 모든 신호를 새 URL에 전송할 수 있”기 때문이다.
구글이 예상하는 처리 기간은 훨씬 짧다. 중소형 사이트는 대부분의 페이지를 옮기는 데 “대개 몇 주 정도” 걸린다는 것이 문서의 설명이다.
실측은 다른 그림을 보여 준다. SEO 에이전시 SALT가 도메인 이전 1,052건의 회복 시점을 모아 정리한 결과다 (SALT.agency, Only 27% of domain migrations recover in 90 days).
| 이전 후 경과 | 트래픽을 회복한 비율(누적) |
|---|---|
| 30일 | 5.1% |
| 90일 | 22.8% |
| 180일 | 35.4% |
| 365일 | 59.5% |
| 730일 | 83.5% |
| 1,095일 | 86.1% |
회복은 새 도메인의 월간 오가닉 트래픽이 이전 전 수준을 따라잡은 시점으로 정의됐다. 중앙값은 304일, 평균은 489일이었다.
3년이 지나도 완전히 회복하지 못한 이전이 13.9% 있었다.
두 숫자가 충돌하는 것처럼 보이지만 재는 대상이 다르다. 구글의 “몇 주”는 크롤링과 재색인에 걸리는 시간이고, 304일은 백링크 재크롤링과 매핑 누락, 재색인 지연이 모두 합쳐진 결과다.
실무에서 읽는 법은 하나다. 리디렉션 자체는 신호를 새지 않게 넘기지만, 이전 직후 몇 달의 트래픽 하락은 정상 범위로 잡고 일정을 세워야 한다.
네이버 웹마스터도구가 사이트 소유확인을 해 주는 조건이기 때문이다. 구글에는 없는 제약이다.
네이버는 리디렉션이 걸린 사이트를 원칙적으로 소유확인해 주지 않는다. 예외가 301 하나뿐이다.
고객센터 문서의 문장이 그대로다. “이러한 리다이렉트 사이트는 웹마스터도구에서 소유확인 되지 않으며, 웹 프로토콜(protocol) 표준인 301 리다이렉트일 경우에만 소유확인을 보장합니다” (네이버 서치어드바이저 고객센터, 301 리다이렉트(redirect) 설정 소개).
meta refresh와 자바스크립트는 아예 막혀 있다. 네이버는 두 방식을 “웹 표준 아님”으로 분류하고, 그렇게 처리하면 소유확인을 할 수 없다고 명시한다.
홈 주소에 리디렉션을 걸어 둔 사이트가 네이버 서치어드바이저 등록에서 막히는 사고가 여기서 나온다. 구글에서는 문제없이 동작하던 meta refresh가 네이버에서는 등록 자체를 막는다.
네 가지가 반복된다. 체인, 의도하지 않은 임시 코드, 관련 없는 페이지로 보내기, 그리고 되돌리기다.
체인부터 보면 홉 수에 한도가 있다. 구글 크롤러는 기본적으로 최대 10개의 리디렉션 홉을 따르지만, 사이트 이전 문서는 “3개 이하가 적당하며 최대 5개까지”로 더 좁게 권한다.
A에서 B로, B에서 C로 걸린 리디렉션은 A에서 C로 한 번에 걸어 정리한다. 체인이 길수록 사용자 대기 시간도 늘어난다.
두 번째는 의도하지 않은 임시 코드다. 직접 건 리디렉션은 301인데 플랫폼이 자동으로 넣는 리디렉션이 302나 307로 나가는 경우가 있다.
서치폴라리스 도메인에서 실제로 확인해 봤다. 2026년 9월 1일 curl -I로 응답 헤더를 직접 읽은 결과다.
| 요청한 주소 | 상태 코드 | 이동한 곳 |
|---|---|---|
| /blog/geo/ | 301 | /wiki/geo/ |
| http로 시작하는 홈 | 301 | https 홈 |
| www가 붙은 홈 | 301 | www 없는 홈 |
| /wiki/geo (끝 슬래시 없음) | 307 | /wiki/geo/ |
우리가 규칙으로 설정한 세 건은 전부 301로 나갔다. 그런데 끝 슬래시를 붙여 주는 네 번째는 우리가 만든 규칙이 아니라 호스팅 플랫폼이 자동으로 넣는 것이고, 307로 나간다.
307은 구글이 302와 같게 다루는 약한 신호다. 슬래시 없는 주소로 걸린 외부 링크가 있다면 그 신호는 표준화에 쓰이지 않는다는 뜻이다.
내가 설정한 규칙만 보고 안심하면 이런 코드를 놓친다. 배포 뒤에는 실제 응답 헤더를 확인하는 편이 안전하다.
세 번째 실수는 없어진 페이지를 전부 홈으로 보내는 것이다. 구글은 이 처리를 명시적으로 금지한다.
문서의 표현은 “이전에 사용하던 여러 URL을 새 사이트의 홈페이지처럼 관련성이 떨어지는 단일 도착 URL로 전부 리디렉션하면 안 됩니다”이고, 그렇게 하면 soft 404 오류로 처리될 수 있다고 덧붙인다.
대응할 페이지가 없으면 리디렉션 대신 404나 410으로 정직하게 응답하는 편이 낫다. 여러 페이지를 하나로 통합한 경우라면 그 통합 페이지로 보내는 것은 문제없다.
마지막은 되돌리기다. HTTP 표준은 301 응답을 “휴리스틱하게 캐시 가능”으로 규정하고 302에는 같은 규정을 두지 않았다.
브라우저가 301을 기억한다는 뜻이다. 잘못 건 301을 서버에서 지워도 이미 그 페이지를 방문한 사용자는 한동안 새 주소로 튕긴다.
301은 되돌릴 수 있다는 전제로 걸면 안 된다. 확신이 서지 않으면 302로 시작해서 확정된 뒤에 301로 바꾸는 순서가 테크니컬 SEO에서 더 안전하다.
리디렉션과 캐노니컬 태그를 헷갈리는 것도 흔하다. 옛 주소를 살려 둘 필요가 있으면 캐노니컬 태그, 옛 주소를 닫아도 되면 리디렉션이다.
301은 에러인가요? 에러가 아닙니다. 오류를 뜻하는 것은 4xx와 5xx 코드이고, 301은 3xx 범위에 속하는 정상 응답입니다. 브라우저 주소창에 다른 주소가 뜨는 것도 리디렉션이 제대로 동작한 결과입니다. 다만 서치 콘솔은 리디렉션이 실패한 3xx에 대해서는 오류 메시지를 냅니다.
리다이렉트가 걸렸는지 어떻게 확인하나요?
명령줄에서 curl -I 주소를 실행하면 첫 줄에 상태 코드가, Location 헤더에 이동할 주소가 그대로 나옵니다. 브라우저 개발자 도구의 네트워크 탭에서도 같은 값을 볼 수 있습니다. 구글이 그 주소를 어떻게 처리했는지까지 보려면 서치 콘솔 URL 검사 도구를 씁니다.
워드프레스나 카페24에서는 어떻게 설정하나요?
서버 설정 파일에 접근할 수 없는 호스팅이면 대개 관리 화면에 리디렉션 메뉴가 따로 있습니다. 워드프레스는 리디렉션 플러그인으로 규칙을 추가하는 방식이 일반적입니다. 어떤 방식이든 설정 후 curl -I로 실제 응답이 301인지 확인해야 합니다. 플러그인에 따라 302로 나가는 경우가 있습니다.
서치폴라리스가 AI 검색 가시성을 진단하고 GEO 실행까지 대행합니다.