301 리디렉션 vs 302: 무엇을 쓸지, Google은 몇 번까지 따라가는지

SEOgrinder 편집팀 · 게시일 2026년 11월 4일 · 읽는 시간 약 11분

핵심 답변: 301 리디렉션(또는 쌍둥이 격인 308)은 옛 주소가 영구히 사라질 때 쓰고, 302(또는 307)는 이동이 일시적이어서 옛 주소가 검색에 남아야 할 때만 씁니다. Google은 영구 리디렉션을 대상 페이지를 처리하라는 강한 신호로, 임시 리디렉션을 약한 신호로 봅니다. 기본적으로 최대 10단계까지 따라가지만, 옛 주소는 모두 한 번에 최종 목적지로 보내야 합니다.

301 리디렉션과 302는 무엇이 다른가요?

리디렉션은 서버가 “여기에는 없으니 저기로 가세요”라고 답하면서 새 주소를 Location 헤더에 적어 주는 응답입니다. 왜 그렇게 답하는지는 상태 코드가 알려 줍니다. HTTP 표준(RFC 9110)에서 301은 페이지에 새롭고 영구적인 주소가 생겼다는 뜻이고, 302는 일시적으로만 다른 곳에 있으니 클라이언트가 원래 주소를 계속 쓰라는 뜻입니다. Google도 같은 차이를 읽고 그에 따라 움직입니다.

코드	의미	Google의 동작
301	영구 이동 (Moved permanently)	따라가며, 대상 페이지를 처리하라는 강한 신호로 봅니다
308	영구 리디렉션 (Permanent redirect)	301과 같습니다
302	임시 이동 (Found)	따라가며, 대상 페이지를 처리하라는 약한 신호로 봅니다
307	임시 리디렉션 (Temporary redirect)	302와 같습니다

이 표는 Google의 HTTP 상태 코드 문서(최종 업데이트 2026-02-04)에서 가져왔습니다. 검색에서 이것이 어떤 의미인지는 Google의 리디렉션 문서(최종 업데이트 2026-04-14)에 나옵니다. 영구 리디렉션이면 검색 결과에 새 대상이 표시되고, 임시 리디렉션이면 원래 페이지가 표시됩니다. 여기에 링크한 Google 문서는 2026년 11월 4일에 읽었습니다.

307과 308은 왜 있을까요? Google은 이 둘을 각각 302, 301과 같게 다루지만 의미상으로는 다르다고 알려 주므로, 상황에 맞는 코드를 고르면 됩니다. 차이는 요청 메서드에 있습니다. 301이나 302 뒤에는 클라이언트가 POST를 GET으로 바꿀 수 있고, 307이나 308 뒤에는 메서드를 그대로 유지해야 합니다(RFC 9110, 15.4절). 일반적인 페이지 조회에서는 차이를 느끼지 못합니다. POST 요청을 받는 폼과 API에는 308이나 307을 쓰세요.

어떤 리디렉션을 언제 써야 하나요?

질문 하나로 대부분 정리됩니다. Google의 리디렉션 문서는 이렇게 말합니다. “Use permanent redirects when you're sure that the redirect won't be reverted.” 옛 주소가 다시 돌아올 일이 없다면 301, 돌아올 것이라면 302를 쓰세요.

상황	사용	참고
페이지의 주소가 바뀌었다(새 slug, 새 폴더)	301 또는 308	새 대상이 검색에 표시됩니다
두 페이지를 하나로 합쳤다	옛 주소 각각에서 합친 페이지로 301	Google의 사이트 이전 가이드가 합쳐진 콘텐츠에 이를 허용합니다
http에서 https로, www에서 www 없는 주소로(또는 그 반대로)	301 또는 308	Google: 선호하는 주소를 하나 정하고 나머지를 그쪽으로 리디렉션하세요
서비스가 한동안 중단되어 방문자가 안내 페이지를 본다	302 또는 307	옛 주소가 검색에 남습니다
페이지가 사라졌고 대체할 페이지도 없다	리디렉션 없음: 404 또는 410	보낼 만한 페이지가 없으니 리디렉션하지 않습니다
옛 주소 여러 개를 홈페이지로	하지 마세요	Google: 소프트 404로 취급될 수 있습니다

