RSS

홈페이지 플랫폼 이전 체크리스트: 도메인, SEO, 콘텐츠, 폼, 분석 데이터

웹 개발글: , Duolabs18분 읽기blogmodel-openai-gpt-5.5seotechnical-noteweb-developmentwebsite-migration

웹사이트 구축 플랫폼 선택 가이드 실전편 2/2
정보 확인 기준: 2026년 7월 29일

홈페이지 플랫폼 이전은 새 화면을 만드는 작업만이 아닙니다. 기존 URL과 검색 노출, 도메인과 회사 메일, 게시물과 이미지, 문의 폼, 분석 태그까지 함께 옮겨야 비로소 이전이 끝납니다.

화면은 정상인데 검색 유입이 줄거나, 대표 메일이 끊기거나, 문의가 저장되지 않는 문제는 대개 전환 전에 목록을 만들지 않았을 때 발생합니다. 이 글은 아임웹, WordPress, Webflow, Framer 같은 제작 도구에서 다른 플랫폼이나 맞춤 사이트로 이동할 때 사용할 수 있는 실전 체크리스트입니다.

1분 요약

단계 핵심 작업 완료 기준
1. 자산 조사 계정, 페이지, 데이터, 도메인과 외부 서비스 목록화 소유자·원본·이전 방법이 표에 기록됨
2. 백업·내보내기 콘텐츠, 파일, 폼, 회원과 설정 보존 새 환경과 별개인 복사본을 열어볼 수 있음
3. URL 설계 기존 URL과 새 URL의 일대일 대응표 작성 유지·리디렉션·삭제가 모든 URL에 지정됨
4. 사전 검수 스테이징에서 화면, 기능, SEO와 분석 시험 공개 차단 상태에서 핵심 시나리오를 통과함
5. 전환 DNS, 인증서, 리디렉션과 사이트 공개 웹과 회사 메일이 모두 정상 동작함
6. 검색 반영 Search Console, sitemap과 색인 상태 확인 기존 URL이 새 URL로 이동하고 오류를 추적함
7. 운영 관찰 폼, 전환, 404, 속도와 데이터 누락 확인 담당자와 복구 기준이 정해져 있음

이전은 복사가 아니라 대응 관계를 만드는 일이다

플랫폼마다 저장 방식이 다릅니다. 한쪽의 페이지가 다른 쪽에서는 CMS 항목이 될 수 있고, 기존 폼 제출 내역은 새 폼으로 자동 이동하지 않을 수 있습니다. 그래서 “무엇을 내보낼 수 있는가?”와 “새 시스템의 어디에 넣을 것인가?”를 함께 정해야 합니다.

먼저 이전 범위를 다음처럼 나눕니다.

자산 조사할 내용 놓쳤을 때 생기는 문제
페이지·게시물 제목, 본문, 작성일, 분류, 작성자 콘텐츠 누락, 날짜·분류 오류
이미지·파일 원본 파일, 대체 텍스트, 사용 페이지 깨진 이미지, 이전 플랫폼 URL 의존
SEO 정보 URL, 제목, 설명, canonical, 구조화 데이터 검색 순위 변동, 중복 페이지
폼·문의 필드, 수신자, 저장 위치, 자동 회신 문의 유실, 개인정보 처리 오류
회원·주문 계정, 동의, 상태, 이력, 비밀번호 로그인 실패, 거래 이력 누락
분석·광고 GA, GTM, 픽셀, 전환, 동의 도구 데이터 단절 또는 중복 집계
도메인·메일 등록기관, DNS, 인증서, MX·TXT 레코드 사이트나 회사 메일 중단
외부 연결 CRM, 채팅, 예약, 지도, 결제, 웹훅 업무 자동화 중단

1단계. 계정과 소유권부터 확인한다

이전 프로젝트가 막히는 흔한 이유는 기술보다 계정입니다. 도메인이 퇴사한 직원이나 제작사 명의로 등록되어 있거나, 분석 도구와 광고 계정의 관리자 권한이 없는 경우입니다.

착수할 때 다음 정보를 정리합니다.

  • 도메인 등록기관과 소유자, 갱신일, 로그인 복구 수단
  • 현재 플랫폼의 소유자와 관리자 계정
  • DNS를 관리하는 서비스와 현재 레코드 전체
  • Google Search Console, Analytics, Tag Manager 관리자
  • 광고 픽셀, 지도, 채팅, 예약과 폼 서비스 계정
  • 회사 메일 관리자와 메일 제공업체
  • API 키, 웹훅과 외부 자동화의 발급 주체

