도메인은 그대로, 플랫폼만 옮길 때 SEO 체크리스트

도메인을 그대로 둔 채 플랫폼만 옮기면 SEO는 안전하다고 생각하기 쉽다. 그러나 도메인이 같아도 플랫폼이 바뀌면 URL 패턴, 메타 태그, 구조화 데이터, robots.txt가 거의 통째로 다시 만들어진다. 이 변화를 "도메인은 그대로니까 괜찮다"고 넘기면, 정작 순위를 흔드는 진짜 원인을 놓치게 된다.

카페24·아임웹 같은 빌더에서 워드프레스나 자체 개발 홈페이지로 옮기는 경우가 대표적이다. 겉보기엔 "같은 주소, 다른 뒷단"일 뿐이지만, 검색엔진은 새 템플릿·새 코드로 만들어진 페이지를 다시 확인하는 절차를 거친다. 도메인 이전보다는 가볍지만, 아무 준비 없이 진행해도 되는 작업은 결코 아니다.

이 글은 도메인은 바꾸지 않고 플랫폼(빌더→자체 홈페이지, 또는 CMS 교체)만 옮길 때 무엇을 먼저 기록해야 하는지, 빌더가 자동으로 해주던 것들을 누가 대신 챙겨야 하는지, 이전 당일과 이후 며칠을 어떤 순서로 점검해야 하는지 실무 순서 그대로 정리했다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• 도메인이 같으면 구글의 주소 변경 도구(Change of Address)는 필요 없다 — 리다이렉트와 사이트맵 갱신이면 충분하다
• 빌더가 자동으로 만들어 주던 메타 태그·구조화 데이터·사이트맵·robots.txt는 이전 후 누군가 직접 다시 챙겨야 한다
• URL이 완전히 같아도, 완전히 달라져도 각각 다른 위험이 있다 — URL 매핑 시트로 미리 대조해야 한다
• 구글 서치 콘솔 도메인 속성(DNS 인증)은 플랫폼이 바뀌어도 유지되지만, URL 접두어 속성(메타태그·파일 인증)은 깨질 수 있다
• 이전 당일은 스테이징 리다이렉트 검증 → 배포 → 사이트맵 재제출 → 색인 요청 순서로 진행해야 한다

플랫폼만 바꾸는데도 SEO 체크리스트가 필요할까?

그렇다. 도메인이 같아도 검색엔진은 새로 만들어진 페이지를 다시 평가하는 절차를 거친다. 구글은 페이지의 HTML 구조, 메타 태그, 구조화 데이터, 내부 링크를 종합해 그 페이지를 이해하는데, 플랫폼이 바뀌면 이 요소가 거의 전부 새로 생성된다. 도메인이 같다는 사실만으로 이 재평가 과정 자체가 사라지지는 않는다.

빌더형 플랫폼(카페24·아임웹·식스샵 등)은 메타 태그, 구조화 데이터, 사이트맵, robots.txt를 관리자가 신경 쓰지 않아도 플랫폼이 자동으로 만들어 준다. 이 편리함이 플랫폼을 옮기는 순간 눈에 보이지 않는 리스크로 바뀐다. 자동으로 챙겨지던 것들이 새 플랫폼에서는 자동으로 챙겨지지 않을 수 있기 때문이다.

실제로 이런 이전은 생각보다 자주 일어난다. 창업 초기에는 빌더로 빠르게 쇼핑몰을 열고, 매출이 커지면서 커스터마이징의 한계를 느껴 자체 홈페이지나 워드프레스로 옮기는 흐름이 대표적이다. 빌더는 디자인과 결제·배송 연동까지 패키지로 제공하지만, 그만큼 URL 구조나 코드 영역을 사업자가 마음대로 손댈 수 없게 막아 둔 경우가 많다. 검색 노출을 더 세밀하게 통제하고 싶어질수록 이 한계가 이전을 결정하는 계기가 된다.

도메인 이전보다 위험도는 낮지만, "도메인만 같으면 안전하다"는 전제 자체가 틀렸다. 플랫폼 이전은 도메인 이전과는 다른 종류의, 그러나 분명히 존재하는 리스크를 갖고 있다.

플랫폼 이전의 핵심은 "검색엔진에게 보이는 페이지의 뒷단이 통째로 바뀐다"는 사실을 인정하는 데서 시작한다. 이 사실을 받아들이면, 무엇을 점검해야 하는지는 자연스럽게 따라온다.

플랫폼 이전은 도메인 이전과 어떻게 다를까?