마지막 줄은 Google의 사이트 이전 가이드(최종 업데이트 2026-08-20)에 나옵니다. 이런 경우를 찾는 방법은 소프트 404 오류 글에서 다룹니다. 이 가이드 자체는 사이트 전체를 새 도메인으로 옮기는 일을 다루며, 이는 이 글이 다루는 범위보다 큰 작업입니다.

잘못 고르면 어떤 대가를 치를까요? 영구적으로 옮긴 페이지에 302를 쓰면 Google에 사실이 아닌 것을 알리는 셈입니다. 임시 리디렉션은 원래 페이지를 결과에 남겨 두고, “the target page might still be indexed if other canonicalization signals are present”라고 합니다. 다른 canonical 신호가 있으면 대상 페이지도 색인될 수 있다는 말이니, 확정이 아니라 ‘어쩌면’입니다. 오래 유지한 302가 나중에 301처럼 바뀐다고 약속하는 Google 문서는 찾지 못했습니다. 그러니 그렇게 되기를 기다리지 마세요.

Google은 리디렉션을 몇 단계까지 따라가나요?

Google의 상태 코드 문서는 이렇게 말합니다. “By default, Google's crawlers follow up to 10 redirect hops.” Googlebot은 웹 콘텐츠를 크롤링할 때 일반적으로 10단계까지 따라가고, 다른 Google 제품은 다른 한도를 쓸 수 있습니다. 리디렉션하는 주소가 돌려주는 내용은 무시되고, 최종 대상의 콘텐츠가 처리됩니다.

10단계는 상한일 뿐 목표치가 아닙니다. 사이트 이전 가이드는 최종 목적지로 직접 리디렉션하라고 조언하고, 그것이 어렵다면 체인을 짧게, 가능하면 3단계 이하로, 어쨌든 5단계 미만으로 유지하라고 권합니다. 이유는 이렇습니다. “Chaining redirects adds latency for users, and not all user agents and browsers support long redirect chains.” Google의 크롤링 오류 문서(최종 업데이트 2025-12-18)는 긴 체인이 크롤링에 부정적인 영향을 준다고 덧붙입니다.

체인은 의도해서가 아니라 규칙이 한 겹씩 쌓이면서 늘어납니다. 페이지가 나타나기까지 3단계를 거치는 전형적인 예는 이렇습니다.

http://example.com/old-guide       301 -> https://example.com/old-guide
https://example.com/old-guide      301 -> https://www.example.com/old-guide
https://www.example.com/old-guide  301 -> https://www.example.com/new-guide
https://www.example.com/new-guide  200

해결책은 옛 주소마다 한 단계로 끝내는 것입니다. 옛 주소의 표기마다 최종 주소를 곧바로 가리키는 301 하나로 응답하게 하세요. 내 사이트의 링크도 마찬가지입니다. 내부 링크, canonical 태그, 사이트맵 항목은 최종 주소를 가리키게 하세요. 리디렉션은 바깥에서 오는 방문자와 오래된 북마크를 위한 것이지, 내 사이트의 탐색에 쓰는 것이 아닙니다.

301 리디렉션 설정 방법

서버 측 리디렉션을 쓰세요. Google의 리디렉션 문서는 이것을 가장 올바르게 해석될 가능성이 높은 유형으로 꼽습니다. 아래 nginx와 Node 예시는 2026년 11월 4일에 실제로 실행하고(nginx 1.24.0, Node 25.9.0) 응답을 curl로 읽었습니다. Apache 줄은 Google 문서의 예시를 그대로 옮긴 것으로, 직접 실행해 보지 않았습니다.

