본문 바로가기

AI CRAWLER ACCESS

AI 크롤러 최적화 —
인용되기 전에, 먼저 읽혀야 합니다

답변엔진이 우리를 근거로 쓰려면 그 전에 우리 문서를 가져갈 수 있어야 합니다. robots.txt·방화벽·렌더링 세 층에서 크롤러가 어디에 막혀 있는지 확인하고, 막힌 지점을 열고, 실제로 다시 방문했는지를 기록으로 확인합니다.

한 문단 요약

AI 크롤러 최적화는 답변엔진의 수집 봇이 사이트를 실제로 가져갈 수 있는 상태로 만드는 기술 작업입니다. 인용은 그다음 문제입니다 — 문서를 읽지 못한 엔진은 그 문서를 근거로 삼을 수 없기 때문입니다. robots.txt 규칙, 방화벽·WAF·봇 차단 서비스, 자바스크립트에만 의존하는 렌더링 중 한 곳만 막혀 있어도 결과는 같습니다.

다만 크롤러가 왔다는 것과 AI가 우리를 인용한다는 것은 서로 다른 사실입니다. 나비랑은 크롤러 방문(A)·AI 답변 인용(B)·AI 경유 방문(C)을 처음부터 다른 지표로 나눠 기록합니다. 이 페이지의 작업이 책임지는 범위는 A이며, B는 진단과 모니터링에서, C는 유입 분석에서 따로 확인합니다.

학습 봇 · 검색 봇 구분robots.txt · WAF · 렌더링방문 기록으로 확인

최종 확인

WHEN YOU NEED THIS

이런 문제가 있을 때
필요한 작업입니다

상담에서 실제로 반복해서 듣는 상황입니다. 하나라도 해당되면 측정부터 하시면 됩니다.

robots.txt는 열어 뒀는데 크롤러가 오지 않습니다

차단은 robots.txt에만 걸리는 것이 아닙니다. 호스팅·CDN·WAF·봇 차단 서비스가 별도의 층에서 User-Agent나 IP 대역으로 거부하면 robots.txt 내용과 무관하게 문서는 전달되지 않습니다.

아무도 손댄 적이 없다는데 robots.txt에 Disallow: /가 있습니다

개발·스테이징 단계에서 막아 둔 설정이 공개 뒤에도 그대로 남아 있는 경우가 가장 흔합니다. 빌더나 솔루션이 기본값으로 넣어 둔 규칙도 섞여 있어, 이 파일을 누가 고칠 수 있는지부터 확인해야 손을 댈 수 있습니다.

보안 담당자는 막자고 하고 마케팅은 열자고 합니다

양쪽이 서로 다른 봇을 놓고 이야기하는 경우가 많습니다. 학습 데이터를 모으는 봇, 답변 근거로 쓸 문서를 모으는 봇, 사용자가 물었을 때 그 자리에서 찾아오는 봇은 이름부터 다릅니다. 논의를 봇 단위로 쪼개 놓으면 대부분 합의가 됩니다.

허용은 다 열었는데도 가져갈 본문이 없습니다

이 경우는 차단이 아니라 빈손입니다. 봇은 200 응답을 정상으로 받아 가는데 그 안에 문장이 없으므로, 접근 설정을 아무리 손봐도 결과는 달라지지 않습니다. 고칠 대상이 허용 규칙이 아니라 렌더링 방식인 상태입니다.

WHAT WE DO

나비랑이
실제로 하는 일

추상적인 제안 대신 작업 단위로 적습니다. 계약 범위도 이 목록에서 정합니다.

차단 지점 확인

지금 어느 층에서 막혀 있는지부터 특정합니다. robots.txt·인프라·렌더링 중 무엇이 원인인지 가르지 않으면 엉뚱한 곳을 고치게 됩니다.

  • robots.txt 원문과 그룹 구조 확인
  • 호스팅 · CDN · WAF · 봇 차단 서비스의 규칙 확인
  • 공개된 봇 IP 대역이 차단 목록에 걸려 있는지 확인
  • 봇 User-Agent로 요청했을 때의 상태 코드 · 리다이렉트 체인

robots.txt 규칙 정리

