CMS 마이그레이션과 리플랫폼 SEO

TL;DR — CMS 마이그레이션은 게시 플랫폼, 커머스 플랫폼 또는 프런트엔드 아키텍처를 바꾸는 것처럼 웹사이트를 다른 시스템으로 옮기는 작업입니다. 검색엔진과 사용자가 이미 의존하는 URL, 콘텐츠, 제목, 캐노니컬, robots 규칙, 구조화 데이터, 내부 링크, 이미지, 렌더링된 페이지를 보존하세요. URL을 변경해야 한다면 모든 기존 URL을 가장 가까운 대체 URL에 매핑하고 리디렉션하세요. 새 플랫폼을 스테이징에서 테스트하고 현재 사이트와 비교하며, 출시를 예행연습하고 애플리케이션과 데이터를 모두 복원할 수 있는 롤백을 준비하세요.

CMS 마이그레이션이란 무엇인가요?

CMS 마이그레이션은 웹사이트를 생성하고 제공하는 콘텐츠 관리 시스템 또는 플랫폼을 교체하는 작업입니다. WordPress에서 헤드리스 시스템으로, Drupal에서 다른 엔터프라이즈 CMS로, 또는 한 전자상거래 플랫폼에서 다른 플랫폼으로 옮기는 것이 일반적인 예입니다.

겉으로 보이는 디자인은 비슷하게 유지되더라도 기술적 출력은 완전히 달라질 수 있습니다. 새 플랫폼은 서로 다른 URL, HTML, 메타데이터, 탐색, 필터, 페이지네이션, 이미지, 구조화 데이터, 리디렉션, robots 지시문을 생성할 수 있습니다.

모든 CMS 마이그레이션이 URL 마이그레이션인가요?

아닙니다. CMS 마이그레이션에서도 모든 공개 URL을 동일하게 유지할 수 있습니다. 기존 URL 구조가 제대로 작동한다면 대개 이것이 더 안전한 선택입니다.

스킴, 호스트명, 경로, 후행 슬래시 규칙, 파일명 또는 의미 있는 매개변수가 바뀌는 순간 프로젝트는 URL 마이그레이션도 됩니다. 사이트 마이그레이션 가이드의 매핑, 리디렉션, 내부 링크, 캐노니컬, 사이트맵 작업을 추가하세요.

“SEO 동등성”은 무엇을 의미하나요?

SEO 동등성이란 새 플랫폼이 기존 플랫폼의 유용하고 검색에 노출되는 동작을 보존한다는 뜻입니다. 픽셀 단위로 디자인이 같다는 뜻은 아닙니다.

중요한 페이지 유형마다 다음을 비교하세요.

• 색인 가능한 URL과 상태 코드
• 제목, 설명, 헤딩, 주요 콘텐츠
• 캐노니컬, robots 지시문, hreflang
• 구조화 데이터
• 크롤링 가능한 내부 링크와 탐색
• 이미지, 동영상, PDF와 기타 미디어
• 모바일 및 렌더링 출력
• 성능과 서버 안정성

동등성에는 의도적으로 개선한 사항도 포함됩니다. 유용한 변경을 마이그레이션 결함으로 오인하지 않도록 별도로 문서화하세요.

CMS 마이그레이션에서 트래픽이 감소하는 이유는 무엇인가요?

CMS 마이그레이션에서 트래픽이 감소하는 이유는 대개 새 플랫폼이 중요한 동작을 재현하지 못하기 때문입니다. 기존 URL이 404를 반환하거나, 캐노니컬이 스테이징을 가리키거나, 카테고리 링크가 사라지거나, 클릭한 뒤에야 본문이 로드되거나, 제품 변형이 색인 가능한 중복 페이지가 되거나, 오래된 리디렉션이 이전되지 않는 경우가 흔합니다.

플랫폼 이름 자체가 원인인 경우는 드뭅니다. 플랫폼이 생성한 사이트가 원인입니다.

기본 절차는 무엇인가요?

1. 현재 사이트의 URL, 템플릿, 콘텐츠, 신호, 링크, 자산, 리디렉션, 통합을 목록화합니다.
2. URL을 그대로 유지할지 결정합니다.
3. 모든 템플릿과 시스템 동작에 대해 측정 가능한 동등성 요구사항을 작성합니다.
4. 콘텐츠 필드를 매핑하고 데이터를 새 CMS로 마이그레이션합니다.
5. 스테이징을 크롤링하고 렌더링한 뒤 저장한 기준선과 비교합니다.
6. URL이 바뀐다면 리디렉션을 테스트합니다.
7. 콘텐츠 동결, 최종 데이터 동기화, 배포, 캐시 삭제, 롤백을 예행연습합니다.
8. 출시 직후 운영 환경을 검증하고 템플릿 및 URL 코호트별로 모니터링합니다.

웹사이트 마이그레이션 체크리스트는 단계별 공통 프로젝트 순서를 제공합니다. 이 가이드는 각 단계에서 새 CMS가 무엇을 바꿀 수 있는지에 초점을 맞춥니다.

마이그레이션 중 기존 SEO 문제를 모두 고쳐야 하나요?