먼저 nginx입니다. location 규칙은 https://example.com의 server 블록에 넣습니다. 아래의 두 server 블록은 그 밖의 모든 표기를 한 단계로 그 주소에 보내며, $request_uri가 경로와 쿼리 문자열을 그대로 유지합니다.

# 페이지 하나를 영구 이동 (임시 이동이면 302를 사용)
location = /old-guide {
    return 301 https://example.com/new-guide;
}

# http://와 https://www.는 모두 https://example.com으로
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/ssl/example.com.pem;
    ssl_certificate_key /etc/ssl/example.com.key;
    return 301 https://example.com$request_uri;
}

패키지 없이 쓰는 Node입니다. POST 요청이 POST로 남아야 한다면 301 대신 308을 쓰세요.

import http from 'node:http';

const moved = new Map([['/old-guide', '/new-guide']]); // 옛 경로 -> 새 경로

http.createServer((req, res) => {
  const { pathname, search } = new URL(req.url, 'http://localhost');
  const target = moved.get(pathname);
  if (target) {
    res.writeHead(301, { location: `https://example.com${target}${search}` });
    return res.end();
  }
  res.writeHead(200, { 'content-type': 'text/plain' });
  res.end('ok');
}).listen(3000);

Apache는 Google 문서의 예시입니다. 서버 설정이나 .htaccess 파일에 넣습니다.

Redirect permanent "/old" "https://example.com/new"
Redirect temp "/two-old" "https://example.com/two-new"

서버를 건드릴 수 없다면 먼저 사용 중인 플랫폼을 확인하세요. Google은 Blogger와 Shopify를 리디렉션 도구가 내장되어 있을 수 있는 예로 듭니다. Google은 meta refresh(0초는 영구, 지연이 있으면 임시로 취급)와 JavaScript 리디렉션도 읽지만, 어디까지나 차선책입니다. JavaScript 방식에서는 렌더링에 실패하면 Google이 “might never see it”, 즉 리디렉션을 끝내 보지 못할 수도 있습니다.

리디렉션 점검 방법과 SEOgrinder가 찾는 것

curl 명령 두 개면 충분합니다. 첫 번째는 모든 단계를 상태와 대상까지 출력하고, 두 번째는 단계 수와 최종 주소를 알려 줍니다. 일부 서버는 HEAD 요청에 다르게 응답하므로 HEAD가 아니라 GET을 씁니다.

curl -s -L -o /dev/null -D - http://example.com/old-guide | grep -i -E "^(HTTP|location)"
curl -s -L -o /dev/null -w "%{num_redirects} redirects, final: %{url_effective}\n" http://example.com/old-guide

사람들과 링크가 내 사이트에 도달하는 모든 표기로 실행해 보세요. http와 https, www가 있는 것과 없는 것입니다. 원하는 결과는 301 한 번 뒤에 200이 나오는 것입니다.

SEOgrinder는 우리의 도구이며, 우리가 만듭니다. SEOgrinder의 무료 스캔은 리디렉션을 세 곳에서 살핍니다(한국어 화면의 이름 기준).

「기술 & 보안」 탭의 「리디렉션」 카드. 스캔한 주소의 리디렉션 단계를 나열합니다. 그 주소가 두 번 이상 리디렉션되면 「리디렉션이 연달아 N회」 할 일이 단계를 보여 주고, 첫 번째 URL이 최종 목적지를 곧바로 가리키게 하라고 안내합니다.
같은 탭의 「도메인 일원화」 카드. http와 https, www 유무에 관계없이 모두 하나의 주소로 끝나야 한다고 봅니다. 그렇지 않으면 「사이트가 N가지로 갈라져 있습니다」 할 일이 나타납니다. 어떤 표기가 302, 303, 307로 리디렉션되면 「도메인 리디렉션이 임시일 뿐입니다」가 나타납니다.
「Google에서의 페이지」 탭. 「내부 링크 N개가 우회 경로를 거칩니다」 할 일은 대상이 리디렉션되거나 다른 페이지를 canonical로 지정하는 내부 링크를 나열합니다(스캔한 페이지의 내부 링크 최대 60개).

