| name | site-migration-seo |
| description | 도메인 이전·URL 구조 변경·플랫폼 마이그레이션 시 SEO 자산을 안전하게 옮기는 운영 워크플로우. D-30 사전 준비부터 D+90 모니터링·롤백까지 전체 라이프사이클 가이드. |
| disable-model-invocation | true |
사이트 이전 SEO 워크플로우 (site-migration-seo)
소스:
검증일: 2026-06-02
이 스킬은 사이트 이전 전체 라이프사이클(준비 → D-Day → 회복)을 다룬다. 301 redirect 문법·canonical 헤더 등 구체 구현은 [[url-canonicalization-redirects]] 스킬에 위임한다.
1. 이전 유형 4가지
Google이 공식적으로 인정하는 URL 변경 사례는 다음과 같다 (Search Central 분류).
| 유형 | 예시 | GSC Change of Address 필요? | 위험도 |
|---|
| 프로토콜 변경 | http:// → https:// | ❌ (불필요) | 낮음 |
| URL 경로 변경 | /blog/123 → /posts/123 | ❌ (도메인 동일) | 중간 |
| 도메인 변경 | old.com → new.com | ✅ 필수 | 높음 |
| 호스팅·플랫폼 변경 | WordPress → Next.js (URL 유지) | ❌ | 중간 |
핵심 원칙: GSC Change of Address 도구는 도메인 변경에만 적용된다. HTTPS 전환·www↔non-www·경로 변경에는 사용 불가 (Search Console 공식 문서 명시).
여러 변경이 동시에 일어나면 위험도가 곱셈으로 커진다. 예: "도메인 변경 + URL 구조 변경 + 디자인 개편"을 한 번에 하면 트래픽 폭락 진단이 거의 불가능하다. 단계 분리 원칙 (§9 참조).
2. 타임라인 한눈에 (D-30 → D+90)
| 시점 | 작업 |
|---|
| D-30 | 현재 인덱싱 URL 전체 추출, 트래픽 상위 URL 식별, 백링크 인벤토리 작성 |
| D-21 | URL 매핑 표 초안 (old → new 1:1) |
| D-14 | staging 환경에서 신 사이트 검증 (robots.txt·canonical·hreflang) |
| D-7 | 매핑 표 최종 확정, 301 redirect 룰 작성·QA, sitemap 양쪽 준비 |
| D-Day | DNS 또는 redirect 활성화, 신 sitemap GSC 제출, 구 sitemap도 일정 기간 유지 |
| D+1 ~ D+7 | 신 사이트 크롤 오류 모니터링, 누락 redirect 즉시 보완 |
| D+14 | GSC Change of Address 신청 (도메인 변경 시) |
| D+30 | 인덱싱 전환률 점검, 트래픽 회복 곡선 확인 |
| D+90 | 전체 회복 평가, 백링크 갱신 요청, 롤백 여부 판정 |
| D+365 | redirect 유지 종료 검토 (영구 유지 권장) |
3. D-30 ~ D-7: 이전 전 준비
3-1. 현재 사이트 인벤토리
A. 인덱싱 URL 전체 추출
| 소스 | 한계 |
|---|
sitemap.xml | 제출한 URL만, 실제 인덱싱 여부 모름 |
| GSC > 페이지 (Coverage) 보고서 | 실제 Google이 인지한 URL, 1,000건 export 제한 |
| GSC > 성능 보고서 (Search Analytics API) | 트래픽이 있던 URL만 |
| 크롤러(Screaming Frog 등) | 내부 링크 기반, 고아 URL 누락 가능 |
복수 소스를 합집합으로 수집한다. 어느 한 소스도 완전하지 않다.
B. 트래픽 우선순위 식별
- GSC 성능 > 페이지 탭: 클릭·노출 상위 100~500개 URL
- Google Analytics 또는 동등 분석 도구: 랜딩 페이지 기준 상위 트래픽
- 상위 트래픽 URL은 1:1 매핑이 반드시 필요한 항목으로 표시
C. 외부 백링크 인벤토리
- GSC > 링크 보고서 — 무료, Google 인지 기준
- 외부 SEO 도구(Ahrefs / Semrush / Majestic 등) — 더 완전, 유료
도메인 변경 시 고권위 외부 링크는 가능하면 사이트 운영자에게 새 URL로 업데이트 요청을 보낸다 (redirect만으로는 PageRank가 100% 넘어가지만 시간이 걸린다).
3-2. URL 매핑 표
| old URL | new URL | 트래픽 등급 | 매핑 유형 |
|---|
old.com/blog/post-1 | new.com/posts/post-1 | A (상위 10%) | 1:1 직접 |
old.com/blog/post-2 | new.com/posts/post-2 | B | 1:1 직접 |
old.com/old-category/ | new.com/topics/ | C (저트래픽) | 1:1 카테고리 |
old.com/discontinued-x | new.com/topics/ | D (제거 예정) | N:1 (마지막 수단) |
원칙:
- 1:1 직접 매핑이 정공법. 같은 의도·같은 내용의 페이지로 보낸다.
- N:1 group page (예: 100개 상품 페이지를 카테고리 1개로 통합)은 Google이 "soft 404"로 취급할 수 있다. 진짜 동일한 의도일 때만.
- 매핑이 없는 old URL은 410 Gone을 반환하는 것이 404보다 명시적 (Google이 더 빨리 제거).
금지: "여러 오래된 URL을 한 관련 없는 목적지로 redirect하지 말 것" (Search Central 공식 표현).
3-3. staging 환경 검증
- staging은 반드시
robots.txt로 차단 + noindex 메타 또는 HTTP Basic Auth로 봉인
- 운영 전환 시 staging용 차단 설정이 그대로 신 사이트에 잔재되는지 점검 — D-Day 최대 사고 원인
- canonical 태그가 신 URL을 가리키는지 확인
- 다국어 사이트는 hreflang cross-reference가 신 URL 기준으로 일관성 있는지 확인
4. 301 vs 302 — 선택 기준
| 코드 | 의미 | SEO 신호 이전 |
|---|
| 301 Moved Permanently | 영구 이전 | ✅ 100% (Gary Illyes 공식 확인) |
| 308 Permanent Redirect | 영구 이전, 메서드 보존 | ✅ 동일 |
| 302 Found | 임시 이동 | ❌ 원본을 유지한다고 판단, 신호 이전 안 됨 |
| 307 Temporary Redirect | 임시 이동, 메서드 보존 | ❌ 동일 |
사이트 이전에는 반드시 301 또는 308을 사용한다. 302를 영구 이전에 잘못 사용하는 것이 site migration에서 가장 흔한 기술적 실수다 (업계 공통 보고).
주의: 일부 자료는 "Google이 시간이 지나면 302를 301로 인식한다"고 하지만, 인식 시점이 예측 불가능하므로 의존하면 안 된다. 처음부터 올바른 코드를 반환하라.
구체적인 Nginx·.htaccess·Next.js 등 서버별 redirect 문법은 [[url-canonicalization-redirects]] 스킬을 참조한다. 이 스킬에서는 이전 프로세스에 집중한다.
5. redirect chain 회피
John Mueller 공식 권장: redirect chain은 5 hops 미만, 가능하면 1 hop.
- Googlebot은 한 번의 크롤 시도에서 최대 5 hops까지만 따라간다.
- 5 hops를 넘으면 최종 URL에 도달 못 하고 인덱싱 실패.
- chain은 site migration이 반복되며 누적된다 — 매번 원본 URL을 최종 목적지에 직접 매핑해야 한다.
나쁜 예 (chain):
old.com/a → middle.com/a → new.com/posts/a
좋은 예 (직접):
old.com/a → new.com/posts/a
이전 작업 후 이전에 있던 redirect 룰을 갱신해서 모두 최종 URL을 직접 가리키게 정리한다.
6. D-Day 체크리스트
이전 당일 순서 (도메인 변경 기준).
사전 (D-Day 0시간 전)
전환 시점
직후 (D-Day +1~24시간)
D+14: GSC Change of Address (도메인 변경 시)
도메인 변경에 한해 다음 절차를 수행한다.
- 신·구 도메인 모두 GSC에 등록 + 소유권 확인
- 동일한 Google 계정으로 두 속성 관리
- 구 도메인 속성 > 설정 > "주소 변경" 도구 진입
- 신 도메인 선택, 301 redirect·HTTPS 정상 작동 자동 점검
- 신청 후 180일간 신호 이전 + 알림 표시
주의: Change of Address는 도메인 수준 속성에만 적용. URL 접두사 속성(http://example.com/petstore/)에는 불가.
7. D+1 ~ D+90: 모니터링
7-1. 인덱스 전환 추적 (GSC)
| 속성 | 보고서 | 보는 지표 |
|---|
| 구 도메인 | 페이지 (Coverage) | "리다이렉션됨" 또는 "Excluded — Redirect" 증가 추세 |
| 구 도메인 | 색인 생성된 페이지 | 감소 추세 |
| 신 도메인 | 색인 생성된 페이지 | 증가 추세 |
| 신 도메인 | Sitemaps | 제출 URL 대비 인덱싱 비율 |
신·구 양쪽 GSC가 서로 거울처럼 움직여야 한다. 양쪽이 동시에 감소하면 redirect 실패 또는 noindex 잔재 가능성.
7-2. 트래픽 회복 곡선 (정상 범위)
| 시점 | 정상 트래픽 (이전 대비) | 이상 신호 |
|---|
| D+1~7 | 5070% (3050% 일시 하락 정상) | 90% 이상 하락 → 즉시 redirect·robots 진단 |
| D+14~28 | 70~90% 회복 | 50% 이하 정체 → 매핑 누락·5xx 에러 의심 |
| D+30~60 | 85~100% | 80% 이하 정체 → 콘텐츠 변경·중복 issue 의심 |
| D+90 | 100% 또는 초과 | 70% 이하 → 롤백 또는 대대적 진단 필요 |
주의: 회복 곡선은 사이트 규모·이전 유형에 따라 크게 다르다. 한 분석(892건 마이그레이션)은 신 도메인이 구 도메인 트래픽을 회복하는 데 평균 523일이 걸렸다고 보고했다. 작은 사이트는 몇 주, 대형 엔터프라이즈는 수개월. 위 표는 중간 규모 기준이며 일반 보고치다.
7-3. 핵심 진단 포인트
문제 발견 시 우선순위:
curl -I {구 URL} → 301 + 정확한 Location?- 신 URL이 직접 200 OK? (redirect 결과가 또 다른 redirect로 가지 않음)
- GSC URL 검사에서 신 URL이 "색인 생성됨"?
- canonical 태그가 신 URL?
- robots.txt가 신 URL을 차단하지 않음?
- noindex 메타 잔재 없음? (staging에서 가져온 흔적)
8. 다국어 사이트 이전 (hreflang)
다국어 사이트는 hreflang cross-reference가 전체 클러스터로 작동한다. 하나라도 깨지면 클러스터 전체가 무시된다 (Google 공식).
이전 시 주의:
- 신 사이트의 hreflang이 신 URL 기준으로 모두 일관성 있게 cross-reference (return tag 양방향)
- ISO 639-1 언어 코드 + ISO 3166-1 Alpha-2 지역 코드 정확히 사용
x-default hreflang 설정 유지 또는 의도적으로 변경- GSC > Legacy tools > International Targeting 보고서로 에러 모니터링 (현재 GSC 신버전에서는 일부 기능 deprecated 가능, WebSearch로 최신 상태 확인 권장)
다국어 sitemap은 언어별 분리 또는 통합 둘 다 가능. 이전 시 기존 구조를 유지하는 것이 변수를 줄인다.
다국어 SEO 자세한 내용은 별도 i18n-seo 스킬 영역. 이전 시점에는 "기존 hreflang 구조를 변경하지 말고 그대로 옮기는" 원칙.
9. 동시에 하지 말아야 할 것
원칙: 한 번에 하나만 바꾼다.
이전 시 동시에 진행하면 트래픽 폭락 시 원인 진단이 거의 불가능해지는 조합:
| 조합 | 위험 |
|---|
| 도메인 변경 + URL 구조 변경 | 신·구 URL 매핑 복잡도 폭증 |
| URL 구조 변경 + 디자인 전면 개편 | UX 변경·콘텐츠 변경 영향 분리 불가 |
| 플랫폼 변경 + 콘텐츠 재작성 | "기술" 문제인지 "콘텐츠" 문제인지 판단 불가 |
| 도메인 + 플랫폼 + 디자인 동시 | 최악, 트래픽 50%+ 손실 위험 |
권장 단계 분리:
Phase 1: 플랫폼 변경 (URL 유지) → 4~8주 안정화
Phase 2: URL 구조 변경 → 4~8주 안정화
Phase 3: 도메인 변경 → Change of Address
Phase 4: 디자인·콘텐츠 개편 → 분리 모니터링
staggered (부분) migration 경고
John Mueller(2025-12)는 부분 이전도 위험하다고 공식 발언했다.
- 사이트의 일부만 신 도메인으로 옮기면 Google이 "어디가 어디 소속인지" 판단 어려움
- 신·구 도메인이 각각 독립된 사이트로 평가됨 → 도메인 권위 분산
- "messy outcome" — 신호가 깔끔히 이전되지 않음
원칙: 도메인 이전은 전체를 한 번에. 어쩔 수 없이 부분 이전한다면 가능한 한 빨리 나머지도 이전한다.
10. 흔한 실수 모음
| 실수 | 결과 | 예방 |
|---|
| 302를 영구 이전에 사용 | SEO 신호 이전 안 됨 | 301 또는 308 사용 |
| redirect chain 3단 이상 | 인덱싱 실패, 속도 저하 | 항상 최종 URL로 직접 |
| 신 사이트 출시 후 구 사이트 즉시 종료 (404) | 신호 이전 기회 상실 | 최소 1년, 가능하면 영구 redirect 유지 |
| 신 sitemap만 제출, 구 sitemap 즉시 삭제 | Googlebot이 redirect 발견 지연 | 구 sitemap도 일정 기간 유지 |
| canonical을 구 URL로 남겨둠 | 인덱싱 혼란, duplicate 신호 | 신 사이트 canonical = 신 URL |
| staging의 noindex·robots.txt 차단 잔재 | 신 사이트 인덱싱 실패 | D-Day 직후 신 URL을 GSC URL 검사로 진단 |
| GSC 소유권 미확인 후 Change of Address 시도 | 신청 불가 | 신·구 양쪽 사전 등록 + 동일 계정 |
| N:1 매핑 남용 (관련 없는 페이지 통합) | soft 404 또는 신호 손실 | 1:1 직접 매핑 우선, N:1은 마지막 수단 |
| 백링크 정리 누락 | 외부 신호가 redirect를 거쳐 우회 | 고권위 외부 사이트에 갱신 요청 |
| redirect 1년 미만 제거 | 미회복 신호 영구 손실 | 최소 1년, 영구 권장 |
| 동시 변경 폭주 (도메인+URL+디자인) | 진단 불가, 회복 불가 | 단계 분리 |
11. 롤백 시나리오
롤백 고려 기준:
- D+30 기준 트래픽 회복률이 50% 미만
- D+60 기준 70% 미만 + 정체 추세
- 핵심 비즈니스 페이지의 검색 노출이 회복되지 않음
롤백 결정 시 주의:
- 롤백 자체가 또 한 번의 이전이다 — 신호 혼란 가중
- 부분 롤백(일부 URL만 구 위치로)은 staggered migration 문제와 동일
- 가능하면 완전 롤백: 신 → 구 방향 301로 전환 + GSC Change of Address 재신청
- 롤백 전에 진단을 먼저: 회복 실패 원인이 이전 자체인가, 동시에 한 다른 변경인가
권장: 트래픽 폭락 발견 즉시 롤백보다 원인 진단 → 부분 수정이 우선. 대부분의 회복 실패는 redirect 누락·robots 차단·canonical 오류 등 수정 가능한 기술 실수에서 온다.
12. redirect 유지 기간
Google 공식 권장: 최소 1년.
| 기간 | 의미 |
|---|
| ~ 30일 | Googlebot이 redirect를 인지하기 시작하는 초기 |
| ~ 6개월 | 대부분의 인덱스 신호 이전 완료 |
| ~ 1년 (Google 최소 권장) | 외부 백링크가 자연스럽게 갱신될 시간 |
| 영구 | 사용자 북마크·외부 인용 영구 보호 (저비용, 권장) |
영구 유지를 권장하는 이유:
- 1년 이후에도 사용자 북마크·이메일 링크·인쇄물 등에서 구 URL 접근 발생
- redirect 룰 자체의 운영 비용은 거의 0
- 1년 뒤 제거 시 또 한 번 손실 위험
13. 이 스킬을 사용하지 않을 경우
- 내용·디자인만 바꾸고 URL은 그대로 두는 경우 — 이 스킬은 URL 변화가 있는 이전에 한정. 단순 콘텐츠 리뉴얼은 redirect가 필요 없으므로 다른 영역(콘텐츠 SEO).
- staging·dev 환경 간 이동 — 검색 노출이 없는 환경은 SEO 관점 무관.
- 지역 단위 마이크로 변경 (예: 1~5개 URL만 변경) — 정식 마이그레이션 절차보다 단건 301로 처리.
부록 — 코드 예시 (포인터)
자세한 redirect 구현 문법은 [[url-canonicalization-redirects]] 스킬 참조. 여기서는 이전 워크플로우 관점의 최소 예시만.
Nginx (도메인 변경, 경로 보존):
server {
listen 80;
server_name old.com www.old.com;
return 301 https://new.com$request_uri;
}
.htaccess (Apache, URL 구조 변경):
RewriteEngine On
RewriteRule ^blog/(.*)$ https://new.com/posts/$1 [R=301,L]
위 두 예시는 전체 사이트 단위 패턴 redirect다. URL 매핑이 1:1로 다른 경우는 URL별 룰 테이블이 필요하다 — [[url-canonicalization-redirects]] 참조.
