301, 302 리디렉션 차이와 SEO 영향: 마케터가 알아야 할 원리

리디렉션은 한 URL, 즉 웹 주소로 접속한 사람을 다른 주소로 보내는 처리입니다. 캠페인 안내 주소가 바뀌었을 때 예전 링크로 온 사람도 새 안내를 볼 수 있게 하는 데 씁니다.

이동이 영구적인지 임시적인지에 따라 알맞은 방식이 달라집니다. 또한 새 페이지가 열리더라도 유입 경로를 기록하는 값이 중간에 빠질 수 있습니다. SEO는 검색엔진이 페이지를 찾고 이해하도록 개선하는 작업입니다. 이 글은 마케터가 이동 목적을 정하고 담당자에게 요청한 뒤 결과를 확인하는 순서를 설명합니다.

먼저 이동 요청서 한 줄 만들기

아래는 가상 교육 안내 페이지의 변경입니다. example.com은 예시용 도메인이며 실제 이동을 시험할 주소가 아닙니다. 메모장에 다음 정보를 적습니다.

이 경우 요청 문장은 다음처럼 쓸 수 있습니다.

같은 교육 안내를 새 주소로 영구 이전합니다. 기존 주소에서 새 주소로 301 또는 308 이동을 적용하고, 캠페인 UTM 값이 유지되는지 확인해 주세요. 최종 페이지가 정상 열리는지도 확인해 주세요.

301과 308은 영구 이동을 알리는 HTTP 상태 코드입니다. HTTP는 브라우저와 서버가 요청과 응답을 주고받는 규칙이며, 상태 코드는 서버가 요청을 어떻게 처리했는지 나타내는 숫자입니다. 예를 들어 200은 정상 응답, 404는 요청한 자료를 찾을 수 없다는 뜻입니다.

UTM은 어느 캠페인에서 들어왔는지 구분하기 위해 주소 뒤에 붙이는 값입니다. 아래 예제는 소식지 이메일에서 온 방문을 구분합니다.

이동 후에도 class-new 주소에 두 값이 유지되는 것이 이번 요청의 확인 기준입니다. 예상 최종 주소는 다음과 같습니다.

실제 업무에서는 유지할 값과 제거할 값을 담당자와 정합니다. UTM에 이름이나 이메일 주소 같은 개인정보를 넣지는 않습니다.

301과 302는 무엇이 다른가요?

301: 영구 이동

301은 기존 자료를 새 주소로 영구히 옮겼다는 응답입니다. 서버는 이동할 주소를 Location이라는 응답 항목으로 알리고 브라우저는 그 주소로 요청을 보냅니다.

Google은 영구 리디렉션을 새 주소를 대표 URL로 선택하는 신호로 사용합니다. 대표 URL은 같은 내용의 여러 주소 중 검색 결과에 사용할 주소를 뜻합니다. 308도 영구 이동에 사용할 수 있습니다.

Google은 301 같은 영구 리디렉션 자체가 PageRank 손실을 일으키지는 않는다고 설명합니다. PageRank는 링크를 바탕으로 평가하는 신호이며 모든 검색 순위를 뜻하지 않습니다. 이전 중에는 검색 시스템의 재처리로 순위가 달라질 수 있으므로, 이동 코드 하나가 기존 성과를 그대로 보장하는 것은 아닙니다.

302: 임시 이동

302는 현재 다른 주소를 임시로 사용한다는 응답입니다. 예를 들어 원래 페이지를 유지하면서 일정 기간 다른 안내로 보낼 때 검토합니다. 307도 임시 이동에 사용됩니다.

이 글의 예제는 안내 페이지를 여는 상황입니다. 307과 308은 요청 방식을 유지하도록 정해져 있어, 신청서 제출처럼 데이터를 보내는 처리에서는 301이나 302와 차이가 중요합니다. 그런 주소는 이 예제를 그대로 적용하지 말고 담당자에게 요청 방식까지 검토하도록 전달합니다.

Google은 임시 리디렉션 자체를 도착 주소가 대표 URL이어야 한다는 신호로 사용하지 않습니다. 다른 신호에 따라 새 주소가 색인될 수는 있습니다. 따라서 “302이면 링크 가치가 전혀 전달되지 않는다”는 단순한 공식으로 판단하지 않습니다. 영구 변경이라면 실제 의도에 맞게 301이나 308을 사용하는 것이 좋습니다.

301과 302는 브라우저에서 모두 새 페이지로 이동하므로 겉모습만으로 구분하기 어렵습니다. 실제 응답 코드를 확인해야 합니다. 서버가 응답을 저장해 재사용하도록 지정하는 캐시 설정도 함께 작용하므로, 코드를 보고 브라우저의 모든 재요청 동작을 단정하지는 않습니다.

브라우저에서 실행하는 두 가지 방식

메타 리프레시

HTML은 웹 문서의 구조를 표시하는 언어입니다. 다음 코드는 문서 안에서 새 주소로 즉시 이동하도록 지정한 예입니다. 운영 사이트에 그대로 붙여 넣는 설정 안내는 아닙니다.

