목차
워드프레스를 옮긴 뒤 홈은 정상인데 글이나 상품을 누르면 404가 뜬다면, 콘텐츠가 있는지와 그 주소가 워드프레스까지 전달되는지를 나누어 확인해야 합니다. 홈이 열린다는 사실만으로 이전이 끝났다고 판단하기는 어렵습니다. 이 글은 실제 이전 작업의 완료 기록을 출발점으로, 고유주소와 Apache·Nginx·Hestia 설정을 구분해 점검하는 방법을 설명합니다.
1. 실제 이전 작업에서 확인된 내용
2025년 12월 완료한 작업은 Hestia 환경에 워드프레스를 설치·이전한 사례입니다. 완료 메시지에는 상세 페이지에서 발생하던 404 오류를 해결했다고 명시되어 있습니다. 같은 작업에서 메일 발송과 DNS 메일 연결도 수정했지만, 이 글에서는 상세 페이지 접속 문제만 다룹니다.
확인된 결과와 알 수 없는 원인
이 글을 작성할 때 확보한 기록에는 당시의 rewrite 설정 변경분이나 요청별 로그가 없습니다. 따라서 특정 Nginx 설정 한 줄, Apache 모듈, 고유주소 재저장이 실제 해결 원인이었다고 단정할 수 없습니다. 확인 가능한 결과는 완료 보고에 남은 상세 페이지 404 해결이며, 아래의 설정 예시와 검증표는 지금 같은 증상을 조사하기 위한 일반 절차입니다.
이 구분은 중요합니다. 글이 비공개이거나 주소가 바뀐 문제에 서버 규칙을 덮어쓰면 다른 페이지까지 손상시킬 수 있고, 서버가 요청을 잘못 처리하는 상황에서는 글을 다시 저장해도 해결되지 않을 수 있기 때문입니다.
2. 주소·공개 상태·이전 대상을 먼저 확인하기
설정을 바꾸기 전에 파일·데이터베이스와 현재 웹서버 설정을 백업하고 복구 방법을 확인합니다. 쇼핑몰처럼 새 주문이 계속 쌓이는 사이트는 이전 시점의 데이터베이스를 통째로 되돌릴 경우 새 데이터가 사라질 수 있으므로 복원 범위를 별도로 정합니다.
- 같은 페이지인지 확인합니다. 관리자에서 해당 글·페이지·상품이 존재하는지, 공개 상태인지, 실제 고유주소가 무엇인지 확인합니다. 메뉴나 외부 링크가 예전 슬러그를 가리키는 경우도 구분합니다.
- 이전 전후 주소 구조를 비교합니다. 날짜·카테고리·하위 폴더가 포함되었는지, 끝의 슬래시와 한글 주소가 어떻게 구성되는지 기록합니다. WordPress 고유주소 문서가 설명하는 것처럼 URL은 글뿐 아니라 페이지와 분류 목록에도 사용됩니다.
- 올바른 사이트를 보고 있는지 확인합니다. 새 서버의 해당 도메인과 문서 루트가 맞는지, HTTP·HTTPS와 www 유무가 의도한 사이트로 연결되는지 확인합니다. 홈이 캐시로 표시되면 옛 서버와 새 서버가 같은 상태로 보일 수도 있습니다.
- 실패 범위를 적습니다. 모든 상세 페이지가 실패하는지, 상품만 실패하는지, 특정 글 한 개만 실패하는지 나눕니다. 오류 발생 시각과 정확한 경로를 서버 로그와 대조합니다.
| 관찰한 증상 | 먼저 비교할 항목 | 주의할 판단 |
|---|---|---|
홈은 정상, 대부분의 상세 주소는 404 | 고유주소 규칙, 웹서버 라우팅, 문서 루트 | rewrite가 원인이라고 바로 확정하지 않기 |
일부 글만 404 | 공개 상태, 슬러그 변경, 부모 페이지, 기존 링크 | 사이트 전체 설정부터 바꾸지 않기 |
글은 정상, 상품·특정 유형만 404 | 해당 플러그인의 활성 상태와 콘텐츠 유형·경로 등록 | 서버 이전 누락과 플러그인 설정 차이도 확인하기 |
특정 접속 환경에서만 예전 화면 또는 404 | DNS 대상, CDN·페이지 캐시, HTTP·HTTPS의 차이 | 한 번의 새로고침으로 전체 복구 판단하지 않기 |
/?p=123처럼 글 ID로 접근하는 주소와 보기 좋은 고유주소를 비교하는 방법도 있습니다. 여기의 숫자는 설명용 예시이며 실제 글 ID로 바꿔야 합니다. 다만 워드프레스가 고유주소로 자동 이동할 수 있으므로 처음 요청과 최종 도착 주소를 함께 확인해야 합니다. 두 화면의 차이만으로 서버 원인을 확정하지 않습니다.
3. 기존 고유주소 구조를 유지한 채 규칙 갱신하기
필요한 플러그인과 테마가 이전되어 정상적으로 활성화됐는지 확인한 뒤, 관리자에서 설정 → 고유주소를 엽니다. 현재 구조와 카테고리·태그·상품 관련 기본 경로를 기록하고, 기존 값을 유지한 상태로 변경 사항을 한 번 저장한 뒤 실패했던 주소를 다시 검사합니다.
복구를 위해 기존 날짜형 주소를 임의로 글 이름형으로 바꾸는 것은 다른 작업입니다. 공유된 링크와 검색에 노출된 주소까지 바뀔 수 있습니다. 또한 고유주소 규칙을 갱신하는 코드를 매 요청마다 실행하도록 넣지 마세요. 공식 flush_rewrite_rules() 문서도 규칙 재생성은 비용이 큰 작업이므로 필요할 때만 사용하도록 설명합니다.
Apache 환경에서 워드프레스가 .htaccess를 쓰지 못한다는 안내가 나오면 파일 위치·소유자·권한과 서버 정책을 확인합니다. 파일 전체를 지우거나 권한을 무조건 넓히지 말고, 기존 보안·리디렉션 규칙을 보존합니다. Nginx 단독 구성에서는 이 저장 작업이 Nginx 설정까지 자동 수정해 주지는 않습니다.
4. Apache와 Nginx 구성에 맞춰 점검하기
응답 헤더에 Nginx라고 표시되어도 뒤에서 Apache가 요청을 처리할 수 있습니다. WordPress의 Nginx 문서는 Nginx 단독 구성과 Apache 앞의 리버스 프록시 구성을 구분합니다. 호스팅 패널의 실제 구성과 적용된 도메인 설정을 먼저 확인하세요.
Apache가 워드프레스 요청을 처리하는 경우
WordPress의 404 문제 해결 문서는 Apache의 mod_rewrite가 활성화되어 있지 않은 경우를 원인 후보로 안내합니다. 현재 서버에서 모듈이 동작하는지, 올바른 디렉터리의 규칙을 읽는지, 다른 규칙이 먼저 요청을 처리하는지 확인합니다.
Apache의 AllowOverride 문서에 따르면 AllowOverride와 AllowOverrideList가 모두 None인 디렉터리에서는 .htaccess를 읽지 않습니다. 파일이 존재한다는 사실만으로 적용된다고 볼 수 없습니다. 관리자는 실제 문서 루트의 설정에서 필요한 rewrite 지시어가 허용되는지 검토해야 합니다. 사이트 전체에 무조건 AllowOverride All을 추가하는 방법을 기본 처방으로 삼지 않습니다.
Nginx와 PHP-FPM이 직접 처리하는 경우
Nginx는 Apache의 .htaccess를 읽지 않습니다. 실제 파일·디렉터리에 해당하지 않는 요청을 워드프레스의 진입점으로 전달하는 규칙과 PHP 처리 설정을 확인합니다. 다음은 루트 경로에 설치된 단일 워드프레스의 라우팅 개념 예시이며, 당시 작업 코드나 완성된 서버 설정이 아닙니다.
# 기존 location / 블록 안에서 검토할 예시 한 줄
try_files $uri $uri/ /index.php?$args;이 예시는 파일·디렉터리를 차례로 확인하고 해당하지 않으면 index.php로 내부 전달하면서 쿼리 문자열을 유지하는 방식입니다. 동작은 Nginx의 try_files 문서와 함께 확인할 수 있습니다. 문서 루트, 기존 location 우선순위, PHP-FPM 연결, 하위 폴더 설치 여부가 다르면 적용 내용도 달라집니다. 기존 블록을 중복 생성하거나 멀티사이트에 그대로 붙여 넣지 마세요.
Nginx가 Apache 앞에 있는 경우
이 구성에서는 앞단 Nginx가 해당 요청을 Apache로 전달하는지, 뒤의 Apache가 고유주소를 처리하는지 순서대로 살펴봅니다. Nginx 단계에서 404가 끝나는지, 백엔드에서 404가 돌아오는지를 같은 시각의 로그로 비교합니다. 단독 Nginx용 예시로 프록시 설정을 통째로 바꾸면 기존 PHP 처리 경로와 보안 설정이 깨질 수 있습니다.
서버 설정을 변경할 때는 현재 값을 보존하고, 해당 서버의 구문 검사와 적용 절차를 거친 뒤 최소 범위로 반영합니다. 적용 오류가 있으면 기존 설정으로 복원하고 서비스 상태를 확인합니다. 사용 중인 구성을 알 수 없다면 호스팅 관리자에게 문제 URL과 발생 시각을 전달하는 편이 정확합니다.
5. Hestia에서는 적용된 템플릿도 확인하기
Hestia의 도메인 설정 파일은 템플릿에서 다시 만들어질 수 있습니다. Hestia 공식 웹 템플릿 문서는 사용자·도메인 재구성 시 설정이 덮어써질 수 있고, 기본 템플릿도 업데이트에 의해 바뀔 수 있다고 설명합니다. 생성된 설정 파일 한 곳만 고쳐서 잠시 정상화됐다면 변경이 유지되는지도 확인해야 합니다.
- 대상 도메인에 선택된 웹·프록시·백엔드 템플릿과 실제 서버 구성을 기록합니다.
- 현재 구성에 맞는 템플릿을 확인합니다. Nginx 프록시용과 Nginx+PHP-FPM용은 다른 경로에 있으므로 이름만 보고 바꾸지 않습니다.
- 사용자 정의가 필요하다면 기본 템플릿을 별도 이름으로 복사하고, HTTP용
.tpl과 HTTPS용.stpl및 관련 파일의 필요 여부를 함께 검토합니다. - 테스트와 복원 준비 후 대상 도메인에 적용하고, 재생성된 설정과 접속 결과를 확인합니다. 같은 템플릿을 사용하는 다른 도메인에 미칠 영향도 확인합니다.
이 목록은 현재의 유지보수 절차입니다. 실제 사례에서 어떤 템플릿을 수정했는지는 남은 완료 기록만으로 확인되지 않습니다.
6. 정상 페이지와 진짜 404를 함께 검증하기
수정 후에는 관련 캐시를 필요한 범위에서 갱신하고, 로그아웃한 브라우저에서도 기존 URL을 확인합니다. 브라우저 개발자 도구의 네트워크 목록에서 문서 요청의 상태 코드와 리디렉션 경로를 확인하면 화면만 보고 놓치는 문제를 줄일 수 있습니다.
| 검사할 주소 | 확인할 결과 | 추가 확인 |
|---|---|---|
홈과 대표 글·페이지·상품 | 정확한 콘텐츠가 표시되고 최종 문서 요청이 정상 응답 | 로그인 여부에 따라 달라지지 않는지 |
카테고리·태그·목록의 2페이지 | 실제로 항목이 있는 목록과 페이지 넘김이 정상 작동 | 홈이나 목록 1페이지로 잘못 돌아가지 않는지 |
이전부터 공유된 주소 | 주소를 유지했다면 그대로 열림. 의도적으로 변경했다면 대응되는 새 페이지로 이동 | 리디렉션 반복이나 엉뚱한 목적지가 없는지 |
실제로 존재하지 않는 임의 경로 | 페이지 없음 안내와 HTTP 404 응답 | 오류 화면인데 200으로 응답하지 않는지 |
이미지·CSS·JS와 관리자 주요 화면 | 기존 파일과 필요한 기능이 정상 작동 | 새 라우팅 규칙이 정적 파일이나 관리 기능을 가로채지 않는지 |
모든 404를 홈으로 보내면 사용자가 찾던 상세 페이지가 복구되는 것은 아닙니다. 또한 오류 안내를 보여주면서 HTTP 200으로 응답하면 검색에서 soft 404로 처리될 수 있습니다. Google의 HTTP 상태 코드 안내도 이런 응답을 구분합니다. 정상 콘텐츠의 접속을 되살리고, 없는 주소는 올바른 404로 남기는 것이 검수 기준입니다.
7. 이전 다음 날에도 유지되도록 기록 남기기
이전 체크리스트에 홈뿐 아니라 글·상품·분류 목록·페이지 넘김·없는 URL을 넣습니다. 고유주소 구조, 문서 루트, 서버 구성, Hestia 템플릿 이름, 수정한 파일과 복원 지점을 함께 기록하면 재발 시 비교할 기준이 생깁니다. DNS 전환 뒤에도 예전 서버나 캐시를 보는 접속이 있는지 확인합니다.
원인을 확인하지 않은 데이터베이스 전체 문자열 치환, 전체 URL 구조 변경, 보안 설정 해제를 404 복구의 첫 단계로 삼지 마세요. 실제 도메인 변경이 필요한 경우에는 직렬화된 데이터와 변경 범위를 고려한 별도 이전 절차로 처리하고 검증합니다. 완료 보고에는 직접 검사한 URL 유형과 남은 미확인 범위를 구분해 남깁니다.
이전 후 특정 페이지만 열리지 않는다면
정상 주소와 실패 주소, 이전 전후 시점, 호스팅·서버 구성, 최근 변경 내용을 정리해 콩디 코딩 워드프레스 오류 해결 서비스로 문의할 수 있습니다. 확인 가능한 범위를 살펴본 뒤 작업 범위와 견적을 안내합니다. 계정 비밀번호나 전체 서버 설정을 공개 댓글에 올리지 마세요.
관련 글: 복구 관점에서 살펴보는 워드프레스 호스팅 · Elementor 업데이트 후 치명적인 오류 복구 순서
작성·공식 자료 확인: 2026년 11월 6일. 실제 완료 기록의 확인 범위와 일반적인 진단·검증 절차를 구분했으며 고객 식별 정보는 공개하지 않았습니다.