301과 308 리디렉션 비교

TL;DR — 301과 308은 모두 영구 리디렉션이며 Google과 Bing은 검색에서 308을 301과 같은 방식으로 처리합니다. 핵심적인 기술 차이는 메서드 보장입니다. 308은 들어온 요청을 같은 방식으로 다시 보내므로 폼 제출도 그대로 유지하지만, 301은 POST에 대해 이를 엄격히 보장하지 않습니다. 일반 페이지 이동에는 301을 사용하고, API나 폼처럼 원래 메서드와 본문이 반드시 도착해야 하는 경우에만 308을 선택하세요. 쿠키나 자격 증명까지 상태 코드가 보장하는 것은 아니므로 실제 클라이언트로 테스트해야 합니다.

이 두 상태 코드는 무엇을 의미하는가

서버가 한 URL에서 다른 URL로 보내면 응답에 상태 코드를 붙입니다. 그중 두 코드는 “이 리소스가 영구적으로 이동했다”는 뜻입니다.

• 301 — “Moved Permanently”(영구 이동). 웹 초창기부터 사용된 가장 오래된 영구 리디렉션 코드입니다.
• 308 — “Permanent Redirect”(영구 리디렉션). 2015년에 추가된 더 새로운 코드로 같은 역할을 하면서 한 가지 보장을 더 제공합니다.

그 추가 보장이 핵심입니다. 폼을 제출하면 브라우저는 데이터를 담은 POST 요청을 보냅니다. 구식 301을 따라갈 때 브라우저는 조용히 POST를 일반 GET으로 바꿀 수 있고, 그 과정에서 데이터가 사라질 수 있습니다. 308은 그런 변환을 금지합니다. 새 주소에서 메서드와 데이터까지 포함한 요청을 정확히 다시 보내라고 지시합니다.

SEO에서 차이가 있는가? 아니다

여기서 가장 많이 오해합니다. 검색에서 301과 308은 같습니다. Google 공식 문서는 308을 “301과 동등함”이라고 설명하고, Gary Illyes와 Bing의 Fabrice Canel도 두 코드를 같은 방식으로 처리한다고 말했습니다.

“equivalent to 301.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 “we just merge that with 301 so we really don’t care.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 “Bing treats 308 redirects the same as 301 redirects.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」

따라서 308이 SEO에 더 좋다거나 순위 상승을 위해 모든 301을 308로 바꾸라는 말은 무시하세요. 상승 효과는 없습니다. 검색 엔진이 그렇게 밝히고 있습니다. Evidence for this claim Google treats 308 as equivalent to 301 for Search while advising sites to use the semantically appropriate status code. Scope: Google Search processing; client behavior still differs when method preservation matters. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

그럼 어느 것을 사용해야 하는가?

• 일반 페이지를 리디렉션하는가? URL 이동, HTTPS 전환, 도메인 변경이라면 → 301을 사용하세요. 대부분의 도구·CDN·플러그인이 기본적으로 이해하는 기본값입니다.
• 데이터를 담은 대상을 리디렉션하는가? API 엔드포인트, 폼 제출 URL, 로그인 POST라면 → 원래 메서드가 홉을 지나도록 308을 사용하세요. 단, 자격 증명과 쿠키가 기대한 방식으로 도착하는지는 별도로 확인해야 합니다.

API나 폼을 리디렉션하는 것이 아니라면 거의 확실히 301을 사용하면 됩니다. 이것이 짧은 결론입니다.

308이 왜 만들어졌는지, Google과 Bing이 정확히 무엇을 말했는지, 각 코드를 구현하는 방법까지 보려면 Advanced 탭으로 전환하세요.