0은 대기 시간이 0초라는 뜻입니다. Google은 즉시 실행하는 메타 리프레시를 영구 이동으로, 0초보다 지연되는 경우를 임시 이동으로 해석합니다. “5초 이상이면 별개 페이지”나 “일부 링크 가치만 전달”이라고 단정하는 설명은 맞지 않습니다.

서버에서 이동 응답을 설정할 수 있다면 그 방식을 우선 검토하고, 플랫폼 제약 때문에 어려울 때 대안을 살핍니다.

자바스크립트 이동

자바스크립트는 웹페이지에서 동작을 실행하는 언어입니다. 아래는 주소를 바꾸는 두 가지 코드 예입니다.

Google은 페이지를 렌더링하는 과정에서 자바스크립트를 처리할 수 있습니다. 렌더링은 코드를 실행해 화면을 만드는 과정입니다. 이 과정이 실패하면 이동을 발견하지 못할 수 있으므로, 서버 방식이나 메타 리프레시를 사용할 수 없는 경우에 검토합니다. 자바스크립트라는 이유만으로 항상 처리 우선순위가 낮거나 모든 링크 가치가 사라진다고 말할 수는 없습니다.

어느 방식이든 UTM을 자동으로 보존한다고 가정하지 않습니다. 목적지 주소를 만드는 설정이나 코드에 따라 결과가 달라집니다.

실제 이동 결과를 확인하는 순서

담당자가 테스트 가능한 주소를 제공하면, 요청서에 적은 기존 URL 전체를 새 탭에서 엽니다. UTM을 확인하는 작업이라면 그 값까지 붙인 주소로 시작합니다.

1. 도착한 주소를 복사해 요청서의 새 주소와 비교합니다. 의도한 페이지의 제목과 본문도 확인합니다. 오류 안내만 열렸다면 주소가 맞아도 완료로 보지 않습니다.
2. 이번 요청에서 유지하기로 한 utm_source와 utm_medium이 남아 있는지 봅니다. class-new로만 도착하고 두 값이 없다면 그 현상을 기록합니다.
3. 담당자에게 기존 주소의 이동 코드, 중간 주소와 최종 응답을 요청합니다. 영구 이동 요청이라면 301 또는 308인지 확인합니다.
4. 주소와 시간이 담긴 결과를 남기고 PC와 모바일에서도 필요한 경로를 확인합니다.

컴퓨터의 Chrome이나 Edge에서는 개발자 도구의 Network 탭으로 직접 응답을 볼 수도 있습니다. 브라우저 메뉴에서 개발자 도구를 열고 Network를 선택한 뒤 Preserve log를 켭니다. 이는 이동하면서 요청 기록이 지워지지 않게 하는 옵션입니다. 그 상태에서 기존 주소로 접속합니다. 요청 목록에서 Doc 또는 문서 필터를 사용해 페이지 요청을 찾고, 항목을 선택해 Status와 Headers 안의 Location을 확인합니다. 메뉴 이름은 브라우저 표시 언어에 따라 다를 수 있습니다. 이번 예제에서는 마지막 문서가 200으로 응답하고 교육 안내 본문이 나오는지 함께 봅니다. 최종 문서의 응답과 이동 단계를 기록합니다.

상태 코드가 보이지 않거나 기억한 주소로 바로 이동한다면 이미 저장된 응답이나 페이지 코드가 영향을 줄 수 있습니다. 설정을 추측해 바꾸지 말고 기존 주소, 최종 주소와 관찰한 화면을 담당자에게 전달합니다. 주소창 확인만 했다면 301까지 검증했다고 기록하지 않습니다.

자주 생기는 문제와 수정 요청

영구 변경인데 임시 이동으로 설정됨

“리디렉션해 주세요”라고만 요청하면 담당자가 이동 목적을 알 수 없습니다. 기본값을 추측하지 말고 영구 이전인지, 언제 원래 주소로 복귀할지부터 적습니다. 이미 302로 설정돼 있다면 검색 가치가 모두 소실됐다고 단정하지 말고, 의도에 맞는 응답으로 바꿀지 확인합니다.

여러 주소를 거쳐 이동함

A → B → C → D처럼 이어지는 처리를 리디렉션 체인이라고 합니다. 여러 번의 요청은 지연을 더하며, 중간 단계에서 추적값이 빠질 수도 있습니다. Google이 여러 단계를 따라갈 수 있어도 이를 불필요하게 길게 만들 이유는 없습니다. 가능하면 A → D로 직접 연결합니다.

세 번 이동했다고 모든 브라우저가 실패한다거나 Google이 항상 다섯 번까지만 따라간다는 규칙으로 점검하지는 않습니다. 실제 이동 목록을 보고 불필요한 단계를 줄입니다.

UTM이 사라짐

이동 전에 있었던 쿼리 문자열, 즉 ? 뒤의 값이 최종 주소에 없다면 어느 단계에서 빠졌는지 확인합니다. 서버 종류만 보고 원인을 확정하지 않습니다.