도메인 이전은 구글이 사이트 전체의 신뢰도를 처음부터 다시 확인하는 큰 변화지만, 플랫폼 이전은 도메인이라는 '신원'은 그대로 유지한 채 콘텐츠를 보여 주는 방식만 바꾸는 작업이다. 두 작업은 필요한 절차와 위험도 자체가 다르다.

구글 서치 센트럴의 공식 안내는 이 구분을 분명히 하고 있다. 사용자에게 보이는 URL이 바뀌지 않는 이전(예: 같은 주소를 유지한 채 호스팅이나 플랫폼만 바꾸는 경우)은 구글의 주소 변경 도구를 쓰지 않는다. 같은 도메인 안에서 경로(path)만 바뀌는 경우에도 이 도구는 필요 없으며, 리다이렉트를 걸고 사이트맵을 갱신하는 것으로 충분하다고 안내한다. 주소 변경 도구는 old브랜드.com을 new브랜드.com처럼 도메인 자체가 바뀌는 경우에만 쓰는 도구다.

구분	변경 범위	주소 변경 도구 필요 여부	참고
도메인 이전	도메인 자체 변경	필수	도메인 이전 SEO 체크리스트
URL 구조 개편(리뉴얼)	같은 도메인, URL 경로 변경	불필요(리다이렉트로 충분)	웹사이트 리뉴얼 SEO 체크리스트
플랫폼 이전(이 글)	같은 도메인, 뒷단(CMS)만 변경	불필요(리다이렉트로 충분)	이 글

이 구분이 중요한 이유는 "무엇을 걱정해야 하는가"가 달라지기 때문이다. 도메인 이전에서는 도메인 자체가 쌓아 온 신뢰도 이전이 가장 큰 걱정거리지만, 플랫폼 이전에서는 그 도메인의 신뢰도는 그대로 유지된다는 것을 전제로, 플랫폼이 자동으로 해 주던 기술적인 요소들을 빠뜨리지 않는가가 핵심 걱정거리다.

이전 전에 무엇부터 기록해둬야 할까?

지금 사이트에 있는 모든 URL과, 그 URL이 갖고 있는 메타데이터·구조화 데이터를 전부 기록해 두는 것이 첫 단계다. 기준이 없으면 이전 후 무엇이 빠졌는지 비교할 방법이 없다.

• 전체 URL 목록: 사이트맵과 크롤링 도구로 현재 모든 페이지의 주소를 뽑아 둔다.
• 페이지별 메타 태그: 타이틀 태그, 메타 디스크립션을 페이지 단위로 캡처하거나 내려받는다.
• 구조화 데이터 종류: 빌더가 자동으로 넣어 준 상품(Product), 리뷰(Review), 지역 업체(LocalBusiness) 스키마가 있다면 어떤 페이지에 어떤 타입이 적용돼 있는지 기록한다.
• 핵심 키워드 순위와 트래픽: 서치 콘솔·애널리틱스에서 최근 3–6개월 데이터를 내려받아 비교 기준선으로 삼는다.

가장 중요한 산출물은 URL 매핑 시트다. 기존 URL과 새 플랫폼에서의 URL을 한 줄씩 짝지어 두는 표로, 이전 당일 리다이렉트 작업의 설계도 역할을 한다.

항목	기존 URL(카페24 예시)	신규 URL(워드프레스 예시)	리다이렉트
상품 상세	/product/상품명/12345/category/34/display/1/	/products/상품명-slug	301
공지 글	/board/notice/view/88	/notice/88-slug	301
자유게시판	/board/free/view/201	(대응 페이지 없음)	관련 카테고리로 301

URL 매핑 시트를 만들지 않고 이전을 진행하면, 리다이렉트를 "대충 메인 페이지로만" 걸게 된다. 그러면 구글은 서로 다른 페이지를 전부 같은 곳으로 보내는 것으로 인식해 오히려 신뢰도를 깎아 먹는다.

URL이 그대로여도, 완전히 달라져도 왜 둘 다 위험할 수 있을까?

둘 다 위험하지만 위험의 종류가 다르다. URL을 똑같이 맞추면 리다이렉트 작업 자체는 줄어들지만, 새 플랫폼의 코드가 예전과 똑같은 URL을 만들어 내도록 설계하는 기술적 난이도가 높아진다. URL이 완전히 달라지면 반대로, 설계는 쉬워지지만 리다이렉트를 하나라도 빠뜨리면 그 페이지는 그대로 사라진 것과 같다.