새 플랫폼이 그대로 재현할 가능성이 있는 확실한 결함은 수정하되, 모든 재설계, 콘텐츠 재작성, 아키텍처 변경, URL 정리를 한 번의 릴리스에 합치지는 마세요. Google은 사이트 이전 안내에서 가능하면 주요 변경을 한 번에 하나씩 진행하라고 권고합니다.

반드시 고칠 결함과 선택적 개선을 구분하세요. 출시 후 무슨 일이 일어났는지 진단하려면 안정적인 기준선이 필요합니다.

TL;DR — 리플랫폼은 두 페이지 생성 시스템 사이의 계약을 마이그레이션하는 작업입니다. 현재의 모든 URL 출처, 템플릿, 콘텐츠 필드, 내부 링크 규칙, 색인 제어, 캐노니컬, hreflang 주석, 스키마 객체, 미디어 URL, 패싯, 리디렉션, 통합을 목록화하세요. 플랫폼 구성이 굳기 전에 URL 유지와 URL 변경 범위를 결정하세요. 목록을 일반 체크리스트가 아니라 동등성 테스트로 전환해야 합니다. 데이터를 옮기고 스테이징에서 원시 HTML과 렌더링된 DOM을 크롤링하여 템플릿 및 보호 대상 URL 코호트별로 차이를 비교하세요. 전환과 데이터 롤백을 예행연습한 뒤, 한 템플릿의 고장이 사이트 전체 수치에 가려지지 않도록 코호트를 따로 모니터링하세요.

계획을 선택하기 전에 리플랫폼 유형을 분류하세요

CMS 마이그레이션에는 여러 변경이 포함될 수 있습니다.

각 계층을 범위에 명시하세요. URL 구조, 호스팅, 렌더링, 탐색까지 바꾸는 “CMS 마이그레이션”은 한 번의 출시를 공유하는 네 가지 마이그레이션입니다.

URL 유지 여부를 일찍 결정하세요

기존 URL이 유용하고 새 플랫폼이 이를 지원할 수 있다면 URL 보존이 대체로 기본값입니다. 리디렉션, 재크롤링, 통합 업데이트, 딥 링크 손실, 운영 복잡성의 비용을 측정하지 않은 채 “플랫폼에서 지원하지 않는다”는 말을 받아들이지 마세요.

현재 구조가 불안정하거나, 낡은 기술을 노출하거나, 중복을 만들거나, 새 정보 아키텍처를 표현할 수 없다면 URL 변경이 정당할 수 있습니다. 테마, 경로, 가져오기, 피드가 새 패턴에 맞춰 구축되기 전에 결정해야 합니다.

URL을 변경한다면 전체 URL 구조 마이그레이션 작업이 필요합니다. 마스터 인벤토리, 명시적 처리 결과, 일대일 또는 근거 있는 다대일 매핑, 영구 리디렉션, 직접 내부 링크, 업데이트된 주석, 새 사이트맵, 모니터링이 포함됩니다.

여러 시스템에서 현재 상태 인벤토리를 구축하세요

현재 CMS 데이터베이스만으로는 웹사이트 인벤토리가 되지 않습니다. 다음을 결합하세요.

• 한 번 이상의 크롤링에서 찾은 크롤링 가능한 URL
• XML 사이트맵과 피드 내보내기
• 애널리틱스 방문 페이지와 Search Console 페이지
• 크롤러가 여전히 요청하는 고립되거나 오래된 URL을 포함한 서버 로그
• 백링크와 캠페인 방문 페이지
• 미디어 라이브러리, PDF, 이미지, 동영상, 다운로드 자산
• 내부 검색, 패싯 탐색, 페이지네이션, 정렬 패턴
• CMS, 서버, CDN, 애플리케이션 코드의 리디렉션 규칙
• API, 앱, 이메일, 유료 광고, 제휴, 현지화, 피드 소비자

모든 URL에 콘텐츠 엔터티, 템플릿, 색인 가능 상태, 캐노니컬 대상, 트래픽/링크 중요도, 예정된 목적지를 지정하세요. 이 인벤토리는 가져오기 후 대조 장부가 됩니다.

페이지 문구만이 아니라 콘텐츠 모델을 목록화하세요

콘텐츠 모델 매핑은 필드와 관계가 어떻게 이동하는지 설명합니다. 다음을 포함하세요.

• 제목, 요약, 본문 블록, 작성자, 날짜, 업데이트 날짜
• 분류 체계, 상위 항목, 컬렉션, 카테고리, 태그
• 슬러그, 로케일 변형, 캐노니컬 재정의, robots 제어
• 이미지 소스, 대체 텍스트, 캡션, 크기, 크롭, 초점
• 관련 콘텐츠, 브레드크럼, 기본 탐색, 문맥 링크
• 제품 식별자, 가격, 재고, 리뷰, 변형, 오퍼
• 구조화 데이터 속성과 엔터티 관계
• 리디렉션, 별칭, 미게시 상태, 예약, 권한