공유 계정 하나를 여러 사람이 사용하는 대신 회사 명의의 소유자 계정과 개인별 관리자 계정을 구분합니다. 비밀번호 자체를 이전 문서에 적기보다 권한과 안전한 전달 방법을 정하는 편이 좋습니다.

2단계. 내보내기 범위와 백업을 구분한다

플랫폼의 “내보내기” 버튼이 사이트 전체 백업을 의미하지는 않습니다.

WordPress의 기본 내보내기는 WXR 형식의 XML 파일에 글, 페이지, 사용자 정의 글 유형, 댓글, 사용자 정의 필드, 분류와 사용자 같은 콘텐츠를 담습니다. 그러나 테마, 플러그인, 설정, DB 전체와 업로드 파일을 모두 보존하는 완전한 사이트 백업은 아닙니다. WordPress 이전이라면 DB와 업로드 파일, 테마·플러그인을 별도로 백업하고 실제 복원도 시험해야 합니다.

Webflow는 지원되는 유료 Workspace에서 HTML, CSS, JavaScript와 자산을 내보낼 수 있지만, 공식 문서상 CMS·사용자 계정·전자상거래 데이터와 기능은 정적 코드 내보내기에 포함되지 않습니다. 폼 처리, 사이트 검색과 비밀번호 보호도 외부 호스팅에서 그대로 작동하지 않습니다. CMS는 CSV로 별도 이동할 수 있으며, 이미지와 파일 URL이 기존 사이트를 가리키는 경우 기존 프로젝트를 지우기 전에 원본 자산을 내려받아야 합니다.

아임웹, Framer와 다른 빌더도 페이지, 게시물, 회원, 주문, 폼 제출 내역과 파일의 내보내기 범위가 서로 다릅니다. 요금제나 권한에 따른 차이까지 현재 계정에서 직접 확인합니다.

백업 완료 기준

  • 원본 콘텐츠와 파일을 새 플랫폼 밖에도 보관한다.
  • CSV·XML·JSON 파일이 열리고 글자 인코딩이 정상인지 확인한다.
  • 이미지와 첨부 파일이 기존 호스팅 URL 없이도 존재한다.
  • 회원·주문·문의 데이터의 개인정보 보관 근거와 기간을 확인한다.
  • 내보낼 수 없는 데이터는 화면 캡처가 아니라 대체 이관 방법을 정한다.
  • 이전 후에도 법적·업무상 필요한 과거 기록을 조회할 방법이 있다.

3단계. 기존 URL과 새 URL을 일대일로 연결한다

검색엔진과 외부 사이트는 디자인이 아니라 URL을 통해 콘텐츠를 찾습니다. URL 구조가 바뀐다면 기존 주소마다 새 목적지를 정해야 합니다.

기존 URL                              새 URL                              처리
/service/web-development              /services/web-development            영구 리디렉션
/blog/old-platform-guide              /insights/platform-guide              영구 리디렉션
/event/2023-summer                    없음                                  404 또는 410

Google Search Central은 URL이 바뀌는 사이트 이전에서 기존 URL과 새 URL의 대응표를 만들고, 서버 측 영구 리디렉션을 설정하며, 새 sitemap을 제출하도록 안내합니다.

실무에서는 다음 원칙을 적용합니다.

  • 내용이 같은 페이지는 가장 가까운 새 URL로 일대일 리디렉션합니다.
  • 모든 기존 URL을 새 홈페이지 하나로 보내지 않습니다.
  • 여러 번 거치는 리디렉션 체인을 줄입니다.
  • 이동하지 않는 콘텐츠는 관련 없는 페이지로 보내지 말고 404 또는 410을 사용합니다.
  • 내부 링크, canonical, sitemap과 구조화 데이터는 최종 새 URL을 가리킵니다.
  • 광고, QR 코드, 프로필과 주요 외부 채널의 링크도 수정합니다.

기존 URL 목록은 sitemap만 보지 말고 Search Console, Analytics, 서버 로그, 광고 랜딩 URL과 실제 검색 결과를 함께 확인해야 누락을 줄일 수 있습니다.

4단계. 도메인을 바꾸기 전에 새 사이트를 검수한다

