robots.txt와 사이트맵

두 파일 모두 크롤러에게 URL에 관해 무언가를 말하지만, 흔히 기대하는 일을 하지는 않습니다. 하나는 가져올 권한을 거두고, 다른 하나는 검토할 목록을 내놓습니다.

허용과 배제는 같은 말이 아니다

robots.txt는 URL을 가져올 권한을 거둘 뿐, 그 이상은 하지 않습니다. 구글은 이것이 페이지를 검색에서 빼는 수단이 아니라고 못박습니다. 두 개념은 끊임없이 뒤섞이고, 그 혼동에서 아주 구체적이고 눈에 잘 띄는 실패가 나옵니다.

다른 사이트가 링크한 차단 URL은 그래도 색인될 수 있습니다. 누군가 링크했으니 구글은 그 주소가 있다는 사실을 알지만, 무엇이 담겼는지는 볼 수 없습니다. 그래서 설명이 전혀 없는 채로 노출되기도 합니다. 페이지는 결과에 공개되어 있는데 어떻게 보일지는 통제할 수 없는, 양쪽 모두 최악인 상태입니다.

파일을 읽고 쓰는 법

이 파일은 호스트의 루트에 놓이며 해당 호스트와 프로토콜에만 적용됩니다. 규칙은 user-agent별로 묶이고, 크롤러는 자신에게 가장 구체적으로 들어맞는 하나의 그룹만 따릅니다. 들어맞을 수 있는 모든 그룹이 아닙니다. 그룹 안에서 구글은 순서가 아니라 더 구체적인 규칙으로 충돌을 정리합니다.

robots.txt