필드가 존재하는지만 확인해서는 부족합니다. 변환 규칙, null 처리, 인코딩, Markdown 또는 리치 텍스트 변환, 삽입 컴포넌트, 참조를 테스트하세요. 옮겨졌지만 비어 있게 렌더링되는 필드도 손실된 콘텐츠입니다.

동등성을 승인 기준으로 전환하세요

동등성 요구사항은 템플릿별로 작성해야 합니다. 제품 페이지와 글은 콘텐츠, 스키마, 페이지네이션, 내부 링크 계약이 같지 않습니다.

각 템플릿에 다음을 정의하세요.

• 예상 상태와 색인 가능성
• 캐노니컬 생성 규칙
• robots 메타와 X-Robots-Tag 동작
• 제목, 설명, H1, 주요 콘텐츠의 원본 필드
• 필수 구조화 데이터 유형과 화면 속성 간의 정합성
• 브레드크럼, 탐색, 관련 링크, 페이지네이션 규칙
• hreflang과 로케일 동작
• 자산 동작과 이미지 메타데이터
• 원시 HTML 및 렌더링된 DOM 요구사항
• 성능과 가용성 게이트
• 애널리틱스와 동의 동작

보존, 제거, 개선 결정을 구분하세요. 그래야 QA 팀이 알려진 결함을 되살리거나 우발적 손실을 개선으로 받아들이는 일을 막을 수 있습니다.

원시 HTML과 렌더링 결과를 테스트하세요

렌더링 전략은 개발 구현 세부사항이 아니라 리플랫폼 결정입니다. Google의 JavaScript SEO 문서는 JavaScript 페이지를 크롤링하고 렌더링한 뒤 색인한다고 설명합니다. 또한 서버 측 렌더링이나 사전 렌더링은 사용자와 크롤러에게 도움이 되고 모든 봇이 JavaScript를 실행하는 것은 아니므로 여전히 좋은 방법이라고 말합니다.

보호 대상 템플릿마다 원시 HTML과 렌더링된 DOM을 비교하세요.

• 사용자 상호작용 없이도 주요 콘텐츠가 존재하나요?
• 링크가 확인 가능한 목적지를 가진 실제 <a href> 요소인가요?
• 상태 코드가 오류 상태와 일치하나요, 아니면 모든 경로가 소프트 404 셸을 반환하나요?
• 캐노니컬과 robots 지시문이 존재하고 일관적인가요?
• 필요한 JavaScript, CSS, API, 자산을 크롤링할 수 있나요?
• 하이드레이션 또는 API 실패로 콘텐츠가 사라지나요?
• 모바일 렌더링에 동등한 주요 콘텐츠와 메타데이터가 있나요?

Google은 noindex를 발견하면 렌더링을 건너뛸 수 있다고 경고하므로, JavaScript로 초기 noindex를 제거하는 방식은 실패할 수 있습니다. 의도한 색인 가능성을 최초 응답에 넣으세요.

캐노니컬과 색인 제어 로직을 보존하세요

캐노니컬 규칙은 세심한 템플릿 로직에서 “모든 페이지를 자기 참조 캐노니컬로” 처리하는 방식으로 퇴행하기 쉽습니다. 그러면 필터, 추적 매개변수, 페이지네이션, 인쇄 보기, 변형이 만든 중복이 노출될 수 있습니다.

각 규칙을 입력과 예상 출력으로 문서화하세요. 다음을 테스트하세요.

• 절대 URL 캐노니컬의 호스트, 스킴, 경로, 슬래시, 인코딩
• 의도한 색인 가능 페이지의 자기 참조 캐노니컬
• 중복 변형의 캐노니컬 대상
• robots 메타와 X-Robots-Tag 상호작용
• 200이 아닌 응답에서의 캐노니컬 동작
• 의도한 캐노니컬 URL만 사이트맵에 포함되는지
• 데스크톱, 모바일, 렌더링 출력 전반의 일관성

대표 페이지에서 캐노니컬 검사기를 사용한 뒤 크롤러로 템플릿을 일괄 검증하세요.

새 소스 모델에서 구조화 데이터를 다시 구축하세요

새 템플릿과 필드가 달라지므로 구조화 데이터가 자동으로 이전되는 경우는 드뭅니다. 각 속성을 새 소스에 매핑한 다음 마크업이 화면에 보이는 페이지 콘텐츠를 설명하는지 확인하세요.

Google은 템플릿 또는 제공 문제로 구조화 데이터가 깨질 수 있으므로 개발 중 Rich Results Test로 테스트하고 배포 후 리치 결과 보고서를 모니터링하라고 권고합니다. Google의 구조화 데이터 소개를 참고하세요.

구문과 자격 요건을 모두 검증하세요. 검사기를 통과해도 리치 결과가 보장되지는 않으며, 구문상 유효한 객체가 잘못된 제품, 글, 브레드크럼, 작성자, 가격 또는 재고를 설명할 수도 있습니다.

링크 수가 아니라 내부 링크 기능을 보존하세요

내부 링크 동등성이란 중요한 페이지가 동등하거나 더 나은 크롤링 경로를 통해 계속 발견된다는 뜻입니다. 다음을 비교하세요.