실무에서 가장 흔한 상황은 "완전히 같지도, 완전히 다르지도 않은" 경우다. 빌더는 보통 /product/상품명/12345/category/34/display/1/ 처럼 플랫폼 고유의 파라미터가 섞인 URL을 쓴다. 이 구조를 새 플랫폼에서 그대로 재현하는 것은 비효율적이고, 대부분은 /products/상품명-slug 같은 더 짧고 깨끗한 구조로 바꾸는 쪽을 선택한다. 이 선택 자체는 문제가 아니다. 문제는 바뀐 URL 전체에 1대1로 리다이렉트를 걸었는가다.

URL을 완전히 동일하게 유지하는 쪽을 택했다면, 이번엔 개발 쪽의 부담이 커진다. 새 플랫폼의 라우팅 구조가 예전 빌더의 URL 패턴과 다른 경우가 많아서, 똑같은 주소를 만들어 내려면 라우터 설정을 억지로 끼워 맞춰야 한다. 이 과정에서 오히려 코드가 복잡해지고 유지보수가 어려워지는 부작용이 생길 수 있으므로, "URL을 반드시 똑같이 유지해야 하는가"부터 먼저 따져 보는 것이 순서다. 대부분의 경우, 깔끔한 신규 URL 구조에 정확한 301 매핑을 거는 쪽이 장기적으로 더 관리하기 쉽다.

상황	나쁜 예	좋은 예
URL 구조 변경	전체 상품 URL을 바꾸고 메인 페이지로만 일괄 리다이렉트	상품마다 새 URL로 1대1 매핑한 301 리다이렉트
게시판 글 이전	과거 게시판 글은 이전 대상에서 빼고 그대로 방치(404)	관련 카테고리나 블로그 글로 리다이렉트, 또는 아카이브 페이지로 안내
카테고리 재구성	카테고리 번호만 체계 없이 뒤바뀜	카테고리명을 유지하거나, 바뀐 경우 명확히 매핑 문서화

URL을 바꾸는 선택 자체보다, 바뀐 URL 전체를 빠짐없이 매핑했는가가 순위를 가른다. 매핑 시트에 없는 URL이 하나라도 있다면, 그 페이지는 이전 당일부터 404가 될 가능성이 크다.

빌더가 자동으로 챙겨주던 것들, 이전하면 누가 책임져야 할까?

빌더에서는 플랫폼이 자동으로 만들어 주던 기술적 요소를, 이전 후에는 개발자나 SEO 담당자가 직접 챙겨야 한다. 이 책임 소재가 명확하지 않으면 "어느 쪽에서 하는 거겠지"라는 생각으로 누락되기 쉽다.

구조화 데이터(JSON-LD)가 대표적이다. 빌더는 상품·리뷰·업체 정보에 맞는 스키마 마크업을 관리자가 입력만 하면 자동으로 코드에 심어 준다. 새 플랫폼으로 옮기면 이 스키마를 다시 설계하고 코드에 넣어야 하는데, 마이그레이션 과정에서 필드 단위로 꼼꼼히 매핑하지 않으면 일부 속성이 누락되거나 아예 빠지는 경우가 흔하다. 특히 커스텀 필드로 넣어 둔 값일수록 자동 변환 스크립트가 놓치기 쉽다.

robots.txt도 마찬가지다. 새 플랫폼으로 옮기는 과정에서 스테이징(테스트) 환경에 걸어 둔 '전체 차단' 설정이 실수로 운영 환경까지 그대로 배포되는 사고가 실제로 자주 일어난다. 테스트 단계에서는 검색엔진이 못 찾게 막아 두는 것이 정상이지만, 이 설정을 운영 환경 배포 전에 반드시 해제해야 한다.

오픈그래프(OG) 태그도 빠뜨리기 쉬운 항목이다. 빌더는 상품·게시글을 카카오톡이나 페이스북에 공유할 때 보이는 미리보기 이미지와 제목을 자동으로 만들어 준다. 새 플랫폼에서는 이 태그를 페이지 템플릿에 직접 넣어야 하는데, 디자인과 콘텐츠 작업에만 집중하다 보면 이 부분은 런칭 이후에야 "공유했는데 미리보기가 안 뜬다"는 식으로 뒤늦게 발견되는 경우가 많다.

요소	빌더에서는	이전 후에는
메타 타이틀·디스크립션	관리자 화면에서 입력하면 자동 반영	템플릿 코드에 직접 출력하거나 CMS 필드 설계 필요
구조화 데이터(JSON-LD)	상품·리뷰 입력 시 자동 생성	페이지 타입별로 직접 설계·구현
사이트맵(sitemap.xml)	자동 생성·갱신	새 플랫폼의 생성 방식 확인, 누락 여부 점검
robots.txt	플랫폼 기본값 제공	직접 작성, 스테이징 차단 설정 해제 필수
오픈그래프(OG) 태그	공유 시 자동 미리보기 생성	og:image·og:title 직접 설정 필요