한계가 두 가지 있습니다. 체인 점검은 스캔한 주소와 내 도메인의 표기들을 대상으로 하며, 사이트의 모든 옛 주소를 보는 것은 아닙니다. 옛 주소는 curl로 직접 테스트하세요. 또 SEOgrinder는 대상 페이지가 적절한 후속 페이지인지, Google이 리디렉션을 어떻게 처리했는지는 판단할 수 없습니다. 「AI에 넘기기」는 할 일 하나를 코딩 에이전트용 브리핑으로 바꿔 주고, 「다시 확인」은 수정한 뒤 새 스캔을 실행합니다.

자주 하는 실수

영구 이동에 302를 쓰는 것. 옛 주소가 결과에 남을 수 있습니다. 301이나 308을 쓰세요.
일시적인 일에 301을 쓰는 것. 일주일 동안 문을 닫는 쇼핑몰에는 302가 맞습니다.
규칙이 쌓여 체인이 되는 것. http, https, www, 새 페이지의 순서면 3단계입니다. 모든 규칙에서 최종 주소를 곧바로 쓰세요.
모든 것을 홈페이지로 보내는 것. 동등한 페이지로 리디렉션하거나 404나 410으로 응답하세요.
내 링크가 아직 옛 주소를 쓰는 것. 내부 링크, canonical, 사이트맵을 고치세요.
옛 주소를 robots.txt로 막는 것. 그러면 Google이 그 주소를 가져올 수 없어서 리디렉션을 끝내 보지 못합니다. 2011년 Google 글 Do 404s hurt my site?에서도, 크롤러가 응답을 보려면 그 URL을 크롤링할 수 있어야 합니다(“has to be able to crawl that URL”).
리디렉션을 너무 일찍 없애는 것. 사이트 이전에 대해 Google은 이렇게 씁니다. “Keep the redirects for as long as possible, generally at least 1 year.” 이를 페이지 하나에 적용하는 것은 우리의 해석입니다.

자주 묻는 질문

301 리디렉션은 SEO에 해로운가요?

Google의 사이트 이전 가이드는 이렇게 말합니다. “301 and other permanent redirects don't cause a loss in PageRank.” 이 문장은 사이트 이전에 관한 가이드에 있으므로, 페이지 하나에 적용하는 것은 우리의 해석입니다. Google이 실제로 경고하는 것은 긴 체인, 관련 없는 페이지로의 리디렉션(소프트 404), 그리고 이전하는 동안 Google이 다시 크롤링하면서 생기는 순위 변동입니다.

308이 301보다 낫나요?

Google에게는 둘이 동등합니다. 308은 요청 메서드도 유지하므로 폼과 API에서 의미가 있습니다. 일반 페이지에는 301이면 충분합니다.

Google이 새 주소를 보여 주기까지 얼마나 걸리나요?

페이지 하나에 대해서는 Google이 시간을 밝힌 곳을 찾지 못했습니다. 사이트 이전에 대해서는, 중간 규모 웹사이트에서 새 URL이 결과에서 옛 URL을 서서히 대체하기까지 “it can take a few weeks or more”라고 합니다. 날짜를 약속하지 마세요.

다음 단계

옛 주소들과 내 도메인의 모든 표기에 대해 첫 번째 curl 명령을 실행하세요. 요청 하나라도 한 단계를 넘기면, 첫 번째 주소가 최종 주소를 곧바로 가리키게 고치세요. 그런 다음 SEOgrinder로 사이트를 스캔하고 「기술 & 보안」 탭에서 「리디렉션」과 「도메인 일원화」를 살펴본 뒤, 수정하고 나서 「다시 확인」을 누르세요. 기술적인 기본기를 더 알고 싶다면 SEO 체크리스트를 참고하세요.

함께 읽어 보세요

구글 검색 결과 삭제: 404·410·301·noindex 중 무엇을 쓸까?