• 기본 및 유틸리티 탐색
• 브레드크럼과 카테고리 계보
• 관련 제품, 관련 글, 문맥 링크
• 페이지네이션과 더 보기 대체 수단
• 푸터, 로케일, 시장 선택기
• 마이그레이션된 본문 콘텐츠의 링크
• 고립 페이지 수, 클릭 깊이, 인링크 분포

새 디자인은 전체 링크 수를 유지하면서도 실제로 깊은 페이지를 지원하던 링크를 제거할 수 있습니다. 목적지와 템플릿별로 변경을 분석하세요.

패싯, 매개변수, 내부 검색을 제품 요구사항으로 다루세요

플랫폼은 흔히 새로운 필터 및 정렬 동작을 강제합니다. 어떤 조합을 크롤링 가능, 색인 가능, 캐노니컬 대상, 링크 대상 또는 차단 대상으로 할지 문서화하세요. 매개변수 순서, 빈 결과, 다중 선택, 페이지네이션, 모바일 동작을 테스트하세요.

새 플랫폼이 다른 경로를 생성한다면 기존 플랫폼의 포괄적인 robots 규칙을 그대로 복사하지 마세요. robots 제외는 크롤링을 줄일 수 있지만, 그 자체로 신호를 통합하거나 이미 색인된 URL을 제거할 수는 없습니다.

패싯 탐색 감사 도구로 매개변수 패턴을 탐색한 다음 사이트가 선택한 크롤링 및 색인 제어를 검증하세요.

미디어를 독립적인 URL로 마이그레이션하세요

미디어 마이그레이션은 파일 복사만으로 끝나지 않습니다. 다음을 보존하거나 명시적으로 매핑하세요.

• 이미지, 동영상, PDF, 다운로드 URL
• 대체 텍스트, 캡션, 제목, 주변 문맥
• 이미지 크기, 형식, 반응형 변형, 안정적인 소스 URL
• 동영상 플레이어, 썸네일, 대본, 구조화 데이터
• PDF 상태, 캐노니컬 헤더, 링크, 접근 제어
• CDN 경로, 서명 URL, 핫링크 규칙, 캐시 동작

Google의 최신 모바일 우선 안내는 모바일과 데스크톱에서 중요한 콘텐츠, 메타데이터, 구조화 데이터, 크롤링 가능한 리소스를 동등하게 유지하라고 권고합니다. 이미지 URL을 바꾸면 새 URL이 처리되는 동안 이미지 검색 트래픽이 일시적으로 감소할 수 있다고도 경고합니다. 모바일 우선 색인 권장사항을 참고하세요.

리디렉션과 오류 동작을 이전하세요

기존 리디렉션은 CMS, .htaccess, nginx, 애플리케이션 미들웨어, 로드 밸런서, CDN 규칙에 흩어져 있을 수 있습니다. 출시 전에 내보내고 체인을 평탄화하세요. 새 플랫폼은 빈 리디렉션 테이블로 시작해 수년간 쌓인 URL 이력을 조용히 버리는 경우가 많습니다.

실제로 없는 콘텐츠도 테스트하세요. 플랫폼은 “찾을 수 없음” 문구가 있는 200 템플릿이 아니라 진짜 404 또는 410을 반환해야 합니다. HTTP 결과를 숨기지 않으면서 맞춤 오류 경험을 유지하세요.

URL이 바뀐다면 매핑된 모든 기존 URL을 테스트하세요. 검토 장부에는 리디렉션 맵 빌더를, 배포 검증에는 대량 HTTP 상태 코드 검사기를 사용하세요.

스테이징을 비공개로 유지하면서 테스트 가능하게 만드세요

스테이징 접근은 보호와 승인된 크롤링 사이의 균형을 맞춰야 합니다. 인증, VPN 또는 네트워크 제어를 우선하고 QA 시스템에 명시적으로 접근 권한을 부여하세요. 임시 robots 또는 noindex 제어가 있다면 출시 제거 장부에 기록하고 운영 환경에 남아 있지 않음을 입증하세요.

탐색만이 아니라 전체 목적지 인벤토리에서 스테이징 크롤링을 구축하세요. 템플릿과 중요도 코호트별로 기준선과 비교하세요. 스테이징 대 운영 SEO 차이 도구는 짝지은 표본 비교에 유용하며, 전체 크롤링은 시스템 전반의 범위를 확인합니다.

출시 전에 마이그레이션을 대조하세요

대조 작업은 다음 네 가지 질문에 답해야 합니다.

1. 의도한 모든 콘텐츠 엔터티를 가져왔나요?
2. 모든 엔터티가 예상한 공개 URL 또는 의도한 URL 없음 상태를 생성했나요?
3. 예상한 모든 목적지가 해당 템플릿 계약을 통과했나요?
4. 모든 기존 URL에 승인된 처리 결과가 지정됐나요?

콘텐츠 유형, 로케일, 상태, 색인 가능성, 템플릿별 개수를 사용하세요. 사이트 전체 합계는 일치해도 특정 언어, 카테고리, 작성자 아카이브 또는 미디어 유형 전체가 빠질 수 있습니다.

