워드프레스가 /wp에 설치됐을 때: WP_HOME과 WP_SITEURL 설정 방법

워드프레스 파일은 /wp 폴더에 두면서 방문자에게는 https://example.com으로 사이트를 보여줄 수 있습니다. 이때 공개 주소와 워드프레스 본체 주소는 서로 다릅니다. 두 설정을 무조건 같은 값으로 맞추거나 모든 주소에서 /wp를 지우면 오히려 관리자나 이미지 경로가 깨질 수 있습니다.

이 글은 본체가 이미 하위 폴더에 설치된 단일 사이트의 주소와 진입 파일을 연결하는 방법입니다. 워드프레스 파일을 루트로 전부 옮기는 이전 작업과는 범위가 다릅니다.

실제 사례: 본체와 공개 진입 파일을 따로 둔 구조

2026년 4월에 완료한 작업 기록에서는 WordPress 본체가 /wp에 설치돼 있고 공개 루트의 index.php가 별도로 있었습니다. WP_HOME은 도메인 루트, WP_SITEURL은 도메인의 /wp 주소로 구분했으며, 루트 index.php에서 /wp/wp-blog-header.php를 불러오도록 수정한 코드가 완료 메시지에 남아 있습니다.

1. URL을 바꾸기 전에 실제 폴더부터 확인합니다

호스팅 파일 관리자나 SFTP에서 해당 도메인의 문서 루트를 확인합니다. 도메인이 연결된 폴더와 로그인 직후 보이는 기본 폴더가 같다고 가정하지 마세요. 다음은 이 글에서 사용하는 단순화한 구조입니다.

문서 루트/
├─ index.php  ← 공개 진입
└─ wp/
   ├─ index.php  ← 유지
   ├─ wp-blog-header.php
   ├─ wp-config.php  ← 설정
   ├─ wp-admin/
   ├─ wp-includes/
   └─ wp-content/

• 실제 폴더 이름이 wp인지, 그 안에 wp-blog-header.php와 wp-admin이 있는지 확인합니다. 이름이 다르면 예시의 경로도 달라집니다.
• 현재 사용 중인 wp-config.php의 위치를 확인합니다. 설치 구성에 따라 위치가 다를 수 있으므로 파일을 임의로 하나 더 만들지 않습니다.
• 루트의 기존 index.php, 설정 파일, 서버의 경로 규칙과 데이터베이스를 백업합니다. 다른 앱이 이미 루트에서 동작 중이면 그 진입 파일을 덮어쓰지 않습니다.
• 관리자 접속이 끊겨도 원래 파일로 되돌릴 수 있도록 파일 접근 수단과 백업 위치를 먼저 확보합니다.

루트 설치, 멀티사이트, 리버스 프록시 또는 별도 콘텐츠 디렉터리 구성에는 이 예시를 일괄 적용하지 마세요. 공식 문서도 설치 방식과 웹서버에 따라 다른 절차를 안내합니다. WordPress를 별도 디렉터리에 두는 공식 안내

2. WP_HOME과 WP_SITEURL의 역할을 구분합니다

함수 이름도 구분하면 이해하기 쉽습니다. home_url()은 공개 화면의 주소를, site_url()은 wp-blog-header.php나 wp-admin 같은 본체 파일이 있는 주소를 기준으로 합니다. 사이트 주소에 /wp가 없다고 관리자와 모든 자산 URL에서도 없어야 하는 것은 아닙니다.

파일 A: 사용 중인 wp-config.php에 주소를 정의합니다

아래 두 줄은 기존 PHP 영역 안에 넣는 설정 조각입니다. 파일 전체를 이 두 줄로 바꾸지 마세요. 같은 상수가 이미 정의돼 있다면 기존 값을 검토해 수정하고 중복 선언하지 않습니다. WordPress를 불러오는 wp-settings.php 로드 코드보다 앞에 둡니다.

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com/wp' );

위 두 URL 값 끝에는 슬래시를 붙이지 않습니다. https를 적는 것만으로 인증서나 서버의 HTTPS 구성이 완료되지는 않습니다. 실제 HTTPS 접속과 도메인 연결이 준비된 값을 사용하세요.

상수를 정의해도 데이터베이스 값 자체는 바뀌지 않습니다. WP_HOME과 WP_SITEURL은 각각 home, siteurl 값을 실행 중에 덮어씁니다. 나중에 이 정의를 제거하면 기존 DB 값이 다시 적용될 수 있으므로, 유지·제거 계획과 원래 값을 기록합니다. 설정 화면과 파일 중 어디에서 관리할지도 정해 두세요. wp-config.php의 주소 상수 공식 설명

파일 B: 공개 루트의 index.php에서 본체를 불러옵니다

다음은 문서 루트의 별도 index.php 예시입니다. 앞의 설정 조각과 한 파일에 합치지 마세요. 실제 파일명을 확인하고, 기존 루트 파일에 필요한 다른 로직이 있다면 보존하면서 적용해야 합니다.

<?php
define( 'WP_USE_THEMES', true );
require __DIR__ . '/wp/wp-blog-header.php';

__DIR__은 이 코드를 적은 파일이 있는 디렉터리입니다. 따라서 위 코드를 루트에 두면 문서 루트/wp/wp-blog-header.php를 찾습니다. 같은 코드를 /wp/index.php에 넣으면 /wp/wp/wp-blog-header.php를 찾게 되므로 위치가 중요합니다. PHP의 __DIR__ 설명