빌더가 자동으로 해 주던 다섯 가지 요소는, 이전 후 누군가 반드시 책임지고 다시 만들어야 할 일로 바뀐다. 담당자를 정하지 않으면 그대로 누락된다.

구조화 데이터를 직접 설계하는 것이 부담스럽다면, AI 스키마 마크업 생성 도구로 초안을 만들고 검증하는 방법도 있다. 다만 생성된 코드를 그대로 쓰지 말고, 실제 페이지 내용과 일치하는지 반드시 확인해야 한다.

서치 콘솔·네이버 서치어드바이저 인증은 플랫폼을 바꾸면 다시 해야 할까?

인증 방식에 따라 다르다. DNS로 인증한 도메인 속성은 그대로 유지되지만, HTML 태그나 파일로 인증한 경우는 플랫폼을 바꾸는 순간 깨질 수 있다.

구글 서치 콘솔의 도메인 속성은 도메인 등록업체의 DNS에 TXT 레코드를 추가하는 방식으로 인증한다. 이 TXT 레코드는 플랫폼이나 호스팅을 바꿔도 DNS 설정 자체에 남아 있으므로, 도메인 속성으로 인증해 뒀다면 플랫폼을 옮겨도 서치 콘솔 접근 권한은 그대로 유지된다. 반면 URL 접두어 속성을 HTML 메타 태그나 HTML 파일 업로드 방식으로 인증했다면, 그 태그나 파일은 예전 플랫폼의 코드·서버에 있던 것이므로 플랫폼을 바꾸면 인증이 깨질 수 있다. 새 플랫폼에 같은 인증 태그를 다시 심거나, 아예 DNS 기반 도메인 속성으로 전환하는 것이 안전하다.

네이버 서치어드바이저도 원리는 비슷하다. HTML 태그 방식이나 파일 업로드 방식으로 소유 확인을 했다면, 새 플랫폼에 그 인증 태그나 파일을 그대로 다시 심어야 소유 확인이 유지된다. 플랫폼을 바꾸면서 이 태그를 깜빡하고 빼먹으면, 색인 요청이나 사이트맵 제출 같은 기능에 다시 접근하지 못할 수 있다.

두 도구 모두 인증이 끊기는 것 자체가 순위에 직접적인 영향을 주지는 않는다. 다만 인증이 깨진 상태에서는 색인 상태를 확인하거나 긴급 요청을 보낼 통로가 사라지므로, 이전 당일 체크리스트에 반드시 포함해야 한다.

도메인 속성(DNS 인증)은 플랫폼이 바뀌어도 유지되지만, URL 접두어 속성(메타태그·파일 인증)은 이전 당일 깨질 수 있다는 것이 핵심이다.

가장 안전한 방법은 이전을 계기로 도메인 속성(DNS 인증)으로 전환해 두는 것이다. 도메인 등록업체 관리 화면에서 TXT 레코드 하나만 추가하면 되고, 이후에는 플랫폼이나 호스팅을 몇 번을 바꾸더라도 인증이 끊길 걱정을 다시 하지 않아도 된다. URL 접두어 속성을 계속 쓰더라도 문제는 없지만, 플랫폼을 다시 바꿀 가능성이 있다면 도메인 속성으로 미리 전환해 두는 쪽이 장기적으로 손이 덜 간다.

속성 종류별 차이가 궁금하다면 서치 콘솔 도메인 속성과 URL 접두어 비교 글에서 더 자세히 다뤘다. 이전을 앞두고 있다면, 지금 쓰고 있는 속성이 어떤 방식으로 인증됐는지부터 확인해 두는 것이 좋다.

이전 당일엔 어떤 순서로 진행해야 할까?

스테이징 환경에서 리다이렉트를 전부 검증한 뒤 배포하고, 그 직후 사이트맵과 색인 요청을 순서대로 진행하는 것이 안전하다. 순서가 바뀌면 검증 안 된 리다이렉트가 운영 환경에 먼저 배포되는 사고로 이어진다.