TL;DR — 301과 308은 모두 영구 리디렉션이며 Google과 Bing은 308을 301과 동일하게 처리합니다. 프로토콜 수준의 핵심 차이는 메서드 보존입니다. 308(RFC 7538, 2015)은 새 URL에서 클라이언트가 같은 메서드와 본문을 다시 보내도록 보장하지만, HTTP/1.0 시대의 301은 특히 POST가 GET으로 바뀌는지 모호합니다. 308은 307의 영구 형제이며, 일반 페이지·사이트·HTTPS 마이그레이션에는 301이 실용적인 기본값입니다. API·웹훅·폼·인증 POST처럼 non-GET 요청을 보존해야 할 때만 308을 사용하고 실제 클라이언트에서 자격 증명·쿠키·멱등성을 검증하세요. 어느 코드도 SEO에서 더 우월하지 않습니다. “equivalent > to 301,” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 “we just merge that with 301,” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」

먼저 의미상의 차이를 보자

301과 308은 영구성에 관해 검색 엔진에 같은 메시지를 보냅니다. 리소스가 완전히 이동했고 대상이 표준이 되어야 한다는 뜻입니다. 둘의 차이는 클라이언트가 요청을 다시 보낼 때 지켜야 하는 좁고 기계적인 보장 하나입니다.

• **301 (Moved Permanently)**은 HTTP/1.0 시대부터 있던 원래의 영구 리디렉션 코드입니다. 요청 메서드를 보존해야 하는지 항상 모호했고, 실제 브라우저와 클라이언트는 301을 따라갈 때 POST를 GET으로 바꾸어 왔습니다. 일반 페이지에는 괜찮지만 메서드나 본문에 의존하는 요청을 조용히 망가뜨릴 수 있습니다.
• **308 (Permanent Redirect)**은 엄격한 버전입니다. 새 URL에서 정확히 같은 메서드와 본문을 다시 보내도록 보장합니다. POST는 POST로 남고 payload도 함께 이동합니다.

한 문장으로 말하면 308은 브라우저가 POST를 GET으로 조용히 바꾸지 않는다는 보장이 추가된 301입니다. Evidence for this claim RFC 9110 defines both 301 and 308 as permanent redirects; 308 forbids changing the request method, while 301 permits POST-to-GET rewriting for historical reasons. Scope: HTTP semantics for 301 and 308 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §§15.4.2, 15.4.9 IETF: RFC 7538 §3 — 308 Permanent Redirect

308은 왜 존재하는가: 빠져 있던 “영구 307”

거의 아무도 설명하지 않지만 비교 전체를 이해하는 가장 깔끔한 방법입니다. 사양에 빈틈이 있었기 때문입니다.

최신 리디렉션 코드는 임시·영구와 느슨함·엄격함의 격자로 볼 수 있습니다.

RFC 7231은 느슨하고 모호한 302의 엄격한 대응으로 307을 정의했습니다. 307은 임시이며 메서드를 보존하지만 영구적인 메서드 보존 코드는 없었습니다. RFC 7538(2015년 4월)이 이 빈틈을 채우기 위해 308을 추가했습니다. 308은 301에 대해 307이 302에 해당하는 것과 같은 관계입니다. 이 클러스터의 302-vs-307 비교를 읽었다면 한 줄 위의 영구 버전이라고 이해하면 됩니다.

301은 이 프레임워크보다 오래되었습니다. 메서드 보존 개념이 정식화되기 전 HTTP/1.0에서 나왔기 때문에 모호하며, 이를 명확히 하는 대신 308을 새로 만들어야 했습니다.

실무에서 “메서드와 본문 보존”이 의미하는 것

대부분의 리디렉션은 링크를 클릭해 브라우저가 GET을 보내고 서버가 다른 곳으로 보내는 경우라 실질적인 차이가 없습니다. 현대 브라우저는 301에서도 GET을 잘 보존합니다. 차이는 일반 GET이 아닌 요청에서 나타납니다.

301의 위험은 POST와 요청 본문에 집중됩니다. 폼·API·웹훅·인증 흐름이 해당합니다. “301은 항상 내 폼을 깨뜨린다”는 과장입니다. 일반 GET은 안전하지만, PUT·DELETE 동작은 RFC에 명시되어 있지 않으므로 실제 클라이언트로 확인해야 합니다. 308은 반복하는 메서드를 바꾸지 않도록 금지합니다. 여기서 보장하는 것은 메서드 보존이며 헤더·쿠키·자격 증명이나 전체 트랜잭션까지 보장하는 것은 아닙니다.

