양용준SEO/GEO 전략 컨설턴트
업데이트 · 최초 게시
301 리디렉션(301 Redirect)은 요청한 페이지가 새 주소로 영구히 옮겨졌다고 서버가 알리고 방문자와 검색엔진을 새 주소로 보내는 HTTP 응답입니다. 국내에서는 “301 리다이렉트”라는 표기가 더 흔하게 쓰이며, 구글은 이 응답을 새 주소를 대표 URL로 삼으라는 강한 신호로 받아들입니다.
브라우저나 크롤러가 어떤 주소를 요청하면 서버는 세 자리 상태 코드로 답합니다. 앞자리 3은 “다른 곳으로 가라”는 리디렉션 계열이고, 301은 그중 Moved Permanently(영구 이동)입니다. 서버는 이 코드와 함께 Location 헤더에 새 주소를 적어 보내고, 브라우저는 그 주소로 곧바로 다시 요청합니다.
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-pageHTTP 표준 문서인 RFC 9110은 301을 “대상 리소스에 새로운 영구 URI가 부여되었고, 앞으로의 참조는 새 URI를 써야 한다”는 뜻으로 정의합니다. 사용자는 주소창이 바뀌는 것 말고는 차이를 느끼지 못하지만, 검색엔진에게는 “옛 주소 대신 새 주소를 기억하라”는 요청이 됩니다. 구글 검색 센터의 리디렉션 문서는 영구 리디렉션을 만나면 검색결과에 새 리디렉션 대상을 표시한다고 설명합니다.
301이 필요한 상황은 대개 주소가 바뀌는 때입니다. 도메인을 옮길 때, http를 https로 바꿀 때, www 유무를 하나로 통일할 때, 글의 주소(슬러그)를 고칠 때, 여러 페이지를 하나로 합칠 때가 대표적입니다.
다시 되돌리지 않을 이동이면 301이나 308, 잠시 다른 곳으로 보냈다가 돌아올 이동이면 302나 307을 씁니다. 네 코드 모두 방문자를 새 주소로 보낸다는 점은 같고, 차이는 “영구인가 임시인가”와 “요청 방식을 유지하는가” 두 가지입니다.
| 301 | 308 | 302 | 307 | |
|---|---|---|---|---|
| 뜻 | 영구 이동 | 영구 이동 | 임시 이동(Found) | 임시 이동 |
| 구글이 보는 신호 | 새 주소를 처리하라는 강한 신호 | 301과 같음 | 약한 신호 | 302와 같음 |
| 검색결과에 보이는 주소 | 새 주소 | 새 주소 | 대개 옛 주소 | 대개 옛 주소 |
| POST 요청 유지 | GET으로 바뀔 수 있음 | 유지 | GET으로 바뀔 수 있음 | 유지 |
구글의 HTTP 상태 코드 문서는 308을 301과, 307을 302와 같게 처리한다고 밝힙니다. 그래서 일반 웹페이지라면 301과 308 중 어느 쪽을 써도 검색 결과는 같습니다. 308은 폼 제출처럼 POST로 들어오는 요청을 옮길 때 의미가 있습니다. RFC 9110에 따르면 301은 역사적인 이유로 브라우저가 POST를 GET으로 바꿔 다시 요청할 수 있고, 이를 막으려면 308을 쓰라고 적고 있습니다.
| 상황 | 고를 코드 |
|---|---|
| 도메인 이전, http→https, www 통일, 슬러그 변경 | 301 |
| 폼·API처럼 POST 요청을 받는 주소를 영구히 옮김 | 308 |
| 서비스 점검, 일시 품절 안내처럼 곧 원래대로 돌아옴 | 302 또는 307 |
| A/B 테스트로 방문자를 다른 버전에 보냄 | 302 |
| 두 주소를 모두 살려 두고 대표만 정하고 싶음 | 리디렉션이 아니라 캐노니컬 태그 |
A/B 테스트에 302를 쓰라는 것은 구글의 A/B 테스팅 권장사항에 명시된 내용입니다. 원래 URL을 색인에 그대로 두라는 뜻을 전하기 위해서입니다. 마지막 줄처럼 옛 주소를 없애지 않을 때는 리디렉션 대신 캐노니컬 태그가 맞습니다. 캐노니컬과 301, noindex의 차이는 그 글에서 표로 정리했습니다.
302를 영구 이동에 잘못 쓰면 어떻게 될까요. 당장은 검색결과에 옛 주소가 남을 수 있습니다. 다만 구글의 John Mueller는 302가 오래 유지되고 링크가 모두 새 주소를 가리키면 구글이 결국 새 주소를 고르게 되며, 그 전환 시점은 정해져 있지 않다고 설명했습니다(2021년 4월). 기다리면 풀릴 수도 있지만 시점을 구글에 맡기는 셈이니, 영구 이동은 처음부터 301로 거는 편이 확실합니다.
컨설턴트의 실전 팁
302만 그런 것은 아닙니다. 307이나 자바스크립트 리디렉션으로 주소를 옮긴 사이트에서도 트래픽은 새 주소로 넘어가는데, 검색 결과에는 옛 주소가 계속 노출되는 일이 있었습니다. 방문자가 새 주소에 잘 도착한다고 해서 끝났다고 보지 마시고, 검색 결과에 어느 주소가 보이는지까지 확인하시길 권합니다.
링크 평가는 손실 없이 넘어가지만, 새 주소가 옛 주소의 자리를 이어받기까지는 시간이 걸립니다. 한때 301을 거치면 링크 가치가 일부 줄어든다는 말이 돌았는데, 구글의 Gary Illyes는 2016년 7월 30x 리디렉션은 더 이상 PageRank를 잃지 않는다고 밝혔습니다. 지금의 사이트 이전 문서도 “301 및 기타 영구 리디렉션으로 인해 PageRank가 손실되는 일은 없습니다”라고 적고 있습니다.
그렇다고 바로 제자리를 찾는 것은 아닙니다. 같은 문서는 이전하는 동안 순위가 일시적으로 흔들릴 수 있고, 중간 규모 사이트에서 새 URL이 옛 URL을 대신해 보이기까지 몇 주 이상, 대형 사이트는 그보다 오래 걸린다고 안내합니다. 그리고 리디렉션은 최소 1년 유지하라고 권합니다. 다른 사이트에서 옛 주소로 걸린 링크를 다시 크롤링해 새 주소로 넘기는 데 그만큼 시간이 필요하다는 이유입니다.
컨설턴트의 실전 팁
도메인을 옮기거나 http를 https로 바꾼 사이트에서 제가 겪은 순위 회복 기간은 1~3개월이었습니다. 301을 제대로 걸어도 그 사이에는 순위가 흔들릴 수 있으니, 이전 일정을 잡을 때 이 기간을 감안해 두시길 권합니다.
그래서 이미 운영 중인 사이트의 URL은 301이나 308을 걸 수 있을 때만 바꾸라고 말씀드립니다.
가장 확실한 방법은 서버에서 거는 것입니다. 구글 문서는 리디렉션 방식을 “올바르게 해석할 가능성이 높은 순”으로 나열하는데, 맨 앞이 서버 측 301·308이고 meta refresh, 자바스크립트가 그 뒤입니다.
Apache는 .htaccess에, NGINX는 서버 설정 파일에 규칙을 적습니다. 아래는 구글 문서에 실린 예시와 같은 형태입니다.
# Apache (.htaccess, mod_alias)
Redirect permanent "/old" "https://example.com/new"
# NGINX
location = /service {
return 301 https://example.com/about/service;
}서버 설정 파일을 만질 수 없다면 PHP에서 헤더를 보낼 수 있습니다. 화면에 무엇이든 출력하기 전에 헤더를 먼저 보내야 합니다.
<?php
header('HTTP/1.1 301 Moved Permanently');
header('Location: https://example.com/new-page');
exit();워드프레스는 글의 슬러그를 바꾸면 옛 주소를 새 주소로 자동으로 보내 주지만, 이는 글 단위일 때의 이야기입니다. 카테고리 구조나 고유주소 형식을 통째로 바꾸는 경우에는 리디렉션 플러그인이나 서버 규칙으로 옛 주소와 새 주소를 하나씩 짝지어 두는 편이 안전합니다.
호스팅 제약으로 서버 측 리디렉션이 불가능하면 0초짜리 meta refresh를 씁니다. 구글은 즉시 실행되는 meta refresh를 영구 리디렉션으로, 지연 시간을 둔 것은 임시 리디렉션으로 해석합니다. 자바스크립트 리디렉션은 렌더링이 실패하면 구글이 리디렉션을 알아채지 못할 수 있어 마지막 수단으로 남겨 둡니다.
가장 빠른 확인은 응답 헤더를 직접 보는 것입니다. 터미널에서 curl -I로 옛 주소를 요청하면 상태 코드와 이동할 주소가 나옵니다. 여기서 301 대신 302가 보이거나, Location이 또 다른 리디렉션 주소를 가리키면 설정을 고쳐야 합니다.
$ curl -I https://example.com/old-page
HTTP/2 301
location: https://example.com/new-page구글이 어떻게 받아들였는지는 서치 콘솔에서 봅니다. 페이지 색인 생성 보고서에서 옛 주소는 리디렉션이 포함된 페이지로 분류되며, 이는 색인되지 않는 것이 정상인 상태입니다. 반대로 리디렉션 오류로 잡히면 문제입니다. 구글은 이 오류의 원인으로 리디렉션 체인이 너무 긴 경우, 리디렉션이 순환하는 경우, 리디렉션 URL이 최대 길이를 넘는 경우, 체인 중간에 잘못되거나 빈 URL이 있는 경우를 꼽습니다. 새 주소는 URL 검사에서 색인이 생성됐는지 따로 확인합니다.
301을 걸었는데도 옛 주소가 계속 보이거나 새 주소의 순위가 오르지 않는다면 대개 아래 중 하나입니다.
네이버 서치어드바이저 문서는 “리다이렉트”라는 표기를 씁니다. 선호 URL 및 로봇 메타 태그 가이드는 사이트 메인 페이지는 link 태그로 선호 URL을 지정하기보다 HTTP redirect를 쓰라고 권합니다. 같은 문서는 리다이렉트 기능만으로 이뤄진 페이지에서는 로봇 메타 태그가 제대로 반영되지 않을 수 있으니, 리다이렉트 대상 페이지에도 같은 설정을 해 두라고 안내합니다.
네이버가 301과 302를 어떻게 구분해 처리하는지, 옛 주소의 평가를 얼마나 빨리 새 주소로 옮기는지는 공개 문서에 나와 있지 않습니다. 그래서 주소를 옮긴 뒤에는 서치어드바이저에 새 사이트맵을 제출하고, 새 주소가 실제로 수집되는지 지켜보는 것까지가 운영자가 할 수 있는 일입니다.