1. 스테이징에서 리다이렉트 전체를 검증한다. URL 매핑 시트의 모든 항목을 실제로 눌러 보거나 크롤링 도구로 일괄 확인한다. 수십 건이 넘는다면 사람이 하나씩 클릭하기보다, 크롤링 도구에 매핑 시트를 입력해 응답 코드를 한 번에 뽑는 것이 정확하고 빠르다.
2. robots.txt에서 차단 설정을 해제했는지 확인한다. 스테이징용 "전체 차단" 설정이 그대로 남아 있지 않은지 반드시 재확인한다. 메타 태그의 noindex 설정도 같은 이유로 함께 점검한다.
3. 운영 환경에 배포한다. 배포 직후 홈페이지와 핵심 페이지 몇 곳을 직접 열어 정상 작동을 확인한다. 결제·예약처럼 전환에 직결되는 기능은 SEO보다 먼저 정상 작동 여부를 확인해야 한다.
4. 리다이렉트가 실제로 작동하는지 다시 확인한다. 스테이징에서 확인한 것과 운영 환경에서 확인하는 것은 서버 설정 차이로 다른 결과가 나올 수 있다. 캐시 때문에 예전 페이지가 잠시 그대로 보이는 경우도 있으니, 브라우저 캐시를 비우고 다시 확인한다.
5. 새 사이트맵을 서치 콘솔·네이버 서치어드바이저에 제출한다. 기존 사이트맵 URL이 바뀌었다면 이전 사이트맵은 삭제 처리한다. 사이트맵에 포함된 URL 개수가 실제 페이지 수와 맞는지도 함께 확인한다.
6. 핵심 페이지는 URL 검사 도구로 색인을 요청한다. 모든 페이지를 요청할 필요는 없고, 매출이나 트래픽이 큰 페이지부터 우선한다. 나머지는 사이트맵과 내부 링크를 통해 자연스럽게 재발견되도록 둔다.

배포는 되돌릴 수 있지만, 그 사이 구글이 깨진 리다이렉트나 전체 차단 robots.txt를 먼저 읽어 버리면 재평가에 추가 시간이 걸린다. 가능하면 트래픽이 적은 시간대에 배포하고, 배포 직후 1시간은 직접 모니터링하는 것이 안전하다.

이전 후 며칠 동안은 무엇을 확인해야 할까?

첫 1–2주는 색인 상태와 404 오류를, 그 이후 4–8주는 순위와 트래픽 회복 추세를 지켜봐야 한다. 플랫폼 이전은 도메인 이전보다 회복이 빠른 편이지만, 완전히 즉시 반영되는 것은 아니다.

• 1주차: 서치 콘솔의 페이지 색인 보고서에서 "검색된 적 없음"이나 오류로 분류된 URL이 급증했는지 확인한다.
• 1–2주차: 크롤링 도구로 전체 사이트를 훑어 404 오류와 리다이렉트 체인이 남아 있는지 점검한다.
• 2–4주차: 핵심 키워드 순위를 기준선과 비교한다. 소폭 하락은 정상 범위지만, 급락한 페이지가 있다면 해당 페이지의 메타데이터·구조화 데이터 적용 여부를 다시 확인한다.
• 4–8주차: 트래픽이 기준선 대비 어느 정도까지 회복됐는지 추세로 확인한다. 이 기간 안에 안정화되지 않는다면, 놓친 리다이렉트나 구조화 데이터가 있는지 처음부터 다시 점검한다.

이 네 구간을 나눠서 보는 이유는 간단하다. 색인 문제는 1–2주 안에 신호가 나타나지만, 순위 회복은 그보다 느리게 나타나기 때문이다. 1주차에 색인 상태가 정상인데도 2–4주차에 순위가 떨어져 있다면, 색인 자체의 문제가 아니라 메타데이터나 구조화 데이터의 품질 문제일 가능성이 높다. 반대로 1주차부터 색인 오류가 많이 잡힌다면, 리다이렉트나 robots.txt 설정부터 다시 확인해야 한다.

이전 직후 일시적인 트래픽 하락은 대부분 정상 범위이지만, "정상인지 실수인지"는 반드시 기준선 데이터와 숫자로 비교해야 한다. 감으로 판단하면 진짜 문제를 놓친다.

플랫폼 이전에서 가장 흔한 실수는 무엇일까?

실수는 대부분 "빌더가 자동으로 해 주던 것을 깜빡하는 것"에서 나온다. 아래는 실제로 자주 반복되는 패턴이다.

