리다이렉트 301·302·307·308 차이 — 영구·임시·메서드 보존과 SEO
주소를 바꿨더니 검색 순위가 떨어졌다는 이야기를 종종 듣는다. 원인은 대개 리다이렉트 코드를 잘못 고른 데 있다. 페이지를 옮길 때 301을 써야 할 자리에 302를 쓰면, 검색엔진은 "이건 잠깐 옮긴 거구나" 하고 옛 주소를 계속 들고 있는다. 반대도 마찬가지다. 영구 이전은 301, 잠깐 보내는 건 302, 메서드를 그대로 지켜야 하면 307·308이다. 이 네 가지를 언제 쓰는지, SEO에 어떤 영향을 주는지, 서버에서 어떻게 설정하고 확인하는지를 정리한다.

이 글의 구성
🔎 리다이렉트(3xx)란 무엇인가
리다이렉트는 "이 주소 말고 저 주소로 가세요"라고 서버가 브라우저에 알려주는 응답이다. HTTP 상태 코드 3xx 묶음이 이 역할을 한다. 서버는 3xx 코드와 함께 새 주소를 Location 헤더에 담아 보내고, 브라우저는 그 주소로 다시 요청한다. 사용자는 주소창이 바뀌는 것만 본다.
리다이렉트는 일상적으로 쓰인다. http에서 https로 강제 이동, www 있는 주소와 없는 주소 통일, 옛 페이지를 새 페이지로 이전, 도메인 변경 등이 모두 리다이렉트다. 문제는 3xx에 여러 코드가 있고, 각각 "영구인가 임시인가", "원래 메서드를 지키는가"가 다르다는 점이다. 이 차이를 모르고 아무거나 쓰면 검색 순위나 폼 전송이 엉킨다.
핵심 두 축 — 영구성과 메서드
리다이렉트 코드는 두 가지로 갈린다. 첫째, 이 이전이 영구(301·308)인가 임시(302·307)인가. 둘째, 원래 요청 메서드(GET·POST)를 그대로 지키는가(307·308), 아니면 GET으로 바뀔 수 있는가(301·302). 이 두 축만 잡으면 네 코드의 자리가 정해진다.
⚖️ 301·302·307·308 한눈 비교
네 코드를 영구성과 메서드 보존으로 나눈 표다. 가장 자주 쓰는 건 301과 302이고, 307·308은 메서드를 반드시 지켜야 할 때 쓴다.
| 코드 | 의미 | 영구성 | 메서드 |
|---|---|---|---|
| 301 | 영구 이동(Moved Permanently) | 영구 | GET으로 바뀔 수 있음 |
| 302 | 임시 이동(Found) | 임시 | GET으로 바뀔 수 있음 |
| 307 | 임시 이동(Temporary Redirect) | 임시 | 그대로 보존 |
| 308 | 영구 이동(Permanent Redirect) | 영구 | 그대로 보존 |
표의 핵심은 메서드 차이다. 301·302는 원래 명세상 메서드 변경을 금지하지만, 현실에서는 많은 브라우저가 POST 요청을 GET으로 바꿔 리다이렉트해 왔다. 그래서 이 동작을 명확히 막으려고 나온 게 307(302의 엄격판)과 308(301의 엄격판)이다. 307·308은 POST를 POST로, 본문까지 그대로 들고 새 주소로 다시 보낸다.
🔗 어떤 상황에 어떤 코드를 쓰나
규칙은 단순하다. "다시는 옛 주소로 안 돌아갈 건가"와 "폼 전송 같은 메서드를 지켜야 하나"를 물으면 된다.
301 — 영구 이전의 기본값
페이지를 새 URL로 완전히 옮겼거나, 도메인을 바꿨거나, http→https·www 통일처럼 앞으로도 바뀌지 않을 이전에 쓴다. 검색엔진이 옛 주소를 새 주소로 교체하도록 신호를 보낸다. 가장 흔하게 써야 할 코드다.
302 — 잠깐만 보낼 때
점검 페이지로 임시 이동, A/B 테스트, 지역·언어별 임시 분기처럼 원래 주소로 곧 돌아올 때 쓴다. 검색엔진은 옛 주소를 그대로 인덱스에 유지한다. 영구 이전에 302를 쓰면 순위 이전이 안 된다.
307·308 — 메서드를 반드시 지킬 때
POST로 보낸 폼·API 요청이 GET으로 변질되면 안 되는 경우다. 임시면 307, 영구면 308. 참고로 HSTS가 켜진 브라우저는 http 요청을 보내기 전에 스스로 https로 올리는데, 이때 내부적으로 307(Internal Redirect)을 쓴다. 서버의 http→https 리다이렉트(301·308)는 첫 방문·HSTS 미적용 사용자를 위해 여전히 필요하다. 메서드 보존이 중요한 API 서버 이전에도 안전하다.
📈 SEO 관점 — 순위가 새는 이유
검색 관점에서 301과 302의 차이는 "어느 주소를 대표 URL로 색인하느냐"에 있다. 301(영구)은 새 주소를 대표로 삼으라는 즉각적이고 분명한 신호다. 검색엔진은 시간이 지나면 옛 URL을 색인에서 빼고 새 URL로 대체하며, 옛 페이지가 쌓아 온 평가, 흔히 말하는 링크 자산(link equity)도 새 주소로 넘어간다.
302(임시)라고 평가 자체가 사라지는 건 아니다. 구글은 모든 3xx 리다이렉트가 평가를 전달한다고 밝혔고, 오래 유지된 302는 결국 301처럼 새 주소로 정리한다. 다만 302는 "원래 주소를 대표로 둬라"는 뜻이라 색인 통합이 더 느리고 예측하기 어렵다. 영구 이전인데 302를 쓰면 새 URL로의 통합이 지연되고 한동안 옛 주소가 대표로 남아, 사이트를 옮겼는데 정리가 더디다는 사례로 이어진다. 그래서 영구 이전에는 즉시 분명한 신호를 주는 301이 안전하다.
SEO에서 지킬 원칙
💻 서버별 설정과 확인 방법
먼저 어떤 코드로 응답하는지부터 확인한다. curl로 헤더만 보면 상태 코드와 Location이 한눈에 보인다.
# 상태 코드와 이동 주소 확인 (-I 는 헤더만)
curl -I https://old.example.com
# 응답 예시
HTTP/2 301
location: https://new.example.com/
# -L 을 붙이면 리다이렉트를 끝까지 따라가며 체인 확인
curl -sIL https://old.example.com | grep -i "HTTP/\|location"
Nginx에서는 return으로 간단히 영구·임시 리다이렉트를 지정한다.
# Nginx — 영구(301) 이전
server {
listen 80;
server_name old.example.com;
return 301 https://new.example.com$request_uri;
}
# 임시면 301 자리에 302 사용
Apache는 .htaccess에서 Redirect 또는 RewriteRule로 지정한다.
# Apache .htaccess — 영구(301)
Redirect 301 /old-page https://www.example.com/new-page
# http → https 강제 (RewriteRule, 308로 메서드 보존)
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=308,L]
🛠 흔한 실수와 점검 포인트
리다이렉트는 한 번 잘못 걸면 조용히 순위와 전환을 갉아먹는다. 자주 나오는 함정을 모았다.
| 실수 | 결과·점검 |
|---|---|
| 영구 이전에 302 사용 | 옛 URL이 색인에 남아 순위 이전 실패 → 301로 교체 |
| 리다이렉트 체인·루프 | 속도 저하·TOO_MANY_REDIRECTS → curl -IL로 단계 확인, 한 번에 직행 |
| POST가 GET으로 변질 | 폼·API 데이터 유실 → 307·308로 메서드 보존 |
| 전 페이지를 홈으로 일괄 이동 | soft 404·평가 분산 → 주제별 1:1 매핑 |
| 301 캐시 후 되돌리기 어려움 | 301은 브라우저가 오래 캐시 → 확실해진 뒤에만 적용 |
마지막 항목은 특히 주의할 만하다. 301은 영구라는 뜻이라 브라우저가 강하게 캐시해, 한번 잘못 걸면 사용자 쪽에서 오래 남는다. "임시일 수도 있겠다" 싶으면 302로 시작해, 확정된 뒤 301로 바꾸는 편이 안전하다.
영구는 301, 임시는 302, 메서드를 지켜야 하면 307·308. 헷갈리면 "다시 옛 주소로 돌아올까"를 먼저 물어라.
— 코드 하나가 검색 순위를 가른다
💬 자주 묻는 질문 5가지
Q1그냥 301만 쓰면 안 되나요?
영구 이전이라면 301이 맞습니다. 하지만 점검·테스트처럼 곧 원래대로 돌아올 이동에 301을 쓰면, 검색엔진이 옛 주소를 색인에서 빼버리고 브라우저도 강하게 캐시해 되돌리기 어렵습니다. 임시면 302를 쓰세요.
Q2307·308은 언제 꼭 필요한가요?
POST 같은 메서드와 본문을 그대로 지켜야 할 때입니다. 301·302는 브라우저가 POST를 GET으로 바꿔 보낼 수 있어 폼·API 데이터가 유실될 수 있습니다. 메서드 보존이 중요한 API 이전·HSTS 환경에서는 307(임시)·308(영구)을 씁니다.
Q3리다이렉트가 SEO에 손해인가요?
올바르게 쓰면 손해가 아닙니다. 영구 이전에 301을 1:1로 걸면 평가가 새 주소로 넘어갑니다. 손해는 잘못 쓸 때 납니다. 302 오용, 리다이렉트 체인, 전 페이지를 홈으로 몰기 같은 경우죠. 한 번에 직행하고 주제를 맞춰 매핑하세요.
Q4지금 어떤 코드로 응답하는지 어떻게 보나요?
curl -I 주소로 헤더만 보면 상태 코드와 Location이 나옵니다. curl -sIL을 쓰면 리다이렉트를 끝까지 따라가며 체인을 확인할 수 있습니다. 브라우저 개발자도구의 네트워크 탭에서도 각 요청의 상태 코드를 볼 수 있습니다.
Q5잘못 건 301을 빨리 되돌리고 싶어요.
서버 설정을 고쳐도 브라우저가 이미 캐시한 301은 한동안 남습니다. 사용자별로 캐시 만료를 기다려야 하는 경우가 많아, 즉시 전체 반영은 어렵습니다. 그래서 확정 전에는 302로 시작하는 습관이 안전합니다. 운영 중이라면 캐시 헤더 정책도 함께 점검하세요.
📌 결론
리다이렉트 코드는 두 가지 질문으로 정리된다. 다시 옛 주소로 돌아올 것인가, 그리고 요청 메서드를 그대로 지켜야 하는가. 이 둘만 답하면 301·302·307·308의 자리가 정해진다.
실무 원칙은 다음과 같다.
🔗 영구 이전은 301을 기본으로 쓴다. 도메인 변경·URL 개편·https 통일이 여기에 해당하고, 링크 자산이 새 주소로 넘어간다.
🔁 임시 이동은 302를 쓴다. 점검·테스트처럼 곧 돌아올 때, 그리고 확정 전 "임시일 수도" 싶은 이동에 안전하다.
📈 메서드 보존이 필요하면 307·308, SEO에서는 체인·루프를 피하고 주제별 1:1로 매핑한다.
리다이렉트 점검 체크리스트
본 글은 HTTP 리다이렉트 상태 코드의 일반적 차이와 설정 방법을 정리한 자료다. 서버 설정 변경은 영향 범위를 확인한 뒤 신중히 적용한다.
#리다이렉트 #301리다이렉트 #302리다이렉트 #308리다이렉트 #307리다이렉트 #HTTP상태코드 #SEO #링크자산 #Nginx #Apache #htaccess #curl #리다이렉트체인 #메서드보존 #웹개발
'IT' 카테고리의 다른 글
| CORS 에러 완전 정리 — 교차 출처 차단 원인·프리플라이트·서버별 해결 (0) | 2026.06.28 |
|---|---|
| HTTP 304 Not Modified — 캐시 검증·조건부 요청 동작과 디버깅 (0) | 2026.06.28 |
| "이 사이트에 연결할 수 없음" 종합 자가진단 — 원인 찾기·해결 (0) | 2026.06.25 |
| ERR_CONNECTION_RESET — 연결이 재설정됨·도중에 끊김 원인·해결·예방 (0) | 2026.06.24 |
| ERR_TOO_MANY_REDIRECTS — 리다이렉트가 너무 많음·무한 루프 원인·해결·예방 (0) | 2026.06.24 |
댓글