허용·차단 의도를 그룹별로 정확히 표현합니다. 그룹이 상속되지 않는다는 규칙 때문에, 의도한 대로 적었어도 실제 적용이 다른 경우가 흔합니다.

  • User-Agent 그룹마다 Allow · Disallow 반복 적용
  • 학습용(GPTBot · ClaudeBot)과 검색용(OAI-SearchBot · Claude-SearchBot) 분리 표기
  • 관리자 · API · 로그인 영역 등 인용될 일이 없는 경로 제외
  • 변경 의도를 주석으로 남겨 다음 담당자가 되돌리지 않게

인프라 통과 규칙 정리

robots.txt가 허용이어도 보안 장비가 봇을 거절하면 결과는 차단과 같습니다. OpenAI 공식 문서가 공개 IP 대역 허용을 포함 조건으로 드는 이유입니다.

  • 봇 차단 규칙의 예외 목록에 검색용 크롤러 등록
  • 자바스크립트 챌린지 · 캡차가 봇 요청에 걸리는지 확인
  • 속도 제한으로 인한 429 · 403 응답 여부 확인
  • 권한이 없는 영역은 변경안을 문서로 전달해 담당자가 적용

렌더링 방식 점검

본문이 HTML 원문에 있는지를 페이지 단위로 확인합니다. 크롤러가 받는 것은 브라우저 화면이 아니라 서버가 처음 보내는 응답이기 때문입니다.

  • 원문에 본문 · 제목 · 링크가 존재하는 페이지와 그렇지 않은 페이지 구분
  • 클라이언트 렌더 화면을 서버 렌더 또는 정적 출력으로 전환
  • 탭 · 아코디언 · 더보기 뒤에 숨은 본문이 원문에 포함되는지 확인
  • 이동 경로를 스크립트가 아닌 정식 링크 태그(href)로

허용 · 차단 판단 정리

전면 허용이 맞는 사업과 선별 차단이 합리적인 사업이 다릅니다. 홈페이지가 홍보 수단인 대부분의 사업은 전면 허용이 맞고, 콘텐츠 자체가 상품인 매체는 학습용만 막는 절충을 검토합니다.

  • 사업 유형별 전면 허용 · 선별 차단 판단
  • Google-Extended는 크롤러가 아니라 제어 토큰이며 구글 검색 색인·순위와 무관함을 전제로 판단
  • 결정과 근거를 문서로 남겨 이후 변경 이력을 추적

크롤러 방문 기록 관찰

열었으면 실제로 다시 왔는지를 로그에서 확인합니다. '설정을 바꿨다'로 끝내면 규칙이 의도대로 적용됐는지, 그 뒤에 봇이 실제로 왔는지를 아무도 모르는 상태가 됩니다.

  • 서버 · CDN 접근 로그에서 봇별 요청 추출(로그 열람이 가능한 환경에 한함)
  • 봇별 재방문 여부 · 요청 경로 · 상태 코드 정리
  • 봇 요청 중 404가 난 경로를 검토 후보로 목록화
  • User-Agent는 위조 가능하므로 '감지된 크롤러'로만 해석

PROCESS

어떤 순서로
진행되나요

단계마다 무엇을 드리는지 함께 적습니다. 기간은 나비랑이 통제하는 작업 시간이며, 결과가 나타나는 시점을 약속하는 값이 아닙니다.

  1. 01 2~3일

    접근 현황 확인

    robots.txt·인프라 규칙·렌더링을 한 번에 훑어 어느 층에서 막히는지 특정합니다. 자료 제출 없이 공개된 상태만으로 시작합니다.

    크롤러 접근 점검표

  2. 02 1~2일

    허용 정책 결정

    사업 유형에 맞춰 전면 허용인지 선별 차단인지 정합니다. 학습용과 검색용을 나눠 결정하고, 그 판단 근거를 함께 적습니다.

    크롤러 허용 정책 문서

  3. 03 1~3일

    규칙 적용

    robots.txt를 그룹 규칙에 맞게 다시 쓰고, 봇 차단 규칙에 예외를 등록합니다. 저희 계정으로 손댈 수 없는 항목은 적용 후 확인 방법까지 적어 담당자에게 넘깁니다.

    적용된 robots.txt · 차단 규칙 변경 내역

  4. 04 사이트 구조에 따라

    렌더링 보완

    본문이 원문에 없는 페이지를 서버 렌더 또는 정적 출력으로 바꿉니다. 구조 변경 범위가 크면 사이트 재구축 여부를 먼저 상의합니다.

    본문이 원문에 담긴 페이지 · 변경 내역

  5. 05 적용 후 관찰

    방문 기록 확인

    로그에서 봇별 재방문과 응답 코드를 확인해 접근이 실제로 열렸는지 검증합니다. 여기서 확인하는 것은 방문이지 인용이 아닙니다.

    크롤러 방문 기록 요약