• 구조화 데이터 누락: 상품·리뷰 스키마를 새 플랫폼에서 재구현하지 않고 그대로 넘어가는 경우. 리치 결과가 사라지는 정도로 끝나지 않고, 일부는 콘텐츠 이해 자체에 영향을 준다.
• 스테이징 차단 설정이 운영에 배포됨: 테스트 단계의 robots.txt 전체 차단이나 noindex 메타 태그가 실수로 운영 환경에 그대로 올라가는 경우. 발견이 늦어지면 몇 주씩 색인에서 완전히 빠질 수 있다.
• 인증 태그 재설정 누락: 서치 콘솔·네이버 서치어드바이저 소유 확인 태그를 새 플랫폼에 다시 심지 않아, 이전 후 관리 도구 접근 자체가 막히는 경우.
• 이미지 alt 텍스트 손실: 이미지를 새 플랫폼에 다시 업로드하면서 기존에 꼼꼼히 써 둔 alt 텍스트가 초기화되는 경우.
• 리다이렉트를 메인 페이지로 일괄 처리: 매핑 없이 전체를 홈페이지로만 리다이렉트해, 구글이 모든 페이지를 중복으로 인식하게 되는 경우.
• 오픈그래프 태그 누락: 공유 미리보기 이미지와 제목을 새 템플릿에 반영하지 않아, 카카오톡·소셜 공유 시 빈 미리보기가 뜨는 경우.

이 여섯 가지 중 상당수는 "눈에 바로 보이지 않는다"는 공통점을 갖고 있다. 화면은 정상적으로 뜨기 때문에 디자인 검수에서는 통과하지만, 검색엔진이나 공유 기능을 직접 테스트하지 않으면 몇 주가 지나서야 문제를 알아차리게 된다. 배포 전 체크리스트에 이 항목들을 명시적으로 넣어 두는 것이 가장 확실한 예방책이다.

이 실수들의 공통점은 "누군가는 당연히 할 거라고 생각했던 일"이라는 점이다. 이전 프로젝트의 담당자를 명확히 정하고, 이 체크리스트를 그 담당자에게 그대로 넘기는 것이 가장 확실한 예방법이다.

가상의 사례로 전체 흐름을 다시 확인하면?

작은 쇼핑몰 하나를 예로 들어 지금까지 설명한 원칙을 순서대로 적용해 보자. 카페24에서 3년째 수제 비누를 판매하던 쇼핑몰이 상품이 200개를 넘어가면서 디자인 커스터마이징의 한계를 느껴 자체 개발 홈페이지로 옮기기로 했다고 가정한다.

이전 전 점검에서 다음과 같은 상태가 드러났다. 상품 상세 URL은 /product/상품명/12345/category/34/display/1/ 형태로 카페24 고유의 파라미터가 섞여 있었고, 상품마다 Product 스키마(가격·재고·리뷰 평점)가 자동으로 심어져 있었다. 구글 서치 콘솔은 URL 접두어 속성으로, HTML 파일 업로드 방식으로 인증돼 있었다.

이 사이트에 적용한 이전 절차는 다음과 같다.

1. URL 매핑 시트를 먼저 완성한다. 상품 200개 전체의 기존 URL과, 새 플랫폼에서 쓸 /products/상품명-slug 형태의 신규 URL을 1대1로 짝지었다.
2. 구조화 데이터를 페이지 타입별로 재설계한다. Product 스키마에 가격·재고·리뷰 평점이 모두 들어가도록, 기존 카페24 화면에 보이던 정보와 하나씩 대조하며 누락 없이 옮겼다.
3. 서치 콘솔 인증 방식을 도메인 속성으로 전환한다. 기존 HTML 파일 인증이 플랫폼 교체와 함께 깨질 것을 미리 예상하고, 이전 전에 DNS TXT 레코드로 도메인 속성을 새로 추가해 뒀다.
4. 스테이징에서 리다이렉트 200건 전체를 크롤링 도구로 검증한다. 사람이 눈으로 다 확인하기엔 수가 많아, 크롤러로 200건의 응답 코드를 한 번에 점검했다.
5. 배포 후 사이트맵을 재제출하고, 매출 상위 20개 상품 페이지만 먼저 색인을 요청한다. 전체를 한꺼번에 요청하지 않고 우선순위가 높은 페이지부터 처리했다.

이 절차를 거친 뒤 2주차에 404 오류 없이 상품 페이지 색인이 유지됐고, 4주차에는 핵심 키워드 순위가 기준선 대비 거의 변동이 없었다. 상품이 200개나 됐지만, 매핑 시트와 크롤링 검증 덕분에 사람이 눈으로 일일이 확인하지 않고도 빠뜨린 URL을 찾아낼 수 있었다.

플랫폼 이전의 성패는 결국 "몇 개를 빠뜨렸는가"로 갈린다. 상품이 많을수록 사람의 기억과 눈이 아니라, 매핑 시트와 크롤링 도구에 더 의존해야 한다.

업종·사이트 규모에 따라 체크리스트가 달라질까?

원칙은 같지만, 우선순위를 둬야 할 항목은 업종과 규모에 따라 달라진다.