전환과 롤백을 예행연습하세요

예행연습에는 운영 환경과 비슷한 데이터 규모와 실제 순서가 포함되어야 합니다.

• 콘텐츠 동결 또는 델타 동기화 시작
• 최종 데이터베이스 및 미디어 가져오기
• 리디렉션과 엣지 규칙 배포
• 애플리케이션, 캐시, 큐, 검색 색인, 피드 활성화
• 인프라가 바뀐다면 DNS 또는 로드 밸런서 전환
• 운영 환경 스모크 테스트와 크롤링
• 코드, 구성, 데이터베이스 스키마, 쓰기 작업 롤백

데이터베이스 롤백이 가장 어렵습니다. 사용자가 새 스키마에서 주문, 계정, 댓글 또는 콘텐츠를 만든 뒤 애플리케이션 코드만 되돌리면 데이터가 손실되거나 손상될 수 있습니다. 기술적 롤백과 함께 롤포워드 수정 및 대조 방법을 정의하세요.

의존성 순서대로 운영 환경을 검증하세요

운영 검증은 시스템 장애에서 페이지 세부사항 순서로 진행해야 합니다.

1. DNS, TLS, 상태, 호스트 가용성
2. Robots.txt, 인증, WAF, 전역 robots 지시문
3. 홈페이지와 보호 대상 템플릿별 페이지 하나
4. 캐노니컬, hreflang, 스키마, 링크, 자산, 렌더링
5. 전체 리디렉션 및 목적지 인벤토리
6. 애널리틱스, 동의, 양식, 결제, 피드, API, 검색
7. 크롤링, 색인, 트래픽, 전환 코호트

개별 URL보다 템플릿 결함을 먼저 수정하세요. 잘못된 캐노니컬 파셜 하나가 수백만 페이지에 영향을 줄 수 있습니다.

출시 후 코호트별로 모니터링하세요

코호트 모니터링은 변경 내용에 따라 URL을 그룹화합니다. URL 유지 페이지, 리디렉션 페이지, 제품, 카테고리, 글, 로케일, 렌더링 템플릿, 미디어, 패싯, 링크가 많은 페이지가 유용한 코호트입니다.

성공 응답, 리디렉션 실패, 캐노니컬 불일치, 색인 가능성, 렌더링 완전성, 내부 링크, 사이트맵 상태, Google 선택 캐노니컬, 클릭, 노출, 전환, 크롤러 활동을 추적하세요. 동등한 기간을 비교하고 관련 없는 캠페인, 계절성, 알고리즘 변경, 측정 업데이트를 주석으로 남기세요.

전체 트래픽 선 하나로는 한 새 템플릿이 실패하고 다른 템플릿이 성장했는지 알 수 없습니다.

AI 요약

• CMS 마이그레이션은 페이지를 생성하는 시스템을 바꾸며 URL, 렌더링, 디자인, 아키텍처, 호스팅, 통합도 바꿀 수 있습니다.
• 플랫폼의 라우팅과 가져오기 기능을 구축하기 전에 URL 유지 또는 변경 범위를 결정하세요.
• 크롤링, 사이트맵, 로그, 애널리틱스, Search Console, 백링크, 미디어, 리디렉션, 하위 소비자를 결합해 인벤토리를 만드세요.
• 본문뿐 아니라 콘텐츠 필드, 관계, 분류 체계, 메타데이터, 미디어, 스키마, 워크플로 상태를 매핑하세요.
• 상태, 색인 가능성, 캐노니컬, robots, 콘텐츠, 링크, 스키마, hreflang, 자산, 렌더링, 성능에 대해 템플릿별 테스트 가능한 계약을 정의하세요.
• 원시 HTML과 렌더링 결과를 비교하세요. 주요 콘텐츠와 크롤링 가능한 링크가 사용자 상호작용에 의존해서는 안 됩니다.
• 패싯, 페이지네이션, 내부 검색, 기존 리디렉션, 실제 404 동작을 플랫폼 요구사항으로 다루세요.
• 출시 전에 가져온 엔터티, 생성된 목적지, 템플릿 테스트, 모든 기존 URL의 처리 결과를 대조하세요.
• 최종 동기화, 배포, 검증, 데이터를 고려한 롤백을 예행연습하세요.
• 출시 후에는 사이트 전체 트래픽뿐 아니라 템플릿 및 변경 코호트별로 모니터링하세요.

공식 문서

Google

• URL 변경을 수반한 사이트 이전은 URL 매핑, 리디렉션, 주석, 링크, 사이트맵, 모니터링을 다룹니다.
• 호스팅 변경은 인프라는 바뀌지만 공개 URL은 바뀌지 않을 때 적용됩니다.
• JavaScript SEO 기본사항은 크롤링, 렌더링, 색인, 캐노니컬, robots 동작을 설명합니다.
• 모바일 우선 색인 권장사항은 콘텐츠, 메타데이터, 스키마, 미디어, 리소스 동등성을 다룹니다.
• 구조화 데이터 소개는 개발 및 출시 후 검증을 권고합니다.
• 구조화 데이터 일반 가이드라인은 기술 및 품질 요구사항을 설명합니다.

