사이트 마이그레이션

TL;DR — 사이트 마이그레이션은 URL을 옮기거나 Google이 페이지를 읽는 방식을 바꿀 수 있는 큰 변경입니다. 새 도메인, HTTPS 전환, 새 플랫폼, 폴더 재구성, 심지어 디자인 개편도 포함됩니다. 트래픽을 보호하는 방법은 매번 같습니다. 각 기존 페이지를 가장 잘 대응하는 새 페이지로 301 리디렉션하고, 그 리디렉션을 오랫동안 유지하세요. 일시적인 트래픽 하락은 정상이지만 끝내 회복되지 않는다면 무언가 잘못된 것입니다.

사이트 마이그레이션이란

“Migration”(마이그레이션)이라는 말은 거창하게 들리고, 실제로 그럴 때도 있습니다. 하지만 검색엔진이 페이지를 찾고 읽고 순위를 매기는 방식에 영향을 줄 수 있는 중요한 사이트 변경을 뜻할 뿐입니다. 새 도메인으로 옮기는 것도, http://에서 https://로 전환하는 것도 마이그레이션입니다. 블로그를 blog.example.com에서 example.com/blog/로 옮기는 것도 해당합니다. 모든 URL을 그대로 유지하는 디자인 개편도 포함됩니다. Google이 순위를 매기는 콘텐츠와 템플릿이 바뀌기 때문입니다.

이 변경들을 한데 묶는 이유는 같은 위험과 같은 실행 원칙을 공유하기 때문입니다.

가장 중요한 한 가지 규칙

URL이 바뀌면 브라우저와 검색엔진에 페이지가 어디로 갔는지 알려야 합니다. 이를 위해 리디렉션, 구체적으로 301(영구) 리디렉션을 사용합니다. “이 페이지는 이곳으로 영구히 이동했습니다.”이라는 뜻입니다. 기존 URL의 순위를 새 URL로 실제로 전달하는 것은 리디렉션입니다. Google은 301과 기타 영구 리디렉션이 PageRank 손실을 일으키지 않는다고 설명합니다.

가장 중요한 부분은 각 기존 페이지를 가장 관련성 높은 새 페이지 하나에 연결하는 것입니다. 모든 페이지를 홈페이지로 보내지 마세요. 기존 상품 페이지에 실제로 대응하는 페이지가 없다면 홈페이지가 아니라 가장 가까운 카테고리로 보내세요. Google은 많은 기존 페이지를 모두 홈페이지로 리디렉션하면 어차피 404 “페이지를 찾을 수 없음” 오류처럼 취급하므로 이점이 없습니다.

흔한 오해

• “리디렉션을 하면 링크 가치가 손실된다.” 그렇지 않습니다. 영구 리디렉션은 PageRank를 잃게 하지 않습니다. 이 오해는 이미 수년 전에 해소됐습니다.
• “주소 변경 도구가 사이트를 대신 옮겨 준다.” 그렇지 않습니다. 이 Google Search Console 도구는 새 도메인으로 옮겼다고 Google에 알릴 뿐이며 실제 작업은 리디렉션이 합니다. 또한 도메인 전체 이동에만 쓰이며 HTTPS 전환이나 폴더 재구성에는 쓰이지 않습니다.
• “트래픽이 줄었으니 마이그레이션이 실패했다.” 대개 그렇지 않습니다. Google이 모든 것을 다시 파악하는 동안의 일시적인 변동은 정상입니다. 몇 주 기다려 보세요. 이 주장에 대한 근거 Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. 범위: Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. 신뢰도: 높음 · 검증일: 2026-07-14 Google Search Central: Site move with URL changes
• “몇 달 후에는 리디렉션을 없애도 된다.” 훨씬 오래 유지하세요. 이상적으로는 수년 동안, 가능하다면 사실상 영구적으로 유지해야 합니다.

한 번에 하나씩 바꾸기

마이그레이션에서 가장 큰 위험은 한 번에 너무 많은 것을 바꾸는 것입니다. 같은 날 새 도메인과 새 플랫폼과 새 URL 구조로 바꾸면 세 가지 마이그레이션을 겹쳐 진행하는 셈이며 위험이 배가됩니다. 큰 변경을 단계로 나눌 수 있다면 그렇게 하세요.

일곱 단계의 전체 과정, 리디렉션 전략, 마이그레이션 유형별 맞춤 체크리스트가 필요하다면 고급 탭으로 이동하세요.

TL;DR — 마이그레이션 위험은 _변경량 × 한 번에 바꾸는 양_입니다. 301/308 리디렉션이 중심축입니다. 순위를 전달하고 PageRank를 잃지 않습니다. 주소 변경 도구, 사이트맵, 내부 링크, canonical 등 나머지는 보조 신호입니다. 기존→신규를 1:1로 연결하고, 홈페이지로 일괄 리디렉션하지 말며(soft 404), 체인을 피하고, 리디렉션을 “12 months”(12개월)라는 기준보다 훨씬 오래 유지하세요. 일시적인 변동과 회복을 예상하세요. 영구적인 하락은 무언가 잘못됐다는 뜻이며, 보통 운영에 남은 스테이징 차단, 제거된 hreflang/canonical, 잘못 들어간 noindex, 엉뚱한 페이지로 향하는 리디렉션이 원인입니다. 아래에서 공통 7단계 과정과 각기 주의 사항이 있는 7가지 마이그레이션 유형을 다룹니다.

이 허브는 분류, 원칙, 위험 모델, 마이그레이션 유형별 결정, 회복 진단을 담당합니다. 실행할 작업 순서, 명시된 담당자, 릴리스 게이트, 인수 기준은 웹사이트 마이그레이션 체크리스트 를 사용하세요.

마이그레이션의 실제 의미와 7가지 유형

사이트 마이그레이션은 검색엔진의 크롤링·색인·순위 결정에 영향을 줄 수 있는 URL 구조, 도메인, 플랫폼, 프로토콜 또는 호스팅의 중요한 변경입니다. 한 줄의 HTTPS 전환부터 수십만 URL을 새 CMS와 새 도메인으로 옮기는 전면적인 리브랜딩까지 포함합니다.

리디렉션을 하나라도 작성하기 전에 가장 유용한 일은 마이그레이션을 분류하는 것입니다. 실제 마이그레이션 대부분이 여러 유형을 동시에 포함한다는 점도 알아야 합니다. 다음은 대략적인 위험 순으로 정리한 일곱 유형입니다.

번호는 아래 유형별 설명의 섹션 순서입니다. 표는 위험 순으로 정렬해 자신의 위치를 파악하기 쉽게 했습니다. 위험 = 바꾸는 양 × 한 번에 바꾸는 양입니다. 같은 URL에서 디자인만 바꾸는 것은 위험이 낮습니다. 도메인 변경 + URL 재구성 + 플랫폼 교체를 동시에 하면 세 가지 고위험 유형이 겹칩니다. Google도 한 번에 하나씩 바꾸라고 조언합니다.

공통 마이그레이션 과정

아래 유형별 단계를 더하기 전에 이 과정을 모든 마이그레이션에 적용합니다. 저는 이런 작업을 많이 진행했으며 성공 사례의 공통점은 같습니다. 마이그레이션의 성공에는 체크리스트 이상이 필요합니다. 체크리스트는 단계 누락을 막지만, 실제로 성공시키는 것은 과정과 모든 단계에서의 SEO 참여입니다.

1단계 — 계획

• 해당하는 모든 유형을 분류하세요. 플랫폼 교체와 함께 URL 구조와 도메인도 바꾸면 세 가지 마이그레이션을 동시에 하는 것입니다. 실제 위험 범위를 파악하도록 처음부터 모두 명시하세요.
• 출시 후가 아니라 전에 경영진과 기대치를 맞추세요. 트래픽은 거의 확실히 변동합니다. 일시적 하락은 정상이며 예상되는 일이라고 이해관계자에게 설명해 평범한 변동 때문에 당황해 롤백하지 않게 하세요.
• 항상 롤백 계획을 마련하세요. 극단적인 상황에서만 쓸 생각이어도 원래 상태로 돌아갈 방법은 항상 있어야 합니다.
• 트래픽이 적을 때 출시하세요. Google도 가능하면 트래픽이 적은 시기에 옮기도록 권장합니다. 실무적으로는 월요일–목요일, 금요일이나 판매 성수기는 피하세요. 문제를 해결할 직원이 있고 안정화 중 위험에 노출되는 매출이 적도록 하기 위해서입니다.
• SEO 프로젝트 관리자를 지정하고 프로젝트 관리 시스템을 쓰세요. 마이그레이션은 개발, 콘텐츠, 분석, SEO에 걸치므로 누군가 의존 관계를 책임져야 합니다.

2단계 — 기존 사이트 기준 측정과 크롤링

‘이전’ 모습 없이는 마이그레이션 품질을 검증할 수 없습니다. 기존 사이트가 운영 중일 때 기록하세요.