Google은 SEO에서 301과 308을 다르게 처리하는가? 아니다

문서와 Google 관계자, Bing이 수년째 일관되게 같은 답을 하는 드문 리디렉션 질문입니다.

Google의 HTTP 상태 코드 문서는 301과 308을 같은 버킷에 둡니다. 301 행은 대상이 처리되어야 한다는 강한 신호라고 하고, 308 행은 **“301과 동등함”**이라고 한 줄로 표시합니다. 두 코드를 직접 동등하게 표현한 Google 공식 문서가 가장 강한 근거입니다. Evidence for this claim Google treats 308 as equivalent to 301 for Search while advising sites to use the semantically appropriate status code. Scope: Google Search processing; client behavior still differs when method preservation matters. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

“Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 “Equivalent to 301.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」

Google의 리디렉션 가이드도 301과 308이 페이지의 영구 이동을 뜻한다고 시작하며 둘 사이에 더 이상의 SEO 차이를 두지 않습니다.

“The 301 and 308 status codes mean that a page has permanently moved to a new location” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」

문서에 명시되기 전부터 Google 관계자들도 같은 설명을 해 왔습니다.

• Gary Illyes(2021): Google은 308을 301과 합쳐 처리한다고 설명했습니다. • John Mueller(2018): 308을 301처럼 사용하면 그렇게 처리하겠다고 말했습니다. 이는 공식 문서보다 오래된 Google의 비공식 입장입니다.

“just merge[s] that with 301 so we really don’t care.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 “Three years later it was added to the official Google documents that Google treats 308 redirects like 301 redirects — so now it is official.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 “If you use it [a 308 redirect] like a 301 we’ll treat it as such.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」

Google 문서에는 중요한 뉘앙스가 하나 있습니다. 두 코드를 같은 방식으로 처리하더라도 의미는 다르므로 다른 클라이언트와 검색 엔진이 이점을 얻을 수 있게 리디렉션에 적합한 상태 코드를 선택하라고 합니다. SEO가 아니라 정확성과 상호 운용성을 기준으로 선택하세요.

“While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」

Bing은 301과 308을 다르게 처리하는가? 역시 아니다

이 주제의 글은 Google만 다루는 경우가 많습니다. 하지만 2024년 9월 Bing의 Fabrice Canel은 영구 308을 301과 같은 방식으로 처리하는지 묻는 질문에 Bing도 동일하게 처리한다고 직접 답했습니다. 이는 2021년 Google의 설명과 일치합니다.

“Bing treats 308 redirects the same as 301 redirects.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」

두 주요 검색 엔진 모두 308이 크롤링·색인·신호 통합에서 301과 기능적으로 같다고 밝혔습니다. 어느 엔진도 308을 SEO에 더 유리하게 처리하지 않습니다.

깨야 할 오해: “308이 SEO에 더 좋으니 301을 모두 바꿔라”

낮은 품질의 글들이 계속 암시하므로 단호하게 말하겠습니다. 일반 리디렉션에서 301보다 308을 선택해 얻는 SEO 이점은 없고, 기존 301을 308로 일괄 변경할 이유도 없습니다. 이는 의견이 아니라 검색 엔진의 명시적 입장입니다.

• Google 문서: 308은 “301과 동등함”.
• Illyes: 301과 합쳐 처리함.
• Canel: Bing은 308을 301과 동일하게 처리함.

“equivalent to 301.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 “we just merge that with 301.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 “treats 308 redirects the same as 301 redirects.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」

301을 308로 대량 교체해도 순위 상승은 0이며, 301·302만 안정적으로 인식하는 오래된 도구나 엣지 시스템에서 위험이 생길 수 있습니다. 순수한 변경 비용입니다.