새 사이트는 임시 주소나 스테이징 환경에서 먼저 시험합니다. 다만 준비 중인 페이지가 검색에 노출되지 않도록 접근 제한이나 noindex를 사용하고, 공개 시점에 이 설정을 반드시 제거합니다.

화면과 콘텐츠

  • 데스크톱과 모바일에서 메뉴, 본문, 표와 이미지가 정상이다.
  • 제목, 본문, 작성일, 작성자와 분류가 원본과 맞는다.
  • 이미지 대체 텍스트와 파일 다운로드가 유지된다.
  • 맞춤 글꼴과 라이선스가 새 환경에서도 유효하다.
  • 주요 브라우저에서 레이아웃과 상호작용을 확인했다.

기능과 업무 흐름

  • 모든 문의 폼이 제출되고 담당자에게 도착한다.
  • 필수 입력, 오류 메시지, 자동 회신과 스팸 방지가 동작한다.
  • 예약, 로그인, 검색, 결제와 파일 업로드를 실제 흐름으로 시험했다.
  • CRM·메일·메신저·자동화 서비스에 데이터가 한 번만 전달된다.
  • 개인정보 동의 문구, 보존 기간과 삭제 절차가 새 흐름과 맞는다.

검색과 공유

  • 페이지마다 고유한 제목과 설명이 있다.
  • canonical이 스테이징 주소가 아닌 최종 공개 URL을 가리킨다.
  • robots.txt와 sitemap의 공개 설정을 확인했다.
  • 소셜 공유 이미지와 제목이 정상이다.
  • 구조화 데이터의 URL과 회사 정보가 최신이다.
  • 공개일에 noindex와 임시 접근 제한을 제거할 담당자가 정해졌다.

5단계. DNS를 바꿀 때 회사 메일을 함께 지킨다

도메인 전환은 홈페이지 주소만 바꾸는 작업이 아닙니다. DNS에는 사이트를 연결하는 A·AAAA·CNAME뿐 아니라 회사 메일을 위한 MX, 발신 인증을 위한 TXT 레코드가 함께 있을 수 있습니다.

전환 전에 현재 DNS 레코드 전체를 내보내거나 기록하고, 새 DNS 관리 서비스로 옮긴다면 웹과 관계없는 레코드도 빠짐없이 재현합니다. 특히 MX, SPF, DKIM과 DMARC 관련 TXT 레코드를 임의로 삭제하면 회사 메일 수신이나 발신 신뢰도에 문제가 생길 수 있습니다.

공개 직전에는 다음을 확인합니다.

  • 새 호스팅에서 사용자 도메인과 HTTPS 인증서가 준비되었는가?
  • 루트 도메인과 www 중 대표 주소가 정해졌는가?
  • 다른 주소는 대표 주소로 일관되게 이동하는가?
  • DNS 변경 권한과 복구할 기존 값이 준비되었는가?
  • 회사 메일 송수신 시험 계정과 담당자가 있는가?
  • 오래된 서버를 바로 종료하지 않고 전환 확인 기간을 두는가?

DNS 변경은 사용자 위치와 캐시 상태에 따라 반영 시점이 다를 수 있습니다. 잠시 동안 기존 사이트와 새 사이트에 모두 접근할 수 있다는 전제로 폼과 데이터 저장 위치를 관리해야 합니다.

6단계. Search Console과 검색 이전을 마무리한다

도메인이나 URL이 바뀌면 검색 순위가 잠시 변동할 수 있습니다. Google은 새 사이트의 크롤링과 색인 재처리에 시간이 필요하다고 설명합니다. 전환 직후의 변동만 보고 리디렉션을 되돌리기보다 오류와 색인 상태를 지속적으로 확인해야 합니다.

검색 이전 작업은 다음 순서로 진행합니다.

  1. 기존 사이트와 새 사이트의 Search Console 속성 소유권을 모두 확인합니다.
  2. 기존 URL에서 새 URL로 서버 측 영구 리디렉션을 적용합니다.
  3. 새 URL로 구성된 sitemap을 새 속성에 제출합니다.
  4. 중요한 페이지의 실제 URL 검사와 색인 가능 상태를 확인합니다.
  5. 404, 리디렉션 오류, 차단된 페이지와 트래픽 변화를 관찰합니다.

Search Console의 주소 변경 도구는 도메인이나 하위 도메인이 바뀌는 이전에 사용하며, 리디렉션을 적용한 다음 실행합니다. HTTP에서 HTTPS로만 바꾸거나 같은 도메인 안에서 경로만 변경할 때 사용하는 도구는 아닙니다.

