워드프레스 도메인 연결을 하려다 DNS, 네임서버, SSL에서 멈췄다면 순서만 잡아도 훨씬 덜 헷갈려요. 제가 직접 확인한 흐름대로 따라가 보세요.
워드프레스 도메인 연결 방식부터 구분하기

워드프레스 도메인 연결을 시작하기 전에 먼저 내가 쓰는 워드프레스가 어떤 유형인지 봐야 해요. WordPress.com은 서비스 안의 도메인 메뉴에서 외부 주소를 추가하고 확인하는 흐름이고, 매니지드 서비스는 업체가 주는 값에 맞춰 연결합니다. 직접 설치한 워드프레스는 도메인 등록기관, 호스팅, 워드프레스 관리자 설정을 각각 봐야 해요.
관리자 화면에서 끝나는 사용자 정의 웹주소 설정과 등록기관·호스팅 화면까지 오가는 설치형 사이트 연동 절차는 범위가 다릅니다. 저는 처음에 이 차이를 모르고 워드프레스 관리자에서만 주소를 바꾸다가 접속이 끊긴 적이 있어요.
| 운영 유형 | 도메인 설정 위치 | 필요한 핵심 작업 |
|---|---|---|
| WordPress.com | 서비스 내부 도메인 메뉴 | 외부 주소 추가, 소유권 확인, 안내 값 적용 |
| 매니지드 서비스 | 업체 관리자와 도메인 DNS 화면 | 제공된 레코드나 네임서버 적용 |
| 직접 설치한 워드프레스 | 등록기관, 호스팅, 워드프레스 관리자 | DNS, 도메인 매핑, 사이트 주소 설정 |
현재 사용 중인 서비스가 애매하다면 결제 내역, 호스팅 관리자 주소, 서버 접속 정보를 먼저 확인하세요. 이 단계에서는 아직 DNS 값을 바꾸지 않는 편이 좋습니다.
도메인 연결 전에 준비할 정보와 백업
도메인 등록기관과 호스팅 업체는 역할이 달라요. 등록기관은 주소와 DNS를 관리하고, 호스팅은 워드프레스 파일과 데이터베이스가 실행되는 서버를 제공합니다. 워드프레스 도메인 연결은 이 둘을 이어주는 작업에 가깝습니다.
- 도메인 소유권과 만료 상태
- 등록기관 관리 콘솔 로그인 가능 여부
- 호스팅 계정과 관리자 페이지 접근 여부
- IPv4 형식의 호스팅 서버 IP
- 현재 적용된 네임서버와 DNS 레코드
- 사이트 파일 및 데이터베이스 연결 전 백업 상태
호스팅 서버 IP 확인을 할 때 워드프레스 관리자 주소나 내 컴퓨터의 내부 IP와 헷갈리면 안 됩니다. 실제 연결 대상은 호스팅 안내 화면이나 고객 지원 문서에 표시된 IPv4 값이에요. 만료 여부 확인도 함께 해두면 중간에 엉뚱한 문제로 시간을 쓰지 않습니다.
네임서버 변경과 DNS 레코드 설정의 선택 기준
네임서버는 이 도메인의 DNS 레코드 구성 관리를 어느 서비스에서 할지 정하는 주소록 같은 역할을 합니다. 네임서버 변경 방법을 쓰면 관리처가 통째로 바뀌고, DNS 레코드 직접 설정은 기존 관리처에서 필요한 값만 고칩니다.
네임서버 변경 방법은 호스팅 업체 안내대로 따라가기 쉬운 편이지만, 기존 MX 레코드 유지가 필요한 이메일이나 SPF, DKIM 같은 값까지 새 관리처에 옮겨야 할 수 있어요. 반대로 DNS 레코드 구성만 직접 수정하면 루트 A 레코드와 CNAME 같은 웹 연결 값만 건드릴 수 있습니다.
| 비교 항목 | 네임서버 변경 | DNS 레코드 직접 설정 |
|---|---|---|
| 관리 범위 | DNS 전체 관리처 변경 | 필요한 레코드만 수정 |
| 설정 난이도 | 안내값만 넣으면 단순한 편 | 레코드 의미를 조금 알아야 함 |
| 기존 이메일 영향 | 기존 값을 옮기지 않으면 영향 가능 | MX 레코드 유지가 비교적 쉬움 |
| 이전 편의성 | 관리처 이동이 큼 | 기존 구조를 유지하기 쉬움 |
| 적합한 상황 | 새 사이트를 처음 여는 경우 | 이메일과 외부 서비스를 이미 쓰는 경우 |
기존 이메일이나 외부 서비스용 레코드가 있다면 직접 설정 방식이 관리에 더 편할 수 있습니다. TTL 값 조정을 낮추고 싶다면 기존 TTL이 끝날 시간도 봐야 해요. 작업이 끝난 뒤에는 운영 환경에 맞는 값으로 다시 정리하면 됩니다.
A 레코드와 CNAME으로 루트·www 주소 연결하기