이 오해는 “301은 PageRank를 잃는다”는 진짜 논쟁적 오해와 구분해야 합니다. PageRank 희석 주장은 Google이 반복해서 바로잡았지만, 301과 308의 동등성은 Google·Bing·문서가 2018년 이후 일관되게 말해 온 정리된 질문입니다. 전체 PageRank 이야기는 이 클러스터의 301-vs-302 비교 글에서 다룹니다.

308이 기술적으로 올바른 선택인 경우

순위가 아니라 기능이 요청 메서드나 본문을 잃으면 깨지는 경우 308을 선택하세요.

• API 엔드포인트 — 클라이언트가 POST/PUT/DELETE를 보내는 주소를 옮길 때.
• 웹훅 URL — 삭제할 수 없는 payload를 발신자가 POST로 보낼 때.
• 폼 action 대상 — <form>이 보낸 데이터를 새 URL에 그대로 전달해야 할 때.
• 인증·로그인 POST 흐름 — 자격 증명이나 토큰이 본문에 있을 때.

POST에서는 301이 클라이언트를 GET으로 바꾸어 본문을 버릴 위험이 있지만 308은 변환을 금지합니다. PUT·DELETE에 관한 301 동작은 RFC가 어느 쪽도 명확히 설명하지 않으므로 추측하지 마세요. 308의 메서드 보존 규칙은 어떤 메서드에도 적용됩니다.

API·웹훅·인증 흐름을 전환하기 전에는 상태 코드만으로 모든 것이 홉을 통과한다고 보장할 수 없습니다. 같은 변경에서 다음을 확인하세요.

• 자격 증명·쿠키·인증 헤더. 어느 코드도 이를 보장하지 않으므로 브라우저·SDK·웹훅 발신자 등 실제 클라이언트로 테스트하세요.
• 교차 출처 동작. 출처가 바뀌면 브라우저나 fetch 클라이언트가 보내는 값이 달라질 수 있으므로 수동 curl만으로 판단하지 마세요.
• 멱등성과 중복 부작용. 결제 POST나 레코드를 만드는 웹훅처럼 반복 요청이 멱등적이지 않으면 리디렉션 후 재시도로 두 번 실행될 수 있습니다.
• 캐시를 고려해 단계적으로 배포·롤백하기. 301과 308은 경험적으로 캐시될 수 있으므로 기존 응답을 캐시한 클라이언트와 새 클라이언트 모두 테스트하고 캐시 상태를 고려한 롤백 계획을 세우세요.

301이 실용적인 기본값으로 남는 경우

SEO에서 리디렉션하는 대부분의 일반 GET에는 301이 합리적인 기본값입니다.

• 일반 페이지·URL 변경과 콘텐츠 이동
• 도메인 변경과 사이트 통합
• HTTP → HTTPS 마이그레이션
• www/비www 또는 trailing slash 변형 통합

308이 더 엄격한데도 왜 오래된 코드를 기본으로 삼을까요? 실무적인 이유가 세 가지 있습니다.

1. 더 넓은 인식 범위. 301은 308보다 20년 앞서 나왔고 브라우저·프록시·CDN·크롤러·분석 도구 대부분이 인식합니다. 308도 널리 지원되지만 레거시 클라이언트와 엣지 도구까지 모두 인식한다고 가정하지 마세요.
2. 도구 현실. WordPress 리디렉션 플러그인, Cloudflare 규칙 빌더, 일부 서버리스·CDN 플랫폼은 301/302를 기본으로 노출하거나 설정과 달리 302/307을 보낼 수 있습니다. 플랫폼이 실제로 지원하는 범위가 결정 요인입니다.
3. 얻을 것이 없음. Google과 Bing은 크롤링·색인에서 두 코드를 같은 방식으로 처리하므로 일반 페이지 이동에서 지원 범위가 좁은 코드를 선택할 SEO 이점이 없습니다.

경험칙: 일반 GET은 301, 보존해야 하는 non-GET 요청은 308입니다.

각 코드 구현하기

문법은 거의 같고 숫자만 바꾸면 됩니다.

Apache (.htaccess) 301/301/308/308

# 301 — permanent, for a normal page move
Redirect 301 /old-page /new-page

