robots.txt 파일을 SEO에 활용하는 방법

이 가이드에서 다루는 내용

이 글에서는 robots.txt가 제어하는 것과 제어하지 않는 것을 설명하고, 올바른 문법과 실용 예시를 보여주며, 실행 가능한 커맨드라인 검사와 일반 실수에서 복구하기 위한 문제해결 단계를 제시합니다. 또한 2026 검색 환경에서 유효한 검증 팁도 제공합니다 (mobile-first indexing은 2024년 7월부터 Google의 기본값이며 Google은 2024년 초에 전통적인 캐시 페이지를 제거했습니다).

robots.txt의 정의와 제어 대상

robots.txt는 사이트 루트에 위치한 일반 텍스트 파일로, 준수하는 웹 로봇에게 크롤링 지침을 전달합니다. Robots Exclusion Standard의 일부입니다. 이 파일로 크롤러가 가져가도 되는 경로를 알려주십시오; 이는 크롤링을 제어할 뿐 인덱싱이나 랭킹에는 영향을 주지 않습니다.

기억해야 할 핵심 차이점:

Crawling vs indexing vs ranking — robots.txt는 crawling(에이전트가 가져오는 것)에 영향을 줍니다. 크롤링이 차단된 URL은 다른 페이지가 링크되어 있고 검색 엔진이 해당 콘텐츠를 가져오지 않고도 URL을 인덱스하기로 선택하면 여전히 인덱싱될 수 있습니다.

robots.txt는 권고사항입니다 — 준수하는 크롤러만 따릅니다. 악성 봇, 스팸 수집기와 일부 스캐너는 이를 무시할 수 있습니다.

robots.txt는 접근 제어를 대체하지 않습니다. 민감한 콘텐츠에는 HTTP 인증, 비밀번호 보호 또는 서버 사이드 제어를 사용하세요.

robots.txt의 위치와 기본 규칙

robots.txt는 규칙을 적용하려는 정확한 호스트와 프로토콜의 사이트 루트에서 제공되어야 합니다. 서로 다른 예시 위치:https://example.com/robots.txt 및 https://sub.example.com/robots.txt. 하위 폴더에 robots.txt를 두고 도메인 전체를 제어할 수 있다고 기대할 수 없습니다.

이 가이드의 편의상 및 예시에서는 표준 테스트 경로를 다음으로 가정합니다:http://www.yoursite.com/robots.txt.

robots.txt 문법 및 일반 지시어

최소한의 robots.txt는 user-agent별로 그룹화된 지시어를 사용합니다. 지시어 이름은 대소문자를 구분하지 않습니다. 아래 예제는 대부분 주요 크롤러에서 지원하는 표준 토큰을 사용합니다:

디렉토리의 모든 크롤러 차단:

User-agent: *

Disallow: /private/

디렉토리는 차단하되 특정 파일만 허용하기(예: Googlebot 스타일 파싱에 유용):

User-agent: *

Disallow: /images/

Allow: /images/logo.png

Sitemaps는 robots.txt에 선언하여 크롤러에게 귀하의 XML sitemap:

Sitemap: http://www.yoursite.com/sitemap.xml

패턴 매칭: 주요 검색 엔진은 robots.txt 패턴에서 애스터리스크(*)와 문자열 끝 달러($) 와일드카드를 지원합니다. 비표준인 Crawl-delay 지시어는 일부 엔진에서 무시됩니다(Google은 Crawl-delay를 지원하지 않습니다).

실용 예제

1) 모든 크롤러가 모든 것을 가져가도록 허용(기본적이고 안전한 옵션):

User-agent: *

Disallow:

2) 단일 크롤러 (예: 특정 에이전트를 모든 콘텐츠에서 차단):

User-agent: BadBot

Disallow: /

3) 렌더링에 필요한 리소스의 크롤링을 차단(일반적인 실수 — 문제해결 참조):

Disallow: /static/js/

CSS/JS를 차단하면 Google이 사용자가 보는 것과 동일하게 페이지를 확인하지 못할 수 있습니다. Google은 모바일 버전을 크롤링과 인덱싱의 주된 기준으로 사용하며 크롤링과 인덱싱 및 평가하는 Core Web Vitals을 렌더링된 페이지에서 평가하므로 렌더링에 필요한 리소스는 차단하지 마세요.

robots.txt 검증 및 문제해결 방법

사이트 외부에서 실행할 수 있는 기본 점검:

파일 본문 가져오기: curl http://www.yoursite.com/robots.txt — 이 명령은 크롤러가 보게 될 파일 내용을 반환합니다.

헤더만 확인: curl -I http://www.yoursite.com/robots.txt — HTTP 상태(200 vs 4xx/5xx)와 Content-Type을 확인합니다. -I는 응답 헤더만 반환합니다.

브라우저에서 받는 모습 확인: 다음을 열어 확인하세요:https://www.yoursite.com/robots.txt 브라우저에서 열어 curl과 동일한 내용을 확인하세요.

서버 로그를 확인하여 /robots.txt에 대한 실제 크롤러 요청과 차단된 페이지를 가져가려 시도한 Googlebot 또는 다른 에이전트를 점검하세요 — 로그는 크롤러 행동을 파악하는 가장 신뢰할 수 있는 제3자 신호입니다.

사이트를 소유한 경우 실행해야 할 점검:

개별 페이지에 대해 Google Search Console의 URL Inspection을 사용하여 Google이 해당 URL을 가져갔는지 또는 인덱스했는지 확인하세요. URL Inspection은 소유한 프로퍼티에 대해 권위 있는 정보입니다.

robots.txt를 변경한 후에는 서버 로그와 Search Console의 Performance 리포트를 모니터링하여 주요 페이지의 크롤 동작을 확인하세요.

문제의 흔한 징후와 대처 방법

실수로 CSS/JS를 차단한 경우 — 증상: 크롤러가 페이지를 다르게 렌더링함; 해결책: 크롤러가 가져갈 수 있도록 Disallow에서 해당 리소스 경로를 제거하세요.

robots.txt가 404/5xx를 반환하는 경우 — 증상: 일부 크롤러는 사이트를 전부 크롤할 수 있다고 판단하거나 크롤링을 일시 중단할 수 있음; 해결책: 200과 올바른 Content-Type을 반환하는 유효한 robots.txt를 복원하세요.

잘못된 서브도메인에 robots.txt를 둬서 전체 호스트나 프로토콜을 차단한 경우 — 증상: 크롤 로그에서 페이지가 사라짐; 해결책: 올바른 호스트에 robots.txt를 추가하고(리다이렉트도 확인) 해결하세요.

페이지가 크롤링에서 차단되었지만 스니펫 없이 검색결과에 여전히 표시된다면, 이는 그 URL이 콘텐츠를 가져오지 않은 상태에서도 외부 신호로 인덱싱되었음을 의미합니다. 이런 URL을 결과에서 제거하려면 적절한 HTTP 인증을 사용하거나 페이지를 삭제하거나 페이지 자체에 noindex 지시문을 제공하세요(noindex는 크롤러가 페이지를 가져가야 적용되므로 noindex를 사용할 계획이라면 robots.txt로 차단하지 마세요).

체크리스트: robots.txt 안전하게 배포 및 검토하기

robots.txt를 정확한 호스트와 프로토콜의 사이트 루트에 배치하세요.

curl로(본문 및 헤더)와 브라우저로 파일을 테스트하세요.

CSS 차단을 피하세요, JavaScript, 또는 렌더링에 사용되는 다른 자산은 크롤러가 렌더링하지 못하게 할 의도가 아닌 한 차단하지 마세요.

robots.txt에 사이트맵을 선언하여 크롤러가 인덱스 가능한 URL을 발견할 수 있도록 하세요.

변경 후 크롤 동작을 확인하려면 서버 로그와 Search Console을 모니터링하세요.

단계별 참조가 필요하면 다음을 읽어보세요: Read the Technical SEO Guide — 크롤러빌리티와 Core Web Vitals에 대한 더 넓은 맥락을 위해.

2026년 추가 고려사항

Google이 모바일 버전을 크롤링과 인덱싱의 주요 기준으로 사용하고 전통적 캐시 페이지가 2024년 초에 제거되었기 때문에, robots.txt로 의도적으로 크롤러에게 숨긴 콘텐츠는 최신 AI 기반 개요와 Search Generative Experience 기능에서 노출될 가능성이 낮아질 수 있습니다. AI 개요에 노출되거나 풍부한 SERP 기능에 사용되기를 원한다면 크롤러가 페이지를 가져가고 인덱싱하도록 허용하고 필요 시 구조화된 데이터를 사용하세요.

자주 묻는 질문

robots.txt는 어디에 호스팅되어야 하나요?

robots.txt는 제어하려는 정확한 호스트와 프로토콜의 루트에서 접근 가능해야 합니다. 예: https://www.example.com/robots.txt. 규칙은 상위 도메인에서 서브도메인으로 계승되지 않습니다.

robots.txt로 페이지를 차단하면 검색 결과에서 제거되나요?

페이지의 크롤링을 차단해도 다른 페이지가 해당 URL을 링크하면 검색결과에 표시될 수 있습니다. 인덱싱을 방지하려면 페이지를 크롤할 수 있게 허용한 뒤 noindex 지시를 반환하거나 서버 측 접근 제어를 사용하세요.

robots.txt 변경은 얼마나 빨리 반영되나요?

크롤러는 주기적으로 robots.txt를 가져가므로 보편적인 고정 시간 프레임은 없습니다. 변경을 확인하려면 /robots.txt에 대한 새 요청이 있는지 서버 로그를 확인하고 Search Console 및 크롤 로그에서 동작 변화를 모니터링하세요.

robots.txt로 비공개 콘텐츠를 숨겨도 될까요?

아니요. robots.txt는 공개 파일이므로 민감한 데이터를 보호하는 수단으로 신뢰하면 안 됩니다. 인증을 사용하거나 해당 콘텐츠를 공개 경로에서 제거하거나 적절한 HTTP 응답 코드를 반환하여 접근을 차단하세요.

한 개의 크롤러(예: Googlebot)만 사이트에 접근하도록 허용하려면 어떻게 하나요?

특정 크롤러에 대한 user-agent 그룹을 포함하고 다른 크롤러에는 더 제한적인 그룹을 설정할 수 있습니다. 예:

User-agent: Googlebot

Disallow:

User-agent: *

Disallow: /

이 방법은 user-agent 문자열과 준수하는 크롤러에 의존하므로 안전한 접근 제어 수단이 아닙니다.