이 require에는 웹 URL이 아닌 로컬 파일 경로를 사용합니다. /wp/index.php는 본체 위치에 유지하고, 공개 루트에는 별도의 진입 파일을 둡니다. 공식 절차도 루트에 필요한 index.php를 복사한 뒤 본체 경로를 연결하도록 안내합니다. 파일을 이동해 본체 쪽에서 없애는 방식으로 처리하지 않습니다.

3. 상세 페이지로 이어지는 서버 경로도 확인합니다

루트 화면이 열려도 글 상세 주소가 열리는지는 별도입니다. 관리자에 접속해 기존 고유주소 구조를 확인하고, 같은 구조를 유지한 상태로 저장한 뒤 상세 페이지를 검사합니다. 단순히 오류를 없애려고 공개 URL 형식을 바꾸면 기존 링크에 영향을 줄 수 있습니다.

Apache에서는 루트 진입 파일과 연결되는 .htaccess 규칙을 확인합니다. WordPress가 규칙을 쓸 권한이 없으면 표시되는 규칙과 기존 설정을 비교해 반영합니다. 다른 앱의 규칙을 통째로 덮어쓰지 마세요. Nginx는 .htaccess를 사용하지 않으므로 서버의 요청 전달 설정을 따로 확인해야 합니다. IIS의 web.config도 Apache와 같은 방식으로 다루지 않습니다. 웹서버별 공식 절차

현재 호스팅의 서버 종류와 기존 규칙을 모르는 상태에서 공통 리라이트 코드를 복사하지 않습니다. 특히 이미 본체가 /wp에 있는 사례에 ‘파일을 루트에서 하위 폴더로 이동’하는 다른 절차까지 중복 실행하지 마세요.

4. 메인·상세·관리자·이미지를 나눠 검증합니다

• 공개 메인: 로그아웃한 새 창에서 도메인 루트가 의도한 사이트를 보여 주는지 확인합니다. 불필요하게 /wp/로 이동하거나 반복 리다이렉트되지 않는지도 봅니다.
• 상세 페이지: 기존 글과 페이지를 각각 열어 제목·내용·주소를 확인합니다. 없는 주소는 적절한 404로 처리되는지 점검합니다.
• 관리자와 로그인: 이 기본 구조의 /wp/wp-admin/에서 로그인·로그아웃을 확인합니다. 로그인 주소를 바꾸는 플러그인이 있다면 그 설정을 따릅니다. 시험용 초안을 저장한 뒤 다시 열어 내용이 유지되는지도 봅니다.
• 이미지·CSS·JS: 개발자 도구의 Network에서 대표 이미지와 스타일·스크립트가 정상 응답하는지 확인합니다. /wp/wp-content/ 경로가 보이는 것 자체는 오류가 아닙니다.
• HTTPS와 캐시: 잘못된 HTTP 요청과 반복 이동이 없는지 확인합니다. 변경한 사이트의 관련 캐시를 갱신한 뒤 비로그인·로그인 상태를 다시 비교합니다.

계속 이상하다면 증상에 맞는 위치로 돌아갑니다

이미지 하나가 깨졌다고 데이터베이스의 모든 /wp 문자열을 없애면 정상 본체·업로드 경로까지 바뀔 수 있습니다. 저장된 이전 URL의 교체가 실제로 필요한 경우에만 백업 후 대상 범위를 정합니다. WP-CLI의 search-replace는 직렬화 데이터를 처리하며 --dry-run으로 DB를 바꾸지 않고 예상 변경을 확인할 수 있습니다. 이 글의 기본 연결 작업에는 무조건적인 일괄 치환이 필요하지 않습니다. WP-CLI 검색·치환 공식 문서

5. 업데이트와 이전에 대비해 구성의 이유를 남깁니다

문서 루트, 본체 폴더, 설정 파일 위치, 두 URL의 관리 위치, 루트 진입 파일과 서버 규칙을 한 메모에 기록합니다. 상수를 임시 복구용으로 넣었는지 계속 유지할지도 적습니다. 이후 파일 배포나 복원 과정에서 루트 index.php를 기본 파일로 덮으면 연결이 끊길 수 있으므로 변경 목록에 포함하세요.

원복할 때는 한 파일만 무작정 되돌리기보다 이번에 변경한 주소·진입 파일·서버 규칙을 함께 비교합니다. 실제 DB를 변경한 경우에만 그 변경도 고려하고, 이후 쌓인 주문이나 게시물까지 오래된 백업으로 덮어쓰지 않도록 범위를 확인합니다. 복구 후에는 위 목록의 요청과 기능을 다시 검증하고 확인한 결과만 완료 보고에 남깁니다.

관련 가이드와 설치 경로 점검 문의

• 워드프레스 이전 후 상세 페이지만 404가 날 때
• 로그인 403에서 방화벽과 플러그인 문제 구분하기
• 워드프레스 호스팅과 백업 복구 조건 확인

작성·공식 문서 확인: 2026년 11월 6일. 예시 도메인은 example.com이며, 고객명·실제 도메인·접속 정보·주문번호는 공개하지 않았습니다.