• 기존 사이트 전체를 크롤링하세요(Screaming Frog, Ahrefs Site Audit 또는 동등한 도구). 저장해 두세요. 출시 후 비교할 기준입니다.
• URL별로 모든 것을 기록하세요: 상태 코드, 제목, 메타 설명, canonical 태그, hreflang, 제목 계층, 내부 링크 구조, Core Web Vitals.
• 출시 전에 모든 핵심 페이지의 순위를 기록하세요.
• 트래픽 기준 데이터를 내보내세요. Search Console 실적 데이터(최근 3/6/12개월)와 GA4 페이지/세션 수준 데이터입니다.
• 백링크가 많은 상위 페이지를 내보내세요(Ahrefs + GSC 링크 보고서). 링크 가치를 지닌 URL이므로 반드시 정확히 리디렉션해야 합니다.
• 모든 출처의 기존 리디렉션을 모으세요: CMS, CDN, .htaccess/서버 설정, Search Console의 리디렉션이 포함된 페이지 보고서, 분석 도구. 출처 하나를 빠뜨리면 출시 후 리디렉션 체인이 생깁니다.
• 기존 문제를 이전하기 전에 감사하세요. 새 도메인이나 CMS로 옮긴다고 기존 canonical 오류, 색인 비대화, 크롤링 차단을 가져가도 되는 것은 아닙니다.

3단계 — URL 매핑

일대일 스프레드시트를 만드세요. 각 기존 URL → 가장 관련성 높은 새 URL 하나. 예외는 없습니다. 모든 URL에 대응 대상을 지정합니다.

• 관련성이 높은 대체 페이지가 있는 제거된 페이지: 주제가 가장 가까운 운영 페이지로 리디렉션하세요. Google은 많은 기존 URL을 홈페이지처럼 무관한 단일 대상으로 리디렉션하지 말라고 명시합니다. 이 주장에 대한 근거 Google advises against redirecting many old URLs to one irrelevant destination such as the home page and says that can be treated as a soft 404. 범위: Google Search guidance for site moves with changed URLs; relevant replacements remain appropriate. 신뢰도: 높음 · 검증일: 2026-07-14 Google Search Central: Site move with URL changes
• 대응하는 페이지가 전혀 없는 경우: 올바른 410(삭제됨) 또는 404를 반환하세요. 홈페이지로 리디렉션하지 마세요. soft 404로 취급됩니다.
• 개별 URL을 추적하는 것이 가장 중요합니다. 각 URL이 무엇이었고 무엇이 되어야 하는지 명확한 지도를 갖추기 위해서입니다. 이 지도가 곧 마이그레이션입니다.

4단계 — 리디렉션 전략

이것이 프로젝트 전체의 중심축입니다.

• 영구 이동에는 301(Moved Permanently, 영구 이동) 또는 308을 사용하세요. Google은 301과 308 같은 서버 측 영구 리디렉션을 권장합니다.
• 301은 PageRank를 전달합니다. 분명한 사실입니다. Google 문서는 영구 리디렉션이 PageRank 손실을 일으키지 않는다고 설명하며, Gary Illyes도 수년 전에 30x 리디렉션이 더 이상 PageRank를 잃지 않는다고 확인했습니다. 영구 리디렉션에서 링크 가치가 새어 나간다는 가이드는 오래된 것입니다. 이 주장에 대한 근거 Google says 301 and other permanent redirects do not cause a loss in PageRank. 범위: Google Search handling of permanent redirects during site moves; this does not guarantee unchanged rankings after a migration. 신뢰도: 높음 · 검증일: 2026-07-14 Google Search Central: Site move with URL changes
• 리디렉션 체인을 피하세요. 기존 → 신규로 직접 연결하세요. Google은 체인을 짧게, 이상적으로는 3개 이하이면서 5개 미만으로 유지하라고 합니다. Googlebot은 약 10홉까지 따라가므로 짧은 체인이 치명적이지는 않지만, 홉마다 실패 가능성과 신호 통합 지연이 생깁니다. 흔히 눈에 띄지 않는 원인은 후행 슬래시 불일치(/page와 /page/)입니다. canonical 형식 하나를 정하고 다른 쪽을 리디렉션하세요.
• 페이지뿐 아니라 이미지, PDF, 기타 비HTML 파일 등 자산도 리디렉션하세요.
• 서버 측 방식만 사용하세요. JavaScript 리디렉션은 최후의 수단입니다. 렌더링이 실패하면 Google이 전혀 처리하지 못할 수 있습니다.
• 임시와 영구를 혼동하지 마세요. 302/307은 색인 파이프라인에 대상을 canonical로 삼으라고 알리지 않습니다. 기존 URL이 색인에 남고 신호도 대체로 그대로입니다. 실제로 일시적인 상황에만 임시 리디렉션을 쓰세요.
• 리디렉션을 ‘1년’보다 훨씬 오래 유지하세요. Google의 최소 기준은 ‘최소 1년’이지만 Illyes는 약 12개월이라는 수치가 사실상 Google을 위한 것이라고 설명했습니다. 사용자에게는 사실상 영구적으로 유지하는 편이 좋습니다. Bing은 최소 1–2년 쪽을 권합니다. 제 원칙은 기존 URL에 트래픽이나 링크가 조금이라도 남아 있는 한 유지하는 것으로, 실무에서는 무기한을 뜻합니다. 이 주장에 대한 근거 Google recommends keeping site-move redirects as long as possible, generally for at least one year. 범위: Google Search's minimum site-move guidance; continuing user traffic or links can justify retaining redirects longer. 신뢰도: 높음 · 검증일: 2026-07-14 Google Search Central: Site move with URL changes

5단계 — 스테이징과 출시 전 테스트

• 스테이징 사이트의 색인을 차단하세요. 스테이징 호스트에 noindex 및/또는 robots.txt Disallow를 적용하세요. 처음부터 색인되지 않게 스테이징이나 개발 사이트의 접근을 제한하세요. 이 차단은 6단계를 위해 기록하세요. 출시할 때 반드시 제거해야 합니다.
• 공개 테스트에는 beta.example.com 같은 임시 호스트명을 쓰세요.
• 기존 → 신규의 모든 리디렉션을 테스트하세요. 잘못된, 존재하지 않는 URL로 리디렉션하는 경우가 흔합니다. 스테이징을 대상으로 기존 URL 전체 목록을 크롤링해 각각 의도한 운영 페이지에 한 홉으로 도달하는지 확인하세요.
• 스테이징 크롤링을 2단계 기준과 비교하세요: 제목, 메타 설명, canonical 태그, hreflang, 구조화 데이터, 메타 robots, 내부 링크, 페이지 속도.
• canonical이 스테이징 URL이 아니라 운영 사이트를 가리키는지 확인하세요.
• 분석 기능 작동을 확인하고(GA4, GSC 인증, 태그 관리자), 양식·결제 등 전환 경로를 테스트하세요.
• 방화벽이나 DoS 방어가 Googlebot을 차단하지 않는지 확인하세요. DNS와 호스트에 도달할 수 있어야 합니다.

6단계 — 출시

• 모든 크롤링 차단을 즉시 제거하세요. 구축용이었던 noindex와 스테이징 robots.txt 규칙을 없애세요. 스테이징 차단을 운영에 남기는 것은 가장 흔한 마이그레이션 참사입니다. 마이그레이션에만 필요했던 noindex나 robots.txt 차단도 빠뜨리지 마세요.
• 모든 301 리디렉션을 동시에 활성화하세요.
• 새 canonical URL만 넣어 현재 운영 XML 사이트맵을 업데이트하고 다시 제출하세요. 기존 URL 사이트맵이 리디렉션 발견이나 모니터링에 도움이 된다면 분리된, 명백히 일시적인 사이트맵으로 제출하세요. 이전·신규 목록을 절대 섞지 말고 기존 URL 사이트맵이 유용한 근거를 더 이상 제공하지 않으면 제거하세요. Google의 사이트 이전 지침 을 참고하세요.
• GSC URL 검사 도구로 리디렉션을 표본 점검하세요.
• 주소 변경 도구를 제출하세요. 도메인 수준 이동에만 해당합니다(유형 1 참조).
• Bing에는 현재 방식인 IndexNow로 제출하세요. Bing의 기존 Site Move 도구는 2021년경 폐지됐으므로 여전히 그 도구를 쓰라는 가이드를 따르지 마세요. IndexNow를 사용하면 마이그레이션 후 이전된 모든 URL을 한꺼번에 제출할 수 있습니다.
• 서버 용량을 확보하세요. 이전 직후 Google은 평소보다 새 사이트를 더 많이 크롤링합니다.

7단계 — 출시 후 모니터링

