크롤러 접근 제어와 사이트맵 연결을 위한 SEO 기반 세팅

robots.txt 파일 하나 추가했는데, 이게 생각보다 신경 쓸 게 많았다.

왜 지금 robots.txt인가

사내 서비스 프론트 작업을 이어가다 보니 SEO 관련 기초 세팅이 아직 안 되어 있다는 걸 뒤늦게 발견했다. 정확히는 누군가 "크롤러가 어디까지 접근하고 있는지 알 수 없다"는 말을 꺼내면서 시작됐다. 확인해보니 public/robots.txt 자체가 없었다. 크롤러 입장에서는 아무 제한이 없는 상태로 동작하고 있던 것.

기능 개발에 치이다 보면 이런 인프라성 세팅들이 뒤로 밀리기 십상이다. 근데 나중에 한꺼번에 몰아서 하면 영향 범위 파악도 어렵고, 특히 SEO는 한 번 인덱싱이 잘못 되면 회복하는 데 시간이 꽤 걸린다. 그래서 "지금 바로 잡자"는 판단으로 작은 파일 하나지만 별도 커밋으로 분리했다.

robots.txt + sitemap 레퍼런스, 뭘 넣었나

robots.txt는 구조 자체는 단순하지만 의도를 명확히 담는 게 중요하다.

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

이번 변경의 핵심은 크롤러 허용/차단 규칙 자체보다 Sitemap 레퍼런스를 명시적으로 추가하는 것이었다. Sitemap 디렉티브는 필수 스펙은 아니지만, Google Search Console 기준으로 봐도 robots.txt에 sitemap URL을 명시해두면 크롤러가 별도 제출 없이도 사이트맵을 인식한다. 인덱싱 속도나 커버리지 측면에서 체감 차이가 있다.

"기본 허용이면 robots.txt 없어도 되는 거 아냐?" 라는 질문이 나올 수 있다. 맞는 말이긴 한데, 명시적 선언이 없으면 나중에 특정 경로를 막아야 할 때 뒤늦게 생성하는 상황이 생긴다. 그때 가면 이미 인덱싱된 경로가 있을 수 있고, 크롤러 캐시 만료까지 기다려야 하는 번거로움이 따라온다. 처음부터 뼈대를 잡아두면 이후에 경로 추가/차단 작업이 훨씬 깔끔하다.

파일 하나지만 팀에 미치는 영향

public/robots.txt 변경 파일 하나, 코드로 보면 몇 줄짜리 텍스트지만 이게 실제로 건드리는 레이어는 꽤 넓다.

• 인덱싱 범위: 어드민 경로나 인증이 필요한 페이지가 크롤링되고 있었다면, 이번 기점으로 명확히 제어 가능한 구조가 생김
• SEO 기준선 확보: 이후에 팀원이 sitemap 자동 생성 작업을 붙이거나, 메타 태그 작업을 추가할 때 "robots.txt 어떻게 되어 있어?" 라는 질문이 사라짐
• 크롤러 예측 가능성: 서비스가 성장하면서 크롤 버짓(crawl budget) 이슈가 생길 수 있는데, 초기에 구조를 잡아두면 그 시점에 대응하기 쉬움

코드리뷰 할 때도 이런 파일은 변경 내용이 단순해 보여서 "LGTM" 하고 넘기기 쉬운데, 오히려 URL이 실제 배포 도메인과 맞는지, 차단 경로가 의도에 맞는지 꼼꼼하게 보는 게 맞다. sitemap URL 하나 잘못 적혀 있으면 크롤러는 아무 에러 없이 틀린 주소를 계속 요청하게 된다.

총괄 입장에서 이런 "파운데이션 작업"들은 기능 티켓처럼 눈에 잘 안 띄지만, 팀 전체가 나중에 밟을 수 있는 지뢰를 미리 제거하는 일이다. 지금 당장 드라마틱한 변화는 없어도, 6개월 뒤에 SEO 점검하다가 "아 이게 미리 되어 있었네" 하는 순간이 반드시 온다.

다음은 sitemap.xml 자동 생성 파이프라인 연결.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.