크롤러가 사이트맵을 못 찾던 경로 오류 수정

robots.txt의 Sitemap 경로가 실제 라우트와 달라서 수정했다.

파일 하나, 수정도 한 줄. 그런데 이게 생각보다 영향 범위가 넓은 작업이다.

왜 이게 문제였나

robots.txt의 Sitemap 지시어는 검색엔진 크롤러가 사이트맵 위치를 찾는 진입점이다. 크롤러가 사이트를 처음 탐색할 때 robots.txt를 읽고, 거기 명시된 경로로 sitemap.xml을 요청한다. 이 경로가 틀리면 크롤러는 조용히 실패한다. 에러 로그도 없고, 알림도 없다. 그냥 색인이 안 된다.

# 수정 전 (잘못된 경로 예시)
Sitemap: https://example.com/sitemap

# 수정 후
Sitemap: https://example.com/sitemap.xml

실제 라우트가 /sitemap.xml로 서빙되고 있었는데, robots.txt는 다른 경로를 가리키고 있었던 것. 흔히 발생하는 패턴이다. 초기 세팅 때 라우트 구조가 바뀌거나, 프레임워크 마이그레이션 과정에서 경로 규칙이 달라지거나, 그냥 복붙 오류였거나. 이유는 여러 가지지만 결과는 동일하다 — 크롤러가 사이트맵을 못 읽는다.

robots.txt와 sitemap.xml, 둘의 관계

팀에서 SEO를 처음 손댈 때 많이 혼동하는 부분이 있다. sitemap.xml을 잘 만들면 끝이라고 생각하는 것. 하지만 그게 제대로 노출되려면 두 가지가 같이 맞아야 한다.

이번 케이스는 세 번째 줄에 해당했다. sitemap.xml 자체는 멀쩡히 존재하고, robots.txt도 있었는데, 연결 고리가 끊겨 있었던 것.

작은 파일, 큰 파급

blog/public/robots.txt — 파일 크기로 보면 사이트에서 가장 작은 파일 중 하나다. 그런데 이 파일 한 줄이 블로그 전체 게시물의 검색 노출에 영향을 준다. 코드 리뷰를 할 때 이런 정적 파일들이 종종 소홀히 다뤄지는 걸 본다. 컴파일도 안 되고, 테스트도 잘 안 붙고, 눈에 잘 안 띈다.

팀 리뷰 관점에서는 이런 파일일수록 배포 체크리스트에 명시적으로 포함시키는 게 맞다. 특히 도메인 변경, 라우트 리팩토링, 프레임워크 전환 같은 큰 작업이 있을 때 robots.txt, sitemap.xml, canonical URL, Open Graph 태그 이 네 가지는 항상 같이 확인해야 한다.

검증 방법도 단순하다.

• curl https://도메인/robots.txt 로 Sitemap 경로 확인
• 그 경로로 다시 curl 해서 XML 실제 응답 여부 확인
• Google Search Console의 "robots.txt 테스터" 활용
• 사이트맵 제출 후 색인 커버리지 모니터링

이번에 수정한 건 한 줄이지만, 발견이 늦었다면 신규 게시물들이 검색에 노출되지 않는 기간이 길어졌을 거다. SEO는 배포 직후 효과가 안 보이고 주단위로 결과가 나타나는 영역이라 문제를 인지하는 타이밍 자체가 늦다. 그래서 초기에 세팅을 정확히 하고, 배포 직후 한 번은 꼭 검증하는 루틴이 필요하다.

작은 수정이지만 앞으로 이런 류의 정적 설정 파일은 라우트 변경 PR에 체크리스트 항목으로 묶어둘 생각이다.

끝.

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

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

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