사이트 마이그레이션은 도메인, URL 구조, 플랫폼처럼 사이트의 기반을 크게 바꾸는 작업입니다. 도메인 변경, HTTPS 전환, 리뉴얼에 따른 URL 개편, 블로그의 서브도메인 통합이 모두 여기에 속합니다. 이 글은 그중 URL이 바뀌는 이전의 SEO 절차를 중심으로 설명합니다. 목표는 검색 노출과 유입의 손실을 줄이고 새 환경으로 신호가 이전되게 하는 것입니다.
이 글은 Google 검색 센터의 공식 문서를 기준으로 작성했습니다.
URL 매핑표와 301 리디렉션 절차
검색엔진에 이전을 알리는 언어가 리디렉션입니다. 절차의 중심에 URL 매핑표가 있습니다.
- 이전 전 전체 URL 목록을 뽑습니다. 크롤링 도구와 사이트맵, 서치콘솔 데이터로 유입이 있는 페이지를 빠짐없이 확인합니다
- 옛 URL별로 가장 알맞은 새 URL이나 삭제 처리를 정한 매핑표를 만듭니다. 여러 옛 페이지를 관련성이 높은 하나의 새 페이지로 통합할 수도 있습니다
- 서버에서 301이나 308 영구 리디렉션을 매핑표대로 구현합니다. 네이버 공식 이전 가이드는 301을 안내하므로 두 검색엔진을 함께 운영한다면 301을 쓰는 편이 확인하기 쉽습니다. 홈으로 전부 몰아 보내는 방식은 매핑이 아닙니다
- 새 사이트의 캐노니컬 태그, 내부 링크, 사이트맵을 새 주소 기준으로 정비하고 Search Console 속성을 확인합니다. 주소 변경 도구는 도메인이나 서브도메인이 바뀌는 이전에 검토합니다. HTTP에서 HTTPS, 같은 도메인의 경로 변경, www와 non-www 변경, URL이 그대로인 호스팅 이전에는 쓰지 않습니다
이전 전에 남겨 둘 기준선
출시 뒤 숫자가 떨어져도 이전 때문인지 원래 변동인지 기준선이 없으면 가르기 어렵습니다. 기간 성과는 최근 3개월과 가능하면 전년 같은 기간을 저장하고, 기술 상태는 출시 직전 시점의 전체 크롤과 핵심 URL 표본으로 남깁니다.
- Search Console의 클릭수, 노출수와 검색어. 색인 상태는 페이지 보고서와 핵심 URL 표본으로 확인
- GA4의 자연 검색 방문, 주요 이벤트와 랜딩 페이지
- 백링크가 있는 URL과 외부 링크의 목적지
- 현재 상태 코드, canonical, robots 지시와 렌더링 결과
- 서버 로그의 주요 검색로봇 요청과 오류 응답
같은 주소가 크롤링 자료와 사이트맵, 분석 도구에 다르게 나타나면 프로토콜, 호스트, 끝 슬래시와 파라미터를 정리한 대표 URL을 정합니다. 이 목록이 URL 매핑표의 출발점입니다.
마이그레이션에 해당하는 것과 아닌 것
| 변경 | 판단 |
|---|---|
old.example.com/a를 www.example.com/a로 이동 | URL이 바뀌는 사이트 마이그레이션 |
| HTTP 주소를 HTTPS로 전환 | 프로토콜과 URL이 바뀌는 마이그레이션 |
| CMS를 바꾸지만 모든 공개 URL과 콘텐츠가 유지됨 | 플랫폼 마이그레이션. URL 매핑은 필요 없지만 렌더링, 상태 코드, 캐노니컬, 색인을 점검 |
| 색상과 폰트만 바꾸고 URL과 콘텐츠는 유지 | 일반 디자인 변경 |
이전 유형에 따라 도구와 유지할 환경도 달라집니다.
| 이전 유형 | 추가로 확인할 작업 |
|---|---|
| 도메인 변경 | 옛 도메인과 새 도메인의 Search Console 소유권, 주소 변경 도구 조건, 옛 서버의 301 유지 |
| HTTP에서 HTTPS 전환 | 주소 변경 도구는 쓰지 않음. 인증서와 모든 HTTP 변형의 HTTPS 이동 확인 |
| CMS나 호스팅만 변경 | URL이 같아도 DNS, 상태 코드, 렌더링, canonical과 분석 태그 대조 |
| 서브도메인과 하위 폴더 통합 | 호스트별 URL 매핑, robots.txt, 내부 링크와 속성 범위 확인 |
URL이 그대로인 호스팅과 CDN 이전은 URL 매핑이 필요하지 않습니다. 대신 DNS와 서버 응답, 검색로봇 접근, 렌더링, 분석 태그가 이전 전과 같은지 확인합니다. CMS만 바꿨더라도 공개 HTML과 JavaScript 처리 결과가 달라졌다면 기술 검증이 필요합니다.
실제 URL 매핑표 예시
| 기존 URL | 새 URL | 처리 |
|---|---|---|
/old-guide | /guide | 가장 가까운 대응 페이지로 301 |
/old-price | /pricing | 가격 페이지로 301 |
/expired-event | 없음 | 대체 페이지가 없으면 404 또는 410 검토 |
모든 옛 URL을 홈으로 보내지 않습니다. 새 페이지가 없는 주소는 관련 없는 곳으로 이동시키기보다 정상적인 삭제 응답을 검토합니다. 구현 뒤에는 각 표의 기존 URL을 요청해 상태 코드와 최종 도착 URL이 맞는지 자동 검사합니다.
사이트 규모에 따라 이전 단위도 달라질 수 있습니다. 중소 사이트는 전체를 한 번에 옮기는 편이 처리 흐름을 단순하게 만들 수 있고, 대형 사이트는 디렉터리나 기능 단위로 시험 이전을 검토할 수 있습니다. 일부 구간의 결과가 전체 이전을 보장하지는 않으므로 기준선과 검증 항목은 동일하게 유지합니다.
출시 직전 확인 순서
스테이징 사이트를 막기 위해 넣은 noindex와 robots.txt 차단이 운영 서버에 남는 사고가 많습니다. 출시 직전에는 공개 URL 표본을 골라 다음 항목을 한 번에 확인합니다.
- 새 URL이 200을 반환하고 옛 URL은 한 번의 301로 대응 URL에 도착하는지 봅니다
- 새 페이지의 canonical, 내부 링크와 사이트맵이 모두 새 주소를 쓰는지 확인합니다
- robots.txt와 robots meta에서 운영 페이지를 막고 있지 않은지 봅니다
- 모바일과 JavaScript 렌더링 뒤에도 본문, 제목과 구조화 데이터가 남는지 확인합니다
- GA4와 광고 전환 태그, 폼과 전화 클릭이 실제로 수집되는지 시험합니다
- 인증서, CDN 캐시, DNS 전환 뒤에도 모든 호스트가 정한 대표 주소로 모이는지 봅니다
도메인이 바뀌었다면 Naver Search Advisor에도 새 사이트를 별도로 등록하고 사이트맵을 제출합니다. 옛 사이트를 먼저 차단하거나 서버를 끄면 네이버 검색로봇이 301과 새 주소를 확인하지 못할 수 있습니다.
출시 뒤 검증과 되돌리기 기준
이전 직후 순위와 유입의 일시 변동은 정상 범위입니다. 전체 트래픽 하나보다 이전 전 상위 URL 묶음을 먼저 봅니다.
- 서치콘솔에서 옛 속성과 새 속성을 함께 보며 크롤링 오류와 404 증가를 확인합니다
- 유입이 컸던 상위 페이지부터 옛 주소 접속이 새 주소로 정확히 넘어가는지 표본 검사합니다
- 리디렉션이 여러 번 튀는 체인, 302로 잘못 걸린 구간을 찾아 정리합니다
- 특정 디렉터리만 404가 늘면 매핑 누락을, 페이지는 열리는데 노출만 사라지면 noindex와 canonical, 렌더링 회귀를 우선 확인합니다
- 리디렉션은 임시 장치가 아닙니다. 구글은 최소 1년 유지를 권하고, 외부 링크가 옛 주소를 가리키는 한 사실상 계속 두는 것이 안전합니다
새 사이트가 열리지 않거나 결제와 문의, 핵심 템플릿이 광범위하게 깨졌다면 애플리케이션 배포나 DNS를 이전 상태로 되돌릴 수 있습니다. 이때 옛 URL이 다시 정상 응답하도록 전체 흐름을 함께 복구해야 합니다. 순위가 잠시 흔들린다는 이유만으로 정상 작동하는 301을 철회하거나 옛 주소와 새 주소를 번갈아 열면 검색엔진의 이전 처리를 더 어렵게 만듭니다.
Google 검색의 AI 기능은 새 URL이 다시 크롤링되고 색인되는 과정에 영향을 받습니다. ChatGPT와 Claude 같은 범용 챗봇은 이전 주소를 갱신하는 시점과 검색 경로가 다를 수 있어 301만으로 출처 변경을 보장할 수 없습니다. 서버 로그에서 AI 크롤러의 옛 주소와 새 주소 요청을 보고, 주요 질문의 실제 출처 URL이 새 주소로 바뀌었는지 서비스별로 확인합니다.
흔한 실패 유형
경험적으로 사고는 기술보다 목록에서 납니다. 매핑표에서 빠진 구석 페이지들, 별도로 운영되던 옛 카테고리 주소, 파라미터가 붙은 변형 주소가 조용히 404가 되어 유입을 흘립니다. 이전 전 인벤토리의 완전성이 성패를 가릅니다.
자주 묻는 질문
마이그레이션하면 순위가 떨어지나요?
이전 과정에서는 검색 노출이 일시적으로 달라질 수 있고 기존 수준의 회복을 보장할 수는 없습니다. 하락이 지속된다면 리디렉션 누락과 콘텐츠 변경, 크롤링 및 색인 문제를 점검합니다.
디자인 리뉴얼도 마이그레이션인가요?
URL이 그대로면 좁은 의미의 마이그레이션은 아니지만, 리뉴얼 과정에서 주소 체계가 바뀌는 경우가 많아 결과적으로 같은 관리가 필요합니다. 리뉴얼 계획 단계에서 URL 변경 여부부터 확인하는 것이 안전합니다.
이전과 리라이팅을 동시에 해도 되나요?
권장하지 않습니다. 주소와 내용이 동시에 바뀌면 순위 변동의 원인을 분리할 수 없습니다. 구글도 사이트 이전 시 큰 콘텐츠 변경을 함께 하지 말라고 안내합니다. 이전을 안정시킨 뒤 개선을 진행하는 순서가 진단 가능성을 지킵니다.