DELIVERABLES

무엇을
받으시나요

말로 끝나는 작업을 만들지 않습니다. 아래 문서가 그대로 남아 다음 측정의 기준이 됩니다.

크롤러 접근 점검표

봇별로 통과·차단 상태와 막힌 층(robots.txt·인프라·렌더링)을 표시한 표입니다. 원인 층이 특정돼 있어야 고칠 곳이 정해집니다.

robots.txt 변경안

적용 전·후 원문과 그룹별 규칙, 그렇게 쓴 이유를 주석으로 함께 드립니다. 다음 담당자가 규칙을 되돌리지 않게 하는 것이 목적입니다.

차단 규칙 예외 목록

CDN·WAF·봇 차단 서비스에 등록해야 할 예외 항목을 정리한 목록입니다. 권한이 없어 저희가 적용할 수 없는 항목은 따로 표시합니다.

렌더링 점검 결과

HTML 원문에 본문이 있는 페이지와 없는 페이지를 나눈 목록입니다. 자바스크립트를 실행하지 않은 상태의 응답을 기준으로 판정합니다.

크롤러 방문 기록 요약

봇별 요청 수·경로·상태 코드를 정리한 기록입니다. User-Agent 기반 감지값이라는 한계를 문서 안에 함께 적습니다. 접근 로그를 열람할 수 없는 환경이면 대신 확인할 방법을 착수 전에 합의합니다.

크롤러는 이름마다 역할이 다릅니다

학습용 봇
GPTBot(OpenAI) · ClaudeBot(Anthropic) — 모델 학습 데이터 수집
검색용 봇
OAI-SearchBot(OpenAI) · Claude-SearchBot(Anthropic) · PerplexityBot — 답변 근거 색인
사용자 요청 방문
ChatGPT-User · Claude-User · Perplexity-User — 사용자가 물었을 때 그 자리에서 방문
Google-Extended
크롤러가 아니라 robots.txt 제어 토큰(고유 User-Agent 없음). 구글 검색 색인·순위와 무관
제어가 걸리는 층
robots.txt · 호스팅/CDN/WAF의 UA·IP 규칙 · 렌더링 방식 — 셋 중 하나만 막혀도 결과는 같습니다
지표 구분
A 크롤러 방문 · B AI 답변 인용 · C AI 경유 방문 — 서로 다른 지표이며 A가 B를 만들지 않습니다

robots.txt는 자율 준수 규약이고 User-Agent 문자열은 위조할 수 있습니다. 그래서 방문 기록은 '감지된 AI 크롤러'로만 읽고, 실제로 막아야 하는 콘텐츠는 인증 뒤에 두거나 서버 단에서 차단합니다. 나비랑은 자사 사이트에서도 같은 전제로 크롤러 요청 기록을 수집해 관찰하고 있습니다.

HOW IT CONNECTS

다른 작업과
어떻게 이어지나요

나비랑의 작업은 한 덩어리로 굴러갑니다. SEO는 검색엔진에서 발견될 기반을 만들고, AEO는 그 정보가 답변에서 인용될 가능성을 높이며, 구조화 데이터는 기계가 사실을 이해하도록 돕고, 콘텐츠는 인용할 근거를 만듭니다.

영역 이 작업과의 관계
인용 콘텐츠 설계 읽히기 시작한 다음, 인용될 수 있는 문서 구조로 다시 쓰는 작업
구조화 데이터 가져간 문서에서 기계가 사실을 읽을 수 있게 하는 층
색인 크롤이 열린 뒤 검색엔진 색인에 실제로 들어갔는지 확인하는 영역
인용 모니터링 크롤러 방문(A)이 아니라 AI 인용(B)이 변했는지를 재측정
AEO 홈페이지 제작 렌더링 구조 자체가 원인일 때 처음부터 다시 만드는 선택지

FAQ

자주 묻는 질문

Q AI 크롤러 최적화는 무엇을 하는 작업인가요?

