많은 회사가blog.example.com같은 별도 서브도메인에 블로그를 운영합니다. 그런데 이렇게 공들여 쌓은 콘텐츠와 검색 점수가 정작 메인 사이트(example.com)에는 온전히 반영되지 않는다는 사실, 알고 계셨나요? 이번 편에서는 서브도메인 블로그가 SEO 점수를 '흘리는' 원인과, 리버스 프록시로 이를 끌어오는 구체적인 방법, 그리고 가장 깔끔한 모범 사례까지 정리합니다.
1. 서론: 따로 떨어진 블로그, 따로 노는 SEO 점수
블로그는 콘텐츠 마케팅의 핵심입니다. 꾸준히 글을 쌓으면 검색 유입이 늘고, 도메인의 신뢰도(권위)가 올라가죠. 그래서 많은 팀이 워드프레스, 인블로그(Inblog) 같은 전문 블로그 서비스를 가져다 붙입니다.
문제는 붙이는 위치입니다. 대부분은 별 생각 없이 blog.example.com이라는 서브도메인에 블로그를 얹습니다. 설정이 간단하고, 블로그 서비스가 기본으로 안내하는 방식이기 때문입니다.
그런데 여기서 조용한 손실이 발생합니다. 블로그에서 아무리 좋은 글을 발행하고 백링크를 쌓아도, 그 점수가 메인 사이트로 온전히 흘러가지 않는 것입니다.
왜 이런 일이 벌어질까요? 원인부터 차근차근 짚어보겠습니다.
2. 원인: 왜 서브도메인 블로그는 SEO 점수를 흘릴까?
검색 엔진은 서브도메인과 서브디렉토리를 다르게 본다
먼저 두 가지 주소 구조를 구분해야 합니다.
- 서브도메인 (Subdomain):
blog.example.com— 루트 도메인 앞에 이름이 붙는 구조 - 서브디렉토리 (Subdirectory):
example.com/blog— 루트 도메인 뒤에 경로로 붙는 구조
URL만 보면 사소한 차이 같지만, 검색 엔진은 이 둘을 전혀 다르게 취급합니다.
| 구분 | 서브도메인 (blog.example.com) | 서브디렉토리 (example.com/blog) |
|---|---|---|
| 구글의 인식 | 별개의 사이트에 가깝게 취급 | 메인 사이트의 일부로 취급 |
| 도메인 권위(Authority) | 메인과 분리되어 따로 쌓임 | 메인에 통합되어 함께 쌓임 |
| 백링크/링크 자산 | 서브도메인에 고임 | 루트 도메인으로 합산 |
| 내부 링크 효과 | 두 사이트로 권위가 쪼개짐 | 하나로 묶여 시너지 |
구글의 공식 입장은 "둘을 동등하게 평가한다"입니다. 하지만 현업의 경험은 다릅니다. 많은 SEO 전문가들이 서브도메인에서 서브디렉토리로 블로그를 옮긴 뒤 검색 유입이 눈에 띄게 늘었다고 보고합니다. 핵심은 권위와 링크 자산이 한 도메인에 집중되느냐, 둘로 쪼개지느냐의 차이입니다.
그렇다면 모두가 서브디렉토리(example.com/blog)를 쓰면 될 텐데, 왜 다들 서브도메인으로 블로그를 운영할까요? 구조적인 두 가지 걸림돌이 있습니다.
원인 1. 웹 빌더가 '외부 연결 서브디렉토리'를 지원하지 않는다
많은 노코드 웹 빌더나 홈페이지 제작 도구는 자기 시스템 안에서 만든 페이지만 example.com/blog 식의 경로를 내줍니다.
하지만 블로그는 인블로그처럼 외부 서비스에서 운영하는 경우가 많습니다. 이때 "외부 서비스의 콘텐츠를 내 도메인의 /blog 경로처럼 보이게 해줘"라는 요구는 대부분의 웹 빌더가 지원하지 않습니다. 외부 서버 콘텐츠를 자기 경로 안으로 끌어오는 기능 자체가 없기 때문이죠.
결국 선택지는 "서브도메인으로 빼는 것"밖에 남지 않고, 그 순간 SEO 점수가 분리되기 시작합니다.
원인 2. 리버스 프록시(Reverse Proxy) 설정의 부재
example.com/blog로 들어온 사용자의 주소창은 그대로 둔 채 뒤에서 외부 블로그 서버의 내용을 가져와 보여 주어야 합니다. 이때 필요한 기술이 리버스 프록시라는 기술입니다.
이건 단순 리다이렉트(주소가 blog.example.com으로 바뀌어 버리는 것)와 다릅니다. 리버스 프록시는 사용자도 검색 엔진도 example.com/blog라는 하나의 주소로 인식하게 만듭니다. 즉, 콘텐츠는 외부에서 가져오지만 SEO 점수는 메인 도메인에 쌓이게 하는 핵심 장치입니다.
문제는 이 설정이 인프라에 대한 이해를 요구한다는 점입니다. 어디에(웹 서버? CDN? 게이트웨이?) 어떻게 설정해야 하는지 모르면 시도조차 어렵습니다. 그래서 많은 팀이 "그냥 서브도메인으로 쓰자"에 멈추게 됩니다.
결국 서브도메인은 메인 도메인과 분리되어, 기껏 쌓은 SEO 점수가 메인 도메인에 반영되지 않는 상황이 됩니다. 열심히 물을 부었는데, 정작 본체 화분이 아니라 옆에 따로 놓인 화분만 키운 셈이죠.
3. 해결책: 리버스 프록시로 블로그를 '서브디렉토리'처럼 붙이기
해결의 큰 그림은 하나입니다.
외부 블로그를 그대로 둔 채, example.com/blog 경로의 트래픽만 리버스 프록시로 외부 서버에 전달한다.
이렇게 하면 사용자의 주소창은 example.com/blog/...로 유지되고, 검색 엔진도 이 콘텐츠를 메인 도메인의 일부로 인식합니다. 데이터(기존 블로그 글)는 그대로 두면서 SEO 점수만 메인으로 끌어오는 것이죠.
문제는 "이 리버스 프록시를 어디서 처리하느냐"입니다. 운영 환경에 따라 손대야 할 지점이 다릅니다. 크게 세 가지 시나리오로 나눠 보겠습니다.
3-1. 모던 호스팅 플랫폼 (PaaS)
모던 호스팅 서비스는 대부분 이 리버스 프록시(Rewrite) 기능을 자체적으로 제공합니다. 별도 서버를 띄울 필요 없이 설정 파일 몇 줄이면 끝납니다.
- Vercel: Next.js 제작사답게
next.config.js의rewrites설정이나vercel.json으로 손쉽게 특정 경로를 외부 주소로 프록시할 수 있습니다. - Netlify:
_redirects파일에서200상태 코드를 부여하면, 사용자의 브라우저 주소는 그대로 유지한 채 외부 주소의 콘텐츠를 프록시로 가져옵니다. - Cloudflare: CDN 단에서 제공하는 Transform Rules를 사용하거나, Cloudflare Workers에 트래픽을 가로채서 프록시 역할을 하는 간단한 서버리스 코드를 얹어 처리할 수 있습니다.
3-2. 직접 호스팅 (자체 서버 / VM)
AWS EC2나 온프레미스 서버 등에서 애플리케이션을 직접 띄워 운영한다면, 앱 앞단에 위치한 웹 서버에서 직접 리버스 프록시를 처리해야 합니다.
- Nginx / Apache: 가장 흔하고 검증된 방식입니다. Nginx라면
nginx.conf에서 아래처럼 특정 경로로 들어오는 트래픽을 외부 블로그 서버로 토스해 줍니다.
location /blog {
proxy_pass https://inblog.ai/your-blog/;
# 헤더 전달 등 부가 설정
}특정 경로(/blog)의 요청만 외부로 흘려보내고, 나머지는 내 애플리케이션이 그대로 처리하는 구조입니다.
여담으로, 넷플릭스 드라마 “참교육” 7화에서 봉근대(표지훈 분)가 도박장에 납치되었을 때, 도박장 서버에 문제가 생겨 코딩을 하는 장면이 나옵니다. 여기서 봉근대가 리버스 프록시를 언급합니다.(30:50) 그 코딩 화면이 정확히 Nginx 리버스 프록시 작업 장면이라 정말 고증을 열심히 했구나라는 생각이 들었습니다.
3-3. 클라우드 네이티브 / 대규모 클라우드 환경
클라우드 인프라를 본격적으로 운영한다면, 트래픽이 애플리케이션에 도달하기 전 진입점(Gateway / Load Balancer 등)에서 라우팅을 손봐야 합니다.
- Kubernetes (K8s): Ingress 컨트롤러를 다룹니다.
/blog경로로 들어오는 트래픽을 외부 서비스(ExternalName)로 포워딩하거나, Nginx Ingress의 어노테이션을 활용해 트래픽 방향을 꺾어줍니다. - AWS 환경: CloudFront 같은 CDN을 앞단에 두고 있다면, Behaviors(동작) 설정에서
/blog/*경로에 대한 Origin(원본 서버)을 내 웹 서버가 아닌 외부 블로그 주소로 따로 지정합니다. CDN 레벨에서 트래픽을 분기시키는 방식이라 성능 손실도 적습니다.
환경별 요약
| 운영 환경 | 손대는 지점 | 대표 방법 |
|---|---|---|
| PaaS (Vercel/Netlify/Cloudflare) | 플랫폼 설정 파일 | Rewrite / _redirects 200 / Transform Rules |
| 자체 서버 (EC2·온프레미스) | 앞단 웹 서버 | Nginx·Apache proxy_pass |
| 클라우드 네이티브 (K8s/AWS) | 게이트웨이·CDN | Ingress / CloudFront Behaviors |
📌 공통점: 어떤 환경이든 핵심은 '주소는 유지, 콘텐츠는 외부에서' 입니다. 리다이렉트가 아니라 프록시여야 SEO 점수가 메인으로 합산됩니다.
4. 모범 사례: 애초에 한 몸으로 만들거나, 깔끔하게 끌어오거나
리버스 프록시는 강력한 해결책이지만, 설정과 유지보수에는 분명 손이 갑니다. 그래서 가장 좋은 모범 사례는 두 갈래로 나뉩니다.
1. 가장 깔끔한 길: 홈페이지와 블로그를 처음부터 '한 몸'으로
핀오버웹은 홈페이지 자체에 블로그 기능과 블로그 관리 페이지를 내장하고 있습니다. 즉, 외부 블로그 서비스를 따로 붙여 서브도메인으로 빼는 것이 아니라, 하나의 서버·하나의 도메인에서 블로그를 함께 제공합니다.
이 구조의 장점은 SEO에만 그치지 않습니다.
- SEO 점수의 자연스러운 통합: 블로그가 처음부터
example.com/blog형태로 메인 도메인 안에 존재하니, 권위와 링크 자산이 쪼개질 일이 없습니다. 리버스 프록시 같은 추가 설정도 필요 없습니다. - 브랜드 아이덴티티의 일관성: 홈페이지와 블로그를 통합 개발하면, 메인 사이트의 브랜드 디자인과 아이덴티티를 블로그 페이지까지 그대로 적용할 수 있습니다. 외부 블로그 서비스를 쓸 때 흔히 겪는 "블로그만 디자인이 따로 노는" 위화감이 사라집니다. 사용자는 메인에서 블로그로 넘어가도 끊김 없이 같은 브랜드 경험을 합니다.
요컨대, 분리해서 붙이느라 고생할 일을 애초에 만들지 않는 것이 가장 깔끔한 모범 사례입니다.
2. 이미 블로그가 있다면: 데이터는 지키고, SEO만 끌어오기
물론 모든 상황이 새 출발일 수는 없습니다.
- 인블로그(Inblog) 같은 외부 블로그 서비스를 계속 쓰고 싶은 경우
- 이미 작성해 둔 블로그 글이 많아 그대로 옮기기 부담스러운 경우
이럴 때 핀오버웹은 앞서 소개한 PaaS 연동이나 리버스 프록시 설정을 지원합니다. 기존에 쌓아온 콘텐츠(데이터)는 외부 서비스에 그대로 유지하면서, example.com/blog 경로로 끌어와 흩어져 있던 SEO 점수를 메인 도메인으로 통합할 수 있습니다.
즉, "처음부터 통합"이든 "기존 자산을 살린 통합"이든, 어느 쪽으로도 길이 열려 있는 셈입니다.
마치며
서브도메인 블로그의 SEO 누락 문제를 한 문장으로 요약하면 이렇습니다.
블로그를 별도 서브도메인(blog.example.com)으로 빼는 순간, 검색 점수도 메인에서 분리된다. 핵심은 그 점수를 다시 한 도메인으로 모으는 것이다.
- 원인은 결국 웹 빌더의 한계와 리버스 프록시 설정의 부재 두 가지로 압축됩니다.
- 해결책은 운영 환경에 맞는 리버스 프록시입니다. PaaS는 설정 파일로, 자체 서버는 Nginx·Apache로, 클라우드는 게이트웨이·CDN으로 처리합니다.
- 가장 좋은 모범 사례는 홈페이지와 블로그를 처음부터 한 도메인으로 통합하는 것이고, 이미 외부 블로그가 있다면 프록시로 데이터를 지키며 SEO만 끌어오는 것입니다.
블로그는 결국 메인 사이트를 키우기 위한 콘텐츠 엔진입니다. 그 엔진의 출력이 옆 화분이 아니라 본체로 흘러가도록 구조를 잡는 일, 그것이 SEO에서 가장 먼저 점검해야 할 기본기입니다.