User-agent: *
Disallow: /admin/
Disallow: /*.pdf$
Allow: /admin/public/

User-agent: Googlebot
Disallow: /drafts/

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

이 예시의 두 가지가 혼란의 대부분을 차지합니다. Allow 줄은 위의 Disallow보다 구체적이므로 /admin/public/은 계속 가져올 수 있습니다. 그리고 Googlebot 그룹이 존재하는 순간 Googlebot은 그 그룹만 따릅니다. 와일드카드 그룹은 더 이상 적용되지 않아, 여기서는 /admin/이 Googlebot에게 열려 있습니다. 작성자가 의도한 바는 거의 아닙니다.

경로를 막아도 이미 색인된 URL은 사라지지 않습니다. 앞으로의 가져오기만 멈춥니다.
Sitemap 지시문은 어떤 user-agent 그룹에도 속하지 않으며 파일 어디에 두어도 됩니다.
robots.txt 자체가 5xx를 내면 크롤러가 호스트 전체에서 물러설 수 있으니, 믿을 만한 곳에서 제공하세요.

robots 규칙이 멀리 떨어진 곳에서 입히는 손해

가장 비싼 robots.txt 실수는 막으려던 페이지가 아닙니다. 페이지가 렌더링에 필요로 하는 리소스입니다. 검색엔진은 색인하기 전에 페이지를 렌더링하고, 그 과정에서 스크립트와 스타일과 API 응답을 가져옵니다.

스크립트 경로나 API 경로를 막아도 크롤러는 HTML을 멀쩡히 가져옵니다. 그다음 거의 빈 페이지를 렌더링하고 거의 빈 페이지를 색인합니다. 어느 보고서에도 페이지가 차단되었다는 말은 없습니다. 차단된 것은 페이지가 아니라 페이지에 필요했던 것들이기 때문입니다.

사이트맵은 제안이지 대기열이 아니다

사이트맵은 링크가 가장 약한 곳에서 발견을 돕습니다. 규모가 큰 사이트, 유입 링크가 적은 갓 만든 사이트, 자연스러운 앵커 텍스트가 없는 미디어 위주 사이트입니다. 구글은 URL을 올려도 크롤링과 색인 어느 쪽도 보장하지 않는다고 분명히 밝힙니다.

구글 자신의 안내는 규모가 작고 내부 링크가 잘 짜인 사이트라면 아예 필요 없을 수도 있다는 것입니다. 크롤러가 링크를 따라 전부 찾아내기 때문입니다. 내부 링크가 더 잘 풀 문제를 위해 사이트맵 설비를 짓기 전에 진지하게 새겨둘 만합니다.

한도	값
파일당 URL 수	5만
파일당 비압축 크기	50MB
둘 중 하나를 넘으면	나누고 사이트맵 색인에서 각 파일을 참조

읽히는 태그, 무시되는 태그, 의심받는 태그

사이트맵에 들이는 노력이 가장 많이 새는 지점입니다. 흔히 쓰는 네 태그 가운데 둘은 아무 일도 하지 않고, 셋째는 오히려 불리하게 작용할 수 있습니다.

태그	구글의 처리
loc	읽음 — URL 자체
lastmod	일관되고 검증 가능하게 정확할 때만 사용
changefreq	무시
priority	무시

무는 것은 lastmod에 달린 조건입니다. 빌드가 모든 URL에 배포 시각을 찍으면 모든 값이 동시에 틀렸고 반박하기도 쉽습니다. 페이지는 바뀌지 않았는데 바뀌었다고 말하고 있고, 검색엔진은 그것을 알아볼 수 있습니다. 그 필드를 믿지 않게 되면 쓰지 않게 되고, 결국 lastmod를 아예 보내지 않는 편보다 불리해집니다. 본문이 실제로 바뀔 때만 내보내고, 지어내느니 빼세요.

sitemap.xml

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/guides/indexing/</loc>
    <lastmod>2026-06-14</lastmod>
  </url>
</urlset>

맞는 도구 고르기

이 분야의 거의 모든 질문은 비슷해 보이지만 서로 다른 세 가지 일을 갈라놓는 순간 풀립니다.

목표	도구	이유
쓸모없는 URL에 크롤링을 낭비하지 않기	robots.txt	가져오기 자체를 막는다
페이지를 결과에서 빼기	noindex 또는 인증	지시문을 읽히려면 가져오기가 필요하다
페이지가 발견되도록 돕기	내부 링크, 그다음 사이트맵	링크는 맥락을 나르지만 사이트맵 항목은 아니다

내 사이트에서 시험해 보기

질문과 답변

disallow와 noindex를 함께 쓸 수 있나요?

아닙니다. 바로 그 조합이 대표적인 실수입니다. robots.txt가 URL을 막으면 크롤러는 페이지를 가져오지 않고 noindex도 보지 못합니다. 크롤링을 허용한 뒤 noindex를 제공하거나 페이지를 인증 뒤에 두세요.

사이트맵이 꼭 필요한가요?

늘 그렇지는 않습니다. 구글은 규모가 작고 내부 링크가 잘 짜인 사이트는 링크를 따라 발견된다고 안내합니다. 사이트맵은 큰 사이트, 유입 링크가 적은 갓 만든 사이트, 미디어가 많을 때 값을 합니다.

차단한 페이지가 왜 구글에 계속 보이나요?

robots.txt가 멈춘 것은 가져오기이지 색인이 아니기 때문입니다. 다른 사이트가 그 URL을 링크하니 구글은 존재를 알지만 내용은 보지 못해 설명 없는 항목이 됩니다. 크롤링을 허용하고 noindex를 제공하면 제대로 지울 수 있습니다.

priority와 changefreq를 설정해야 하나요?

아닙니다. 구글은 둘 다 무시합니다. 그 노력은 lastmod를 정확하게 유지하거나 내부 링크에 쓰는 편이 낫습니다.

robots.txt가 오류를 내면 어떻게 되나요?

5xx라면 크롤러는 전부 허용으로 보지 않고 호스트에서 물러설 수 있습니다. robots.txt는 사이트 자체만큼은 믿을 만한 기반에서 제공하세요.

이어서 읽기 페이지가 색인되지 않는 이유 이어서 읽기 내부 링크