A 레코드 IP 매핑은 이름을 IPv4 주소에 연결하는 작업이고, CNAME 별칭 지정은 한 호스트를 다른 이름으로 보내는 작업입니다. 루트 도메인 연결 방식에서 루트 호스트는 관리자 화면에 `@`, 빈칸, 도메인 자체 중 하나로 보일 수 있어요.
- 기존 루트 A 레코드와 `www` 레코드의 충돌 여부 확인
- `@` A 레코드에 호스팅 서버 IPv4 입력
- `www` CNAME의 대상에 루트 도메인 입력
- 호스팅 관리자에서 두 주소를 동일한 사이트에 매핑
- 대표 주소를 정한 뒤 나머지 주소에 영구 이동 적용
| 호스트 | 유형 | 대상 값 예시 | 용도 |
|---|---|---|---|
| @ | A | 203.0.113.10 | 루트 A 레코드 |
| www | CNAME | example.com | www 주소 연결 |
| blog | A 또는 CNAME | 203.0.113.10 또는 example.com | 선택 사항인 별도 서브도메인 |
DNS 레코드 구성에서 `www`를 넣었다고 해서 주소가 자동으로 하나로 합쳐지는 것은 아닙니다. 워드프레스 도메인 연결 후에는 `https://example.com` 또는 `https://www.example.com` 중 하나를 대표 주소로 정하고, www 호스트 리디렉션이나 비 www 주소 통합을 따로 적용해야 합니다.
가비아·카페24·AWS·시놀로지 환경별 연결 절차
모든 환경의 공통 흐름은 서버 주소 확보, 호스팅에 도메인 추가, DNS 지정, 접속 확인입니다. 메뉴 이름만 다를 뿐 큰 흐름은 같다고 보면 덜 헷갈려요.
가비아와 카페24에서 연결하는 순서
가비아 구매 주소 연동은 DNS 관리 화면에서 루트 A 레코드와 `www` CNAME을 입력하는 방식으로 진행합니다. 카페24 호스팅 매핑은 호스팅 관리자에서 도메인을 먼저 추가한 뒤 카페24 네임서버 또는 외부 DNS 레코드 중 하나를 적용하는 흐름이에요.
AWS 라이트세일과 시놀로지 NAS 연결 순서
AWS 라이트세일 고정 IP는 인스턴스 재시작 뒤에도 같은 주소를 쓰기 위해 먼저 연결합니다. 이후 DNS 영역이나 Route 53 호스팅 영역에 A 레코드를 만들면 됩니다. 시놀로지 NAS 외부 접속은 공인 IP 확인과 내부 NAS IP 구분이 중요하고, 유동 IP라면 DDNS 사용 여부를 봐야 해요.
- 공유기에서 NAS로 포트 80 전달
- 공유기에서 NAS로 포트 443 전달
- NAS 방화벽의 웹 접속 규칙 확인
- 웹 서비스의 도메인 바인딩 확인
- 해당 도메인을 포함하는 인증서 지정
| 환경 | 먼저 확인할 값 | DNS 설정 위치 | 추가 작업 |
|---|---|---|---|
| 가비아 | 호스팅 서버 IP | 가비아 DNS 관리 콘솔 | A, CNAME 입력 |
| 카페24 | 호스팅 도메인 추가 상태 | 카페24 또는 외부 DNS | 호스팅 매핑 확인 |
| AWS 라이트세일 | 고정 IP | DNS 영역 또는 Route 53 | 인스턴스 연결 확인 |
| 시놀로지 NAS | 공인 IP 또는 DDNS | 등록기관 DNS | 공유기 포트 포워딩, 방화벽, 인증서 |
호스팅과 웹 서버에 도메인 매핑하기
DNS가 서버 위치를 알려준다면, 호스팅 매핑은 그 서버 안에서 어느 워드프레스 폴더를 보여줄지 정하는 단계입니다. 설치형 사이트 연동 절차에서 이 부분을 빼먹으면 DNS는 맞아도 엉뚱한 기본 화면이 열릴 수 있어요.
- 공유호스팅의 도메인 추가 메뉴와 문서 루트 지정
- cPanel 애드온 도메인의 디렉터리 연결
- Plesk 웹사이트 바인딩의 호스트 이름 지정
- Apache VirtualHost의 `ServerName`과 `ServerAlias`
- Nginx `server_name`의 루트 및 `www` 호스트 지정
직접 운영 서버라면 웹 서버가 포트 80 열기와 포트 443 허용 상태인지 확인해야 합니다. 클라우드 서버에서는 방화벽 인바운드 규칙도 함께 봐야 해요. 웹 서버 가상 호스트는 요청받은 도메인을 올바른 워드프레스 경로로 보내는 핵심 설정입니다.
기본 서버 화면이나 다른 사이트가 열린다면 DNS를 계속 바꾸기보다 Apache VirtualHost 구성, Nginx server_name 지정, 문서 루트를 먼저 확인하세요. 문제 위치를 나누면 훨씬 빨리 잡힙니다.
워드프레스 주소와 사이트 주소 안전하게 바꾸기
관리자 페이지 접속 후 설정 메뉴를 보면 워드프레스 주소와 사이트 주소가 따로 보입니다. `siteurl`은 워드프레스 핵심 파일 위치이고, `home`은 방문자가 접속하는 사이트 주소예요. 파일을 하위 폴더에 따로 둔 경우가 아니라면 보통 두 값을 같은 새 도메인으로 맞춥니다.
- 파일과 데이터베이스 백업
- 새 도메인의 DNS 및 호스팅 매핑 확인
- 관리자 설정에서 두 주소를 HTTPS 기준으로 수정
- 로그아웃 후 새 주소의 관리자 페이지 접속
- 로그인과 주요 페이지 동작 확인
| 설정 항목 | 저장 위치 | 의미 | 접근 불가 시 수정 방법 |
|---|---|---|---|
| `home`·`WP_HOME` | 데이터베이스 또는 wp-config.php | 방문자가 보는 사이트 주소 | 상수 임시 지정 또는 home 옵션 업데이트 |
| `siteurl`·`WP_SITEURL` | 데이터베이스 또는 wp-config.php | 워드프레스 파일 위치 주소 | 상수 임시 지정 또는 siteurl 옵션 업데이트 |
관리자 접속이 끊겼다면 `wp-config.php` 상수 설정으로 WP_HOME 값 지정과 WP_SITEURL 값 지정을 임시로 넣거나, phpMyAdmin 옵션 수정으로 `home`, `siteurl`을 고칠 수 있습니다. HTTP·HTTPS 또는 `www` 형식이 서로 다르면 로그인 쿠키 오류가 날 수 있으니 두 값을 정확히 대조하세요.
SSL 인증서와 HTTPS 리디렉션 적용하기

