웹사이트 이관(Migration) 전략: 도메인을 변경하거나 호스팅사를 바꿀 때 기존 SEO 점수를 100% 보존하는 301 리다이렉트 기술

301 리다이렉트는 이전 URL의 링크 자산(순위 신호) 대부분을 새 URL로 이전시키는 것으로 알려져 있습니다. 도메인을 바꾸거나 호스팅사를 옮기면 물리적으로 URL 자체가 달라지는데, 301 리다이렉트가 없으면 구글 입장에서는 기존 URL이 그냥 사라진 것으로 보여 그동안 쌓인 순위 신호가 새 URL로 이어지지 않습니다.

등록기관(레지스트라)의 기본 도메인 포워딩 기능이 302(임시 리다이렉트)로 설정된 경우가 많아, 이관 담당자가 별도로 신경 쓰지 않으면 자기도 모르게 302로 이관을 진행하게 됩니다. 302는 "임시로 옮겼다"는 신호라 구글이 순위 신호를 새 URL로 이전하지 않고 기존 URL을 계속 대표로 취급할 수 있어, 이관 후 몇 주가 지나도 순위가 회복되지 않는 원인이 이 하나의 설정 실수인 경우가 실무에서 드물지 않습니다.

이관 프로젝트의 핵심은 기존 사이트의 전체 URL 목록을 확보하고, 이 각각의 URL이 새 사이트의 어느 URL로 대응되는지 1:1 매핑표를 만드는 것입니다. 이 매핑표 없이 이관을 진행하면 실무자가 임의로 "비슷해 보이는 페이지"로 리다이렉트하게 되는데, 이는 원래 콘텐츠와 무관한 페이지로 신호가 흩어지는 결과로 이어질 수 있습니다.

매핑이 애매한 URL이 있을 때 편의상 전부 홈페이지로 리다이렉트해버리는 선택을 하기 쉬운데, 구글은 이런 패턴을 감지해 소프트 404에 가깝게 취급하며 링크 자산을 보존하려던 원래 목적 자체가 무산됩니다. 정확히 대응되는 페이지가 없다면 최소한 같은 카테고리의 상위 페이지로 리다이렉트하는 편이 홈페이지로 몰아버리는 것보다 낫습니다.

트래픽이 몰리는 성수기 직전에 이관을 진행하면 리다이렉트 오류나 매핑 누락이 매출에 직접 타격을 줄 수 있으므로, 상대적으로 트래픽이 적은 시기를 골라 이관하고 문제 대응 여유 기간을 충분히 확보하는 것이 안전합니다. 이관 당일에는 팀 전체가 모니터링에 집중할 수 있도록 다른 배포 일정과 겹치지 않게 조율해야 합니다.

이관 직후에는 새 도메인을 서치 콘솔에 별도 속성으로 등록하고, "변경 주소" 도구로 기존 도메인에서 새 도메인으로 이전한다는 사실을 구글에 명시적으로 알려야 합니다. 이후 며칠간은 8강에서 다룬 커버리지 리포트를 평소보다 자주 확인해 예상치 못한 404·리다이렉트 오류가 급증하지 않는지 지켜봐야 합니다.

이관이 정상적으로 이뤄져도 구글이 새 URL을 다시 크롤링·평가하는 데는 시간이 걸리므로, 이관 직후 일시적으로 트래픽이 흔들리는 것은 흔한 현상입니다. 경영진이나 클라이언트에게 이관 전에 "일정 기간 변동이 있을 수 있다"는 점을 미리 설명해두면, 회복 기간 중 성급한 추가 변경으로 상황을 더 꼬이게 만드는 것을 막을 수 있습니다.

대량의 URL을 리다이렉트하는 규칙을 서버 설정 파일에 무분별하게 쌓아두면, 규칙 수가 많아질수록 매 요청마다 이를 순차 검사하는 서버 부담이 커질 수 있습니다. 매핑표를 데이터베이스나 리다이렉트 전용 미들웨어로 관리해 규칙이 늘어나도 응답 속도가 느려지지 않도록 설계하는 것이 대규모 사이트에서는 중요한 고려 사항입니다.

모든 URL을 똑같은 비중으로 매핑하기보다, 외부 사이트로부터 링크를 많이 받고 있는 페이지나 오가닉 트래픽이 높은 페이지의 리다이렉트를 특히 꼼꼼히 검증하는 것이 손실을 최소화하는 방법입니다. 이런 핵심 페이지의 매핑이 틀리면 사이트 전체 트래픽에서 차지하는 손실 비중이 다른 페이지보다 훨씬 크기 때문입니다.

도메인 자체를 바꾸는 이관이라면, 옛 도메인을 완전히 폐기하지 않고 일정 기간 리다이렉트 서버로만 살려두는 것이 안전합니다. 아직 캐시나 북마크에 남아있는 옛 URL로 유입되는 트래픽과 검색엔진의 재크롤링 요청을 계속 새 도메인으로 넘겨줘야, 이관 초기의 신호 이전이 끊기지 않고 이어집니다.

이관은 개발팀만의 작업으로 취급되기 쉽지만, 실제로는 어느 페이지가 트래픽·매출 기여도가 높은지 판단하는 것은 마케팅팀의 몫입니다. 마케팅팀이 우선순위 페이지 목록과 트래픽 데이터를 개발팀에 전달하고, 개발팀이 이를 바탕으로 매핑표와 리다이렉트 규칙을 구현한 뒤 다시 마케팅팀이 실제 리다이렉트가 의도대로 걸렸는지 URL 단위로 검수하는 순환 구조를 만들어두면, 어느 한쪽만 작업을 떠맡아 누락이 생기는 상황을 줄일 수 있습니다.

실 서비스 도메인에서 바로 이관을 실행하면 리다이렉트 매핑의 오류를 실시간 트래픽으로 발견하게 되는 위험이 있습니다. 가능하다면 스테이징(테스트) 환경에서 전체 URL 매핑표대로 리다이렉트가 정확히 작동하는지 먼저 검증하고, 표본으로 뽑은 상위 트래픽 URL 몇십 개를 하나씩 직접 열어 확인하는 리허설 단계를 거친 뒤 실제 이관을 진행하는 것이 사고 발생 가능성을 크게 줄여줍니다.