WordPress 이전 후 점검: 검색 트래픽, 기존 호스트, 갱신 정리

새 사이트가 열리고 이전 도구도 완료라고 표시하면 기존 호스트를 바로 취소하고 싶어집니다. 그러나 기존 환경은 여전히 메일, DNS, 리디렉션, 다운로드 파일을 제공할 수 있습니다. 새 사이트도 첫 화면만 점검했을 뿐 양식 알림과 최신 데이터는 확인하지 않았을 수 있습니다. 이전을 마무리하려면 이런 남은 의존 관계를 하나씩 정리해야 합니다.

마무리 문서를 인계 기록으로 생각하세요. 어떤 서비스를 옮겼는지, 누가 검증했는지, 무엇을 유지해야 하는지, 언제 비용 지불을 멈출 수 있는지 적습니다. 이 글은 전환 이후부터 시작하며 파일 복사 절차를 반복하지 않습니다. 관찰할 수 있는 증거를 마련해 기존 서비스를 안전하게 종료하고 새 사이트를 계속 돌볼 담당자도 정합니다.

전환 시각과 비교 기준 먼저 저장하기

실제 전환 날짜, 시간대, 대표 URL, 기존·새 호스트, 변경 범위를 기록합니다. 호스트만 바꾸었나요, 아니면 도메인, 화면 구성, 양식 서비스도 바꾸었나요? 범위에 따라 살펴야 할 결과가 다릅니다. 기준이 없으면 며칠 뒤 트래픽이 변해도 그때 어떤 설정을 함께 바꾸었는지 파악하기 어렵습니다.

이전 전 주요 페이지 목록, 중요 기능의 테스트 결과, 확보할 수 있는 트래픽과 오류 기록을 보관합니다. 같은 시간대와 조건으로 비교하세요. 평일과 주말, 행사일과 평소에는 원래 차이가 있습니다. 분석 도구나 태그 설정도 함께 바꿨다면 적어 두어 측정 방식의 변화를 실제 방문자 감소로 오해하지 않게 합니다.

1. 전환 시각, URL, 함께 바꾼 모든 항목을 기록합니다.
2. 첫 화면, 인기 글, 양식, 다운로드 페이지의 검증 기준을 보관합니다.
3. 매일 결과를 살필 담당자와 핵심 기능 실패 시 연락처를 정합니다.

트래픽 그래프보다 기능을 먼저 확인하기

방문자가 실제로 하는 일부터 점검합니다. 글 열기, 사이트 검색, 첨부 파일 다운로드, 양식 제출, 필요한 로그인 등이 있습니다. 익숙한 브라우저만 보지 말고 휴대전화와 다른 네트워크에서도 확인합니다. 각 테스트의 URL, 시각, 동작, 결과를 기록하고 실패하면 재현 가능한 절차를 남깁니다.

기존 호스트와 새 호스트의 로그를 비교해 운영 트래픽이 점차 새 환경에서 제공되는지 확인합니다. 기존 사이트에도 요청이 오면 일반 방문자, 정기 콜백, 갱신하지 않은 다운로드 링크 등 출처를 구분합니다. 요청 총수만으로 종료 여부를 결정할 수 없습니다. 특히 기존 호스트가 웹사이트 밖의 서비스도 맡을 때는 더욱 그렇습니다.

기존 사이트가 마지막에 받은 댓글이나 양식처럼 데이터가 양쪽에 나뉘었는지 확인합니다. 이를 저장하고 처리한 뒤 기존 사이트가 불필요한 새 데이터를 받지 않게 합니다. 운영 중인 새 사이트에 기존 데이터베이스를 그대로 덮어쓰지 마세요. 전환 후 새로 생긴 내용이 지워질 수 있습니다. 데이터 유형에 맞춰 병합해야 합니다.

검색 보고서로 문제를 찾되 성급히 단정하지 않기

Search Console 검색 실적에서 페이지, 검색어, 기기, 날짜별 클릭과 노출을 살펴볼 수 있습니다. 먼저 같은 중요 페이지 묶음을 비교해 사이트 전체 변화인지 일부 글의 하락인지 구분합니다. 도메인도 변경했다면 새 사이트에 쌓이기 시작한 수치만 보지 말고 기존·새 사이트의 자료를 함께 보세요. 최신 자료는 아직 집계 중일 수 있어 한 시간만으로 결론을 낼 수 없습니다.

색인 보고서의 “색인되지 않음”이 항상 오류는 아닙니다. 삭제한 페이지, 합당한 중복 URL, 의도적으로 공개하지 않은 콘텐츠에는 정당한 이유가 있을 수 있습니다. 정말 공개되어야 할 중요 URL은 URL 검사 도구로 상태를 확인하고 테스트용 noindex, 잘못된 canonical, 동작하지 않는 리디렉션이 남았는지 살펴보세요.