• 일시적인 변동을 예상하세요. Google은 이전 중 사이트 순위의 일시적 변동을 예상하라고 합니다. 하락은 마이그레이션 실패의 증거가 아닙니다. Martin Splitt는 전체 URL 구조와 콘텐츠를 새 도메인에 그대로 복사하는 경우 반드시 하락하는 것은 아니라고 말했습니다.
• 소요 시간을 알아두세요. Google에 따르면 중간 규모 사이트의 대부분 페이지가 색인에서 이동하는 데 몇 주가 걸릴 수 있고 큰 사이트는 더 오래 걸립니다. 완전한 안정화에는 흔히 두어 달이 걸립니다.
• 회복되지 않는 하락을 진단하세요. 이런 하락은 거의 ‘이동 자체’ 때문이 아닙니다. Gary Illyes의 가장 유용한 마이그레이션 통찰은 이전 후 하락이 대개 새 사이트의 누락되거나 잘못 들어간 태그/지시 때문이라는 것입니다. 제거된 hreflang, 추가된 noindex, 깨진 canonical부터 살펴보세요.
• 리디렉션을 일괄 검증하세요. 기존 URL 목록을 다시 크롤링하고 각 URL이 올바른 운영 페이지로 301을 반환하는지 확인하세요. 체인이거나 끝에서 404가 나면 안 됩니다.
• canonical 선택을 관찰하세요. 많은 외부 링크와 남아 있는 내부 링크가 계속 기존 URL을 가리키면 Google은 신규 대신 기존 URL을 계속 색인할 수 있습니다. 따라서 내부 링크 업데이트는 리디렉션만큼 중요하며, 주요 링크 제공자에게 변경을 요청할 가치가 있습니다. 새 직접 링크가 리디렉션된 링크보다 낫습니다.
• GSC를 모니터링하세요: 페이지 색인 생성 보고서, 실적(페이지별 클릭/노출), 크롤링 통계, 새로운 직접 조치입니다. 첫 달에는 매주 순위를 기록하세요. Bing은 마이그레이션 후 최소 세 달 동안 서버 로그를 살펴보라고 안내합니다.

리디렉션은 효과가 있었나? 스스로를 속이지 않고 영향 측정하기

출시 당일 스크린샷으로 마이그레이션을 평가하지 마세요. 출시 전에 기존 URL, 새 URL, 검색어/페이지 집단, 지표를 정하고 동일한 집단을 네 점검 시점에서 살펴보세요.

각 점검에서 변경 후 기간을 같은 길이의 변경 전 기간과 비교하고 변경 당일은 제외하세요. 출시 당일에는 이전·신규 상태, 부분 배포, 캐시 변경, QA 트래픽, 추적 단절이 섞입니다. 어느 쪽에 넣어도 비교가 오염됩니다. 집단과 지표 정의를 고정하고, 브랜드/비브랜드·기기·국가·템플릿·마이그레이션 유형 구분은 측정 계획에 포함된 경우에만 적용하세요.

이익이나 손실의 원인을 돌리기 전에 같은 기간의 다른 변경을 주석으로 남기세요. 릴리스, 콘텐츠 업데이트, 추적 변경, 계절성, 캠페인, Google의 확인된 순위 업데이트 이력 입니다. 알고리즘 업데이트가 겹쳤다고 마이그레이션에 책임이 없거나 있다고 단정할 수 없습니다. 원인 구분이 혼재됐다는 뜻이므로 불확실성을 보고하고, 응답 테스트·색인 커버리지·canonical 선택·서버 로그 같은 직접적인 구현 근거에 더 의존하세요.

‘변화 없음’도 유효한 결과입니다. 리디렉션의 역할은 흔히 URL이 이동하는 동안 접근, 신호, 전환을 유지하는 것입니다. 정상적인 단일 홉 응답과 함께 실적이 유지됐다면 성공일 수 있습니다. 데이터가 뒷받침하지 않는 성장 이야기를 찾지 말고 그 결과를 기록하세요.

계획 중인 Before/After Impact Checker(전후 영향 검사기) 는 이 단계에 해당합니다. 출시되면 변경 당일 제외와 7/14/30/90일 비교를 표준화할 수 있습니다. 그때까지는 스프레드시트나 보고 계층을 사용하고 각 점검의 정확한 기간, 필터, 집단, 주석을 저장하세요.

7가지 마이그레이션 유형

위 공통 과정이 작업의 대부분입니다. 아래에서는 각 유형에 특유한 내용, 즉 놓치기 쉬운 주의 사항과 필수 작업을 다룹니다.

유형 1 — 도메인 변경 / 리브랜딩

의미: 모든 페이지를 oldbrand.com에서 newbrand.com으로 옮깁니다. 새 도메인과 새 GSC 속성을 사용하며, 이상적으로는 URL 구조를 동시에 바꾸지 않습니다.

위험: 가장 높음. 모든 URL이 바뀌고 외부 링크를 업데이트해야 하며 GSC 이력이 두 속성으로 나뉩니다.

주의 사항과 필수 작업:

• 도메인 변경에 디자인 개편과 URL 재구성을 결합하지 마세요. Google의 주소 변경 문서도 도메인 이동과 콘텐츠·URL 구조 개편을 함께 하면 어느 정도 트래픽 손실이 발생할 가능성이 높다고 경고합니다. 도메인을 먼저 옮기고 구조는 나중에 바꾸세요.
• 등록 전에 새 도메인의 이력을 조사하세요. archive.org를 확인하세요. 과거 직접 조치 이력이 있는 기존 등록 도메인은 새 브랜드가 불리하게 출발하게 할 수 있습니다.
• 기존 도메인을 만료시키지 마세요. 갱신하고 리디렉션을 유지하세요. 만료돼 다른 사람이 가져가면 리디렉션과 링크 가치가 사라집니다.
• 도메인 이동을 연달아 연결하지 마세요(A → B 직후 B → C). 주소 변경 도구는 연쇄 적용할 수 없습니다.

주소 변경 도구가 하는 일과 하지 않는 일. 가장 혼동이 많은 부분입니다. 이 도구는 Google에 새 사이트 크롤링과 색인을 중시하도록 알리고, 신호를 전달하며, 새 사이트의 canonical을 선호하게 합니다. 기간은 180일입니다. 중요한 점은 다음과 같습니다.

• 경로 범위가 없는 도메인 또는 하위 도메인 이동에 적용됩니다. 사이트 내 개별 페이지나 폴더 이동에는 해당하지 않습니다.
• 자격을 충족하는 기존·신규 Search Console 속성의 확인된 소유자여야 합니다. 도메인 속성은 가능하고 루트 URL 접두어 속성도 가능하지만, 경로 범위가 지정된 URL 접두어 속성은 안 됩니다. Google의 주소 변경 요구 사항 과 속성 적격성 안내 를 참고하세요.
• 엄격한 1:1 이동입니다. 병합이나 부분 이동에는 사용할 수 없습니다.
• 필수가 아니라 선택 사항입니다. 추가 신호 하나일 뿐이며 리디렉션이 올바르면 없어도 괜찮습니다. 실제 역할은 301이 하고 도구는 전달을 빠르고 명확하게 할 뿐입니다. 검색엔진 도구 클러스터에 주소 변경 도구의 별도 심층 안내가 있습니다.

180일이라는 기간은 리디렉션 종료 기한이 아닙니다. 180일 후 Google은 이 도구를 통한 기존·신규 사이트 관계를 더 이상 인정하지 않고 기존 사이트를 무관한 사이트로 취급합니다. 바로 그래서 리디렉션이 도구보다 오래 유지되어야 합니다. 최소 1년이라는 Google의 기준을 지키고, 현실적으로는 훨씬 오래 유지하세요.

유형 2 — HTTP → HTTPS

의미: 암호화되지 않은 HTTP에서 HTTPS(TLS/SSL)로 옮깁니다. 모든 URL이 http://에서 https://로 바뀝니다. HTTPS는 2014년부터 가벼운 순위 신호였으며, 오늘날 HTTP 사용은 실제 불이익입니다.

위험: 제대로 하면 낮음–중간, 인증서나 혼합 콘텐츠 문제가 생기면 높음입니다.

주의 사항과 필수 작업:

• 주소 변경 도구를 사용하지 마세요. Google은 HTTP → HTTPS에는 대신 사이트 이전 지침을 사용하라고 명시합니다.
• 모든 것을 HTTPS 홈페이지로 보내는 포괄 규칙 대신 URL별 301 리디렉션을 쓰세요. 단순한 프로토콜 이동이라는 신호가 명확할수록 Google이 더 원활하게 전환합니다.
• 혼합 콘텐츠를 수정하세요. 전환 후에도 HTTP로 로드되는 이미지, 스크립트, 스타일시트는 혼합 콘텐츠 경고와 상충하는 신호를 만듭니다. 프로토콜 상대 또는 상대 URL을 사용하세요. upgrade-insecure-requests 콘텐츠 보안 정책은 남은 항목을 빠르게 처리하는 방법입니다.
• Google은 자동으로 HTTPS를 canonical로 선호합니다. 단, 잘못된 인증서, 안전하지 않은 의존 리소스(혼합 콘텐츠), HTTP로 돌아가는 리디렉션, 기타 상충 신호가 있으면 예외입니다. 따라서 인증서 문제는 보기만 나쁜 것이 아니라 HTTP 버전을 canonical로 남게 할 수 있습니다.
• HSTS를 주의해서 사용하세요. HSTS는 정해진 기간 HTTPS로만 연결하도록 브라우저에 알립니다. TLS가 확실히 안정되기 전에 켜면 인증서 오류가 재방문자의 접속 실패로 이어집니다. 확신이 생긴 후 낮은 max-age부터 시작해 점차 늘리세요.
• 강력한 인증서(2048비트 RSA 또는 EC, Qualys SSL 테스트 A/A+ 목표)를 사용하고 쿠키에 Secure 플래그를 설정하세요.

