크롤링 제어를 위해 robots.txt를 추가한 이유와 SEO 기초 정리

robots.txt 파일 하나 추가했다. 파일 하나지만, 이 작업이 생각보다 꽤 많은 맥락을 담고 있어서 기록해둔다.

왜 지금 robots.txt였나

서비스를 어느 정도 만들고 나면 "구글에 잘 잡히나?" 라는 질문이 자연스럽게 나온다. 이번에도 그랬다. 기능 개발에 집중하다 보면 SEO 기반 작업들이 뒤로 밀리는 경우가 많은데, 사실 robots.txt는 가장 먼저 챙겨야 할 것 중 하나다. 구글봇이 처음 사이트에 접근할 때 이 파일을 먼저 읽기 때문이다. 없으면? 기본적으로 전체 허용으로 간주하긴 하지만, 명시적으로 제어하지 않으면 인덱싱이 의도치 않은 방향으로 흘러갈 수 있다.

팀 내에서 "왜 아직 robots.txt가 없지?"라는 말이 나왔고, 솔직히 대답하기 애매했다. 그냥 빠뜨린 거였다. 이런 인프라성 파일들은 누군가 "이거 있어요?" 물어봐야 비로소 확인하게 되는 경우가 많다. 그게 좀 찜찜해서 이번에 제대로 챙겼다.

robots.txt가 실제로 하는 일

간단히 말하면 크롤러에게 "어디는 와도 되고, 어디는 오지 마" 를 알려주는 파일이다. public/ 디렉토리에 두는 건 Next.js든 일반 정적 서빙이든 거의 공통 패턴이다. 루트 URL(/robots.txt)로 접근되어야 하기 때문에 빌드 아웃풋 루트에 위치해야 한다.

기본 구조는 이렇다:

User-agent: *
Allow: /

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

여기서 중요한 건 몇 가지다:

• User-agent — 특정 봇만 제어하고 싶으면 Googlebot, Bingbot 등으로 나눌 수 있음
• Disallow — 관리자 페이지, API 라우트, 인증 필요 페이지 등은 여기에 명시
• Sitemap — 크롤러에게 sitemap 위치를 직접 알려주는 것. 없으면 크롤러가 알아서 찾아야 해서 인덱싱이 느려질 수 있음

robots.txt가 보안 수단이 아니라는 점은 팀원들한테도 항상 강조한다. 악의적인 봇은 이 파일을 무시한다. 그러니 민감한 경로는 인증/인가로 막아야지, Disallow 하나만 믿으면 안 된다.

이 파일 하나가 주는 시그널

파일 크기로만 보면 아주 작은 변경이다. 근데 이 파일의 유무는 "이 서비스가 프로덕션을 신경 쓰고 있나"의 지표 중 하나가 된다. Google Search Console에 사이트를 등록할 때도 robots.txt가 제대로 서빙되는지 먼저 확인한다. 없거나 500 에러가 뜨면 그 자체로 경고 신호다.

SEO 작업은 보통 아래 순서로 챙기는 게 좋다:

• robots.txt — 크롤러 접근 제어
• sitemap.xml — 인덱싱할 URL 목록 제공
• <meta name="robots"> — 페이지 단위 인덱싱 제어
• Open Graph / structured data — 검색 결과 노출 품질

이번에 robots.txt를 추가하면서 sitemap이 아직 없다는 것도 다시 확인됐다. 이건 다음 작업으로 이어질 것 같다. 작은 파일 하나 추가했는데 SEO 체크리스트 전체를 훑게 된 셈이다. 이런 게 인프라 작업의 특징이기도 하다. 하나 건드리면 연결된 게 보인다.

다음

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

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

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