SSL 인증서 발급은 인증기관이 도메인의 서버 연결 상태를 확인할 수 있어야 진행됩니다. 그래서 워드프레스 도메인 연결에서는 DNS 전파와 호스팅 매핑을 먼저 끝낸 뒤 루트와 `www`를 인증서 범위에 포함해야 해요.
- 루트와 `www`가 모두 올바른 서버를 가리키는지 확인
- 두 호스트를 포함하도록 SSL 인증서 발급
- 워드프레스의 두 주소를 `https://`로 통일
- 웹 서버 또는 호스팅에서 HTTP→HTTPS 규칙 적용
- 대표 URL이 아닌 주소를 대표 URL로 통합
- 브라우저에서 인증서 범위와 자물쇠 상태 확인
연결이 안전하지 않음 또는 인증서 이름 불일치가 보이면 실제 접속한 호스트가 인증서에 포함됐는지 확인하세요. `www`로 들어갔는데 인증서는 루트만 포함하면 이런 일이 생깁니다.
혼합 콘텐츠 오류 해결은 내부 이미지, 스크립트, 스타일 주소를 HTTPS로 바꾸는 작업입니다. 클라우드플레어 프록시 설정을 쓰는 경우에는 프록시 상태와 원본 서버의 SSL 모드가 서로 맞는지도 봐야 해요. HTTPS 강제 적용 규칙이 여러 곳에 겹치면 반복 이동이 생길 수 있습니다.
DNS 전파를 확인하고 접속 상태 테스트하기
DNS 전파 시간은 고정된 완료 시각이 아닙니다. 통신망과 캐시에 따라 이전 값과 새 값이 함께 보일 수 있어요. 전파 상태 조회를 할 때는 DNS 조회 도구 활용으로 루트 A 레코드, `www` CNAME, 네임서버 값을 따로 확인하는 편이 좋습니다.
- 외부 DNS 조회 결과
- PC의 일반 브라우저 접속
- 시크릿 창 접속
- 다른 브라우저 접속
- 와이파이를 끈 모바일 접속
- 브라우저 및 운영체제 DNS 캐시 삭제 후 재확인
- 필요한 경우 hosts 파일로 새 서버 사전 테스트
hosts 파일 테스트는 내 기기에만 영향을 줍니다. 그래서 공개 전파 확인을 대신할 수는 없어요. DNS는 새 IP를 반환하지만 예전 화면이 보인다면 워드프레스, 서버, CDN 순서로 캐시 초기화를 진행하세요. TTL 값 조정은 다음 변경부터 체감되는 경우가 많습니다.
기존 도메인 변경과 검색 노출 이전하기
새 도메인을 처음 붙이는 일과 기존 주소 이전은 범위가 다릅니다. 운영 중인 사이트는 `home`·`siteurl`뿐 아니라 본문, 위젯, 첨부파일 안에 남은 예전 주소까지 봐야 해요. 데이터베이스 URL 교체와 검색 노출 신호 이전까지 포함됩니다.
- 전체 파일과 데이터베이스 백업
- 새 도메인의 DNS·호스팅·SSL 준비
- `home`과 `siteurl`을 새 주소로 변경
- 직렬화 데이터를 처리하는 검색 바꾸기 도구로 URL 교체
- 내부 링크와 이미지 경로 확인
- 이전 주소에서 동일 경로의 새 주소로 301 리디렉션
- 캐시 초기화와 퍼머링크 다시 저장
- 이전 주소와 새 주소의 주요 페이지 비교
| 교체 방법 | 적합한 상황 | 직렬화 처리 | 주의점 |
|---|---|---|---|
| Better Search Replace | 관리자 화면에서 처리하고 싶을 때 | 지원 | 실행 전 미리보기와 백업 확인 |
| WP-CLI `search-replace` | 서버 명령 사용이 가능할 때 | 지원 | 명령 대상 테이블 확인 |
| 도메인 변경 플러그인 또는 관리 도구 | 호스팅에서 전용 도구를 줄 때 | 도구별 확인 필요 | 변경 범위와 제외 항목 확인 |
phpMyAdmin의 단순 문자열 교체는 직렬화 데이터 처리에 문제를 만들 수 있습니다. Better Search Replace 사용법이나 WP-CLI search-replace 명령처럼 워드프레스 데이터 구조를 고려하는 방법을 쓰세요. 내부 링크 일괄 수정 뒤 이미지 경로 깨짐 복구, 로그인, 양식 같은 핵심 기능도 확인하면 SEO 순위 보존에 도움이 됩니다.
대표 URL과 검색엔진 정보를 새 주소로 통일하기
`www`·비 `www`, HTTP·HTTPS 중 하나를 대표 URL로 선택하고 301 리디렉션 설정과 canonical 태그 점검이 같은 주소를 가리키게 해야 합니다. 두 개 주소 대표 URL 선택이 흔들리면 검색엔진과 방문자가 서로 다른 주소를 보게 됩니다.
- 새 도메인의 검색엔진 도구 속성 확인
- 새 XML 사이트맵 생성 및 주소 제출
- 이전 URL별 301 응답 확인
- 새 페이지의 canonical 태그 확인
- 내부 링크의 새 주소 반영 여부 확인
- 색인 대상과 제외 대상 상태 확인
- 회사 이메일·양식 알림 주소 영향 점검
검색엔진 색인 갱신은 바로 끝나는 작업이 아닙니다. 이전 도메인과 리디렉션을 충분히 유지하고, 404가 늘어나는 경로를 찾아 대응 페이지로 연결하세요. 구글 서치 콘솔 속성 변경과 사이트맵 주소 제출도 함께 진행하면 상태를 더 분명하게 볼 수 있습니다.
서브도메인·멀티사이트·여러 도메인 확장 연결
`blog.example.com` 같은 서브도메인 연결에는 별도 DNS 레코드, 문서 루트 또는 사이트 매핑, SSL 인증서가 필요합니다. 하위 주소 별도 설치를 할 수도 있고, 같은 서버 안의 다른 폴더로 보낼 수도 있어요. 와일드카드 레코드 활용은 웹 서버가 각 호스트를 처리할 준비가 됐을 때만 쓰는 편이 안전합니다.
| 확장 구성 | DNS 요구사항 | 워드프레스·서버 설정 | 대표 URL 처리 |
|---|---|---|---|
| 서브도메인 별도 설치 | 별도 A 또는 CNAME | 하위 주소별 문서 루트 지정 | 각 사이트 주소 따로 지정 |
| 멀티사이트 도메인 매핑 | 사이트별 도메인 레코드 | 멀티사이트 도메인 매핑 설정 | 별도 사이트별 웹주소 지정 |
| 여러 도메인 한 사이트 연결 | 여러 도메인을 같은 서버로 연결 | 같은 워드프레스에 매핑 | 하나만 대표 URL 선택 |
| 스테이징 환경 전환 | 임시 주소 또는 서브도메인 | 운영 전환 시 주소 교체 | 운영 주소로 전환 |
| 임시 도메인 또는 로컬 개발 사이트 배포 | 새 운영 도메인 레코드 | 임시 도메인 교체, 로컬 개발 사이트 배포 | 운영 주소만 노출 |
멀티사이트에서 각 사이트에 별도 웹주소를 지정할 때는 DNS와 인증서를 사이트 수만큼 확인해야 합니다. 여러 도메인 한 사이트 연결을 한다면 두 개 주소 대표 URL 선택 후 나머지는 이동시키세요. 스테이징 주소는 색인 대상에서 제외한 뒤 운영 주소로 전환하는 흐름이 좋습니다.
이메일 DNS 레코드와 도메인 운영 상태 지키기
A·CNAME과 MX·SPF·DKIM은 목적이 다릅니다. 웹 연결에 필요하지 않다는 이유로 MX 레코드 유지, SPF 레코드 보존, DKIM 레코드 충돌 방지 항목을 지우면 메일 수신이나 SMTP 발신 도메인 인증에 문제가 생길 수 있어요.
- MX 레코드의 메일 서버 대상
- SPF TXT 레코드의 발신 서비스 범위
- DKIM 선택자와 기존 레코드 충돌 여부
- SMTP 발신 도메인 인증 상태
- 도메인 만료일과 자동 갱신 상태
- 기존 DNS 설정 내보내기 또는 기록
도메인 해제 절차를 진행하기 전에는 현재 DNS 값을 보관하세요. 연결 취소 후 복구가 필요할 때 원래 네임서버, 레코드, 대표 URL을 되돌릴 수 있도록 변경 이력을 남기면 훨씬 덜 불안합니다. 자동 갱신 설정과 만료 여부 확인도 운영 점검에 넣어두세요.
접속 불가와 리디렉션 오류를 순서대로 해결하기