7단계. 분석과 광고 데이터의 연결을 확인한다

분석 태그가 화면에 보인다고 전환 측정까지 정상인 것은 아닙니다. 새 사이트에서 페이지 주소, 버튼 구조와 폼 완료 방식이 바뀌면 기존 이벤트 규칙도 함께 수정해야 합니다.

  • Google Analytics 측정 ID와 도메인 설정
  • Google Tag Manager 컨테이너와 공개 버전
  • Google Ads·Meta 등 광고 전환과 리마케팅 픽셀
  • 문의 완료, 구매, 전화·메일 클릭 같은 핵심 이벤트
  • 쿠키·추적 동의 도구와 태그 실행 조건
  • 결제나 예약이 외부 도메인으로 이동할 때의 세션 연결
  • 내부 직원과 스테이징 트래픽 제외 규칙

기존 플랫폼 태그와 새 태그가 동시에 실행되면 방문과 전환이 두 번 집계될 수 있습니다. 브라우저 개발 도구와 각 분석 서비스의 실시간·디버그 기능을 이용해 이벤트 이름, 횟수와 파라미터를 확인합니다.

공개일 실행표

시점 확인할 작업
공개 전 최종 콘텐츠 동결, 백업, URL 표와 DNS 기존 값 보관
전환 직후 HTTPS, 대표 도메인, 주요 페이지와 영구 리디렉션 확인
1시간 이내 문의·로그인·결제·메일 송수신과 분석 이벤트 시험
당일 sitemap 제출, 중요 URL 검사, 404와 서버 오류 확인
1주 이내 검색 유입, 색인, 광고 전환과 폼 누락 비교
1개월 이내 남은 외부 링크, 리디렉션 체인과 이전 시스템 종료 여부 검토

복구 기준도 공개 전에 정한다

문제가 생긴 뒤 “원래대로 돌릴까?”를 논의하면 판단이 늦어집니다. 어떤 문제가 발생하면 즉시 수정하고, 어떤 문제에서는 이전 환경으로 트래픽을 되돌릴지 미리 정합니다.

예를 들어 결제·로그인 전체 장애, 문의 데이터 유실, 회사 메일 중단은 즉시 대응할 기준이 될 수 있습니다. 반면 일부 이미지 누락이나 문구 오류는 새 사이트에서 고치는 편이 빠를 수 있습니다.

복구 계획에는 다음이 포함되어야 합니다.

  • 기존 DNS 값과 이전 호스팅의 유지 기간
  • 전환 중 새로 입력된 문의·주문 데이터를 합칠 방법
  • 되돌림을 결정하고 실행할 담당자
  • 사용자와 내부 운영자에게 장애를 알리는 방법
  • 오류 수정 후 다시 전환할 검증 절차

전체 체크리스트

  • 도메인, 플랫폼, 분석과 외부 서비스의 소유권을 확보했다.
  • 페이지·게시물·이미지·파일·폼·회원·주문의 이전 범위를 정했다.
  • 플랫폼 내보내기와 완전한 백업의 차이를 확인했다.
  • 기존 URL마다 유지·리디렉션·삭제 처리를 지정했다.
  • 스테이징에서 모바일, 폼, 로그인, 결제와 외부 연동을 시험했다.
  • canonical, robots, sitemap과 noindex 제거를 확인했다.
  • DNS의 웹·메일·인증 관련 레코드를 모두 보존했다.
  • Search Console의 기존·새 속성과 검색 이전 절차를 준비했다.
  • 분석·광고 이벤트가 누락되거나 중복되지 않는지 확인했다.
  • 공개일 담당자, 모니터링 항목과 복구 기준을 정했다.

정리

홈페이지 이전의 품질은 새 디자인보다 기존 자산을 얼마나 정확히 연결했는지에서 결정됩니다. 콘텐츠와 파일을 보존하고, 모든 기존 URL의 목적지를 정하며, 도메인·메일·폼·검색·분석을 하나의 전환 계획으로 관리해야 합니다.

특히 내보내기 파일을 전체 백업으로 오해하거나, DNS에서 회사 메일 레코드를 빠뜨리거나, 모든 기존 URL을 새 홈페이지로 보내는 실수를 피해야 합니다. 공개 전에 체크리스트와 복구 기준을 만들면 전환 당일의 위험을 크게 줄일 수 있습니다.

시리즈 이어 읽기

공식 자료

함께 읽기