사이트를 옮길 때, 검색 순위는 안 잃기.

리뉴얼이 끝나고 새 사이트를 띄운 다음 날, 트래픽 그래프가 절벽처럼 떨어지는 화면을 본 적 있으신가요. 디자인은 더 좋아졌고 속도도 빨라졌는데, 검색 유입만 사라집니다. 원인은 거의 항상 같습니다. 주소가 바뀌었는데 옛 주소를 새 주소로 이어주지 않은 것. 검색엔진 입장에서는 평가하던 페이지가 통째로 사라진 셈이라, 쌓아둔 순위도 함께 내려놓습니다.

왜 사이트를 옮기면 순위가 날아가나요?

검색엔진은 ‘페이지’가 아니라 ‘URL’을 평가합니다. /blog/old-slug가 몇 년에 걸쳐 모은 링크·신뢰·랭킹 신호는 그 주소에 묶여 있습니다. 도메인을 바꾸거나 URL 구조를 갈아엎으면 그 주소가 더 이상 존재하지 않으므로, 엔진은 새 주소를 ‘처음 보는 페이지’로 다시 평가하기 시작합니다. 그 사이 순위는 비어버립니다. 301은 “이 주소는 영구히 저기로 옮겨갔다”고 엔진에 명시해, 옛 주소의 평가를 새 주소로 넘기게 하는 유일하게 안정적인 방법입니다.

301과 302, 무엇을 써야 하나요?

이전에는 반드시 301(영구 이전)입니다. 302는 ‘임시 이전’으로 해석돼 검색엔진이 옛 URL을 색인에 계속 남겨둡니다. 잠깐 점검 페이지로 돌릴 때나 A/B 테스트처럼 정말 임시일 때만 302를 씁니다. 도메인 변경·리뉴얼은 영구적인 변화이므로 302를 쓰면 평가가 새 주소로 넘어가지 않아 손해를 봅니다.

핵심은 ‘1:1 매핑’ — 어떻게 만드나요?

이전의 절반은 매핑표 작성입니다. 옛 사이트의 모든 URL을 뽑아(크롤러나 기존 sitemap·로그에서) 각각 새 사이트에서 가장 가까운 페이지로 연결합니다. 1:1이 원칙입니다. 대응되는 페이지가 사라졌다면 홈이 아니라 ‘가장 가까운 상위·카테고리 페이지’로 보냅니다.

# _redirects (Cloudflare Pages / Netlify)
/old-page        /new-page        301
/blog/old-slug   /insights/new    301
/products/:id    /shop/:id        301
# 주의: 전부 홈(/)으로 보내지 말 것 — 1:1 매핑

위는 Cloudflare Pages·Netlify의 _redirects 파일 문법입니다. 정적 매핑(/old-page → /new-page)과 패턴 매핑(/products/:id → /shop/:id)을 함께 쓸 수 있습니다. Apache는 .htaccess의 RewriteRule … [R=301,L], Nginx는 return 301으로 같은 일을 합니다. 환경마다 문법이 다르니 본인 호스팅 문서를 한 번 확인하세요.

가장 흔한 실수 — “일단 전부 홈으로”

시간이 없다는 이유로 옛 URL을 모조리 /로 보내는 경우가 많습니다. 이게 최악입니다. 검색엔진은 ‘내용이 다른 페이지를 홈으로 몰아 보내는 것’을 soft 404에 가깝게 취급해 평가를 넘기지 않습니다. 결과적으로 리다이렉트는 걸려 있는데 순위는 그대로 사라집니다. 번거롭더라도 1:1 매핑이 정답입니다.

새 sitemap은 어떻게 재제출하나요?

새 URL만 담은 sitemap.xml을 만들어 Google Search Console과 네이버 서치어드바이저에 재제출합니다. 옛 URL은 sitemap에서 빼되 리다이렉트는 살려둡니다 — 그래야 엔진이 “옛 주소는 사라졌고, 여기 새 주소가 있다”를 동시에 파악합니다. Search Console에는 ‘주소 변경(Change of Address)’ 도구가 따로 있어 도메인 통째로 옮길 때 함께 쓰면 인식이 빨라집니다.

내부 링크와 모니터링은요?

본문·메뉴·푸터·이미지 경로의 내부 링크를 전부 새 URL로 직접 갱신합니다. 내부 링크가 옛 주소를 가리키면 클릭마다 리다이렉트가 한 번 더 일어나 느려지고 크롤 예산도 낭비됩니다. 리다이렉트는 어디까지나 외부 유입을 받는 안전망으로만 남깁니다. 이전 직후에는 색인 수·트래픽·검색어 순위를 수 주간 점진적으로 모니터링하면서, 누락된 매핑이나 깨진 리다이렉트가 없는지 확인합니다.

제가 이전 프로젝트에서 가장 먼저 챙기는 건 호스팅별 리다이렉트 문법입니다. 정적 호스팅이 아니라면 서버 설정 파일에 직접 규칙을 적어야 하는데, Apache·Nginx 두 환경의 1:1 매핑을 같은 모양으로 정리해 둡니다.

# Apache (.htaccess) — 영구 이전
RewriteEngine On
RewriteRule ^blog/old-slug$   /insights/new   [R=301,L]
RewriteRule ^products/([0-9]+)$  /shop/$1       [R=301,L]

# Nginx (server 블록) — 영구 이전
location = /blog/old-slug   { return 301 /insights/new; }
location ~ ^/products/(\d+)$ { return 301 /shop/$1; }
# 금지: location / { return 301 /; }  ← 전부 홈으로(soft 404)

Apache는 .htaccess, Nginx는 server 블록에 넣고 재적용하면 됩니다. 두 환경 모두 ‘옛 경로 → 정확한 새 경로’로 1:1을 지키는 게 핵심입니다.

매핑표를 짤 때 저는 옛 URL의 ‘상태’를 먼저 분류합니다. 대응 페이지가 있는지, 사라졌는지, 통합됐는지에 따라 보낼 곳과 코드가 달라지기 때문입니다.

대부분은 301로 끝나지만, 진짜 폐기한 페이지까지 301로 돌리면 평가를 엉뚱한 곳으로 흘려보내게 됩니다. 그래서 410·302를 분리해 적는 표가 실수를 막아 줍니다.

요약하면, 이전은 ‘옮기는 일’이 아니라 ‘잇는 일’

사이트 이전의 본질은 파일을 새 서버에 올리는 게 아니라, 옛 주소가 쌓은 검색 자산을 새 주소로 끊김 없이 잇는 일입니다. 301 1:1 매핑, sitemap 재제출, 내부링크 갱신, 점진 모니터링 — 이 네 가지가 한 세트입니다. Findable은 리뉴얼·도메인 이전 프로젝트에서 이 매핑표를 먼저 만들고 출시합니다. 순위를 잃지 않는 이전, 같이 설계해 드릴까요?