301 vs. 302 리다이렉트

301과 302 리다이렉트의 차이는 미묘해 보입니다—둘 다 브라우저에게 다른 곳으로 이동하라고 말합니다. 하지만 이 세 자리 숫자의 차이는 엄청난 결과를 초래합니다. 잘못 선택하면 사이트가 검색 순위에서 사라질 수 있습니다. 뭔가 고장나서가 아니라, 검색 엔진에게 의도에 대해 잘못된 정보를 전달했기 때문입니다.

핵심 차이점

두 리다이렉트 모두 "다른 곳으로 이동하라"고 말합니다. 차이는 미래에 대해 무엇을 암시하느냐에 있습니다:

301 Moved Permanently: 이름 변경입니다. 기존 URL은 사라졌습니다. 기록을 업데이트하세요.

302 Found: 임시 전달 주소입니다. 기존 URL은 여전히 중요합니다. 나중에 다시 확인하세요.

그게 전부입니다. 그 외 모든 것—캐싱 동작, SEO 영향, 브라우저 처리 방식—은 이 단 하나의 의미 차이에서 비롯됩니다.

리다이렉트 작동 방식

리다이렉트가 설정된 URL을 요청하면, 서버는 3xx 상태 코드와 Location 헤더로 응답합니다:

GET /old-page HTTP/1.1
Host: example.com

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

브라우저는 자동으로 새 위치를 요청합니다. 리다이렉트가 아닌 최종 목적지가 표시됩니다.

301: 영구 이전

301은 세상에 말합니다: "이 URL은 영구적으로 이전되었습니다. 더 이상 사용하지 마세요."

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

발생하는 일:

• 브라우저가 이 리다이렉트를 캐시합니다—종종 무기한으로
• 검색 엔진이 랭킹 신호의 90-99%를 새 URL로 이전합니다
• 검색 엔진이 색인에서 기존 URL을 새 URL로 교체합니다
• 북마크를 새 URL로 업데이트해야 합니다

301을 사용해야 할 때:

• 사이트 구조 개편 (/products/item-123 → /shop/item-123)
• 도메인 마이그레이션 (old-domain.com → new-domain.com)
• 중복 콘텐츠를 표준 URL로 통합
• HTTPS 강제 적용 (http:// → https://)

핵심 질문: 이 URL이 다시 돌아올 가능성이 있나요? 없다면 301을 사용하세요.

302: 임시 우회

302는 세상에 말합니다: "이 URL은 일시적으로 다른 곳에 있습니다. 원래 주소가 여전히 진짜 주소입니다."

HTTP/1.1 302 Found
Location: https://example.com/temporary-location

발생하는 일:

• 브라우저가 이 리다이렉트를 장기간 캐시하지 않습니다
• 검색 엔진이 원래 URL을 색인에 유지합니다
• 랭킹 신호가 원래 URL에 남아 있습니다
• 각 요청마다 리다이렉트가 여전히 적용되는지 확인합니다

302를 사용해야 할 때:

• 유지보수 페이지 (사이트가 일시적으로 다운된 경우)
• A/B 테스트 (일시적으로 일부 사용자를 다른 곳으로 보낼 때)
• 지역별 리다이렉트 (사용자가 이동할 수 있는 경우)
• 로그인 리다이렉트 (로그인 페이지로 보낸 후 원래 페이지로 돌아가기)
• 원래 URL이 "진짜" 주소로 남아야 하는 모든 상황

핵심 질문: 이 URL이 다시 정상으로 돌아올 건가요? 그렇다면 302를 사용하세요.

SEO 함정

여기서 사람들이 실수를 합니다:

사이트를 개편합니다. URL이 영구적으로 변경됩니다. 그런데 302를 사용합니다... 프레임워크의 기본값이어서, 신경 쓰지 않아서, 아니면 "리다이렉트는 다 같은 거 아닌가"라고 생각해서.

몇 달 후, 검색 순위가 급락한 것을 발견합니다. 기존 페이지에는 수년간의 백링크와 권위가 쌓여 있었습니다. 새 페이지에는 아무것도 없습니다. "이것은 임시입니다—기존 URL을 색인에 유지하세요"라고 Google에 알렸기 때문에 랭킹 신호가 이전되지 않았습니다.

Google은 기존 URL을 색인에 유지했습니다. 이제 그 URL들은 리다이렉트되는 페이지를 가리킵니다. 새 URL에는 아무런 역사가 없습니다. 스스로 SEO 파워를 잘라낸 셈입니다.

해결책은 간단하지만 느립니다: 302를 301로 변경하고 검색 엔진이 재처리하는 데 몇 주에서 몇 달을 기다리세요.

캐싱 함정

반대로 실수하는 것도 마찬가지로 고통스럽습니다:

유지보수 페이지를 띄웁니다. "어차피 리다이렉트니까"라는 생각에 301을 사용합니다. 유지보수가 끝납니다. 그런데 사용자들은 계속 유지보수 페이지를 봅니다. 브라우저가 301을 캐시해두어 여전히 유효한지 확인조차 하지 않기 때문입니다.

서버 측에서는 이를 고칠 수 없습니다. 리다이렉트가 사용자의 브라우저 안에 저장되어 있습니다. 사용자가 직접 캐시를 지워야 하거나, 캐시가 만료될 때까지 기다려야 합니다.

규칙: 영구적인 것에는 301. 임시적인 것에는 302. 예외는 없습니다.

307과 308: 메서드를 보존하는 변형

역사적인 특이점이 있습니다: 브라우저가 301/302 리다이렉트를 따를 때 POST 요청을 GET으로 바꾸는 경우가 있었습니다. 이로 인해 폼 제출이 중단되었습니다.

HTTP/1.1은 이를 보완한 더 엄격한 버전을 도입했습니다:

307 Temporary Redirect: 302와 같지만, 요청 메서드가 변경되지 않음을 보장합니다.

308 Permanent Redirect: 301과 같지만, 요청 메서드가 변경되지 않음을 보장합니다.

POST /old-endpoint HTTP/1.1
Content-Type: application/json
{"data": "value"}

HTTP/1.1 308 Permanent Redirect
Location: /new-endpoint

브라우저는 원래 본문을 그대로 유지한 채 /new-endpoint에 POST 요청을 보냅니다(GET이 아닙니다).

307/308을 사용해야 할 때:

• POST/PUT/DELETE를 받는 API 엔드포인트를 리다이렉트할 때
• HTTP 메서드 보존이 중요한 모든 리다이렉트

단순한 GET 요청의 경우, 301/302가 적합하며 호환성도 더 넓습니다.

리다이렉트 체인과 루프

체인은 리다이렉트가 다른 리다이렉트를 가리킬 때 발생합니다:

/page-1 → 301 → /page-2 → 301 → /page-3

각 홉마다 지연이 생기고 SEO 가치가 일부 손실됩니다. 최종 목적지를 직접 가리키도록 설정하세요.

루프는 리다이렉트가 순환을 형성할 때 발생합니다:

/page-a → 302 → /page-b → 302 → /page-a

브라우저가 이를 감지하고 "리다이렉트 횟수가 너무 많습니다"를 표시합니다. 리다이렉트 로직을 꼼꼼히 점검하세요.

구현

Nginx:

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

# 임시
location /product {
    return 302 /maintenance;
}

Apache:

# 영구
Redirect 301 /old-page /new-page

# 임시
Redirect 302 /product /maintenance

Node.js/Express:

// 영구
app.get('/old-page', function(request, response) {
    response.redirect(301, '/new-page');
});

// 임시
app.get('/product', function(request, response) {
    response.redirect(302, '/maintenance');
});

리다이렉트 테스트

curl -I https://example.com/old-page

다음과 같이 표시됩니다:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

또는 브라우저 DevTools → 네트워크 탭을 사용하세요. 리다이렉트된 요청을 클릭하면 상태 코드와 Location 헤더를 확인할 수 있습니다.

결정 기준

리다이렉트를 추가할 때, 한 가지 질문을 하세요:

"원래 URL이 언젠가 다시 올바른 URL이 될 가능성이 있나요?"

• 없다 → 301 (GET이 아닌 요청에는 308)
• 있다 → 302 (GET이 아닌 요청에는 307)

판단 기준은 이것 하나입니다. SEO, 캐싱, 브라우저 동작 등 모든 것이 이것을 올바르게 선택하면 자동으로 따라옵니다.

자주 묻는 질문

Google은 302 리다이렉트를 301과 다르게 처리하나요?

네, 상당히 다르게 처리합니다. 301의 경우 Google은 랭킹 신호를 새 URL로 이전하고 기존 URL을 색인에서 제거합니다. 302의 경우 Google은 원래 URL을 색인에 유지하고 리다이렉트가 임시적이라고 판단해 랭킹 파워를 이전하지 않습니다. 영구적인 이전에 302를 사용하면 더 이상 콘텐츠를 제공하지 않는 URL에 SEO 가치가 갇혀버릴 수 있습니다.

302를 나중에 301로 변경할 수 있나요?

네, 하지만 시간이 걸립니다. 검색 엔진이 변경을 인식하고 순위를 이전하기 시작하지만, 사이트 크롤링 빈도에 따라 몇 주에서 몇 달이 걸릴 수 있습니다. 처음부터 올바르게 설정하는 것이 훨씬 낫습니다.

실수로 임시 리다이렉트에 301을 사용하면 어떻게 되나요?

브라우저와 CDN이 리다이렉트를 무기한 캐시할 수 있습니다. 서버에서 리다이렉트를 제거한 후에도 브라우저에 301이 캐시되어 있어 사용자가 계속 리다이렉트될 수 있습니다. 사용자가 직접 캐시를 지우거나 캐시된 리다이렉트가 만료될 때까지 기다려야 하는데—이는 매우 오랜 시간이 걸릴 수 있습니다.

302/301 대신 307/308을 사용해야 하나요?

표준 페이지 리다이렉트(GET 요청)의 경우 301과 302가 잘 작동하며 호환성도 더 넓습니다. API 엔드포인트처럼 POST, PUT, 또는 DELETE 요청을 리다이렉트해야 할 때—HTTP 메서드 보존이 중요한 경우—307/308을 사용하세요.