예를 들어 많이 읽히던 수공예 강좌의 트래픽이 갑자기 떨어졌다면 예전 링크를 직접 열어 올바른 새 글로 가는지 확인합니다. 이어서 글 내용, 이미지, 색인 가능 상태를 확인하세요. 기술적인 경로가 정상이라면 검색어와 비교 기간의 차이를 살펴봅니다. 원인을 좁히는 절차이지 시기가 가깝다는 이유만으로 호스트 변경이 검색 순위를 바꿨다고 단정할 수는 없습니다.

새 환경만의 백업과 담당자 정하기

이전 전 백업은 기존 환경의 한 시점을 나타냅니다. 새 사이트가 가동된 뒤에는 자체 백업 일정, 별도 장소의 보관, 복원 방법이 필요합니다. 새 환경 백업을 먼저 수동으로 만들고 전체 데이터를 가져올 수 있는지 확인한 다음 정기 일정이 예상대로 실행되는지 살펴보세요. 여전히 기존 호스트에 백업하면 서비스 종료와 함께 복구 경로도 잃을 수 있습니다.

필요한 이전 전 복사본, 전환 기록, 설정 차이를 보관하고 파일명에 환경과 시각을 표시합니다. 각 백업의 용도와 보존 담당자를 정해 구분할 수 없는 압축 파일만 쌓지 마세요. 개인정보가 있는 복사본은 접근을 제한하고 내부 보존 기간이 지나면 정해진 절차에 따라 처리합니다.

인계받는 사람은 최소한 로그인 주소, 장애 연락처, 새 백업 위치, 업데이트 시간대를 알아야 합니다. 플러그인 라이선스, 양식 발신 메일, 예약 작업의 담당자도 분명히 적습니다. 이전 당일 작업자만 설정을 안다면 사이트가 잘 돌아가도 유지 관리 인계는 끝나지 않았습니다.

이전 서비스를 항목별로 중단할 수 있는지 판단하기

기존 계정의 호스팅, 메일, DNS, 도메인, 인증서, CDN, 리디렉션을 표로 만들어 각각 “이전 완료”, “계속 사용”, “확인 필요”라고 표시합니다. 호스트 변경이 도메인 갱신 중단을 뜻하지는 않습니다. 도메인까지 바꿨다면 이전 도메인에서 링크 리디렉션과 메일 수신을 계속해야 할 수 있으므로 기존 계정 전체를 한 가지 취소 비용으로 다루지 마세요.

“옮긴 뒤 며칠이면 삭제 가능하다”는 공통 답은 없습니다. 종료 전 핵심 기능이 안정적인지, 이전 환경에 필요한 요청이나 데이터가 더는 없는지, 새 백업을 사용할 수 있는지, 의존 서비스의 목적지가 모두 마련되었는지 확인합니다. 해결되지 않은 항목에는 다음 점검일과 담당자를 정해 너무 이른 삭제와 무기한 방치를 모두 피합니다.

서비스 제공업체에 갱신 중단, 웹사이트 삭제, 요금제 삭제, 환불 요청이 각각 어떤 결과를 내는지 먼저 문의하세요. 이 글의 확인 시점에 따른 Hostinger 공식 안내에서는 자동 갱신을 꺼도 기간이 끝날 때까지 서비스가 유지됩니다. 반면 환불 자격이 있고 환불이 처리되면 서비스가 종료됩니다. 두 버튼을 같은 청구 정리 동작으로 생각하면 안 됩니다.

청구 내역을 확인하고 마무리 증거 남기기

실제 종료 전 필요한 사이트 파일, 데이터베이스, 메일을 다시 내려받고 유일한 백업이 곧 만료될 계정에만 있지 않은지 확인합니다. Hostinger의 사이트 삭제 안내도 자료를 먼저 저장하라고 하며 관련 이메일 삭제 여부를 선택할 수 있게 합니다. 오래된 안내의 버튼 위치나 옵션을 그대로 따르지 말고 현재 화면을 항목별로 읽어 보세요.

작업 후 서비스명, 처리 날짜, 확인 메시지, 마지막 사용 가능일을 저장합니다. 청구 화면에 자동 갱신이 꺼져 있다고 표시되는 것과 이번 기간의 요금을 모두 냈는지는 별개입니다. 결제 항목과 추가 청구되는 부가 서비스를 확인하세요. 웹사이트를 쓰지 않는다고 모든 청구가 끝난 것은 아닙니다.

마무리 문서 끝에는 짧은 결과를 남깁니다. 새 환경의 핵심 기능 통과, 유지해야 하는 이전 항목과 이유, 종료한 서비스, 새 백업, 유지 관리 담당자를 적습니다. 미완료 항목에는 다음 단계와 검증 조건을 명시합니다. 그러면 나중에 다시 호스트를 바꾸거나 담당자가 바뀌거나 청구서를 확인할 때 같은 기록에서 이어 갈 수 있습니다.

URL을 유지하면서 호스트 이전하기

도메인 변경 시 검색과 메일 인계하기

새 환경 백업 방법 만들기

• 튜토리얼
• 앱·소프트웨어
• 웹사이트·이커머스
• WordPress