Bing

• Bing을 사용한 웹사이트 마이그레이션은 CMS 마이그레이션, 감사, 리디렉션, 로그, 모니터링을 다룹니다. Site Move Tool에 관한 내용은 오래됐으므로 현재의 Bing Webmaster Tools와 IndexNow를 사용하세요.
• IndexNow는 추가, 업데이트 또는 삭제된 URL을 Bing과 참여 검색엔진에 알립니다.

출처의 인용문

• “Plan your changes to your site one after the other, not everything at the same time.” (번역) “사이트 변경은 한꺼번에 모두 하지 말고 하나씩 차례로 계획하세요.” Google Search Central. 안내로 이동
• 의역: URL이 바뀌는 경우 Google의 사이트 이전 문서는 각 목적지 URL이 자기 자신을 캐노니컬로 지정해야 한다고 설명합니다. 캐노니컬 안내
• “When Google encounters the noindex tag, it may skip rendering and JavaScript execution” (번역) “Google이 noindex 태그를 발견하면 렌더링과 JavaScript 실행을 건너뛸 수 있습니다.” Google Search Central. noindex 안내로 이동
• 의역: Google은 서버 측 렌더링 또는 사전 렌더링이 사용자와 크롤러에게 성능 친화적인 제공 방식이라고 여전히 권고합니다. 렌더링 안내
• “Be sure to check your structured data using the Rich Results Test during development”. (번역) “개발 중에는 Rich Results Test를 사용해 구조화 데이터를 반드시 확인하세요.” Google Search Central. 검증 안내로 이동

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

범위와 결정

• CMS, 데이터, 템플릿, 렌더링, 아키텍처, URL, 인프라, 애널리틱스, 통합 등 모든 변경 계층을 나열했습니다.
• 경로 구현 전에 URL 유지 또는 URL 변경 범위를 승인했습니다.
• 보존, 제거, 개선 결정을 구분했습니다.
• 템플릿별 담당자와 통과/실패 게이트를 지정했습니다.

인벤토리와 마이그레이션

• 크롤링, 사이트맵, 로그, 애널리틱스, Search Console, 백링크, 피드를 결합했습니다.
• 미디어, 패싯, 페이지네이션, 내부 검색, 리디렉션, API, 앱을 목록화했습니다.
• 모든 콘텐츠 필드, 관계, 분류 체계, 로케일, 워크플로 상태를 매핑했습니다.
• 콘텐츠 유형, 로케일, 템플릿, 상태별 엔터티 수와 URL을 대조했습니다.

스테이징 QA

• 공개 발견을 막으면서 승인된 크롤러가 스테이징에 접근할 수 있습니다.
• 모든 보호 대상 템플릿에서 원시 HTML과 렌더링된 DOM을 테스트했습니다.
• 상태, 제목, 헤딩, 콘텐츠, 캐노니컬, robots, hreflang, 스키마의 차이를 비교했습니다.
• 탐색, 브레드크럼, 관련 링크, 페이지네이션, 본문 링크를 비교했습니다.
• 패싯, 매개변수, 검색, 빈 결과, 변형, 실제 오류를 테스트했습니다.
• 미디어 URL, 메타데이터, 형식, 삽입 요소, 구조화 데이터를 테스트했습니다.
• 기존 리디렉션을 가져오고 평탄화한 뒤 테스트했습니다.
• 애널리틱스, 동의, 양식, 결제, 피드, API, 검색을 테스트했습니다.

출시와 모니터링

• 최종 콘텐츠/데이터 동기화와 동결 순서를 예행연습했습니다.
• 애플리케이션 및 데이터베이스 롤백 또는 롤포워드 계획을 예행연습했습니다.
• 임시 스테이징 제어를 제거 장부에 포함했습니다.
• 시스템, 템플릿, URL 순서로 운영 환경을 검증했습니다.
• 사이트맵에는 의도한 성공 상태의 캐노니컬 URL만 있습니다.
• 템플릿, 로케일, 중요도, 변경 코호트별로 모니터링합니다.

리플랫폼 계약

서로 연결된 네 가지 장부를 사용하세요.

1. 엔터티 장부: 마이그레이션해야 하는 모든 콘텐츠 레코드와 관계
2. URL 장부: 모든 기존 URL과 유지, 이동, 통합, 폐기 또는 제외 결과
3. 템플릿 계약: 생성된 모든 페이지 동작과 통과/실패 테스트
4. 의존성 장부: 플랫폼이 지원하는 모든 피드, 통합, 자산, 검증, 리디렉션, 작업, 비즈니스 프로세스

장부가 서로 일치해야 마이그레이션 대조가 끝납니다. 예상 URL이 없는 콘텐츠 엔터티나, 소유 엔터티 또는 의도된 시스템 동작이 없는 공개 URL은 검토가 필요합니다.

동등성 매트릭스

CMS 마이그레이션에 URL 이전 작업이 필요한가요?

손실을 일으키는 리플랫폼 실수