유형 3 — 플랫폼 / CMS 교체

의미: 새 CMS나 기술 구성으로 옮깁니다(예: WordPress → 헤드리스, Magento → Shopify). URL, 템플릿, 내부 링크, 렌더링 변경이 함께 따라오는 경우가 많습니다.

위험: 높음. 여러 가지가 동시에 바뀌기 때문입니다.

주의 사항과 필수 작업:

• URL 변경을 예상하세요. 플랫폼마다 슬러그 구조, 카테고리 계층, 페이지 나누기를 다르게 생성합니다. 플랫폼을 확정한 후가 아니라 전에 URL 매핑을 계획하세요.
• 리디렉션은 자동으로 이전되지 않습니다. .htaccess 파일의 기존 리디렉션을 새 호스트에 복사하지 않는 것이 전형적인 실수입니다. 새 리디렉션 계층을 만들기 전에 CMS, CDN, 서버 설정, GSC 리디렉션이 포함된 페이지 보고서 등 모든 출처의 규칙을 모으세요.
• 구조화 데이터를 다시 구현하세요. schema 마크업이 옮겨진다고 가정하지 말고 출시 후 검증하세요.
• 헤드리스/SPA 프런트엔드로 옮기면 JavaScript 렌더링을 테스트하세요. 렌더링은 Googlebot의 페이지 처리 방식을 바꿉니다. 콘텐츠 렌더링, 특히 JavaScript는 제가 이전 후 QA에서 가장 철저히 점검하는 항목 중 하나입니다.
• 페이지 속도와 모바일을 기준 측정하세요. 새 테마는 흔히 더 무겁습니다. Google은 모바일 버전을 색인하므로 새 플랫폼이 모바일에서 느려지거나 망가지지 않았는지 확인하세요.
• 후행 슬래시의 일관성을 강제하세요. 플랫폼마다 처리가 다르고 불일치는 눈에 띄지 않게 체인을 만듭니다.
• 출시 전에 새 플랫폼에 분석 및 인증 태그를 다시 배포하세요(GA4, GSC, 태그 관리자).
• URL, 내부 링크, 템플릿이 모두 동시에 바뀌는 큰 재구성에서는 Google이 사이트에 대한 기존 이해를 그대로 유지할 수 없습니다. 따라서 동등한 상태로 옮기는 경우보다 안정화가 오래 걸릴 수 있습니다.

유형 4 — URL 구조 / 사이트 재구성

의미: 같은 도메인의 URL 경로를 바꿉니다. 예를 들어 /category/post/ → /post/입니다. 도메인은 그대로이며 콘텐츠는 바뀔 수도, 그대로일 수도 있습니다.

위험: 중간. 도메인 권위는 유지되지만 변경되는 모든 URL에 리디렉션이 필요하고 내부 링크 그래프도 업데이트해야 합니다.

주의 사항과 필수 작업:

• 사람들이 잊는 것은 내부 링크입니다. 리디렉션은 해 놓고 rel=canonical, 탐색 메뉴, 푸터, 본문 링크를 업데이트하지 않는 패턴을 계속 봅니다. 이런 오래된 신호는 리디렉션이 있어도 Google이 새 URL을 canonical로 선택하기 훨씬 어렵게 합니다.
• canonical 전환이 늦어질 수 있습니다. 기존 URL에 백링크가 더 많고 내부 링크도 계속 가리키면 301 이후에도 Google이 이를 canonical로 선호할 수 있습니다. 내부 링크가 새 URL을 직접 가리키도록 바꾸는 것이 중요합니다.
• 같은 도메인 안에서 구조를 바꾸는 경우 주소 변경 도구를 사용하지 마세요. Google의 안내는 단순합니다. 리디렉션을 추가하고 사이트맵을 업데이트하세요.
• 새 경로로 탐색 경로, 탐색 메뉴, 사이트맵을 업데이트하세요. 사이트맵에는 새 URL만 있어야 합니다.

유형 5 — 웹사이트 디자인 개편(URL 동일)

의미: 도메인과 URL은 유지하지만 템플릿, 문구, 탐색, 이미지 또는 페이지 내 SEO 요소를 바꾸는 디자인 개편입니다. 위험이 가장 낮지만 위험이 없는 것은 아닙니다.

위험: 낮음. 그래도 페이지 내 변경은 순위를 바꿀 수 있습니다.

주의 사항과 필수 작업:

• 페이지 내 요소는 조용히 망가집니다. 디자인 개편에서 <title> 태그, 메타 설명, 제목 계층, 구조화 데이터가 제거되거나 바뀌는 일이 흔합니다. 기존 사이트 기준과 각각 대응시켜 확인하세요.
• 내부 링크를 관찰하세요. 탐색 메뉴 개편으로 깊은 페이지에 권위를 전달하던 고가치 내부 링크가 조용히 사라질 수 있습니다.
• 변경 전후 Core Web Vitals를 측정하세요. 새로운 CSS, JS, 글꼴, 이미지는 거의 항상 페이지 속도를 바꿉니다.
• 콘텐츠 변경은 의도적으로 하세요. ‘URL은 같은’ 디자인 개편에서도 콘텐츠가 줄거나 통합되는 경우가 많습니다. 내용이 줄어든 페이지의 실적이 같을 것이라 가정하지 마세요.
• Google의 URL 변경 없는 사이트 이전 지침이 참고 자료입니다. URL은 유지하면서 인프라나 표현 방식이 바뀔 때 영향을 최소화하는 내용입니다.

유형 6 — 하위 도메인 ↔ 하위 폴더

의미: 하위 도메인과 하위 폴더 사이에서 콘텐츠를 옮깁니다. 가장 흔한 예는 blog.example.com → example.com/blog/입니다. 통합하면 두 호스트에 나뉘어 있던 권위를 하나로 모읍니다.

위험: 중간–높음. Google은 여러 목적에서 하위 도메인과 루트 도메인을 별개로 취급하므로 통합 시 실제 재색인 변동이 발생합니다.

주의 사항과 필수 작업:

• Google에는 두 버전이 별개의 대상입니다. 크롤링 예산은 별개이고 신호도 일부 분리됩니다. 하위 폴더로 통합하면 순효과가 긍정적인 경우가 많지만 시간이 걸리며 실제 이전처럼 작동합니다.
• 같은 루트 내 하위 도메인 → 하위 폴더 이동에는 주소 변경 도구를 사용하지 마세요. Google이 도구 대신 canonical/리디렉션으로 처리하라고 하는 www/non-www 사례와 같은 계열입니다.
• GSC 속성: 하위 도메인과 루트의 속성이 별도로 있을 가능성이 높습니다. 통합 후 데이터가 루트 속성으로 모이므로 하위 도메인의 커버리지가 줄고 루트의 커버리지가 커지는지 보세요.
• 모든 하위 도메인 URL을 대응하는 하위 폴더 URL로 리디렉션하고, 리디렉션을 거치지 않고 새 URL을 직접 가리키도록 내부 링크를 업데이트하세요. 하위 도메인의 전체 백링크 프로필은 301을 통해 주 도메인에 전달되며 주요 링크의 변경 요청도 여전히 도움이 됩니다.
• 분석 설정을 통합 조정하세요. 하위 도메인에 별도/교차 도메인 추적이 있었다면 연속성이 끊기지 않게 GA4를 다시 설정하세요.

유형 7 — 도메인 통합 / 사이트 병합

의미: 둘 이상의 별도 사이트를 하나로 합칩니다. 인수한 경쟁사의 콘텐츠를 주 도메인으로 흡수하거나 브랜드의 국가별/제품별 사이트를 합치는 경우가 예입니다.

위험: 매우 높음. 일반적인 마이그레이션과는 다릅니다. 알릴 1:1 이동이 없고, 통합된 대상은 여러 면에서 Google에 사실상 새 사이트입니다. Martin Splitt의 설명처럼 두 사이트의 결합은 마이그레이션이라기보다 합쳐진 버전으로 새 사이트를 만드는 일에 가깝습니다.

주의 사항과 필수 작업:

• 주소 변경 도구를 사용할 수 없습니다. 한 도메인에서 다른 도메인으로 1:1 이동한다는 전제에 의존하는데 병합은 그렇지 않습니다. URL별 작업입니다.
• 어느 정도 트래픽 손실을 예상하세요. Google은 사이트 A, B, C를 모두 새 위치 D로 옮기면 혼란과 트래픽 손실을 일으킬 수 있다고 경고합니다. 긴 안정화 기간을 계획하세요.
• 중복을 먼저 제거하세요. 병합할 사이트의 주제가 겹치면 중복 콘텐츠가 생깁니다. 리디렉션 전에 겹치는 주제별 canonical 페이지를 결정하세요.
• URL별로 가장 관련성 높은 페이지에 리디렉션하세요. 인수한 도메인 전체를 홈페이지로 일괄 리디렉션하지 마세요. 홈페이지가 아닌 모든 페이지가 soft 404가 됩니다. 각 페이지가 실제 대응 페이지로 갈 때 페이지 수준의 링크 가치가 가장 잘 이전됩니다.
• 병합하는 각 사이트의 GSC 속성을 유지하고 각각의 커버리지(감소 예상)와 주 도메인의 커버리지(증가 예상)를 함께 모니터링하세요.

