WordPress 도메인 변경: 리디렉션, 검색 신호, 이메일 함께 점검하기

브랜드 이름을 바꾸고 새 도메인을 등록했더라도 다음 단계가 곧바로 WordPress 사이트 주소를 수정하는 일은 아닙니다. 글에 담긴 이미지, 오래된 소셜 게시물, 검색 결과, 양식 알림, 업무용 이메일이 여전히 이전 이름을 가리킬 수 있습니다. 모든 예전 진입점에 명확한 목적지를 정하는 대응표가 필요합니다.

예를 들어 공예 작업실이 더 기억하기 쉬운 도메인을 쓰면서 기존 강좌 글은 유지한다고 가정해 봅시다. 실질적인 목표는 독자가 예전 글 링크를 눌렀을 때 같은 새 글로 가고, 편집자는 로그인해 계속 일하며, 고객이 예전 메일 주소로 보낸 문의도 누군가 받는 것입니다. 아래 절차는 이 세 경로를 기준으로 전환을 준비합니다.

이전 URL을 정리하고 페이지마다 새 목적지 정하기

사이트맵, 글 목록, 자주 쓰는 탐색 메뉴, 실제 방문자가 있는 페이지를 바탕으로 목록을 만들고 이미지와 다운로드 파일도 포함합니다. 도메인만 바꾼다면 기존 경로를 우선 유지하면 대응 관계를 쉽게 확인할 수 있습니다. 카테고리를 조정하거나 글을 삭제한다면 항목별 새 목적지와 처리 이유를 기록하세요.

예를 들어 기존 /workshop/은 새 사이트의 강좌 소개로 보내야 하며 모든 이전 글과 함께 첫 화면으로 보내면 안 됩니다. 여러 글을 합친다면 그 정보를 실제로 담은 새 페이지로 리디렉션할 수 있습니다. 삭제했고 합당한 대체 내용도 없는 페이지는 적절한 찾을 수 없음 응답을 반환해야 합니다. 독자가 원래 찾던 정보를 발견할 수 있는지가 대응표의 기준입니다.

1. 글, 페이지, 미디어, 다운로드 파일, 중요한 외부 링크의 이전 URL을 정리합니다.
2. 각 항목에 새 URL을 지정하고 유지·통합·삭제의 이유를 적습니다.
3. 첫 화면, 인기 있는 개별 페이지, 중국어 문자로 된 경로, 쿼리 매개변수가 있는 링크를 표본 점검합니다.

백업한 뒤 데이터베이스 URL 치환을 미리 보기

WordPress 사이트 주소는 설정의 일부일 뿐입니다. 글 내용, 플러그인 옵션, 페이지 빌더는 절대 URL을 별도로 저장할 수 있습니다. 파일과 데이터베이스를 먼저 백업하고 접근을 제한한 복사본에서 WordPress 데이터 형식을 처리할 수 있는 이전 도구를 사용하세요. SQL 덤프 전체의 도메인을 텍스트 편집기로 단순 치환하면 직렬화된 데이터 구조가 손상될 수 있습니다.

기술 담당자가 WP-CLI를 쓴다면 공식 search-replace 명령은 직렬화된 데이터를 처리하고, 쓰지 않고 예상 내용을 보고하는 --dry-run 옵션도 제공합니다. 대상 테이블 범위와 이전·새 URL을 대조한 뒤 예상 변경 건수를 확인하세요. 특히 하나의 데이터베이스에 다른 사이트도 있으면 모든 테이블을 무조건 포함하지 마세요.

치환 범위는 변경이 필요한 사이트 URL이어야 합니다. 도메인만 적힌 문자열은 이메일 주소, 과거 기록, 외부 서비스 설정에도 들어갈 수 있어 무분별하게 모두 바꾸면 안 됩니다. 작업 후에는 사용자 정의 테마 파일, CSS, 메뉴, 플러그인 캐시를 확인해 실제 페이지가 더는 기존 사이트에서 리소스를 가져오지 않도록 합니다.

새 도메인과 이전 도메인 모두 HTTPS 유지하기

새 도메인에는 올바른 DNS 설정과 유효한 인증서가 필요합니다. 이전 도메인에서 HTTPS를 사용했다면 리디렉션을 유지하는 동안 그쪽도 유효하게 연결되어야 합니다. 브라우저는 리디렉션 응답을 받기 전에 보안 연결을 맺습니다. 이전 인증서가 만료되면 독자가 새 사이트에 도착하기 전에 경고를 볼 수 있습니다.

호스팅 업체나 사이트 관리자가 검증한 대응표를 바탕으로 영구 리디렉션을 설정한 뒤 이전 URL의 응답과 최종 목적지를 시험합니다. Google은 301이나 308 같은 서버 측 영구 리디렉션을 권장하며 가능한 한 최종 페이지에 직접 도달하도록 안내합니다. 최상위 도메인, www, HTTP, HTTPS 규칙이 서로 되돌리는 순환을 피하세요.