플랫폼을 구축한 뒤 URL을 선택함. 실패 이유: 라우팅, 가져오기, 템플릿, 피드, 리디렉션이 우발적인 기본값에 맞춰 굳습니다. 대신: 구현 전에 보존 또는 변경 결정을 내리세요.

시각적 일치를 SEO 동등성이라고 부름. 실패 이유: 디자인이 같아도 상태, 원시 HTML, 캐노니컬, robots, 링크, 스키마, 모바일 콘텐츠, 오류가 다를 수 있습니다. 대신: 원시 응답과 렌더링된 응답에서 템플릿 계약을 테스트하세요.

사이트맵만 마이그레이션함. 실패 이유: 사이트맵에는 여전히 트래픽이나 링크를 받는 고립 URL, 리디렉션 URL, 기존 URL, 매개변수 URL, 자산 URL이 빠집니다. 대신: 크롤링, 로그, 애널리틱스, Search Console, 백링크, 피드를 결합하세요.

출시 때 모든 개선을 함께 적용함. 실패 이유: 콘텐츠, 아키텍처, 렌더링, URL, 디자인을 동시에 바꾸면 회귀 진단이 어려워집니다. 대신: 필수 결함과 후속 개선을 분리하고 가능한 경우 변경을 단계화하세요.

롤백을 코드 배포로만 취급함. 실패 이유: 새 스키마의 쓰기, 주문, 업로드, 콘텐츠 편집은 애플리케이션 롤백에서 살아남지 못할 수 있습니다. 대신: 데이터 대조와 롤포워드 수정도 계획하세요.

흔한 리플랫폼 실패

목적지 수가 소스 인벤토리보다 적음

가능한 원인: 가져오기 실패, 제외된 상태, 로케일 누락, 지원되지 않는 콘텐츠 유형 또는 엔터티 중복 제거. 수정: 하나의 합계만 비교하지 말고 콘텐츠 유형, 로케일, 워크플로 상태, 템플릿별로 대조하세요.

페이지가 200을 반환하지만 크롤링에서 콘텐츠가 사라짐

가능한 원인: 클라이언트 렌더링, 차단된 리소스, API 실패, 상호작용 후에만 로드되는 콘텐츠 또는 하이드레이션 오류. 수정: 대표 페이지에서 원시 및 렌더링 HTML, 콘솔/네트워크 오류, URL Inspection의 렌더링 보기를 비교하세요.

Google이 예상하지 않은 캐노니컬을 선택함

가능한 원인: 복사된 캐노니컬 규칙, 기존/스테이징 대상, 중복 경로, 내부 링크 충돌, 사이트맵 충돌 또는 크게 바뀐 콘텐츠. 수정: 템플릿 캐노니컬, 직접 링크, 리디렉션, 사이트맵을 의도한 URL에 맞춘 뒤 재크롤링될 시간을 주세요.

카테고리 또는 제품 페이지가 크롤 함정이 됨

가능한 원인: 새 패싯 경로, 매개변수 순서, 무한 조합, 달력 경로 또는 크롤링 가능한 내부 검색. 수정: 허용할 조합을 정의하고 유용한 페이지만 링크하며, 정직한 빈 상태를 반환하고 제품 요구사항에 따라 캐노니컬 또는 색인 제어를 적용하세요.

기존 링크가 404를 반환하기 시작함

가능한 원인: 리디렉션이 기존 CMS 외부에 있었거나 새 규칙 엔진의 순서가 바뀌었습니다. 수정: 기존의 모든 계층에서 규칙을 모으고 체인을 평탄화한 뒤 전체 과거 URL 인벤토리를 테스트하세요.

구조화 데이터는 통과하지만 잘못된 엔터티를 설명함

가능한 원인: 필드 매핑 오류 또는 템플릿이 상위 데이터, 자리표시자 값, 오래된 캐시를 렌더링합니다. 수정: 마크업을 화면 콘텐츠 및 소스 레코드와 비교하세요. 구문 검증만으로 의미 정확성을 입증할 수는 없습니다.

CMS 마이그레이션 QA 도구

• SEO 마이그레이션 계획 및 검증 도구는 맵 검토, 리디렉션 검증, 기존 URL 상태, 사이트맵 비교를 결합합니다.
• 리디렉션 맵 빌더는 경로가 바뀔 때 정확, 불확실, 통합, 미일치, 폐기 URL 결과를 검토하는 데 유용합니다.
• 스테이징 대 운영 SEO 차이 도구는 상태, 리디렉션, 캐노니컬, 지시문, 선택 헤더, 스키마, 콘텐츠를 비교합니다.
• 캐노니컬 검사기는 대표 페이지에서 관찰 가능한 캐노니컬 신호를 진단합니다.
• 스키마 검사기는 구조화 데이터 구문과 추출된 엔터티를 검사합니다. Google 기능 자격 확인에는 Google의 Rich Results Test를 사용하세요.
• 패싯 탐색 감사 도구는 새 필터가 일으킨 크롤링 및 매개변수 위험을 탐색합니다.
• 링크 분석기는 대표 템플릿의 렌더링된 내부 링크를 검사합니다.
• 대량 HTTP 상태 코드 검사기는 배포 후 목적지 및 과거 URL 코호트를 검증합니다.

