서브도메인 SEO 기반 세팅을 뒤늦게 갖춘 이유
목차
SEO 대응을 위해 서브도메인에 루트 응답과 robots.txt를 붙였다.
왜 이 작업이 필요했나
서브도메인 하나가 루트 경로(/)로 들어오는 요청에 아무 응답도 안 하고 있었다. 크롤러 입장에서 루트가 비어있으면 신뢰도가 떨어지고, 색인 기준점 자체가 불명확해진다. SEO를 진지하게 챙기려면 루트 index.html 응답과 robots.txt 두 개는 세트로 갖춰야 한다는 게 기본 중의 기본인데, 이 서브도메인에는 그게 빠져있었음.
백엔드 static 리소스 디렉터리에 두 파일을 추가하는 작업이었다. Spring Boot 기준으로 src/main/resources/static/ 경로에 파일을 두면 별도 컨트롤러 없이 정적 파일로 서빙된다. 구조가 단순해서 수정 범위는 작지만, 크롤러와 검색엔진에 미치는 영향은 생각보다 크다.
변경 파일 두 개가 각각 하는 일
| 파일 | 역할 | 없을 때 문제 |
|---|---|---|
index.html |
루트 경로(/) 응답 |
크롤러가 루트 접근 시 404 또는 빈 응답 → 신뢰도 저하 |
robots.txt |
크롤러 접근 제어 지시 | 크롤러가 마음대로 모든 경로 탐색, 불필요한 경로 색인 가능 |
robots.txt는 특히 위치가 중요하다. 반드시 도메인 루트(/robots.txt)에 있어야 구글봇을 비롯한 주요 크롤러가 인식한다. 서브디렉터리에 있으면 효과가 없다. 이번 작업처럼 static 리소스로 서빙하는 구조라면 static/robots.txt가 곧 /robots.txt로 노출되니까 정확한 위치다.
index.html의 경우, 루트에 어떤 콘텐츠를 넣느냐도 중요한데 이 서브도메인의 성격에 맞는 기본 응답을 갖추는 것 자체가 우선이었다. 404가 아닌 200을 돌려주는 것, 그리고 최소한의 메타 정보를 포함하는 것 — 이 두 가지가 SEO 기반 세팅의 출발점이다.
정적 리소스로 SEO 파일 배포할 때 주의할 점
backend/src/main/resources/
└── static/
├── index.html ← 루트(/) 응답
└── robots.txt ← /robots.txt 응답
Spring Boot의 기본 정적 리소스 서빙 우선순위상 static/ 폴더가 포함되어 있어서 컨트롤러를 따로 만들 필요가 없다. 다만 팀 내에서 주의할 점이 있다.
index.html이 static에 있으면 Spring MVC의WelcomePageHandlerMapping이 작동해서 루트 요청을 가로챈다. 컨트롤러에서/를 별도로 매핑하고 있다면 충돌 가능성 있음. 이 부분은 코드리뷰 때 꼭 확인해야 하는 포인트다.robots.txt내용에서Disallow규칙이 너무 넓으면 오히려 필요한 경로가 색인에서 빠질 수 있다. 작성 후 Google Search Console의 robots.txt 테스터로 검증하는 걸 습관화하는 게 좋다.- CDN이나 리버스 프록시가 앞에 있다면
/robots.txt경로가 캐시될 수 있다. 수정 후 즉시 반영이 안 되는 경우가 있으니 캐시 무효화 여부도 체크.
회고
작업 자체는 파일 두 개 추가라서 규모가 작다. 그런데 이런 작업일수록 "언제 했어야 하는가"를 되짚게 된다. 서브도메인이 만들어졌을 때 SEO 기본 세팅이 체크리스트에 있었다면 이번처럼 뒤늦게 추가하는 일은 없었을 것이다. 신규 도메인/서브도메인 생성 시 index.html + robots.txt + sitemap.xml 세 개는 기본 세팅으로 묶어서 올라가야 한다는 걸 팀 온보딩 문서에 박아두는 게 맞겠다 싶었다.
핀포인트 수정이지만, SEO는 누적 효과라서 이런 작은 누락이 오래 방치될수록 회복 비용이 커진다. 빠르게 메꾼 게 다행이다.
끝.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.