언어

302 리디렉션

302 임시 리디렉션의 의미, Google의 약한 대상 처리 신호와 표준 URL 처리, A/B 테스트·프로모션·지역 라우팅·유지보수에서의 올바른 사용법을 설명합니다.

최초 게시: 2026년 7월 2일 · 최근 업데이트: 2026년 8월 8일 · Advanced
언어
AI작성자AI v2
이 페이지의 근거 신호 1개

302(Found)는 임시 리디렉션으로 방문자를 새 URL로 보내면서 원래 URL을 검색 결과에 유지하라는 신호입니다. Google의 크롤링 인프라는 302를 대상 처리의 약한 신호로 부르지만 색인 파이프라인은 임시 리디렉션을 대상 표준화 신호로 사용하지 않습니다. 302의 링크 신호가 0이라는 통념은 틀렸고, 오래 유지하면 고정된 기한 없이 301처럼 처리될 수 있습니다. A/B 테스트·지역/기기 라우팅·임시 유지보수·기간 제한 프로모션에는 302를, 영구 이동에는 301을 사용하세요.

TL;DR — 302(“Found”)는 임시 리디렉션입니다. Google의 정확한 설명은 두 단계로 나뉩니다. 크롤링 인프라는 대상을 처리하라는 약한 신호로 보고, 301은 강한 신호로 봅니다. 별도의 Search 색인 파이프라인은 임시 리디렉션을 대상이 표준이어야 한다는 신호로 사용하지 않지만 다른 신호로 대상이 색인될 수 있습니다. 링크 신호 전달과 표준화 선호를 혼동하지 마세요. 오래 유지된 302는 고정된 공개 일정 없이 301처럼 바뀔 수 있습니다. Google은 A/B 테스트에 301 대신 302를 권장합니다. 영구 이동에 302를 쓰지 말고, 사용자 입력을 검증하지 않은 채 대상 URL을 만들지도 마세요.

”Moved Temporarily”에서 “Found”로: 짧은 역사

302는 모호하게 태어났습니다. HTTP/1.0에서는 **“Moved Temporarily”**라고 불렸고 사양은 클라이언트가 따라갈 때 원래 메서드를 재사용해야 한다고 했습니다. 하지만 실제 브라우저는 많은 경우 리디렉션에서 POST를 GET으로 조용히 바꾸었습니다. HTTP/1.1은 현실을 반영해 302를 **“Found”**로 이름을 바꾸고 GET으로 전환하는 303 (See Other), 메서드를 절대 바꾸지 않는 **307 (Temporary Redirect)**을 추가했습니다. 현재 RFC 9110(2022)도 302에서 POST→GET이 가능하다고 적는데, 메서드를 바꾸면 안 되는 경우에 307이 존재하는 이유입니다. 일상적인 GET 페이지 리디렉션에서는 검색 엔진 관점의 302와 307이 비슷하고 메서드 보존 차이는 폼·API 요청에서만 중요합니다. Evidence for this claim RFC 9110 defines 302 Found as a temporary move to another URI and notes that user agents may change POST to GET when following it. Scope: HTTP semantics for 302 responses. Confidence: high · Verified: IETF: RFC 9110 §15.4.3 — 302 Found

“Moved Temporarily,” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」

검색 목적에서 Google은 302(found)·303(see other)·**307(temporary redirect)**을 “Temporary”로 묶고, 301·308을 “Permanent”로 구분합니다.

둘 중 선택할 때의 간단한 판단:

  • 302 — 따라가는 클라이언트가 POST를 GET으로 바꿀 수 있습니다(RFC 9110). 일반 GET 페이지에는 괜찮지만 메서드 변경을 허용할 수 없으면 피하세요.
  • 307 — 메서드를 바꾸지 않고 다른 요청으로 재전송하지도 않습니다. 폼·API 요청을 보낸 그대로 재생해야 할 때 사용하세요.
  • 303 — 보통 GET/HEAD로 가져오는 다른 비동등 리소스를 의도적으로 가리킵니다. POST 후 확인 페이지로 보내는 전형적인 패턴이지 원래 요청의 동일한 대체물이 아닙니다.
  • 캐싱 — RFC 9111에 따라 302는 상태 코드만으로 경험적 캐시가 되지 않습니다. 명시적인 freshness 또는 cache 지시를 설정한 경우에만 저장·재사용됩니다.