# 308 — permanent + method-preserving, for an API/form endpoint
RewriteEngine On
RewriteRule ^old-api/(.*)$ /new-api/$1 [R=308,L]

nginx

# 301
location = /old-page {
    return 301 /new-page;
}

# 308 — preserves POST body to the API
location = /old-api {
    return 308 /new-api;
}

둘 모두에 적용되는 주의점이 있습니다. 일부 CDN·엣지 플랫폼·CMS 플러그인은 설정한 308을 그대로 보내지 않고 301/302/307을 보낼 수 있습니다. 메서드 보존이 중요하다면 설정을 믿지 말고 URL을 curl로 호출해 실제 상태 줄을 확인하세요. 지시문 문법은 서버 버전과 프레임워크에 따라 달라질 수 있으므로 현재 문서를 확인하세요.

301과 308의 선택보다 더 중요한 레버: 체인 길이

어느 코드를 고르든 더 큰 성능 레버는 리디렉션을 짧게 유지하는 것입니다. Google은 포기하기 전 약 10개의 리디렉션 홉까지 따라가며, 홉이 늘수록 지연과 신호 분산 가능성이 커집니다. 올바른 코드로 한 번에 보내는 깔끔한 홉이 기술적으로 맞는 코드 여러 개의 체인보다 낫습니다. 최종 대상에 직접 보내세요.

이 글의 위치

301과 308은 두 영구 리디렉션 코드입니다. 이 클러스터에는 임시 형제인 302와 엄격한 307, 다른 3xx인 303도 있습니다. 비교 글은 301-vs-302(영구 대 임시), 302-vs-307(임시·느슨함 대 엄격함), 이 글(영구·느슨함 대 엄격함)으로 격자를 이룹니다. 체인과 루프 같은 운영 위험도 확인하세요. 전체 응답은 HTTP 상태 코드 허브, 표준화 신호로서의 리디렉션은 표준화에서 볼 수 있습니다.

AI 요약

고급 버전의 핵심은 다음과 같습니다.

• 둘 다 영구 리디렉션이며 Google과 Bing은 308을 301과 동일하게 처리합니다. Google 문서는 308을 301과 동등하다고 하고, Illyes와 Bing도 같은 입장입니다.
• 프로토콜 차이는 메서드 보존입니다. 308은 같은 메서드와 본문을 보장하지만 301은 특히 POST→GET이 모호합니다. PUT·DELETE에는 같은 주의를 일반화하지 말고 실제 클라이언트로 확인하세요.
• 308이 존재하는 이유: RFC 7231의 임시 메서드 보존 코드 307에 영구 형제가 없었고 RFC 7538이 그 빈틈을 채웠습니다.
• 실무상 non-GET에서만 중요합니다. 일반 GET은 301에서도 안전하고 위험은 폼·API·웹훅·인증의 요청 본문입니다.
• non-GET을 보존해야 하면 308, 나머지는 301을 사용하세요. 301은 더 오래되고 CDN·CMS·플러그인 지원이 넓습니다.
• 308이 SEO에 더 좋다는 말은 오해입니다. 검색 엔진은 동등하게 처리하므로 일괄 변경하지 마세요.
• 더 큰 레버는 체인을 짧게 유지하는 것입니다. Google은 약 10홉까지 따라가므로 최종 URL로 직접 보내세요.

“equivalent to 301,” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 “we just merge that with 301,” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 “Bing treats 308 redirects the same as 301 redirects.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 302

공식 문서

검색 엔진과 사양의 1차 문서입니다.

Google

• HTTP 상태 코드·네트워크·DNS 오류와 Google Search — 308이 301과 동등하다는 표.
• Google Search의 리디렉션 — 두 코드가 영구 이동이라는 설명.
• URL 변경이 있는 사이트 이동 — 마이그레이션에서 영구 리디렉션을 유지하는 방법.
• Search Off the Record — 리디렉션 이야기 — 307·308을 다루는 에피소드. 308

Bing / Microsoft