예를 들어 Apache 서버의 QSA는 기존 쿼리와 새 쿼리를 합치는 옵션입니다. 도착 주소에 새 쿼리가 있을 때 기존 값을 덮어쓰는 설정과 관련이 있습니다. QSA가 없으면 언제나 기존 쿼리가 사라진다는 뜻은 아니므로, 실제 이동 규칙과 전체 주소를 담당자에게 전달합니다.

주소에 값이 남는 것과 분석 도구에 수집되는 것도 따로 확인합니다. GA4는 방문과 행동을 분석하는 도구이며, 값이 남아도 동의 설정이나 수집 코드 등의 상태에 따라 기록이 달라질 수 있습니다. 실시간 화면에 숫자가 보인다는 사실만으로 해당 캠페인의 유입 정보까지 검증한 것은 아닙니다.

단축 주소가 또 다른 중간 주소를 가리킴

단축 URL은 긴 주소 대신 공유하는 짧은 주소입니다. 단축 서비스의 목적지가 이미 이동하는 옛 주소라면 최종 목적지로 수정할 수 있는지 확인합니다. 두 번 이동한다는 이유만으로 모든 플랫폼이 스팸으로 처리한다고 단정하지는 않습니다.

HTTPS 이전 뒤 옛 HTTP 주소가 남음

HTTPS는 브라우저와 사이트 간 통신을 암호화하는 방식입니다. 전환 후에는 기존 HTTP 주소를 같은 내용의 HTTPS 주소로 연결하고, 내부 링크와 대표 URL 표시도 새 주소에 맞춥니다. HTTP 이동을 설정하지 않았다고 반드시 404가 되는 것은 아니며, 실제 서버의 응답을 확인해야 합니다.

종료된 페이지와 언어별 페이지의 선택

캠페인이 끝났다고 모든 페이지를 홈페이지로 보내지는 않습니다. 같은 내용을 대체하는 새 안내가 있으면 그곳으로 영구 이동을 검토합니다. 종료 기록이 필요한 경우에는 종료 안내를 남길 수 있고, 삭제한 내용에 관련 대체 페이지가 없다면 404나 삭제를 뜻하는 410 응답이 적절할 수도 있습니다.

관련 없는 한 페이지로 주소를 몰아 보내면 이용자가 필요한 내용을 찾지 못합니다. Google도 이를 정상 콘텐츠가 없는 상태인 soft 404로 처리할 수 있다고 안내합니다.

언어별 사이트에서는 언어를 직접 선택하고 해당 주소로 접근할 수 있게 만듭니다. IP나 브라우저 언어만으로 항상 강제 이동하면 이용자와 크롤러가 원하는 언어 페이지에 접근하지 못할 수 있습니다. 조건에 따른 이동이 필요해도 자바스크립트만 가능한 것은 아니므로 사이트 구조에 맞게 담당자와 결정합니다.

인쇄물에 쓰는 짧은 주소도 목적지 교체 계획을 먼저 정합니다. 매년 같은 주소를 다른 행사로 연결할 계획이라면 무조건 영구 이동으로 설정하지 않습니다.

혼자 다른 상황으로 반복하기

첫 연습의 조건을 “기존 안내는 유지하고, 일주일 동안만 임시 장소 안내로 이동한 뒤 복귀”로 바꿔 요청서를 써 봅니다. 이번에는 임시 이동인 302나 307을 검토하고 종료 날짜와 복귀할 주소를 적어야 합니다.

다음으로 “행사가 종료됐고 대체 안내가 없음”이라는 조건을 추가합니다. 무조건 새 주소로 보내지 말고 종료 안내를 남길지, 삭제 응답을 제공할지 먼저 정합니다. 이동 방식과 이유를 설명하고, 도착 내용과 추적값을 어떻게 확인할지 적을 수 있으면 연습을 마친 것입니다.

자주 묻는 질문

개발팀에 리디렉션만 요청하면 어떤 종류로 설정되나요?

사용하는 서버와 구현에 따라 다릅니다. 영구인지 임시인지와 목적지, 유지할 추적값을 요청서에 적고 실제 응답을 확인합니다. 302를 발견했다고 검색 가치가 전부 사라졌다고 단정하지는 않습니다.

캠페인이 끝난 페이지는 그냥 404로 두면 되나요?

관련 대체 페이지가 있는지부터 봅니다. 같은 정보를 옮겼다면 영구 이동을 검토하고, 보존할 종료 안내가 필요하면 내용을 갱신합니다. 삭제했고 대체할 내용이 없다면 404나 410이 적절할 수 있습니다.

이동 후 GA4에서 유입 경로가 안 보이면 무엇을 확인하나요?

기존 전체 주소와 최종 주소를 비교해 UTM이 어디서 빠졌는지 확인합니다. 값이 유지됐다면 동의 설정과 분석 코드의 수집 상태, 보고서의 기간과 지표를 점검합니다. 서버 종류나 실시간 숫자 하나만으로 원인을 확정하지 않습니다.

Sources

• 리디렉션과 Google 검색
• 주소 변경이 있는 사이트 이전, Google Search Central
• 302와 307의 요청 방식 차이, MDN
• Apache RewriteRule의 QSA와 QSD