약한 신호와 강한 신호: Google의 정확한 표현

통념을 건너뛰고 Google의 실제 문서를 보세요. 크롤링 인프라 문서에서 Google은 302를 약한 신호라고 말합니다.

“By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (번역) 「기본적으로 Google 크롤러는 리디렉션을 따라가며 Google 시스템은 대상이 처리되어야 한다는 약한 신호로 리디렉션을 사용합니다.」

Evidence for this claim Google's crawling-infrastructure documentation says crawlers follow a 302/303 and Google systems use it as a weak signal that the target should be processed; it also warns that product behavior can differ. Scope: product-specific crawl and processing handoff Confidence: high · Verified: How HTTP Status Codes Affect Google's Crawlers

같은 표의 301 행은 한 단어만 다르고 **strong(강한)**이라고 합니다.

“Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (번역) 「Google은 리디렉션을 따라가며 대상이 처리되어야 한다는 강한 신호로 리디렉션을 사용합니다.」

Evidence for this claim Google's crawling-infrastructure documentation says crawlers follow a 302/303 and Google systems use it as a weak signal that the target should be processed; it also warns that product behavior can differ. Scope: product-specific crawl and processing handoff Confidence: high · Verified: How HTTP Status Codes Affect Google's Crawlers

“약함”은 “0”이라는 뜻이 아닙니다. 다만 무엇이 약한지 정확히 구분해야 합니다. 서로 다른 Google 시스템이 하나의 연속선이 아니라 서로 다른 단계에 대해 말하고 있습니다.

  • 크롤링 인프라는 리디렉션 대상이 처리되는지, 즉 Google 크롤러가 대상을 가져와 살펴볼지를 말합니다.
  • Search 색인 파이프라인은 그보다 뒤의 별도 단계입니다. 임시 리디렉션을 대상이 표준이어야 한다는 신호로 사용하지 않지만 다른 표준화 신호가 있으면 대상이 색인될 수 있다고 합니다. Evidence for this claim Google follows a 302 temporary redirect but does not use it as a signal that the destination should become canonical; Google recommends 302 rather than 301 for temporary site tests. Scope: Google Search handling of temporary redirects and A/B tests. Confidence: high · Verified: Google: Redirects and Google Search Google: Website testing

“Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical. The target page might still be indexed if other canonicalization signals are present.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」

함께 읽으면 302는 Google이 대상을 보러 가도록 약하게 밀어 주지만, 색인 파이프라인은 같은 리디렉션을 대상 표준화의 투표로 보지 않습니다. 대상은 302 자체가 아니라 다른 신호 때문에 색인·표준이 될 수 있습니다. 이를 “302는 대상 표준화에 대한 약한 투표”라고 단순화하지 마세요. 두 문서는 서로 다른 범위를 설명합니다.

하나가 아닌 두 가지 메커니즘

경쟁 글들이 서로 섞어 버리는 부분입니다. 다음 두 가지를 분리해서 보세요.

  1. 302의 링크 신호·PageRank 전달은 0이 아닙니다. Gary Illyes는 2016년에 Google이 301·302 등 30x에서 PageRank 희석을 더 이상 적용하지 않는다고 말했고, Mueller도 302가 일반 리디렉션처럼 동작하며 PageRank를 전혀 전달하지 않는 것은 아니라고 설명했습니다. 이는 Google 관계자의 공개 발언이지 모든 상황에 대한 공식적인 보편 보장은 아닙니다.
  2. 표준화·색인 선호가 실제로 달라지는 메커니즘입니다. 301은 대상을 색인하라는 강한 신호이고 302는 약한 신호이므로 기본적으로 출발지를 색인합니다.

“do work the same as normal redirects… It’s not that they don’t pass any PageRank or anything like that.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」

“302가 PageRank를 전달하는가?”와 “302가 순위를 매기는 URL을 바꾸는가?”는 다른 질문입니다. 첫 번째 답은 예, 두 번째 답은 기본적으로 아니요입니다. 둘을 섞은 것이 “302=가치 0”이라는 오해를 만들었습니다.

URL을 리디렉션하면 Google은 출발지와 대상 양쪽을 추적합니다. 둘 중 하나가 표준이 되고 다른 하나는 표준 URL의 대체 이름이 됩니다. 어느 쪽인지는 임시인지 영구인지 같은 신호에 달려 있습니다. 302에서는 당분간 출발지가 표준으로 남습니다. Evidence for this claim A 302 expresses temporary intent, but it does not guarantee that the source URL will always remain Google's selected canonical or that the target cannot index through other signals. Scope: redirect crawling, indexing, and canonicalization Confidence: high · Verified: Redirects and Google Search

“Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical; which one, depends on signals such as whether the redirect was temporary or permanent. The other URL becomes an alternate name of the canonical URL.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」

302를 너무 오래 유지하면 일어나는 일: “플립”

사람들을 놀라게 하는 부분입니다. 제거되지 않은 임시 리디렉션은 더 이상 임시로 처리되지 않을 수 있습니다. Mueller는 302를 장기간 유지하면 결국 301과 정확히 같은 방식으로 처리한다고 말했습니다.

“if you have 302 redirects for the long run, we treat them exactly the same as 301 redirects anyway.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」

왜 이런 일이 일어날까요? 내 Ahrefs 표준화 가이드에서 설명한 관찰 기반 실무 모델을 사용하면 저울이 기우는 것과 같습니다. 영구 리디렉션은 새 URL로 신호를 앞으로 보내고 임시 리디렉션은 원래 URL로 뒤로 보냅니다. 그러나 모든 링크·내부 링크·사이트맵이 새 URL을 가리키면 균형이 달라집니다.

“If a temporary redirect is left in place long enough or the URL it’s redirected to already exists, it may be treated as a permanent redirect and send signals forward instead. It requires enough signals to flip the scale we saw earlier for canonicalization signals. As links build up, internal links are changed, sitemap URLs are updated, etc., more signals point to the new URL than the old URL, and the flip occurs.” (번역) 「임시 리디렉션을 충분히 오래 두거나 대상 URL이 이미 존재하면 영구 리디렉션처럼 처리되어 신호를 앞으로 보낼 수 있습니다. 링크·내부 링크·사이트맵이 새 URL을 더 많이 가리킬 만큼 표준화 신호의 저울이 기울면 전환이 일어납니다.」

문제는 얼마나 걸리는지 아무도 모른다는 것입니다. Google이 302를 실수로 영구 이동에 사용했다고 판단하면 더 빨리 301처럼 처리할 수도 있습니다. “며칠”처럼 특정 숫자를 인용하지 마세요. Google이 공개한 기한은 없고 Bing의 “2일”도 Google이 확인한 수치가 아닙니다.

“Nobody knows how long a 302 redirect has to exist before Google starts treating it as a 301 redirect. Usually, it’s a few weeks to a few months, but it can be days, weeks, or months.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 “Only if Google thinks you used a 302 redirect by mistake for a permanent move does this not happen. In that case, it treats the redirect as a 301… In some circumstances, Google even appears to treat 302s as 301s from the get-go.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 자료

Bing이 302를 처리하는 방식: 헤더뿐 아니라 동작을 본다

Bing도 다른 경로로 비슷한 결론에 도달하며 이를 명시적으로 설명했습니다. Bing은 상태 코드만 믿지 않고 반복 크롤링에서 관찰된 리디렉션 패턴을 봅니다. 대상이 계속 바뀌는 301은 302처럼, 늘 같은 곳을 가리키는 302는 301처럼 처리할 수 있습니다. 충분히 일관된 동작이 반복되면 두 검색 엔진 모두 헤더가 주장하는 것보다 리디렉션이 실제로 하는 일을 신뢰합니다.

Bing의 오래된 지침은 오늘날 Google보다 302를 더 아껴 쓰라고 경고하며 잘못 사용한 302가 이전 URL에 가치를 남길 수 있다고 했습니다. 실무 결론은 Google과 같습니다. 실제 의도에 상태 코드를 맞추세요.

302가 올바른 선택인 경우

Google은 302를 단순히 허용하는 것이 아니라 한 사례에서는 권장합니다. A/B 테스트 지침을 보세요.

“If you’re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect. This tells search engines that this redirect is temporary—it will only be in place as long as you’re running the experiment—and that they should keep the original URL in their index rather than replacing it with the target of the redirect (the test page). JavaScript-based redirects are also fine.” (번역) 「원래 URL에서 변형 URL로 사용자를 보내는 테스트라면 301이 아니라 302를 사용하세요. 실험이 실행되는 동안만 임시로 존재하므로 검색 엔진이 원래 URL을 색인에 유지하게 합니다. JavaScript 리디렉션도 괜찮습니다.」

