워드프레스 이전 후 로그인하면 이전 도메인으로 이동하는 이유와 해결 순서
사이트를 새 서버나 새 도메인으로 이전한 뒤 홈페이지는 정상적으로 열리는데 /wp-admin/ 로그인 과정에서 이전 도메인으로 이동하는 경우가 있습니다. 이 현상은 단순히 파일 복사가 덜 된 문제가 아닙니다. 워드프레스 데이터베이스에 저장된 URL, wp-config.php의 강제 설정, 웹 서버와 CDN의 리디렉션, 브라우저 쿠키가 각각 영향을 줄 수 있습니다.
문제를 빠르게 해결하려면 여러 설정을 한꺼번에 바꾸기보다 브라우저에서 시작해 워드프레스, 데이터베이스, 서버 계층 순서로 원인을 좁혀 가는 편이 안전합니다.
워드프레스가 이전 도메인을 기억하는 위치
워드프레스의 주소 정보는 파일에만 저장되지 않습니다. 일반적인 단일 사이트에서는 데이터베이스의 옵션 테이블에 home과 siteurl 값이 들어 있습니다. 기본 설치라면 wp_options라는 이름을 사용하는 경우가 많지만, 실제 테이블 접두사는 사이트마다 다를 수 있습니다. 따라서 테이블 이름을 무조건 wp_options로 가정해서는 안 됩니다.
siteurl은 워드프레스 코어 파일이 설치된 주소와 관련된 값이고, home은 방문자가 접속하는 사이트의 기본 주소입니다. 일반적인 설치에서는 두 값이 모두 다음처럼 동일합니다.
home = https://new-example.com
siteurl = https://new-example.com
다만 워드프레스 코어를 별도 디렉터리에 설치했거나 특수한 서버 구성을 사용한다면 두 값이 달라질 수 있습니다. 이 경우 현재 설치 구조를 확인하지 않고 무조건 같은 주소로 덮어쓰면 오히려 접속 문제가 생길 수 있습니다.
관리자 화면에 접속할 수 있다면 설정 → 일반에서 워드프레스 주소와 사이트 주소를 확인하면 됩니다. 하지만 로그인 버튼을 누르는 순간 이전 도메인으로 이동하는 상황이라면 관리자 화면 대신 데이터베이스나 설정 파일을 확인해야 합니다.
먼저 확인할 주소 설정과 wp-config.php
가장 먼저 할 일은 데이터베이스의 home, siteurl 값이 현재 도메인을 가리키는지 확인하는 것입니다. 이전 주소인 https://old-example.com이 남아 있다면 새 주소인 https://new-example.com으로 변경해야 할 가능성이 큽니다.
직접 데이터베이스를 수정하기 전에는 백업을 준비해야 합니다. 운영 중인 사이트에서는 주소 하나를 잘못 입력해 관리자와 프런트엔드 모두 접근할 수 없게 될 수 있습니다. 수정 후에는 브라우저 캐시를 배제한 상태에서 다시 로그인해 결과를 확인합니다.
데이터베이스 값이 이미 정상인데도 같은 문제가 계속되면 wp-config.php를 확인해야 합니다. 이 파일에 다음과 같은 상수가 정의되어 있을 수 있습니다.
define( 'WP_HOME', 'https://old-example.com' );
define( 'WP_SITEURL', 'https://old-example.com' );이 설정은 데이터베이스보다 우선해 워드프레스 주소를 강제로 지정할 수 있습니다. 이전 서버에서 사용하던 설정을 그대로 복사했다면 데이터베이스를 새 주소로 바꿔도 워드프레스가 계속 과거 주소를 사용할 수 있습니다. 현재 구조에 맞게 주소를 수정하거나, 해당 상수가 정말 필요한지 검토해야 합니다.
데이터베이스 전체 URL은 안전한 방식으로 변경해야 한다
home과 siteurl만 수정해도 로그인 문제는 해결될 수 있지만, 사이트 이전이 완전히 끝났다고 보기는 어렵습니다. 게시물 본문, 위젯, 테마 옵션, 플러그인 설정, 페이지 빌더, 업로드 이미지 주소 등에 이전 도메인이 남아 있을 수 있기 때문입니다.
예를 들어 이미지 주소가 다음처럼 저장되어 있다면 새 사이트에서 일부 이미지가 이전 서버에서 로드될 수 있습니다.
https://old-example.com/wp-content/uploads/...
이전 URL을 새 URL로 바꿀 때 데이터베이스 전체에 단순한 SQL REPLACE()를 실행하는 방식은 주의해야 합니다. 워드프레스 데이터에는 PHP 직렬화 데이터가 포함될 수 있는데, 이 데이터는 문자열과 함께 문자열 길이 정보도 저장합니다. 기존 도메인과 새 도메인의 길이가 다르면 문자만 치환했을 때 길이 정보가 어긋나 설정이나 위젯 데이터가 손상될 수 있습니다.
SSH와 WP-CLI를 사용할 수 있다면 wp search-replace를 검토할 수 있습니다. 예를 들어 실제 변경 전에는 다음처럼 미리 결과를 확인할 수 있습니다.
wp search-replace 'https://old-example.com' 'https://new-example.com' --dry-run--dry-run은 실제 데이터베이스를 바꾸지 않고 변경 대상과 범위를 확인하는 옵션입니다. 결과가 예상과 일치할 때 실제 작업을 진행하고, 실행 전에는 데이터베이스 백업을 별도로 보관하는 것이 좋습니다. 멀티사이트나 도메인 매핑을 사용하는 사이트는 단일 사이트와 구조가 다르므로 일반 명령을 그대로 실행하지 말고 네트워크 구성을 먼저 파악해야 합니다.
또 하나 놓치기 쉬운 값이 guid입니다. 게시물의 GUID에 이전 도메인이 표시되더라도 GUID를 일반 URL처럼 일괄 변경해서는 안 됩니다. GUID는 콘텐츠를 식별하기 위한 값이므로 도메인 이전만을 이유로 무조건 수정하는 대상이 아닙니다.
워드프레스 밖의 리디렉션과 캐시 점검
데이터베이스와 wp-config.php가 모두 정상이라면 리디렉션이 워드프레스 외부에서 발생하는지 확인해야 합니다. 점검 범위는 다음 흐름으로 생각하면 편합니다.
브라우저 → CDN 또는 프록시 → 웹 서버 → 워드프레스 → 데이터베이스
| 계층 | 이전 도메인이 남는 자리 | 확인 방법 |
|---|---|---|
| 브라우저 | 301 캐시, 이전 로그인 쿠키 | 시크릿 창·다른 브라우저에서 재현되는지 |
| CDN·프록시 | 페이지 규칙, 저장된 301 응답 | 리디렉션 규칙과 캐시 삭제 |
| 웹 서버 | .htaccess 규칙, Nginx return 301, 호스팅 포워딩 |
설정 파일과 호스팅 관리 화면 |
| 워드프레스 | wp-config.php의 WP_HOME·WP_SITEURL |
파일 직접 확인(데이터베이스보다 우선) |
| 데이터베이스 | 옵션의 home·siteurl, 본문·설정에 박힌 URL |
접두사 확인 후 값 조회 |
웹 서버 설정
Apache 서버라면 .htaccess에 이전 도메인으로 보내는 규칙이 남아 있을 수 있습니다. Nginx라면 서버 블록 설정에 return 301 또는 유사한 리디렉션이 있는지 확인해야 합니다. 호스팅 관리 화면에서 도메인 포워딩을 별도로 설정한 경우도 있습니다.
CDN과 리버스 프록시
Cloudflare와 같은 CDN이나 리버스 프록시를 사용한다면 페이지 규칙, 리디렉션 규칙, 캐시 설정도 살펴봐야 합니다. 서버가 새 주소를 정상적으로 반환해도 CDN이 과거에 저장한 301 응답을 제공하면 브라우저에서는 이전 도메인으로 계속 이동하는 것처럼 보일 수 있습니다.
브라우저 캐시
브라우저의 301 캐시도 변수입니다. 시크릿 창이나 다른 브라우저에서 같은 주소를 열어 보세요. 여러 환경에서 동일한 결과가 나오면 브라우저보다는 서버, CDN 또는 워드프레스 설정을 의심할 가능성이 높습니다. 캐시를 삭제할 때도 워드프레스 캐시, 서버 캐시, CDN 캐시를 구분해 확인해야 합니다.
로그인에서만 문제가 생길 때 확인할 항목
일반 페이지는 새 도메인에서 열리는데 로그인 과정에서만 문제가 발생한다면 쿠키와 인증 설정도 확인할 필요가 있습니다. 도메인 이전 전의 로그인 쿠키가 브라우저에 남아 있거나, 사용자 정의 쿠키 도메인이 과거 주소를 기준으로 지정되어 있을 수 있습니다.
먼저 새 도메인의 쿠키를 삭제하고 시크릿 창에서 다시 로그인합니다. wp-config.php에 쿠키 도메인과 관련된 사용자 정의 설정을 직접 추가한 적이 있다면 현재 도메인과 일치하는지도 확인합니다. 원인을 모르는 상태에서 인터넷에서 찾은 쿠키 관련 코드를 새로 추가하는 것은 피하는 편이 좋습니다. 기존 문제를 해결하지 못한 채 인증 오류를 더 복잡하게 만들 수 있습니다.
HTTP와 HTTPS 설정이 서로 어긋난 경우에는 이전 도메인 이동이 아니라 무한 리디렉션으로 나타나기도 합니다. 데이터베이스는 https://new-example.com을 사용하지만 프록시나 웹 서버가 워드프레스에 요청을 HTTP로 전달하면 워드프레스와 서버가 프로토콜을 다르게 판단할 수 있습니다. 이때 Too Many Redirects 오류가 발생할 수 있으므로 HTTPS 종료 지점, 프록시 전달 설정, 웹 서버 규칙, 워드프레스 URL을 함께 확인해야 합니다.
DNS 변경과 사이트 이전 검증 순서
도메인의 DNS를 새 서버로 변경한 직후에는 모든 사용자가 같은 서버에 접속하지 않을 수 있습니다. DNS 캐시와 TTL의 영향으로 어떤 환경은 새 서버를, 다른 환경은 이전 서버를 바라보는 시간이 생길 수 있습니다. 이 상태에서 설정을 수정하면 실제로 어느 서버를 변경하고 있는지 혼동하기 쉽습니다. 현재 도메인이 어느 서버의 IP를 가리키는지 먼저 확인하는 것이 좋습니다.
새 홈페이지가 한 번 열렸다는 이유로 이전 서버를 바로 삭제해서도 안 됩니다. 관리자 로그인뿐 아니라 게시물과 페이지의 내부 링크, 이미지, 테마와 플러그인 기능, 문의 양식, 예약 작업, 이메일 발송을 확인해야 합니다. 쇼핑몰이라면 주문과 결제까지 별도로 테스트해야 합니다. 문제가 발생했을 때 이전 파일이나 데이터베이스가 필요할 수 있으므로 검증과 백업이 끝날 때까지 기존 환경을 유지하는 편이 안전합니다.
도메인 자체를 변경한 경우에는 기존 주소의 처리도 정해야 합니다. 검색엔진과 기존 방문자를 새 주소로 보내려면 영구 이동에 301 리디렉션을 사용할 수 있습니다. 이때 모든 기존 URL을 새 홈페이지 하나로 보내기보다, 가능한 경우 기존 페이지와 대응하는 새 페이지로 연결하는 것이 적절합니다. 예를 들어 old-example.com/wordpress-backup/를 new-example.com/wordpress-backup/로 보내는 방식입니다.
원인을 좁혀 가는 실제 점검 순서
한 번에 모든 설정을 바꾸지 말고 다음 순서로 확인하면 변경 이력을 추적하기 쉽습니다.
- 시크릿 창이나 다른 브라우저에서 같은 리디렉션이 발생하는지 확인합니다.
- 데이터베이스의
home,siteurl과 테이블 접두사를 확인합니다. wp-config.php의WP_HOME,WP_SITEURL, 쿠키 관련 사용자 정의 설정을 살펴봅니다.- 이전 URL이 게시물·플러그인·테마 설정에 남아 있는지 확인하고, 필요하면 백업 후 직렬화 데이터를 처리할 수 있는 도구를 사용합니다.
- 워드프레스·서버·CDN 캐시를 각각 비웁니다.
.htaccess, Nginx 설정, 호스팅 포워딩 규칙에 과거 도메인이 남았는지 확인합니다.- HTTPS와 프록시 설정이 같은 프로토콜을 기준으로 동작하는지 점검합니다.
- 마지막으로 쿠키를 삭제하고 새 도메인에서 관리자 로그인과 주요 기능을 다시 테스트합니다.
이 순서는 단순한 도메인 값 오류와 서버 리디렉션을 구분하는 데 유용합니다. 멀티사이트라면 네트워크 주소와 개별 사이트 주소가 여러 곳에 저장될 수 있으므로, 단일 사이트용 일괄 치환을 바로 적용하지 않는 것이 안전합니다.