• Bing과 웹사이트 마이그레이션 — 영구 이동 신호에는 301이면 충분하다는 안내.

사양·참고 자료

• RFC 7538 — HTTP 상태 코드 308 — 영구·메서드 보존 리디렉션을 만든 2015년 사양.
• MDN — 308 Permanent Redirect — 메서드와 본문 보존 설명 및 301과의 비교.

출처 인용

Google과 Bing의 기록된 발언입니다. 원문 페이지가 지원하면 각 링크는 인용 부분으로 이동하는 deep link입니다.

Google 문서 — 308은 301과 동등함

Google 문서 — 308은 301과 동등함

• 301 행의 강한 대상 처리 신호, 308 행의 동등 처리, 그리고 검색에서는 같지만 의미는 다르므로 기술적으로 적합한 코드를 선택하라는 주의입니다.

“Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 “Equivalent to 301.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 자료 자료 자료

Google 문서 — 두 코드는 “영구 이동”을 뜻함

Google 문서 — 두 코드는 “영구 이동”을 뜻함

• 두 상태 코드가 페이지가 새 위치로 영구 이동했음을 뜻한다는 설명입니다.

“The 301 and 308 status codes mean that a page has permanently moved to a new location.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 자료

Gary Illyes, Google(2021) — 308을 301과 합쳐 처리한다는 설명

Gary Illyes, Google

• 308을 301과 합치므로 실제로는 신경 쓰지 않는다는 발언. 보도

“we just merge that with 301 so we really don’t care iirc.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」

John Mueller, Google(2018) — 더 이른 비공식 입장

John Mueller, Google

• 308을 301처럼 사용하면 그렇게 처리한다는 발언. 보도

“If you use it [a 308 redirect] like a 301 we’ll treat it as such.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」

Fabrice Canel, Microsoft Bing(2024) — Bing의 동등 처리

Fabrice Canel, Microsoft Bing

• Bing은 308을 301과 동일하게 처리한다고 확인했습니다. 보도

“Bing treats 308 redirects the same as 301 redirects.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」

참고: 두 Google 문서의 deep link는 실시간 문서의 #:~:text= fragment를 사용합니다. Illyes(2021), Mueller(2018), Canel(2024)의 발언은 당시 Search Engine Roundtable 보도를 통해 재현한 것이므로 원문을 확인하세요. Search Off the Record 에피소드는 307·308을 논의하지만 공식 transcript를 이 글에서 직접 확보하지 않았으므로 직접 인용하지 않았습니다. 301

어떤 영구 리디렉션을 사용해야 하는가: 301 또는 308?

Google과 Bing이 크롤링·색인에서 301과 308을 같은 방식으로 처리하므로 이 트리는 순위가 아니라 요청의 메서드와 본문을 보존해야 하는지를 묻습니다.

짧게 말하면 일반 GET은 301, 보존해야 하는 non-GET 요청은 308입니다. SEO에서 둘은 서로 바꿔 쓸 수 있으므로 메서드 질문이 유일한 결정 요인입니다.

영구성 × 메서드 격자

두 축으로 일반적인 네 가지 리디렉션 코드를 고르세요. SEO 처리는 첫 번째 축을 따르고 애플리케이션 동작은 두 번째 축을 따릅니다.

다음 순서로 판단하세요:

1. 이동이 영구적인가요? 아니면 임시 행에 머물고, 그렇다면 영구 행을 선택해 대상이 의도한 표준 URL이 되게 합니다.
2. 요청에 반드시 보존해야 할 메서드·본문이 담길 수 있나요? 일반 페이지 GET에는 엄격한 보장이 필요하지 않지만, POST, PUT, DELETE, 웹훅, 폼, API 호출에는 필요할 수 있습니다.
3. 셀을 고르세요. 일반적인 영구 페이지 이동은 301, 영구적인 non-GET 엔드포인트 이동은 308입니다.
4. 실제 응답을 검증하세요. UI나 프레임워크에서 고른 코드와 플랫폼 기본값이 다를 수 있으므로 설정만이 아니라 리디렉션된 요청과 응답을 테스트하세요.