정당한 사용 사례는 모두 실제로 임시입니다.

  • A/B 테스트 — Google의 명시적 권장 사항입니다. 단, 통계적 유의성에 필요한 기간이 지나면 제거하고 불필요하게 오래 실행하지 마세요.
  • 지역·기기·언어 라우팅 — 방문자에 따라 대상이 달라집니다. Googlebot에 실제로 무엇을 제공하는지, 쿠키·헤더·캐시 키·Vary가 변형을 분리하는지, 접근성 사용자가 콘텐츠에 접근하는지, 자동 라우팅을 덮어쓸 수 있는지 확인하고 로컬라이즈된 URL에는 hreflang을 사용하세요.
  • 임시 유지보수·서비스 불가 페이지 — 다른 설명 페이지로 의도적으로 보내는 경우 302가 적합합니다. 같은 URL을 잠시 제공할 수 없는 장애라면 Retry-After와 함께 503 Service Unavailable을 검토하세요.
  • 기간 제한 프로모션 — 캠페인 기간에만 보내고 되돌립니다.
  • 로드 밸런싱·장애 조치 — 원본 서버나 데이터센터가 잠시 불가할 때 임시로 다른 곳에 보냅니다.

“if we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 “if a service your site offers is temporarily unavailable, you can set up a temporary redirect to send users to a page that explains what’s happening, without compromising the original URL in search results.” (번역) 「위 인용은 해당 출처의 핵심 표현을 한국어로 옮긴 것입니다.」 hreflang

Examples 탭에서 위 사례를 나란히 주석과 함께 보고 Checklists 탭에서 배포 전 점검을 수행하세요.

유일한 진짜 실수

영구 이동을 의도하면서 302를 사용하는 것입니다. Google에 이전 URL을 색인에 유지하라고 말하므로 실제로 순위를 원하는 새 페이지가 예측할 수 없이 오랫동안 선택되지 않을 수 있습니다. 페이지가 영구적으로 사라졌다면 301(또는 308)을 사용하세요. 리디렉션 체인 안에서 301과 302를 일관성 없이 섞거나 두 URL이 서로를 가리켜 루프를 만드는 것도 피해야 합니다.

302 구현하기

중요한 것은 헤더입니다. 상태 줄 302 Found와 Location이 필요합니다. Google의 PHP 예시는 다음과 같습니다.

header('HTTP/1.1 302 Found');
header('Location: https://www.example.com/newurl');
exit();

Apache(.htaccess)에서는 R=302 플래그가 임시임을 나타냅니다. R=301 또는 플래그 없는 R은 영구로 기본 처리될 수 있습니다.

Redirect 302 /old-path https://www.example.com/newurl
# or with mod_rewrite:
RewriteRule ^old-path/?$ https://www.example.com/newurl [R=302,L]

nginx의 redirect는 302를 발행하며 permanent를 사용하면 301을 발행합니다.

location = /old-path {
    return 302 https://www.example.com/newurl;
}

WordPress 리디렉션 플러그인, CDN·엣지 규칙, 애플리케이션 핸들러 등 스택이 무엇이든 원칙은 같습니다. 서버 측 리디렉션을 우선하고 임시 코드를 의도적으로 선택하세요. 대부분의 도구는 301을 기본값으로 하므로 302는 보통 명시적으로 설정해야 합니다.

모든 리디렉션에 적용되는 보안 주의: Location 헤더의 대상이 사용자 입력(예: ?next= 또는 ?returnUrl=)으로 만들어지면 오픈 리디렉션이 될 수 있습니다. 공격자가 귀하의 도메인 링크를 악성 사이트로 튕기게 만들 수 있습니다. 요청 파라미터에 들어온 URL을 그대로 사용하지 말고 안전한 경로·출처를 allowlist로 제한하세요. //evil.example이나 %2F%2Fevil.example 같은 인코딩·scheme-relative 입력도 테스트하고, 배포 전 현재 서버·CDN 버전의 문법을 확인하세요.

영구 이동의 대응 글과 전체 비교는 이 클러스터의 301 리디렉션, 301과 302, 302와 307 글을 참고하세요.

Try it live

This is a real endpoint on this site — not a simulation. Hit it from the button, open it in a new tab, or curl -i it from your terminal, and the server answers with the actual status code this article is about.

Open in new tab ↗

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.