쇼핑몰이라면 상품 URL 매핑이 가장 중요하다. 상품 수가 많을수록 매핑 시트 작성에 시간이 오래 걸리지만, 이 작업을 건너뛰면 상품 상세 페이지 전체가 한꺼번에 색인에서 빠질 위험이 있다. 구조화 데이터 중에서도 가격·재고 정보가 담긴 Product 스키마는 특히 꼼꼼히 재구현해야 한다.

병원·학원처럼 예약·상담 전환이 중심인 사이트라면 폼(양식) 기능 이전을 우선 챙겨야 한다. 빌더의 예약 폼이나 상담 신청 폼은 플랫폼 고유 기능으로 동작하는 경우가 많아, 새 플랫폼에서 같은 기능을 그대로 쓸 수 없는 경우가 흔하다. SEO보다 먼저 전환 경로가 끊기지 않는지부터 확인해야 한다.

블로그·콘텐츠 중심 사이트라면 기존 글의 내부 링크 구조 보존이 중요하다. 글이 많을수록 글 사이의 상호 링크가 복잡하게 얽혀 있는데, 플랫폼을 옮기면서 이 링크들이 깨지면 리뉴얼 체크리스트에서 설명한 것과 같은 문제가 발생한다.

소규모 사이트(페이지 수십 개 이하)라면 체크리스트 전체를 그대로 사람이 직접 훑어도 충분하다. 반면 페이지가 수백 개를 넘는다면, 크롤링 도구로 이전 전후 URL 목록을 자동으로 비교하는 과정을 반드시 포함해야 사람이 놓치는 부분을 줄일 수 있다.

자주 묻는 질문

플랫폼만 바꾸면 구글 서치 콘솔에 새로 등록해야 하나요?

도메인이 같다면 새로 등록할 필요는 없다. 이미 등록된 속성이 도메인 속성(DNS 인증)이라면 그대로 쓸 수 있다. URL 접두어 속성이라면 인증 방식에 따라 다시 인증해야 할 수 있으니, 이전 전에 미리 확인해 두는 것이 안전하다.

사이트맵 URL이 바뀌면 어떻게 해야 하나요?

새 사이트맵 URL을 서치 콘솔에 제출하고, 기존 사이트맵은 삭제 처리하면 된다. 두 사이트맵을 동시에 등록해 둘 필요는 없다. 다만 기존 사이트맵에 있던 URL이 새 사이트맵에서 모두 빠짐없이 다시 등장하는지 비교해 보는 것이 좋다.

플랫폼을 바꾸면 트래픽이 얼마나 떨어지나요?

도메인 이전보다는 적게 떨어지는 편이지만, 수치로 단정하기는 어렵다. URL이 거의 그대로 유지되고 리다이렉트·구조화 데이터를 꼼꼼히 챙겼다면 하락이 거의 없을 수도 있고, 반대로 매핑이 부실하면 URL 구조 개편과 비슷한 수준의 하락이 나타날 수도 있다. 준비의 완성도가 결과를 가장 크게 좌우한다.

리뉴얼과 플랫폼 이전을 동시에 하면 안 되나요?

가능하지만 위험이 더 커진다. 디자인(URL 구조 포함)과 플랫폼(CMS)을 한꺼번에 바꾸면, 문제가 생겼을 때 원인이 디자인 쪽인지 플랫폼 쪽인지 구분하기 어려워진다. 일정이 허락한다면 플랫폼을 먼저 안정적으로 옮긴 뒤, 어느 정도 안정화된 시점에 디자인 리뉴얼을 진행하는 쪽이 문제를 추적하기 쉽다.

네이버 쪽은 따로 신경 쓸 게 있나요?

있다. 네이버 서치어드바이저의 소유 확인 방식을 먼저 확인해야 한다. HTML 태그나 파일 방식으로 인증했다면 새 플랫폼에도 그 태그·파일을 다시 심어야 한다. 사이트맵 제출 역시 구글과 마찬가지로 새 주소로 다시 제출해야 한다.

구조화 데이터를 전부 다시 만들 필요가 있나요?

빌더에서 자동으로 넣어 줬던 종류라면 전부 다시 확인해야 한다. 상품·리뷰·업체 정보처럼 리치 결과와 직결된 스키마는 누락되면 검색 결과에서 눈에 띄는 요소가 사라질 수 있다. 새로 만들기 전에, 이전 플랫폼에서 어떤 타입이 어떤 페이지에 적용돼 있었는지부터 목록으로 정리해 두는 것이 먼저다.

호스팅(서버)만 바꾸고 플랫폼(CMS)은 그대로면 체크리스트가 더 짧아지나요?