전문 가이드 선택

해결해야 할 결정이나 실패 유형에 맞는 가이드를 사용하세요.

• 호스팅 마이그레이션 SEO — URL을 유지하는 서버, CDN, DNS 또는 호스팅 변경
• CMS 마이그레이션 SEO — 템플릿, 렌더링, 데이터 일치 위험을 포함한 플랫폼/CMS 변경
• URL 구조 마이그레이션 — 같은 도메인의 경로, 분류 체계, 폴더 변경
• 사이트 분할 / 분리 이전 SEO — 한 사이트의 정해진 섹션을 별도 속성으로 이동
• 인수 후 SEO 통합 — 인수한 사이트, 브랜드, 콘텐츠의 통합 방식 결정
• 마이그레이션 후 트래픽 손실 — 출시 후 회복되지 않는 노출도나 트래픽 진단

관련 주제와의 연결

마이그레이션은 이를 수행하는 리디렉션, Google이 어떤 URL을 유지할지 정하는 canonical 결정, HTTPS 프로토콜, 국제 사이트의 hreflang, 도메인 이동을 알리는 주소 변경 도구 등 여러 인접 주제에 걸칩니다. 각각 별도 심층 주제지만 모든 마이그레이션의 중심축은 같습니다. 기존과 신규를 1:1로 매핑하고, 영구 리디렉션을 적용하고, 유지하며, 이후 적절한 신호를 관찰하세요.

AI 요약

고급 버전의 요약입니다.

• 사이트 마이그레이션은 크롤링·색인·순위에 영향을 줄 수 있는 URL, 도메인, 플랫폼, 프로토콜, 호스트의 주요 변경입니다. 위험 = 변경량 × 한 번에 바꾸는 양입니다.
• 위험 순의 7가지 유형: 디자인 개편(URL 동일, 낮음) → HTTP→HTTPS(낮음–중간) → URL 재구성(중간) → 하위 도메인↔하위 폴더(중간–높음) → CMS 교체(높음) → 도메인 변경/리브랜딩(가장 높음) → 도메인 병합/통합(매우 높음).
• 공통 7단계 과정: 계획·분류 → 기존 사이트 기준 측정/크롤링 → 1:1 URL 매핑 → 리디렉션 전략 → 스테이징·출시 전 테스트 → 출시 → 출시 후 모니터링.
• 301/308 리디렉션이 중심축입니다. 순위를 전달하며 PageRank를 잃지 않습니다. 주소 변경 도구, 사이트맵, 내부 링크, canonical은 모두 보조 신호입니다.
• 기존→신규를 1:1로 매핑하세요. 홈페이지로 일괄 리디렉션하지 말고(soft 404로 취급), 체인을 피하세요(약 3–5홉 미만 유지). 리디렉션을 “12 months”(12개월)보다 훨씬 오래, 사용자에게는 사실상 영구적으로 유지하세요.
• 일시적인 변동과 회복을 예상하세요. 지속적인 하락은 보통 이동 자체가 아니라 운영에 남은 스테이징 차단, 제거된 hreflang/canonical, 잘못된 noindex, 엉뚱한 리디렉션 등 문제가 생겼다는 뜻입니다.
• 주소 변경 도구: 도메인 수준만, 엄격한 1:1, 선택 사항입니다. HTTP→HTTPS, 같은 도메인 재구성, 병합에는 해당하지 않습니다.
• Bing: 기존 Site Move 도구는 폐지됐습니다(약 2021년). 이전한 URL은 IndexNow로 제출하세요. Bing은 리디렉션을 1–2년 유지하는 쪽을 권합니다.

공식 문서

검색엔진의 1차 출처 문서입니다.

Google

• URL 변경을 수반하는 사이트 이전 — 리디렉션, 시기, 기대 사항, 약 1년 리디렉션 유지에 관한 주요 실행 지침
• URL 변경 없는 사이트 이전 — 호스팅/인프라 및 디자인 개편, 임시 호스트명, DNS, 방화벽/DoS 주의 사항
• 리디렉션과 Google 검색 — 영구·임시 리디렉션의 차이와 JavaScript 리디렉션 위험
• 주소 변경 도구, Search Console 도움말 — 지원 이동 범위, 속성 사전 조건, 제외 사항, 리디렉션 지침
• 중복 URL 통합 — HTTPS canonical 선호와 301이 임시 리디렉션보다 강한 canonical 신호인 이유
• canonical 결정 — Google이 canonical URL을 선택하는 방식(명령이 아닌 힌트)
• 서버에서 HTTPS 사용 — TLS 인증서, 혼합 콘텐츠, HSTS 지침. 기존 Google HTTPS 문서는 현재 이곳으로 리디렉션됩니다.

Bing / Microsoft

• Bing과 함께하는 웹사이트 마이그레이션 — Bing의 마이그레이션 체계, 리디렉션 유지 기간, 이전 후 로그 모니터링
• IndexNow — 이전한 URL을 Bing에 제출하는 현재 방식. 기존 Site Move 도구는 폐지됐습니다.

출처의 인용문

Google의 공개 발언입니다. 각 링크는 출처 페이지의 인용 구절로 바로 이동하는 딥 링크입니다.

Google — 리디렉션과 PageRank

• “301 and other permanent redirects don’t cause a loss in PageRank.” (번역) 「301과 기타 영구 리디렉션은 PageRank 손실을 일으키지 않습니다.」 — Search Central, 「URL 변경을 수반하는 사이트 이전」. 인용문으로 이동
• “keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5” (번역) 「체인의 리디렉션 수를 적게, 이상적으로는 3개 이하이면서 5개 미만으로 유지하세요.」 — Search Central, 「URL 변경을 수반하는 사이트 이전」. 인용문으로 이동
• “Keep the redirects for as long as possible, generally at least 1 year.” (번역) 「리디렉션을 가능한 오래, 일반적으로 최소 1년 동안 유지하세요.」 — Search Central, 「URL 변경을 수반하는 사이트 이전」. 인용문으로 이동
• “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page” (번역) 「많은 기존 URL을 홈페이지 같은 무관한 단일 URL 대상으로 리디렉션하지 마세요.」 — Search Central, 「URL 변경을 수반하는 사이트 이전」. 인용문으로 이동

Google — 기대 사항과 시기

• “Expect temporary fluctuation in site ranking during the move.” (번역) 「이전 중에는 사이트 순위의 일시적인 변동을 예상하세요.」 — Search Central, 「URL 변경을 수반하는 사이트 이전」. 인용문으로 이동
• “a medium-sized website can take a few weeks for most pages to move in our index” (번역) 「중간 규모 웹사이트의 대부분 페이지가 Google 색인에서 이동하는 데 몇 주가 걸릴 수 있습니다.」 — Search Central, 「URL 변경을 수반하는 사이트 이전」. 인용문으로 이동
• “Check your redirects from the old site to the new one. We frequently see people redirecting to the wrong (non-existent) URLs.” (번역) 「기존 사이트에서 새 사이트로 가는 리디렉션을 확인하세요. 잘못된, 존재하지 않는 URL로 리디렉션하는 경우를 자주 봅니다.」 — Search Central, 「URL 변경을 수반하는 사이트 이전」. 인용문으로 이동

Google — 주소 변경 도구(180일 기간)

• “Maintain the redirects for at least 180 days—longer if you still see any traffic to them from Google Search.” (번역) 「리디렉션을 최소 180일 동안 유지하고, Google 검색에서 오는 트래픽이 여전히 보인다면 더 오래 유지하세요.」 — Search Console 도움말, 「주소 변경」. 출처 읽기
• “After the 180 day period, Google does not recognize any relationship between the old and new sites, and treats the old site as an unrelated site.” (번역) 「180일 후 Google은 기존 사이트와 새 사이트 사이에 어떠한 관계도 인정하지 않고 기존 사이트를 무관한 사이트로 취급합니다.」 — Search Console 도움말, 「주소 변경」. 출처 읽기

Google — HTTPS canonical과 리디렉션 신호

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals.” (번역) 「Google은 문제나 상충 신호가 없는 한 동등한 HTTP 페이지보다 HTTPS 페이지를 canonical로 선호합니다.」 — Search Central, 「중복 URL 통합」. 인용문으로 이동
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (번역) 「Googlebot은 리디렉션을 따라가지만 색인 파이프라인은 그 대상을 canonical로 삼아야 한다는 신호로 리디렉션을 사용하지 않습니다.」 (임시 리디렉션에 관한 발언) — Search Central, 「리디렉션과 Google 검색」. 인용문으로 이동

Google — 출시와 인프라 주의 사항