이 표가 의도적으로 단순하게 만드는 SEO 질문은 이것입니다. Google과 Bing은 301과 308을 동일하게 처리하므로 둘 중 선택은 HTTP 정확성에 달려 있습니다.

301과 308 한눈에 보기

경험칙: 일반적인 영구 페이지 GET은 301, non-GET 요청을 그대로 받아야 하는 영구 엔드포인트 이동은 308입니다.

영구 리디렉션을 검증하는 도구

Patrick의 무료 도구

• Redirect Checker — 실제 첫 상태, 모든 홉, 최종 대상을 확인합니다. 308을 설정했는데 플랫폼이 301, 302, 307을 보낸 경우를 찾습니다.
• Bulk HTTP Status Code Checker — 최대 500개 페이지 URL을 검사하고 마이그레이션 중 섞인 코드와 체인을 내보냅니다. 308

메서드 보존이 중요할 때 검증하기

• 실제 메서드와 안전한 테스트 payload를 사용한 curl — 리디렉션된 요청이 POST/PUT/DELETE로 남고 대상이 본문을 받는지 확인합니다. 스테이징이나 비파괴 엔드포인트를 사용하세요.
• 애플리케이션·게이트웨이 로그 — 출발지와 대상에서 메서드와 본문 처리를 비교합니다. 상태 검사기는 308을 확인할 수 있지만 요청이 온전히 도착했는지는 수신 시스템만 증명할 수 있습니다.
• 브라우저 DevTools Network 패널 — 폼 흐름에 유용하지만 API·웹훅 클라이언트도 별도로 테스트하세요. 바로 그 클라이언트 동작 때문에 301과 308의 차이가 존재합니다. 308

스스로 테스트하기: 301과 308

두 영구 리디렉션의 차이와 검색 엔진의 처리에 관한 다섯 가지 질문입니다. 각 답을 고른 뒤 확인하세요.

읽어 볼 만한 자료

관련 글

• 리디렉션 11가지 유형과 SEO 영향 — 모든 리디렉션 유형과 308이 원래 HTTP 메서드를 보존한다는 설명을 다룹니다. SEO에서는 같지만 폼 데이터에서 GET·POST를 바꾸면 안 된다는 실무 결론도 있습니다.
• HTTP 상태 코드와 SEO 영향 — 308의 기능과 301과 같은 처리에 관한 글입니다.
• 기술 SEO 초보자 가이드 — 더 큰 맥락에서 리디렉션의 위치를 설명합니다.

“has the same functionality as a 301 redirect, except you can’t switch between POST and GET,” (번역) 「301과 기능은 같지만 POST와 GET을 서로 바꿀 수 없다는 뜻입니다.」 “308s are treated the same as 301s and consolidate forward.” (번역) 「308은 301과 같은 방식으로 처리되어 신호를 앞으로 통합한다는 뜻입니다.」

발표 자료

• Patrick Stox on SlideShare 및 Speaker Deck — 리디렉션과 표준화를 다루는 기술 SEO 발표 자료입니다. “이는 시스템에 대한 나의 이해이며 100% 완전하거나 정확하지 않을 수 있다”는 고지를 적용합니다.

공식 자료

• Google — HTTP 상태 코드와 Google Search 및 리디렉션 가이드.
• RFC 7538 — HTTP 상태 코드 308 — 308이 존재하는 이유.
• MDN — 308 Permanent Redirect — 메서드·본문 보존 참고 자료.

업계 자료

• Google이 공식적으로 308을 301처럼 처리 — Illyes의 발언.
• Google이 308을 301처럼 처리할 수 있음 — Mueller의 초기 설명.
• Bing은 308을 301과 동일하게 처리 — Canel의 확인.
• Google이 리디렉션 유형의 오해를 반박 — 기술적으로 올바른 코드를 선택하라는 설명.
• 308 Permanent Redirect: 의미와 사용 시점 — 비교용 개요.
• r/TechSEO — 리디렉션 디버깅 커뮤니티.

변경 내역