서브도메인은 상위 도메인 아래에 이름을 추가한 하위 도메인입니다. blog.example.com은 example.com의 서브도메인으로, 앞의 blog가 이를 구분하는 이름입니다. 블로그, 쇼핑몰, 고객센터, 앱처럼 운영 환경이 다른 영역에 별도 주소를 줄 때 활용합니다.
반면 example.com/blog의 blog는 호스트 이름 뒤에 붙은 경로입니다. 두 주소는 블로그를 나타낼 수 있지만, 하나는 호스트 이름을 나누고 다른 하나는 같은 호스트 안에서 경로를 나눕니다.
서브도메인과 하위 폴더의 차이
| 방식 | 주소 예시 | 구분하는 부분 |
|---|---|---|
| 서브도메인 | blog.example.com | 기본 도메인 앞의 별도 호스트 |
| 하위 폴더 | example.com/blog | 같은 호스트 아래의 경로 |
www.example.com의 www도 기술적으로는 서브도메인입니다. 다만 웹사이트 운영에서는 www 주소를 기본 주소처럼 쓰는 경우가 많습니다.
Google은 색인과 순위에서 서브도메인이나 하위 폴더 중 어느 한쪽을 선호하지 않는다고 안내합니다. 운영자가 관리하기 쉬운 구조를 선택하면 됩니다. 하위 폴더로 옮기면 도메인의 평가가 자동으로 합쳐져 순위가 오른다는 보장도 없습니다.
어떤 경우에 서브도메인을 쓰나
서브도메인을 쓰면 같은 기본 도메인 아래에서 영역별로 호스트를 나눌 수 있습니다. 별도 앱이나 고객센터에 주소를 연결하거나 운영팀별로 배포를 관리할 때 검토합니다.
- 본 사이트와 앱의 배포 환경이 다를 때
- 고객센터나 개발 문서가 다른 CMS를 쓸 때
- 서비스마다 로그인과 보안 정책이 다를 때
- 국가나 조직별 운영팀이 독립적으로 관리할 때
- 별도 서버와 장애 대응 범위가 필요할 때
같은 CMS와 메뉴 구조로 관리하는 콘텐츠는 하위 폴더가 편리할 수 있습니다. 반면 주제가 비슷해도 배포 환경과 권한을 나눠야 한다면 서브도메인이 적합할 수 있습니다. 다만 주소를 나누는 것만으로 서버나 접근 권한이 분리되는 것은 아닙니다. 호스팅과 인증 설정도 그 운영 목적에 맞게 구성해야 합니다.
SEO에서 실제로 달라지는 관리 범위
Search Console 속성
구글 서치 콘솔의 도메인 속성은 해당 도메인의 여러 프로토콜과 서브도메인을 함께 포함합니다. URL 접두어 속성은 입력한 접두어의 범위만 보여 줍니다. 따라서 https://example.com/ 접두어 속성에는 https://blog.example.com/의 데이터가 포함되지 않습니다.
robots.txt와 호스트 설정
example.com과 blog.example.com은 서로 다른 호스트입니다. 기본 도메인의 robots.txt로 서브도메인의 크롤링까지 제어할 수는 없습니다. Google은 robots.txt가 놓인 프로토콜, 호스트, 포트 범위에 그 규칙을 적용합니다.
리디렉션과 서버 응답도 호스트별로 검사하고, 각 페이지의 canonical이 의도한 대표 URL을 가리키는지 대조합니다. 기본 사이트에서 정상 작동한다는 이유로 새 서브도메인의 설정도 같을 것이라고 가정하지 않습니다.
검색결과에서는 사이트를 어디까지 묶나요?
Google은 기능에 따라 사이트를 묶는 범위를 달리 정합니다. 사이트 다양성 시스템은 보통 루트 도메인과 서브도메인을 같은 사이트로 처리하지만, 필요하면 별개로 볼 수 있습니다. 검색결과의 사이트 이름은 도메인과 서브도메인 단위로 지원하며 하위 폴더에는 별도 이름을 지원하지 않습니다.
Search Console에 속성을 따로 등록하는 것은 데이터를 나눠 보는 방법입니다. 이 구분이 Google의 모든 순위 시스템에 같은 방식으로 적용되는 것은 아닙니다.
사이트맵 제출
Search Console에서 관련 사이트의 소유권을 모두 확인했다면 여러 사이트의 URL을 한 사이트맵에 담아 제출할 수 있습니다. 서브도메인마다 반드시 별도 파일을 제출해야 하는 것은 아닙니다. 다만 운영팀이나 갱신 주기가 다르면 파일을 나눠 관리할 수 있습니다.
서브도메인에서 하위 폴더로 옮길 때
서브도메인의 콘텐츠를 하위 폴더로 옮기면 URL이 바뀝니다. 예를 들어 blog.example.com/post를 example.com/blog/post로 바꾼다면 기존 주소로 들어온 방문자와 검색로봇을 새 주소로 보내야 합니다.
- 기존 URL마다 내용을 이어받을 새 URL을 정해 대응표를 만듭니다.
- 각 기존 주소에서 대응하는 새 주소로 301 리디렉션을 설정합니다.
- 내부 링크와 캐노니컬, 사이트맵을 새 주소로 갱신합니다.
- Search Console에서 이전 전후 주소를 모두 확인할 수 있는 속성과 소유권을 준비하고, 새 URL의 수집 및 색인 상태를 추적합니다.
- 이전 URL이 새 페이지로 연결되는지 검사하고, 서버 오류와 검색 실적의 변화를 살펴봅니다.
이전 후 트래픽이 달라져도 서브도메인 변경만의 효과로 단정하기는 어렵습니다. URL 외에 내부 링크, 서버, 콘텐츠, 메뉴 구조가 함께 바뀌었는지 확인해야 합니다.
자주 묻는 질문
서브도메인은 SEO에 불리한가요?
Google은 색인과 순위에서 서브도메인과 하위 폴더 중 선호하는 방식이 없다고 밝힙니다. 서브도메인에서 페이지를 찾지 못하거나 색인하지 못하는 문제가 있다면 주소 형태만 원인으로 지목하지 말고, 내부 링크와 robots.txt, 서버 응답을 확인해야 합니다.
블로그를 하위 폴더로 옮기면 순위가 오르나요?
주소를 하위 폴더로 바꿨다는 이유만으로 순위가 오르지는 않습니다. CMS를 통합하거나 메뉴와 콘텐츠를 함께 관리하려는 목적이 있다면 이전을 검토할 수 있지만, URL 대응표와 리디렉션을 준비해야 합니다. 이전과 동시에 콘텐츠나 링크를 바꿨다면 검색 실적 변화의 원인도 나눠 검토합니다.
서브도메인마다 사이트맵을 따로 제출해야 하나요?
Google에는 관련 사이트의 소유권을 모두 확인한 뒤 Search Console에서 통합 사이트맵을 제출하는 방법이 있습니다. 파일을 나누더라도 한곳에 모아 둘 수 있습니다. robots.txt로 사이트맵을 알리는 방식을 택한다면 사이트별 URL만 담은 파일을 만들고, 각 사이트의 robots.txt에서 해당 파일을 가리켜야 합니다.
함께 알아두면 좋은 용어
- URL 구조: 호스트와 경로를 포함한 주소 구성 방식
- 301 리디렉션: 영구적으로 옮긴 주소를 안내하는 서버 응답
- 구글 서치 콘솔: 속성 범위별 검색 데이터를 확인하는 도구
- 사이트맵: 검색엔진에 알릴 URL 목록을 담은 파일