CMS 마이그레이션이 올바르게 배포됐음을 입증하세요

엔터티-URL 대조 테스트

• 실행할 테스트: 안정적인 콘텐츠 ID를 기준으로 소스 엔터티 내보내기, 목적지 엔터티 내보내기, 예상 URL 장부, 목적지 크롤링을 조인합니다.
• 예상 결과: 범위 내 모든 엔터티에 승인된 상태와 URL이 있고, 모든 공개 목적지에 소유 엔터티 또는 문서화된 시스템 목적이 있습니다.
• 실패 해석: 가져오기 누락, 중복, 경로 충돌 또는 제외 상태 때문에 콘텐츠가 누락되거나 의도하지 않은 페이지가 생성됐습니다.
• 모니터링 기간: 출시 전, 최종 동기화 후, 가져오기 수정 후
• 롤백 조건: 출시 결정 전에 보호 대상 콘텐츠 유형 또는 로케일을 대조할 수 없음

템플릿 계약 테스트

• 실행할 테스트: 보호 대상 템플릿별 층화 표본을 크롤링하고 렌더링하여 상태, 콘텐츠, 메타데이터, 캐노니컬, 지시문, 스키마, 링크, 자산, 모바일 출력의 차이를 비교합니다.
• 예상 결과: 모든 보존 요구사항이 통과하고 모든 차이가 승인된 의도적 변경에 매핑됩니다.
• 실패 해석: 컴포넌트, 필드 매핑, 경로 또는 렌더링 계층이 검색에 노출되는 출력을 시스템적으로 바꾸고 있습니다.
• 모니터링 기간: 스테이징, 출시 직후, 템플릿 수정 후
• 롤백 조건: 사이트 전체 또는 고가치 템플릿이 색인 가능성, 콘텐츠, 캐노니컬 무결성 또는 핵심 기능을 잃고 허용 시간 안에 복구할 수 없음

리디렉션 및 오류 상태 테스트

• 실행할 테스트: 모든 기존 URL을 대량 HTTP 상태 코드 검사기 또는 전체 크롤러로 실행하고, 존재하지 않는 것으로 알려진 경로를 테스트합니다.
• 예상 결과: 이동한 URL은 하나의 영구 리디렉션으로 승인된 동등 페이지에 도달하고, 보존 URL은 성공 상태를 유지하며, 폐기 URL은 계획한 404 또는 410을 반환합니다.
• 실패 해석: 규칙 누락, 잘못된 순서, 체인, 소프트 404 또는 포괄 라우팅이 의도한 처리 결과를 가리고 있습니다.
• 모니터링 기간: 가능한 경우 스테이징, 출시 시점, 각 규칙 변경 후
• 롤백 조건: 시스템적 규칙 실패로 보호 대상 URL을 사용할 수 없거나 관련 없는 목적지로 보냄

데이터를 고려한 롤백 예행연습

• 실행할 테스트: 전환 후 생성된 쓰기 작업을 포함해 문서화된 롤백을 운영 환경과 비슷한 예행연습에서 실행합니다.
• 예상 결과: 코드, 스키마, 콘텐츠, 주문, 세션, 업로드, 큐, 통합이 조용한 손실 없이 정의된 일관 상태에 도달합니다.
• 실패 해석: 계획은 소프트웨어를 복원할 수 있지만 새 플랫폼이 만든 데이터를 대조할 수 없습니다.
• 모니터링 기간: 출시 전, 중요한 스키마 또는 전환 변경 후
• 롤백 조건: 핵심 쓰기 작업에 안전한 롤백 또는 롤포워드 경로가 없음

시간을 들일 만한 자료

내 관련 글

• 성공적인 웹사이트 마이그레이션에는 체크리스트 이상의 것이 필요합니다에서는 공통 프로젝트 절차, 스테이징, 동등성, 모니터링을 다룹니다.
• SEO를 위한 리디렉션에서는 리플랫폼으로 경로가 바뀔 때 이전하거나 다시 구축해야 하는 리디렉션 계층을 다룹니다.

이 사이트의 관련 가이드

• 사이트 마이그레이션은 마이그레이션 유형, 공통 위험, 보편적 절차를 다룹니다.
• 웹사이트 마이그레이션 체크리스트는 프로젝트에 바로 쓸 수 있는 순서를 제공합니다.
• 웹사이트 재설계 SEO 체크리스트는 URL을 유지하면서 템플릿이 바뀌는 경우에 적용됩니다.
• JavaScript SEO는 렌더링과 발견을 더 깊이 다룹니다.

업계 자료

• Google: URL 변경을 수반한 사이트 이전
• Google: JavaScript SEO 기본사항
• Google: 모바일 우선 색인
• Google: 구조화 데이터
• Bing: Bing을 사용한 웹사이트 마이그레이션
• Bing: IndexNow

스스로 테스트하기: CMS 마이그레이션과 리플랫폼 SEO

범위, 동등성, 렌더링, 대조, 롤백에 관한 다섯 문제입니다. 각 답을 고른 뒤 확인하세요.

변경 내역