1. 새 도메인의 최상위 도메인과 www에 일관된 대표 URL 정책을 적용합니다.
2. 여러 유형의 이전 URL이 의도한 새 페이지에 도착하는지 확인하고 단순히 이동 여부만 보지 않습니다.
3. 이미지, 다운로드, 양식에서 순환, 누락된 경로, 보안 경고가 없는지 확인합니다.

검색 신호와 직접 관리할 수 있는 링크 업데이트하기

새 페이지의 canonical, 사이트맵, 내부 링크는 새 URL을 가리켜야 합니다. 공개 전에 테스트 단계에서만 쓰던 색인 차단 설정을 해제하세요. Search Console 주소 변경 도구에는 적용 조건이 있으며, 실제로 도메인 간 이동할 때는 공식 요구에 따라 이전 사이트와 새 사이트를 모두 인증하고 도구의 검사를 완료해야 합니다.

도구가 리디렉션을 대신 만들어 주지는 않으며 검색 결과가 즉시 모두 바뀌지도 않습니다. Google은 리디렉션을 되도록 오래, 일반적으로 최소 1년 유지하라고 권장합니다. 여전히 쓰이는 명함, 북마크, 외부 링크에는 더 긴 지원이 필요할 수 있습니다. 사이트 이전 중 일시적인 변동이 있을 수 있으므로 며칠 안에 예전 순위가 돌아온다고 약속하지 마세요.

직접 수정할 수 있는 진입점도 따로 일정에 넣으세요. 소셜 프로필, 뉴스레터 바닥글, 사업자 정보, 협력 사이트, 문서의 QR Code 등이 있습니다. 클릭이 많거나 거래에 영향을 주는 항목을 먼저 바꾸고 담당자와 완료일을 남깁니다. 이전 URL이 리디렉션되더라도 새 URL로 직접 연결하면 독자의 대기와 추후 관리를 줄일 수 있습니다.

이메일을 별도 검증 서비스로 취급하기

웹사이트 리디렉션이 old.example 메일함을 new.example 메일함으로 자동 변경하지는 않습니다. 이메일 서비스에 새 도메인 추가 방법과 계정 또는 별칭 규칙을 확인한 뒤 해당 서비스가 요구하는 MX 및 발신자 인증을 설정합니다. 예를 들어 Google Workspace에는 기본 도메인을 바꾸고 이전 도메인 별칭을 유지하는 별도 절차가 있으며 WordPress 관리자 설정으로 대신할 수 없습니다.

일상적으로 쓰는 메일함, 양식 발신자, 회신 주소, 계정 복구 주소를 나열합니다. 이전 주소로 계속 수신할 방법을 마련하고 고객에게 새 주소를 알린 다음 외부 메일함에서 두 주소로 각각 보내 보세요. 수신, 회신, 발신자 표시를 확인합니다. 메일 전달을 설정했다면 저장된 설정만 확인하지 말고 목적지 메일함에 실제로 도착하는지 검증하세요.

인계표 없이 같은 날 직원 전원의 로그인 계정을 바꾸지 마세요. 일부 외부 서비스는 이메일을 사용자 식별자로 쓰므로 이름이 바뀐 뒤 재인증이나 관리자 조정이 필요할 수 있습니다. 이전 주소에 의존하는 사람을 먼저 확인해 웹사이트는 옮겼는데 관리 계정에 로그인하지 못하는 일을 방지합니다.

실제 문제를 통해 전환 결과 추적하기

공개 후에는 실패한 URL, 양식 알림, 새·이전 메일함을 정기적으로 확인하고 각 문제를 URL 대응표에 연결합니다. 특정 글의 방문이 줄었다면 다른 원인을 논의하기 전에 이전 URL이 올바른 새 페이지로 이동하는지, 그 페이지가 색인될 수 있는지, 이미지와 내용이 온전한지 먼저 확인하세요.

이전 도메인의 갱신과 인증서 관리, 리디렉션 서비스의 책임자를 유지합니다. 되돌려야 한다면 새 사이트에 추가된 콘텐츠와 문의를 먼저 보존하고 어떤 설정을 복구할지 결정하세요. 오래된 백업으로 새 데이터를 모두 덮어쓰면 안 됩니다. 전환 기록, 계정 진입점, 검증 결과를 한 문서에 모아 다음 관리자가 아직 중단하면 안 되는 이전 서비스를 알 수 있게 합니다.

URL은 그대로 두고 호스트만 이전하기

웹사이트 백업과 복원 검증하기

도메인과 호스팅 갱신 관리하기

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