robots.txt에 사이트맵 인덱스 위치를 추가해 크롤 효율 개선

public/robots.txt에 sitemap-index.xml 위치를 명시하는 한 줄을 추가했다.

작업 자체는 작다. 파일 하나, 변경 내용도 몇 자 되지 않는다. 그런데 이 커밋을 넣기까지 생각보다 긴 논의가 있었고, 돌아보면 SEO 기초 중의 기초인데 실제로 제대로 세팅되어 있지 않은 프로젝트가 생각보다 많다는 걸 다시 실감했다.

왜 robots.txt에 sitemap 위치를 넣어야 하나

robots.txt는 크롤러에게 "이 사이트의 어느 경로를 수집해도 되고 어느 경로는 막겠다"는 규칙을 전달하는 파일이다. 그런데 Sitemap: 디렉티브를 함께 선언하면, 크롤러가 별도 제출 없이도 사이트맵 위치를 자동으로 파악할 수 있다. Google Search Console 등에 사이트맵을 수동으로 제출하는 것과 병행하면 더 좋지만, robots.txt에 명시해두는 것만으로도 크롤 효율이 올라간다.

User-agent: *
Allow: /

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

이번에 가리킨 파일은 sitemap.xml 단일 파일이 아니라 sitemap-index.xml이다. 이 차이가 작지 않다.

sitemap.xml vs sitemap-index.xml

프로젝트 초반에는 단일 sitemap.xml 하나로 충분했다. 근데 콘텐츠가 쌓이고 카테고리가 늘어나면서 sitemap-index 구조로 전환했는데, 그 시점에 robots.txt를 업데이트하지 않았던 것. 크롤러 입장에서는 예전 단일 sitemap 파일을 참조하거나, 아니면 sitemap 위치 자체를 모르는 상태로 수집하고 있었을 가능성이 높다.

핀포인트 수정이지만 영향은 크다

파일 하나, 줄 하나 추가가 왜 feat으로 태깅됐냐는 이야기가 나왔다. 내 기준은 이렇다. 기능적으로 새로운 동작이 크롤러에게 제공되는 거라면 feat이다. 버그 수정이나 기존 동작 복원이 아니라, "이제부터 크롤러에게 sitemap-index 위치를 알려주는 기능"을 추가한 거니까.

팀원 중 한 명이 "이거 테스트는 어떻게 하냐"고 물었다. 맞는 질문이다. robots.txt 변경은 로컬에서 바로 확인 가능하고, Google Search Console의 robots.txt 테스터를 통해 파싱 결과를 검증할 수 있다. 반영 후 sitemap 제출 상태도 Search Console에서 크롤링 커버리지 리포트로 추적하기로 했다. 이런 변경은 효과가 즉각적으로 수치로 잡히지 않아서, 보통 2~4주 단위로 색인 수 변화를 지켜봐야 한다.

• 변경 후 확인 체크리스트
• https://도메인/robots.txt 직접 접근해서 Sitemap 디렉티브 노출 확인
• Google Search Console → robots.txt 테스터 파싱 결과 확인
• sitemap-index.xml 직접 접근해서 하위 sitemap 파일 목록 유효성 확인
• 각 하위 sitemap의 <lastmod> 값이 최신인지 점검

작은 커밋이라고 코드리뷰를 가볍게 넘기면 이런 것들이 빠진다. 오히려 한 줄짜리 변경일수록 "왜 이 타이밍에", "이 값이 맞는지" 같은 맥락 검토가 중요하다. robots.txt는 잘못 건드리면 사이트 전체 수집이 막히는 경우도 생기니까, 팀 내에서 SEO 관련 파일 변경은 반드시 리뷰를 거치도록 컨벤션을 잡아뒀다.

끝.

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

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

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