A 답변엔진의 수집 봇이 사이트 문서를 실제로 가져갈 수 있도록 접근 조건을 정비하는 기술 작업입니다. robots.txt의 그룹별 허용 규칙, 호스팅·CDN·WAF·봇 차단 서비스의 User-Agent·IP 규칙, 그리고 본문이 HTML 원문에 존재하는지를 함께 점검합니다. 세 층 중 하나만 막혀 있어도 크롤러에게는 읽을 것이 없는 사이트가 됩니다.

Q AI 크롤러를 허용하면 AI 답변에 인용되나요?

A 아닙니다. 접근 허용은 인용의 전제 조건이지 인용 자체가 아닙니다. 크롤러 방문(A)과 AI 답변 인용(B), AI 답변을 거친 실제 방문(C)은 각각 다른 지표이고, 이 작업이 책임지는 범위는 A입니다. OpenAI도 공식 문서에서 OAI-SearchBot 크롤링 허용과 공개 IP 대역 허용을 포함의 전제로 들면서, 상위 배치를 보장할 방법은 없다고 명시하고 있습니다.

Q 학습에는 쓰이지 않으면서 AI 답변에는 나올 수 있나요?

A 봇 이름이 용도별로 분리된 회사에 한해 가능합니다. OpenAI는 학습용 GPTBot과 검색용 OAI-SearchBot을 서로 다른 이름으로 두었고, 공식 문서에도 앞의 것만 차단하고 뒤의 것은 열어 두는 설정이 예시로 실려 있습니다. 다만 모든 회사가 이름을 나눠 두지는 않았고, 검색용까지 막으면 그 엔진의 답변에서 브랜드 이름 자체가 사라집니다.

Q robots.txt에 크롤러별 규칙을 추가했는데 왜 원래 Disallow가 적용되지 않나요?

A User-Agent 그룹이 별표(*) 그룹을 상속하지 않고 대체하기 때문입니다. 특정 크롤러 이름으로 그룹을 하나 만들면 그 크롤러는 자기 그룹만 읽으므로, 별표 그룹에 적어 둔 Disallow는 그 크롤러에게 적용되지 않습니다. 관리자 화면이나 API 경로를 제외하려면 같은 Disallow를 각 그룹 안에 반복해서 적어야 합니다.

Q Google-Extended를 막으면 구글 검색에서 사라지나요?

A 아닙니다. Google-Extended는 별도의 크롤러가 아니라 robots.txt에서만 쓰이는 제어 토큰이고, 관장 범위는 Gemini 앱·Vertex AI의 학습과 그라운딩입니다. 구글 검색 색인과 순위에는 영향이 없습니다. 반대로 Googlebot을 막으면 검색 자체에서 빠지므로 둘을 혼동하지 않아야 합니다.

Q 우리 사이트가 크롤러를 막고 있는지 어떻게 확인하나요?

A robots.txt · 인프라 · 렌더링 순서로 세 층을 열어 보면 확인됩니다. 먼저 브라우저에서 도메인 뒤에 /robots.txt를 붙여 원문을 확인하고, Disallow: / 가 어느 그룹에 걸려 있는지 봅니다. 그다음이 인프라입니다 — 봇 User-Agent로 요청했을 때 403·429가 돌아오는지, CDN·WAF·봇 차단 서비스의 규칙이나 IP 차단 목록에 걸리는지 확인합니다. 마지막으로 자바스크립트를 실행하지 않은 상태의 HTML 원문에 본문이 들어 있는지 봅니다. 어느 층에서 멈추는지가 곧 고칠 곳입니다.

Q 차단을 풀면 언제부터 크롤러가 다시 오나요?

A 즉시는 아니며 시점을 약속할 수 없습니다. 재방문 주기는 엔진과 사이트마다 다르고, 저희가 통제할 수 있는 값이 아니기 때문입니다. 대신 접근 로그에서 봇별 요청을 계속 관찰해 재방문이 실제로 일어났는지를 기록으로 확인하고, 인용 여부는 같은 질문을 반복 측정하는 모니터링에서 따로 잽니다.

함께 보면 좋은 페이지

관련 인사이트

지금 답변엔진이 우리 사이트를 읽을 수 있는 상태일까요?

홈페이지 주소만 주시면 robots.txt·인프라 차단·렌더링 세 층을 점검해 어디서 막히는지 알려드립니다. 확인 결과는 점검표로 그대로 드립니다.

영업일 기준 1일 내 회신드립니다.

SERVICES

서비스 바로가기

전체 서비스 자세히 보기
무료진단 전화상담 이메일 블로그