• “Make sure it does not block Googlebot’s ability to reach the DNS or the hosting provider’s servers.” (번역) 「Googlebot이 DNS나 호스팅 제공업체의 서버에 접근하는 것을 막지 않는지 확인하세요.」 (방화벽 / DoS 방어에 관한 발언) — Search Central, 「URL 변경 없는 사이트 이전」. 인용문으로 이동
• “it’s normal to see a temporary drop in Googlebot’s crawl rate immediately after the launch, followed by a steady increase over the next few days.” (번역) 「출시 직후 Googlebot의 크롤링 속도가 일시적으로 감소했다가 이후 며칠 동안 꾸준히 증가하는 것은 정상입니다.」 (서버/호스팅 이전에 관한 발언) — Search Central, 「URL 변경 없는 사이트 이전」. 인용문으로 이동

전체 마이그레이션 체크리스트

유형과 관계없이 모든 마이그레이션에서 실행한 뒤 아래 유형별 목록을 더하세요.

출시 전

• 해당하는 모든 마이그레이션 유형을 분류하고 고위험 유형의 중첩을 피했습니다.
• 일시적 하락이 정상이라고 이해관계자에게 설명하고 트래픽이 적을 때 출시하도록 정했습니다.
• 롤백 계획을 문서화하고 테스트했습니다.
• 기존 사이트 전체 크롤링을 QA 기준으로 저장했습니다.
• 순위, GSC 실적(3/6/12개월), GA4, 주요 백링크 페이지를 내보냈습니다.
• CMS, CDN, 서버 설정, GSC 리디렉션이 포함된 페이지 보고서에서 모든 기존 리디렉션을 모았습니다.
• 일대일 기존→신규 URL 매핑을 만들었습니다. 모든 URL의 처리 대상을 정하며 제거된 페이지는 홈페이지가 아니라 410/404를 반환합니다.
• 리디렉션 계획은 301/308, 단일 홉(체인 없음)을 사용하며 이미지/PDF도 포함합니다.
• 스테이징 색인을 차단하고(noindex 및/또는 robots.txt) 출시 시 제거할 차단으로 기록했습니다.
• 스테이징 크롤링과 기준의 제목, 메타 정보, canonical, hreflang, 구조화 데이터, 메타 robots, 내부 링크, 속도를 비교했습니다.
• 스테이징의 canonical이 스테이징 URL이 아니라 운영 URL을 가리킵니다.
• 모든 기존→신규 리디렉션이 의도한 페이지에 한 홉으로 도달하는지 테스트했습니다.
• 분석/인증 태그가 있고 양식과 전환 경로를 테스트했습니다.
• 방화벽/DoS 방어가 Googlebot을 차단하지 않음을 확인했습니다.

출시 당일

• 스테이징 크롤링 차단(noindex, robots.txt)을 모두 제거하고 운영에서 확인했습니다.
• 모든 301 리디렉션을 활성화했습니다.
• 현재 운영 XML 사이트맵을 새 canonical URL만 포함하도록 업데이트하고 GSC에 다시 제출했습니다.
• 유용한 경우 리디렉션 발견이나 모니터링을 위한 별도의 임시 기존 URL 사이트맵을 제출하고 담당자와 제거 조건을 정했습니다.
• GSC URL 검사로 리디렉션을 표본 점검했습니다.
• 주소 변경 도구를 제출했습니다(도메인 수준 이동에만).
• 이전한 URL을 IndexNow로 Bing에 제출했습니다.
• 출시 후 늘어날 크롤링을 감당할 서버 용량을 확인했습니다.

출시 후

• 기존 URL 목록을 일괄 재크롤링했고 모든 URL이 올바른 운영 페이지로 301을 반환합니다.
• 내부 링크를 새 URL을 직접 가리키도록 업데이트했습니다(기존 URL을 가리키는 오래된 링크 없음).
• GSC의 페이지 색인 생성, 페이지별 실적, 크롤링 통계, 직접 조치를 모니터링합니다.
• 첫 달에는 매주 순위를 기록합니다.
• 주요 외부 링크 제공자에게 링크 변경을 요청했습니다.
• 리디렉션을 도구의 180일만이 아니라 수년간 유지하도록 계획했습니다.
• 트래픽 하락이 지속되면 제거된 hreflang, 잘못된 noindex, 깨진 canonical, 잘못된 리디렉션부터 확인했습니다.

유형별 체크리스트

유형 1 — 도메인 변경 / 리브랜딩

• 새 도메인의 이전 사용 이력을 archive.org에서 확인하고 기존 도메인 갱신을 확보했습니다.
• 경로 범위 없는 적격 기존·신규 GSC 속성의 소유권을 확인했습니다. 도메인 속성이나 루트 URL 접두어 속성이며 경로 범위가 지정된 URL 접두어는 아닙니다.
• 도구가 요구하는 기존 홈페이지 → 새 홈페이지 301을 적용했습니다.
• 사이트 전체의 canonical, 내부 링크, 사이트맵을 새 도메인으로 업데이트했습니다.
• 하위 도메인 및 www/non-www 변형별로 주소 변경을 제출했습니다.
• 거부 파일을 새 속성으로 옮겼으며 디자인 개편/재구성을 동시에 하지 않았습니다.

유형 2 — HTTP → HTTPS

• 유효한 인증서(2048비트 RSA/EC), Qualys A/A+를 갖추고 http→https URL별 301을 적용했습니다(홈페이지로 일괄 이동 아님).
• 혼합 콘텐츠를 검사하고 수정했습니다(상대/프로토콜 상대 URL, upgrade-insecure-requests CSP).
• canonical, 사이트맵, robots.txt, hreflang을 HTTPS로 업데이트하고 쿠키에 Secure 플래그를 설정했습니다.
• TLS가 안정적임을 확인한 후에만 낮은 max-age부터 HSTS를 추가했습니다.
• 주소 변경 도구를 사용하지 않았습니다(대신 사이트 이전 지침 사용).

유형 3 — 플랫폼 / CMS 교체

• 플랫폼을 확정하기 전에 기존→신규 URL 매핑을 만들었습니다.
• CMS + CDN + 서버 설정 + GSC에서 리디렉션 규칙을 모았습니다(.htaccess 규칙을 잃지 않음).
• 후행 슬래시 규칙을 강제하고 구조화 데이터를 다시 만들고 검증했습니다.
• 헤드리스/SPA라면 JavaScript 렌더링을 테스트하고 모바일 렌더링과 페이지 속도를 측정했습니다.
• 새 플랫폼에 GA4/GSC/태그 관리자를 다시 배포했습니다.

유형 4 — URL 구조 / 재구성

• 완전한 기존→신규 매핑을 만들고 URL별 301을 구현했습니다.
• 모든 내부 링크를 업데이트했습니다(탐색 메뉴, 탐색 경로, 푸터, 본문, 관련 글 위젯).
• rel=canonical을 새 URL로 업데이트했고 사이트맵은 새 URL만 나열합니다.
• 주소 변경 도구를 사용하지 않았습니다(같은 도메인 재구성: 리디렉션 + 사이트맵 업데이트만).
• 새 사이트를 크롤링해 리디렉션되는 기존 URL을 가리키는 내부 링크가 없음을 확인했습니다.

유형 5 — 웹사이트 디자인 개편(URL 동일)

• 기존 사이트의 페이지 내 요소(제목, 설명, H1, canonical, 구조화 데이터)를 저장하고 출시 후 비교했습니다.
• 탐색 메뉴 개편 중 고가치 내부 링크를 보존했습니다.
• 변경 전후 Core Web Vitals를 측정했습니다.
• 콘텐츠 변경은 의도적이며 실수로 내용이 줄지 않았고 분석도 계속 작동합니다.

유형 6 — 하위 도메인 ↔ 하위 폴더

• 하위 도메인을 크롤링하고 전체 blog.example.com/post/ → example.com/blog/post/ 매핑을 만들었습니다.
• 모든 하위 도메인 URL에서 대응 하위 폴더 URL로 301을 적용하고 내부 링크가 이를 직접 가리키도록 업데이트했습니다.
• 같은 루트 내 이동에 주소 변경 도구를 사용하지 않았습니다.
• 두 GSC 속성을 모니터링하며(하위 도메인 커버리지 감소, 루트 증가) 분석을 다시 설정했습니다.

유형 7 — 도메인 통합 / 병합

• 병합하는 모든 사이트를 감사했습니다(크롤링, 순위, 백링크, GSC).
• 겹치는 콘텐츠를 중복 제거하고 리디렉션 전에 주제별 canonical 페이지를 골랐습니다.
• URL별로 가장 관련성 높은 페이지로 301을 적용했습니다(홈페이지로 일괄 리디렉션하지 않음).
• 알릴 1:1 이동이 없으므로 주소 변경 도구를 사용하지 않았고 긴 안정화 기간을 계획했습니다.
• 병합하는 각 사이트의 GSC 속성을 유지하고 각 속성과 주 도메인의 커버리지를 모니터링합니다.

사고 모델