그렇다. URL·메타데이터·구조화 데이터는 그대로 유지되는 경우가 많아 리스크가 훨씬 낮다. 다만 이 경우에도 서버 응답 속도 변화가 코어 웹 바이탈에 영향을 줄 수 있으니, 이전 후 속도 측정은 빠뜨리지 않는 것이 좋다.

이전 작업은 보통 얼마나 걸리나요?

준비 기간을 포함하면 소규모 사이트는 2–4주, 페이지 수가 많은 쇼핑몰은 1–3개월 정도를 잡는 것이 현실적이다. URL 매핑과 구조화 데이터 재설계에 가장 많은 시간이 들어가므로, 이 두 작업의 분량을 먼저 가늠해 전체 일정을 잡는 것이 안전하다.

이전 후에도 기존 백링크(외부 링크)는 그대로 유효한가요?

그렇다. 도메인이 바뀌지 않았으므로 외부 사이트가 걸어 둔 백링크의 목적지도 그대로 유효하다. 다만 그 백링크가 가리키는 정확한 URL이 이전 과정에서 바뀌었다면, 반드시 새 URL로 301 리다이렉트가 걸려 있어야 그 링크의 신뢰도가 끊기지 않고 이어진다. 백링크 자체의 가치는 도메인에 쌓이는 것이므로, 플랫폼 이전만으로 이 가치가 사라지지는 않는다.

이전 전에 꼭 외부 전문가(SEO 담당자·개발자)가 필요한가요?

페이지 수가 적고 단순한 사이트라면 체크리스트를 따라 직접 진행할 수 있다. 다만 상품·게시글이 많거나 구조화 데이터가 복잡하게 적용돼 있다면, URL 매핑과 스키마 재설계만큼은 경험 있는 담당자가 검토하는 것이 안전하다. 특히 리다이렉트 매핑에서 몇 개만 빠져도 전체 상품군의 색인에 영향을 줄 수 있으므로, 규모가 클수록 검증 단계에 전문가를 포함시키는 것을 권한다.

마무리: 도메인이 같아도 할 일은 줄지 않는다

도메인을 그대로 둔 플랫폼 이전은 도메인 이전보다 분명히 가벼운 작업이다. 그러나 "도메인이 같으니까 안전하다"는 생각 하나만으로 체크리스트 없이 진행하면, 빌더가 자동으로 해 주던 것들을 하나씩 빠뜨리게 된다.

오늘 정리한 내용을 요약하면 이렇다.

• 도메인이 같으면 구글 주소 변경 도구는 필요 없지만, 리다이렉트와 사이트맵 갱신은 여전히 필요하다.
• 메타데이터·구조화 데이터·robots.txt는 빌더가 자동으로 해 주던 것을 사람이 직접 다시 챙겨야 한다.
• 서치 콘솔·네이버 서치어드바이저 인증은 방식에 따라 깨질 수 있으므로 이전 전에 확인해야 한다.
• 이전 당일은 스테이징 검증 → 배포 → 사이트맵 재제출 → 색인 요청 순서를 지켜야 한다.

지금 바로 할 수 있는 것부터 시작한다면 이렇다.

1. 현재 사이트의 URL 전체와 구조화 데이터 목록을 뽑아 둔다. 이 목록이 모든 이후 작업의 기준선이 된다.
2. 서치 콘솔·네이버 서치어드바이저의 인증 방식을 확인한다. 도메인 속성인지, URL 접두어인지만 확인해도 무엇을 다시 챙겨야 할지 알 수 있다.
3. 새 플랫폼에서 재구현해야 할 기능 목록을 먼저 뽑는다. 예약 폼, 리뷰 스키마처럼 플랫폼 고유 기능일수록 먼저 확인해야 늦게 발견하는 사고를 막을 수 있다.

무인도에 아무리 예쁜 호텔을 지어도 손님이 그 존재를 모르면 소용없듯, 플랫폼만 바꿔도 검색엔진에게 다시 소개하는 절차는 똑같이 필요하다. 이루웹은 빌더에서 자체 홈페이지로 옮기는 플랫폼 이전 작업을, URL 매핑부터 구조화 데이터 재설계까지 SEO 전문가와 개발자가 함께 진행하고 있습니다. 지금 쓰고 있는 플랫폼의 한계 때문에 이전을 고민 중이시라면 이루웹의 홈페이지 제작 서비스를 살펴보시고, 무료 상담을 통해 지금 사이트의 이전 범위와 리스크를 먼저 점검받아 보시길 권해 드립니다. 순위를 지키면서 플랫폼을 옮기는 일, 이루웹이 함께하겠습니다.