Robots.txt SEO: 크롤링을 효율적으로 제어하기

Robots.txt의 역할 — 가능한 것과 불가능한 것

Robots.txt는 사이트 루트에 위치한 일반 텍스트 파일입니다 (https://example.com/robots.txt). 역할은 제한적입니다: 준수하는 크롤러에게 크롤링 지침을 제공합니다. 저가치 영역에서 불필요한 요청을 줄이고 크롤링 효율을 개선하는 데 사용하세요. 색인 제어나 민감한 콘텐츠 숨김 용도로는 의존하지 마십시오.

크롤링을 제어하며 색인 제어는 아닙니다

Disallow 지시문은 준수하는 크롤러가 특정 URL 경로를 가져오지 못하게 합니다. 페이지가 크롤링에서 차단되면 검색 엔진은(는) 외부 신호(예: 링크)에 따라 여전히 해당 URL을 색인할 수 있지만 페이지의 HTML이나 meta robots 태그는 볼 수 없습니다. 색인을 확실히 막으려면 크롤러가 크롤러가 meta robots noindex 태그를 읽거나 리소스 자체의 응답 헤더에 X-Robots-Tag: noindex를 적용할 수 있어야 합니다.

공개적이고 권고적이며 보안 통제가 아님

Robots.txt는 공개적으로 접근 가능하고 권고적 문서입니다: 누구나 /robots.txt에서 읽을 수 있으며, 악의적 크롤러는 지시를 무시할 수 있습니다. 비밀이나 개인 경로를 robots.txt에 나열하지 마십시오; 접근 제어 수단이 아니라 크롤링 제어 문서로 다루세요.

핵심 문법 및 일반적인 디렉티브

대부분의 사이트는 적은 수의 디렉티브만 사용합니다. 명세와 주요 검색 엔진에서 사용하는 실무적 확장은 기본 패턴, 와일드카드 및 Sitemap 포인터를 지원합니다. 규칙은 간단하게 유지하고 가능하면 주석으로 의도를 문서화하세요.

주요 디렉티브(예시는 실제 라인 형태):

• User-agent: <bot-name> — 특정 크롤러를 지정합니다; 모든 크롤러에는 User-agent: *를 사용하세요.
• Disallow: /path/ — /path/ 이하 경로에 대한 크롤러의 요청을 차단합니다.
• Allow: /path/file.js — Disallow된 상위 경로 아래의 특정 경로를 명시적으로 허용합니다(주요 엔진에서 지원).
• Sitemap: https://example.com/sitemap.xml — 크롤러에게 귀하의 XML sitemap(들).
• 와일드카드: *(임의의 시퀀스 일치)와 $(문자열 끝)은 주요 엔진에서 사실상 지원됩니다; 쿼리 매개변수 패턴에는 신중히 사용하세요.
• 비표준 디렉티브: Crawl-delay와 Host는 일부 크롤러에서 인식하지만 원래 표준에 포함되지는 않습니다 — 관심 있는 user-agents에 대해 동작을 테스트하세요.

Robots.txt가 색인화 및 랭킹과 상호작용하는 방식

크롤링, 색인화, 랭킹은 별개의 단계입니다: robots.txt는 크롤링 단계(크롤러가 URL을 가져오는지 여부)에 영향을 줍니다. 색인화는 크롤러가 페이지 콘텐츠나 meta/X-Robots-Tag를 읽어야 가능합니다. 랭킹은 이후 단계로 페이지 콘텐츠에서 파생된 신호에 의존하므로, 크롤러가 페이지를 가져오지 못하면 그 신호들은 사용할 수 없습니다.

실무적 결과:

• robots.txt에서 페이지를 차단하면 검색 엔진이 해당 페이지를 가져와 meta robots noindex 태그나 구조화된 데이터를 읽을 수 없게 됩니다.
• 중요한 리소스(CSS/JS)가 차단되면 mobile-first indexing 렌더링에서 페이지를 제대로 볼 수 없게 됩니다; Google이 모바일 버전을 주요 기준으로 사용하므로 크롤링 및 색인화에 필요한 모바일 렌더링 리소스는 허용하세요. 그리고 2024년 7월 기준으로 Googlebot Smartphone이 기본 크롤러이므로 모바일 렌더링에 필요한 리소스는 허용해야 합니다.

검증: 크롤러가 실제로 무엇을 보는지 테스트하는 방법

외부에서 robots.txt 접근성과 내용을 확인하고 사이트가 실제 크롤러 요청에 어떻게 응답하는지 검증하세요. 소유한 페이지는 서버 로그, 직접 가져오기, Search Console 도구를 사용하세요.

curl로 빠르게 확인하기

robots.txt의 HTTP 응답 헤더만 가져오려면(헤더만):

• curl -I https://example.com/robots.txt — 응답 헤더만 반환합니다; 상태 코드와 Content-Type을 확인하세요.

특정 user-agent로 전체 파일을 가져오려면(본문과 지시문):

• curl -A "Googlebot" https://example.com/robots.txt — 지정한 user-agent 문자열로 파일 본문을 반환합니다.

서버 로그와 실제 크롤 증거

서버 로그에서 /robots.txt 요청과 Googlebot, Bingbot 같은 크롤러 user-agent 요청을 확인하세요. 로그는 요청 빈도, 응답 코드, 크롤러가 Disallow된 URL을 시도했는지 등을 보여줍니다. 소유한 페이지는 Search Console의 URL Inspection으로 크롤 및 색인 신호를 확인하세요; 타사 페이지는 site: 쿼리로 대략적인 징후를 볼 수 있지만 결정적이지 않습니다.

자주 있는 실수와 해결 방법

robots.txt를 관리할 때 다음 빈번한 실수를 피하세요.

• 렌더링에 필요한 CSS/JS 차단: 해결책 — Googlebot Smartphone이 페이지를 정확히 렌더링할 수 있도록 모바일 렌더링 파이프라인에 필요한 자산 경로를 허용하세요.
• robots.txt로 URL을 noindex 처리하려 기대하는 경우: 해결책 — 해당 페이지의 Disallow를 제거하고 meta robots noindex 태그나 X-Robots-Tag 응답 헤더를 사용해 검색 엔진이 지시를 볼 수 있도록 하세요.
• 민감한 URL을 robots.txt에 나열: 해결책 — robots.txt에 개인 경로를 노출하지 마세요; 인증과 서버 측 접근 제어로 보호하세요.
• 의도치 않게 유효한 페이지와 일치하는 지나치게 복잡한 와일드카드 규칙: 해결책 — 각 패턴을 샘플 URL로 테스트하고 주석으로 의도를 문서화하며 규칙을 가능한 한 구체적으로 유지하세요.

권장하는 robots.txt 전략

보수적이고 테스트 가능한 접근을 취하세요: robots.txt는 최소화하고 크롤러가 Sitemap을 발견할 수 있게 하며 색인 관리는 페이지 수준의 meta/X-Robots-Tag 제어를 우선하세요.

실용적인 패턴:

• 기본 허용 + Sitemap: User-agent: *와 Sitemap 지시문을 포함해 크롤러가 구조를 빠르게 발견하도록 하세요.
• 저가치 쿼리 페이지나 내부 검색 결과를 Disallow하되 정규화된 콘텐츠와 일치하는 파라미터 패턴까지 차단하지 마세요; 파라미터 처리는 Sitemap이나 canonical 태그로 처리하는 것을 권장합니다.
• 스테이징/개발: 스테이징이 공개된 동안에는 크롤러를 차단하되, 출시 전에 차단을 제거하거나 변경하세요; 프리프로덕션 자산 보호 수단으로 robots.txt만 의지하지 마십시오.

적용 가능한 예시

사이트맵이 있는 단순 사이트

User-agent: *
Disallow:
Sitemap: https://example.com/sitemap.xml

일반적인 CMS (admin-ajax 허용)

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xml

스테이징 차단(공개 서버이지만 아직 라이브 아님)

User-agent: *
Disallow: /

주의: 스테이징 차단은 출시 전에 반드시 제거해야 합니다; 또한 robots 파일이 변경될 경우 검색 엔진과 제3자가 실수로 인덱스하지 않도록 스테이징을 인증으로 보호하세요.

대규모에서 robots.txt 유지 관리

대형 사이트에서는 robots.txt를 구성 산출물로 취급하세요: 소스 컨트롤에 보관하고 풀 리퀘스트에서 변경을 검토하며 사이트와 함께 배포해 스테이징과 프로덕션에서 환경별로 올바른 파일을 유지하세요. 배포된 robots.txt를 가져와 대표 URL에 대해 규칙 문법을 검증하는 테스트를 자동화하세요.

여러 서브도메인을 운영하는 경우 robots.txt는 호스트별이라는 점을 기억하세요: example.com/robots.txt의 규칙은 sub.example.com에 적용되지 않습니다.

자주 묻는 질문(FAQ)

robots.txt가 페이지의 검색 결과 노출을 막을 수 있나요?

확실하지 않습니다. robots.txt는 크롤러의 페이지 가져오기를 막을 수 있지만 검색 엔진은 외부 링크나 기타 신호에 따라 여전히 URL을 색인할 수 있습니다. 색인을 막으려면 크롤링을 허용하고 페이지에 meta robots noindex 태그 또는 X-Robots-Tag: noindex 응답 헤더를 사용해 크롤러가 지시를 읽을 수 있게 하세요.

Google이 내 robots.txt를 준수하는지 어떻게 확인하나요?

외부에서, https://example.com/robots.txt curl로 파일과 상태 코드를 확인하고 서버 로그에서 Googlebot의 파일 및 크롤링 대상 페이지 요청을 검사하며, 소유한 페이지는 Search Console의 URL Inspection으로 크롤 시도와 색인 상태를 확인하세요. site: 쿼리는 공개적 징후를 제공할 수 있지만 확정적이지 않습니다.

robots.txt에서 URL 파라미터를 차단해야 하나요?

신중하세요. 파라미터화된 URL을 차단하면 크롤 예산을 절약할 수 있지만 패턴이 너무 광범위하면 정규화되거나 이미 색인된 콘텐츠를 숨길 위험이 있습니다. 가능한 경우 canonical 태그, Sitemap 내 파라미터 처리, 또는 서버 측 리디렉션을 우선하세요; 어떤 패턴도 배포 전에 철저히 테스트하세요.

Crawl-delay에 의존해도 안전한가요?

Crawl-delay는 비표준 디렉티브이며 크롤러마다 지원 여부가 다릅니다. 크롤 속도 제어가 필요한 사이트는 서버 측 속도 제한을 우선하고, robots meta 태그 은(는) 일부 페이지에 적용하거나, 다음과 같은 서비스에서 제공하는 크롤러별 설정을 사용하세요: Bing Webmaster Tools. 타깃하는 user-agents에 대해 항상 동작을 테스트하세요.