1. 위험 = 변경량 × 한 번에 바꾸는 양. 무엇보다 먼저 해당 유형을 분류하세요. 같은 URL에서 디자인만 바꾸면 저위험 변경 하나지만 도메인 이동 + URL 재구성 + 플랫폼 교체는 고위험 유형 세 개가 겹칩니다. 단계로 나눌 수 있다면 한 번에 하나씩 바꾸세요.

2. 리디렉션이 실제 작업을 하고 나머지는 신호를 보냅니다. 순위를 전달하는 장치는 301입니다. 주소 변경 도구, 사이트맵 제출, 내부 링크 업데이트, canonical은 검색엔진이 이동을 더 빠르고 명확하게 처리하도록 돕는 _보조 신호_입니다. 리디렉션을 먼저 만들고 나머지는 대체물이 아니라 촉진 수단으로 다루세요.

3. 1:1 매핑이 모든 것을 홈페이지로 리디렉션하는 것보다 낫습니다. 각 기존 URL은 가장 관련성 높은 새 URL 하나에 대응합니다. 다수의 홈페이지 리디렉션은 soft 404로 취급됩니다. 이점이 없고 보존하려던 페이지 수준 링크 가치를 잃습니다. 대응 페이지가 없다면 홈페이지가 아니라 올바른 410/404를 사용하세요.

4. 도구의 적용 기간은 리디렉션의 수명이 아닙니다. 주소 변경 도구는 180일 동안 신호를 전달합니다. 리디렉션은 그보다 수년 더 오래, 기존 URL에 트래픽이나 링크가 남아 있는 한 유지해야 합니다. 두 시간표 중 더 긴 리디렉션 유지 기간이 이전을 지속시킵니다.

5. 일시적 하락은 정상이고, 지속적인 하락은 버그입니다. 일시적인 변동과 수주에서 두어 달 내 회복을 예상하세요. 트래픽이 돌아오지 않는다면 ‘이동 자체’를 탓하지 말고 흔한 원인을 찾으세요. 운영에 남은 스테이징 차단, 제거된 hreflang, 잘못 들어간 noindex, 깨진 canonical, 엉뚱한 페이지로 가는 리디렉션입니다.

6. canonical 선택에서 내부 링크는 리디렉션만큼 중요합니다. 모든 리디렉션이 완벽해도 탐색 메뉴, 푸터, 본문 및 외부 링크가 기존 URL을 계속 가리키면 Google이 이를 계속 색인할 수 있습니다. 내부 링크를 새 URL로 직접 바꾸고 주요 외부 링크 제공자에게도 변경을 요청하세요.

마이그레이션 요약표

언제 어떤 리디렉션을 쓰나

마이그레이션별 도구 / 신호

Bing의 대응 수단

핵심 사실

• 301은 PageRank를 잃지 않습니다. 약 2016년 이후 해소된 오해입니다.
• 리디렉션 체인: 약 3–5홉 미만으로 유지하세요(Googlebot은 약 10홉을 따라감).
• 180일은 주소 변경 도구의 적용 기간이지 리디렉션 종료 기한이 아닙니다. 리디렉션은 사실상 영구적으로 유지하세요.
• 재색인 소요 시간: 중간 규모 사이트는 ‘몇 주’, 큰 사이트는 더 오래 걸립니다.
• 지속적인 하락의 1순위 원인: 이동 자체가 아니라 새 사이트에서 누락되거나 잘못 들어간 태그(hreflang, noindex, canonical)입니다.

어떤 마이그레이션 유형이며 주소 변경 도구가 적용될까?

가장 큰 변경에 대해 트리를 한 번 실행한 뒤 같은 릴리스에 포함된 추가 변경마다 다시 실행하세요. 플랫폼을 교체하면서 경로와 도메인도 바꾸면 하나가 아니라 세 가지 마이그레이션입니다.

실행 지침: 출시 후 트래픽이 떨어지고 회복되지 않을 때

예상한 출시 변동이 가라앉지 않을 때 사용하세요. 사이트 전체 접근 실패부터 URL 수준 신호 충돌로 좁혀 가세요. 구현에 문제가 없음을 확인하기 전에는 ‘이동 자체’를 탓하지 마세요.

1단계 — 실제로 하락했는지와 범위를 확인하세요. 출시 전에 기록한 동일한 기준 페이지, 검색어, 시장, 분석 정의를 비교하세요. 보고만 사라졌다면 측정을 먼저 고치세요. 기존 URL의 노출도가 줄고 대응하는 새 URL의 노출도가 늘면 정상적인 교차 변화를 계속 관찰하세요. 두 집합 모두 줄었다면 2단계로 가세요.

2단계 — 출시 전반의 크롤링 또는 색인 차단을 확인하세요. 크롤러처럼 운영 페이지를 가져와 robots.txt, 메타 robots, X-Robots-Tag, 인증, 방화벽 응답, DNS, 상태 코드를 검사하세요. 스테이징 noindex, Disallow: /, 인증 장벽, 봇 차단이 함께 배포됐다면 제거하고 즉시 재크롤링하세요. 운영 사이트에 접근할 수 있고 색인 가능하다면 계속 진행하세요.

3단계 — 전체 기존→신규 리디렉션 매핑을 다시 실행하세요. 링크와 트래픽이 가장 많은 페이지부터 기존 URL 전체 목록을 테스트하세요. 404, 무관한 대상, 루프, 체인으로 끝나면 매핑을 고치고 모든 경로를 최종 대응 URL로 직접 연결하세요. 올바른 대상으로 한 홉에 도달하면 계속 진행하세요.

4단계 — 새 페이지를 기준과 비교하세요. canonical, hreflang, 제목, 제목 계층, 본문, 구조화 데이터, 내부 링크, 렌더링된 HTML을 비교하세요. 템플릿 전체에서 태그가 사라지거나 스테이징/기존 URL을 가리키면 개별 페이지보다 템플릿을 먼저 고치세요. 일치 상태가 온전하면 계속 진행하세요.

5단계 — 통합 신호를 확인하세요. 새 URL이 자기 자신을 canonical로 지정하고 내부 링크와 탐색 메뉴가 직접 가리키며 현재 운영 사이트맵에 새 canonical URL만 있는지 확인하세요. 모니터링용 기존 URL 사이트맵을 별도로 제출했다면 계속 유용한지 확인하고 그렇지 않으면 제거하세요. URL 검사에서 Google이 선택한 canonical을 표본 확인하세요. Google이 기존 URL이나 무관한 URL을 계속 선택하면 상충하는 링크, canonical, 사이트맵 항목을 제거하고 재크롤링을 기다리세요.

6단계 — 용량과 서버 근거를 확인하세요. 크롤링 통계와 접근 로그에서 새 호스트의 Googlebot 응답 코드와 활동을 읽으세요. 이전 후 크롤링 급증 중 오류, 지연, 요청 제한, 방화벽 인증 요구가 늘면 용량이나 접근을 복구하세요. 크롤링이 정상이라면 남은 페이지 집단을 마이그레이션 유형과 템플릿별로 상위 담당자에게 전달하세요.

7단계 — 실제 배포된 회귀가 입증됐을 때만 롤백 계획을 사용하세요. 사전에 합의한 조건이 충족되고 크롤링 차이 분석이 하락을 되돌릴 수 있는 템플릿·플랫폼·설정 결함과 연결할 때 롤백하세요. 첫날 변동만으로 롤백하지 마세요. 계획하지 않은 두 번째 이동은 검색엔진이 처리할 마이그레이션을 하나 더 만듭니다.

실제 실패를 만드는 마이그레이션 오해

“영구 리디렉션은 링크 가치를 잃게 한다.” 틀린 이유: Google은 영구 리디렉션이 PageRank를 잃지 않는다고 말합니다. 실제 위험은 301 자체가 아니라 잘못된 대상, 체인, 루프, 막다른 경로입니다. 대신 할 일: 각 기존 URL을 가장 가까운 대응 페이지로 직접 연결하고 최종 응답을 테스트하세요.

“주소 변경 도구가 사이트를 대신 옮겨 준다.” 틀린 이유: 엄격한 도메인 전체 이동에 쓰는 선택적인 보조 신호입니다. 리디렉션을 생성하지 않으며 HTTPS 이동, 경로 재구성, 부분 이동, 도메인 병합을 지원하지 않습니다. 대신 할 일: 리디렉션 매핑을 먼저 만들고 범위가 맞을 때만 도구를 사용하세요.

“트래픽 하락은 모두 마이그레이션 실패를 입증한다.” 틀린 이유: 검색엔진이 이전을 처리하는 동안 순위, 크롤링, 그리고 별도의 기존 URL 사이트맵을 사용한다면 사이트맵 교차 변화에서 일시적인 변동이 예상됩니다. 대신 할 일: 출시 전에 기준과 롤백 조건을 합의하고 평범한 잡음에 반응하기보다 지속적이거나 구조적으로 설명되는 하락을 진단하세요.

“몇 달 뒤 리디렉션을 없애도 된다.” 틀린 이유: Google의 1년 지침은 자체 처리를 위한 최소 기준이지 북마크·백링크·사용자의 만료일이 아닙니다. 대신 할 일: 기존 URL에 트래픽이나 링크가 있는 동안, 대체로 무기한 리디렉션을 유지하고 기존 도메인도 계속 관리하세요.