워드프레스 도메인 연결이 안 될 때 한 번에 여러 설정을 바꾸면 원인을 찾기 어렵습니다. DNS 응답, 서버 응답, 워드프레스 응답을 나눠서 보는 문제 해결 순서가 필요해요.
- 도메인 만료와 등록 상태 확인
- 네임서버 값 검증
- 루트 A와 `www` CNAME 대상 검증
- 호스팅 서버 IP 및 도메인 매핑 확인
- DNS 전파와 TTL 상태 확인
- 브라우저·서버·워드프레스 캐시 초기화
- `home`·`siteurl` 또는 관련 상수 확인
- 인증서 범위와 중복 이동 규칙 확인
- 퍼머링크 다시 저장 후 서버 로그 확인
| 증상 | 가능성이 높은 원인 | 우선 확인 항목 |
|---|---|---|
| `DNS_PROBE_FINISHED_NXDOMAIN` | 유효한 DNS 응답 없음 | 등록 상태, 네임서버, 레코드 |
| 서버를 찾을 수 없음 | 전파 지연 또는 잘못된 대상 | A 레코드, CNAME, TTL |
| `ERR_TOO_MANY_REDIRECTS` | 중복 HTTPS 또는 대표 URL 규칙 | 호스팅, 웹 서버, 플러그인 설정 |
| 403 | 권한 또는 방화벽 문제 | 문서 루트, 파일 권한, 접근 규칙 |
| 404 | 경로 또는 재작성 규칙 문제 | 퍼머링크, 웹 서버 설정 |
| 500 | PHP, 플러그인, 테마, 서버 문제 | 서버 로그, 오류 로그 |
404 페이지 오류가 특정 글에서만 난다면 퍼머링크 다시 저장과 웹 서버 재작성 규칙을 먼저 확인하세요. 500 내부 서버 에러는 플러그인, 테마, PHP 설정, 서버 로그를 중심으로 봅니다. 무한 리디렉션 해결은 클라우드 서비스, 웹 서버, 워드프레스, 플러그인 중 어디에서 같은 이동 규칙이 겹쳤는지 찾는 게 핵심입니다.
- 루트와 `www` 접속
- HTTP에서 HTTPS 이동
- 대표 URL 통일
- 인증서 호스트 일치
- 관리자 로그인
- 주요 페이지와 이미지 표시
- PC와 모바일 접속
- 이메일 송수신 상태 확인
워드프레스 도메인 연결, 순서를 나누면 덜 막힙니다
처음에는 DNS라는 말만 봐도 막막했지만, 실제로 해보니 핵심은 순서였어요. 내 워드프레스 유형을 구분하고, DNS와 호스팅 매핑을 확인한 뒤, 워드프레스 주소와 SSL을 차례로 맞추면 대부분의 문제를 좁혀 볼 수 있습니다. 접속이 바로 안 되더라도 무작정 값을 바꾸지 말고 전파, 캐시, 리디렉션을 따로 확인해보세요. 마지막에는 루트와 www, PC와 모바일, 관리자 로그인까지 한 번씩 열어보는 습관이 가장 도움이 됐습니다. 읽어주셔서 감사합니다.