마이그레이션 매핑과 검증 도구

• 리디렉션 매핑 작성기 — 기존·신규 URL 집합을 붙여 넣어 신뢰도 등급, 미대응 행, 410 목록, 체인 단축, 수동 수정, 플랫폼별 내보내기를 갖춘 301 매핑 제안을 만듭니다. 모든 제안은 출시 전에 편집 관점의 동등성 확인이 필요합니다.
• 리디렉션 체인 매퍼 — 모든 홉을 추적해 상태, 호스트/경로 변경, 메타 새로고침, 정리 규칙을 확인합니다. 슬래시·프로토콜·도메인 규칙이 겹칠 수 있는 스테이징 표본과 출시 후 실패에 사용하세요.
• 리디렉션 검사기 — 단일 URL이나 소규모 묶음의 최종 상태, 홉, 대상을 빠르게 확인합니다. 기존 URL 전체 목록에는 전체 크롤러를 쓰세요. 표본 점검으로 전체 매핑을 입증할 수 없습니다.
• 전체 사이트 크롤러 — 이전 전 기준을 저장하고 전체 리디렉션 목록을 테스트하며 제목, canonical, hreflang, 지시, 링크, schema, 렌더링을 비교합니다.
• Google Search Console — 페이지 색인 생성, 실적, 사이트맵, 크롤링 통계, URL 검사와 적격 도메인 전체 이동에만 주소 변경을 사용하세요.
• 서버 접근 로그 — 검색 봇이 새 호스트에 도달하는지, 어떤 응답을 받는지, 인프라를 종료하기 전에 기존 URL이 여전히 요청되는지를 입증합니다.

매핑대로 마이그레이션이 배포됐는지 입증하기

기존 URL 전체 리디렉션 테스트

• 실행할 테스트: 운영 환경을 대상으로 2단계의 기존 URL 전체 목록을 크롤링하고 Redirect Chain Mapper (리디렉션 체인 매퍼) 또는 Redirect Checker (리디렉션 검사기)로 실패를 검사하세요.
• 예상 결과: 이동한 모든 URL이 서버 측 301 또는 308 한 홉으로 의도한 대응 대상에 도달하며, 의도적으로 제거한 URL은 계획된 404 또는 410을 반환합니다.
• 실패 해석: 기존 URL의 200, 체인, 루프, 무관한 대상, 계획되지 않은 404는 매핑이나 규칙 순서가 승인대로 배포되지 않았다는 뜻입니다.
• 모니터링 기간: 출시 직후, 수정 배포 시, 그리고 기존 URL이 여전히 많이 크롤링되는 초기 모니터링 기간에 반복합니다.
• 롤백 조건: 시스템 차원의 매핑 규칙이 중요한 보호 대상 섹션을 잘못된 곳으로 보내거나 접근 불가능하게 만들고, 운영 중 안전하게 수정할 수 없는 경우입니다.

새 페이지 색인 가능성과 canonical 테스트

• 실행할 테스트: 새 URL 집합의 상태, robots 지시, canonical을 크롤링하고 대표적인 고가치 페이지에 URL 검사를 사용하세요.
• 예상 결과: 새 페이지가 200을 반환하고 차단이나 noindex가 없으며 의도한 새 canonical을 선언합니다. 재크롤링 후 Google이 표본에서 의도한 canonical을 보고합니다.
• 실패 해석: 사이트 전체의 스테이징 지시, 기존/스테이징 canonical, 인증 요구, 다른 Google 선택 canonical은 상충하는 출시 설정을 뜻합니다.
• 모니터링 기간: 기술 신호는 즉시 확인할 수 있지만 Google 선택 canonical과 색인 이동은 재크롤링이 필요하며 중간 규모 사이트에서 수주, 대규모에서는 더 오래 걸릴 수 있습니다.
• 롤백 조건: 운영 전체의 크롤링/색인 차단이나 템플릿 canonical 결함이 보호 집합에 영향을 주고 릴리스를 되돌리지 않고는 신속히 제거할 수 없는 경우입니다.

링크·사이트맵 대상 테스트

• 실행할 테스트: 내부 링크를 크롤링하고 제출한 사이트맵을 파싱해 모든 대상을 승인된 새 canonical URL 집합과 비교하세요.
• 예상 결과: 탐색 메뉴와 내부 링크가 새 URL을 직접 가리키고 현재 운영 사이트맵은 정상 응답하는 새 canonical URL만 나열합니다. 선택적으로 사용하는 기존 URL 사이트맵은 분리되고 일시적이며 제거 조건과 연결되어 있습니다.
• 실패 해석: 오래된 내부 링크, 섞인 이전·신규 사이트맵 목록, 유용한 근거를 주지 못한 뒤에도 유지되는 기존 URL 사이트맵은 이전→신규 교차 변화를 늦추거나 가릴 수 있습니다.
• 모니터링 기간: 렌더링된 사이트와 사이트맵 파일에서 즉시 확인하고 출시 후 모니터링 기간에 제출한 사이트맵이 처리되는지 확인합니다.
• 롤백 조건: 템플릿 전체 탐색 메뉴나 사이트맵 생성기의 회귀가 크롤러를 기존·스테이징·비canonical URL로 돌려보내며 안전하게 긴급 수정할 수 없는 경우입니다.

읽을 가치가 있는 자료

제가 쓴 관련 글

• 웹사이트 마이그레이션 성공에는 체크리스트 이상이 필요합니다 — 흔한 실수 목록과 출시 후 모니터링 체크리스트를 담은 제 전체 마이그레이션 가이드
• SEO 리디렉션 초보자 가이드 — 리디렉션 유형, 체인, 유지 기간
• 1년 후 301 리디렉션을 제거해도 괜찮을까? 직접 테스트했습니다 — ‘리디렉션 장기 유지’의 근거가 된 직접 수행 실험
• canonical 결정 초보자 가이드 — 이전 후 기존 URL과 신규 URL이 경쟁할 때 중요한 Google의 canonical 선택 방식
• 테크니컬 SEO 초보자 가이드 — 더 큰 맥락에서 마이그레이션의 위치

공식 자료

• URL 변경을 수반하는 사이트 이전 — Google의 주요 마이그레이션 실행 지침
• 주소 변경 도구 — Google이 지원하는 이동 범위, 속성 사전 조건, 리디렉션 지침
• Bing과 함께하는 웹사이트 마이그레이션 — Bing의 체계와 리디렉션 유지 기간 지침

다른 작성자의 자료

• r/TechSEO — 마이그레이션 경계 사례와 출시 후 하락을 진단하는 곳
• Google Mueller가 말하는 성공적인 사이트 마이그레이션의 핵심, Search Engine Journal — URL 매핑, 내부 링크, 리디렉션만으로는 충분하지 않은 이유에 관한 Mueller의 안내
• Google: 깔끔한 마이그레이션도 시간이 걸리지만 편법 마이그레이션은 훨씬 오래 걸립니다, Search Engine Roundtable — 사이트 병합과 편법의 비용에 관한 Mueller의 조언
• HTTP에서 HTTPS로 이전할 때 Google은 301 리디렉션을 쓰라고 합니다, Search Engine Land — HTTPS 이전에 일괄 리디렉션보다 URL별 301을 권하는 Mueller의 발언
• Bing과 함께하는 웹사이트 마이그레이션, Bing Webmaster Blog — Bing의 8단계 마이그레이션 체계, 리디렉션 기간(1–2년), 이전 후 로그 모니터링 조언
• 도메인 이동: 함정 피하기, Bing Webmaster Blog — 새 도메인 이력 확인과 리디렉션 대신 canonical을 사용하는 실수 방지에 관한 Bing 안내
• 서버에서 HTTPS 사용, web.dev — HTTP→HTTPS 이전 중 TLS 인증서, 혼합 콘텐츠, HSTS 설정의 기준 문서

Google은 사이트 이전 리디렉션을 가능한 오래, 일반적으로 최소 1년 유지하라고 권장합니다. 이 주장에 대한 근거 Google recommends keeping site-move redirects as long as possible, generally for at least one year. 범위: Google Search's minimum site-move guidance; continuing user traffic or links can justify retaining redirects longer. 신뢰도: 높음 · 검증일: 2026-07-14 Google Search Central: Site move with URL changes 일시적인 순위 변동을 예상해야 하며 중간 규모 사이트의 대부분 페이지가 Google 색인에서 이동하는 데 몇 주가 걸릴 수 있다고 설명합니다. 이 주장에 대한 근거 Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. 범위: Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. 신뢰도: 높음 · 검증일: 2026-07-14 Google Search Central: Site move with URL changes 가능하다면 Google은 주요 변경을 한 번에 하나씩 하도록 권장합니다.

지식 확인: 사이트 마이그레이션

마이그레이션 유형, 리디렉션, 출시 후 진단에 관한 다섯 질문입니다. 각각 답을 고른 뒤 확인하세요.

변경 내역