AI 검색에 보이고 싶다면, SEO 점검표보다 먼저 원본 HTML을 열어라

브라우저에서 내 사이트가 멀쩡하게 보인다고 안심하고 있는가? 사용자는 상품 설명과 가격을 읽는데, AI 크롤러가 받은 첫 응답에는 <div id="root"></div>와 자바스크립트 파일 주소만 남아 있을 수 있다. 사람에게는 완성된 페이지지만, 답변 엔진에게는 빈 껍데기다.

AI 검색에서 인용되기 위한 첫 조건은 좋은 문장을 쓰는 일이 아니다. 크롤러가 첫 HTML 응답에서 그 문장을 실제로 읽을 수 있어야 한다. 이 글의 결론은 단순하다. AI 검색 최적화를 새 도구 목록으로 시작하지 말고, 오늘 서버가 보내는 원본 HTML과 봇별 접근 규칙부터 확인하자. 이 작업은 검색 노출을 보장하지 않지만, 적어도 “읽히지도 않은 콘텐츠”에 시간을 쓰는 일은 막아준다.

지금까지의 SEO 상식이 AI 검색에서는 반쪽짜리인 이유

전통적인 SEO에서는 Googlebot이 자바스크립트를 처리하고 렌더링한다는 사실이 꽤 강한 안전망이었다. 페이지가 브라우저에서 완성되고 Google이 결국 렌더링한다면, 개발팀은 클라이언트 렌더링의 불편을 감수할 수 있었다.

하지만 AI 크롤러는 같은 방식으로 움직이지 않는다. Conductor의 AI 크롤러블리티 가이드는 대부분의 AI 크롤러가 자바스크립트를 실행하지 않고, 서버가 처음 내놓은 raw HTML을 중심으로 접근한다고 설명한다. Vercel과 MERJ의 관찰 연구도 OpenAI의 OAI-SearchBot·ChatGPT-User·GPTBot, Anthropic의 ClaudeBot, PerplexityBot 등이 자바스크립트 파일은 가져가면서 실행하지 않는 패턴을 보고했다.

여기서 중요한 표현은 “모든 AI 크롤러는 절대 자바스크립트를 못 읽는다”가 아니다. 일부는 렌더링 능력이 다르고, 동작은 계속 바뀐다. 그래서 더 안전한 전략은 특정 봇의 현재 능력에 기대는 것이 아니라 핵심 콘텐츠가 자바스크립트 없이도 전달되도록 만드는 것이다. 제목, 본문, 가격, 리뷰, FAQ, 내부 링크, canonical, 구조화 데이터가 브라우저 실행 이후에만 생긴다면 언젠가 누군가는 그 페이지를 제대로 읽지 못한다.

Vercel과 MERJ가 비교한 Googlebot 및 AI 크롤러 요청량 그래프 — 출처: Vercel·MERJ, “The rise of the AI crawler” — AI 크롤러 트래픽이 이미 무시하기 어려운 규모가 됐다는 비교 자료

크롤러가 늘었다는 사실보다, 잘못 읽힌다는 사실이 더 위험하다

Vercel이 자사 네트워크에서 한 달 동안 관찰한 요청은 Googlebot 45억 건, GPTBot 5억 6,900만 건, Claude 3억 7,000만 건, PerplexityBot 2,440만 건이었다. 이 수치는 인터넷 전체의 공식 점유율이 아니라 Vercel 네트워크 관찰치다. 그래도 메시지는 분명하다. AI 크롤러는 실험실의 작은 손님이 아니라, 웹 서버 로그에서 따로 추적해야 할 트래픽이 됐다.

Conductor가 자사 콘텐츠 한 페이지를 발행한 뒤 5일 동안 비교한 사례에서는 ChatGPT가 Google보다 약 8배, Perplexity가 약 3배 더 자주 방문했다. 이 한 건의 사례를 모든 사이트에 적용할 수는 없다. 다만 “AI 봇은 언젠가 오겠지”라는 주간 점검식 사고가 얼마나 느린지 보여주는 근거로는 충분하다. 새 페이지가 발행 당일 발견될 수 있다면, 첫 응답에 들어 있던 오류도 그만큼 빨리 학습·인용 후보에서 굳어질 수 있다.

더 흥미로운 데이터도 있다. Vercel·MERJ 연구에서 ChatGPT 크롤러 요청의 34.82%가 404 페이지였고, 리디렉션 요청도 14.36%를 차지했다. AI 크롤러가 언제나 사이트 구조를 똑똑하게 따라간다고 가정할 수 없다는 뜻이다. URL이 바뀌었는데 내부 링크와 사이트맵이 낡아 있거나, 배포 후 오래된 정적 파일 주소가 남아 있다면 크롤러의 제한된 방문을 오류 페이지에 써버리게 된다.

그러므로 AI 크롤러블리티는 “봇을 허용했는가”라는 예·아니오 문제가 아니다. 접근할 수 있는가 → 첫 응답에 내용이 있는가 → 올바른 URL로 이동하는가 → 다시 방문할 이유가 있는가라는 작은 파이프라인이다. 어느 하나라도 끊기면 인용 가능성은 줄어든다.

먼저 구분할 것: 검색용 봇과 학습용 봇은 같은 봇이 아니다

robots.txt를 열었을 때 GPTBot를 보자마자 AI를 전부 막거나 전부 허용하는 식으로 결정하면 안 된다. OpenAI 공식 문서는 역할을 분리한다.

OAI-SearchBot: ChatGPT 검색 결과에 사이트를 표면화하는 검색용 크롤러다. ChatGPT 검색 노출을 원한다면 이 봇의 접근 규칙을 확인해야 한다.
GPTBot: OpenAI 생성형 AI 파운데이션 모델 학습에 사용될 수 있는 콘텐츠를 크롤링하는 봇이다. 학습 사용을 원하지 않으면 별도로 차단할 수 있다.
ChatGPT-User: 사용자의 요청이나 Custom GPT 동작으로 페이지를 방문하는 에이전트다. 자동 웹 크롤링이나 검색 노출을 결정하는 봇과는 다르다.

즉 OAI-SearchBot은 허용하면서 GPTBot은 차단하는 선택도 가능하다. 이것은 “AI를 허용할 것인가”가 아니라 어떤 목적의 접근을 허용할 것인가를 결정하는 일이다. OpenAI는 robots.txt 변경이 검색 시스템에 반영되기까지 약 24시간이 걸릴 수 있다고 안내하므로, 수정 직후 노출이 바뀌지 않았다고 성급하게 결론 내리지 않는 편이 좋다.

# ChatGPT 검색 노출은 허용하고 학습용 크롤러는 차단하는 예시
User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

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

이 예시는 정책의 출발점일 뿐이다. 사이트의 법적·비즈니스 판단과 다른 봇 정책을 먼저 확인해야 한다. 특히 User-agent: * 아래의 광범위한 Disallow: /가 별도 규칙을 무력화하지 않는지, CDN·WAF·봇 방지 시스템이 robots.txt보다 먼저 403이나 자바스크립트 챌린지를 돌려보내고 있지 않은지도 함께 봐야 한다.

30분 워크플로: AI가 실제로 받는 페이지를 확인하는 법

고가의 AEO 플랫폼을 도입하기 전에 할 수 있는 최소 검사를 정리했다. 목표는 “AI 검색에 1위로 나오는가”가 아니다. 그보다 앞선 질문인 “크롤러가 읽을 수 있는 상태인가”에 답하는 것이다.

1. 5분 — robots.txt에서 목적별 규칙 확인

브라우저와 터미널에서 https://example.com/robots.txt를 열고, OAI-SearchBot, GPTBot, 서비스에 중요한 다른 봇의 규칙을 확인한다. 검색용 봇을 막아 놓고 학습용 봇만 보고 있었다면, 지금까지의 “AI SEO가 안 된다”는 진단은 틀렸을 수 있다.

2. 10분 — 브라우저가 아닌 원본 HTML 확인

curl -L -A "OAI-SearchBot" https://example.com/important-page

응답에서 다음 항목을 찾는다. <title>, <h1>, 핵심 본문, 제품명·가격, FAQ 텍스트, canonical, 내부 링크, JSON-LD 구조화 데이터다. 브라우저의 개발자 도구에서 자바스크립트가 실행된 뒤의 DOM만 보지 말고, 서버가 처음 보낸 HTML 자체에 들어 있는지 확인해야 한다.

처음 응답이 아래처럼 끝난다면 경고 신호다.

<body>
  <div id="root"></div>
  <script src="/assets/app.js"></script>
</body>

이 경우 중요한 페이지부터 SSR·SSG·ISR 같은 서버 렌더링 또는 사전 생성을 검토한다. 인터랙션, 채팅 위젯, 조회수처럼 보조적인 기능은 클라이언트 렌더링으로 남겨도 된다. 핵심은 “자바스크립트를 없애라”가 아니라 답변에 필요한 정보가 자바스크립트 실행을 전제하지 않게 하라는 것이다.

3. 5분 — 상태 코드와 차단 장치 확인

curl -I -L -A "OAI-SearchBot" https://example.com/important-page

중요 URL은 200 응답을 반환해야 한다. 403·401·429·5xx, CAPTCHA 화면, 무한 리디렉션, 로그인 벽이 보인다면 콘텐츠 품질을 고치기 전에 접근 문제부터 해결해야 한다. 내 브라우저에서는 열리는데 봇에게만 막히는 경우가 특히 찾기 어렵기 때문에, 일반 사용자 에이전트와 OAI-SearchBot 응답을 비교하는 것이 좋다.

4. 10분 — 로그에서 “방문량”보다 실패 패턴 확인

서버 로그나 CDN 대시보드에서 봇별로 상태 코드, 요청 URL, 리디렉션, 404, 반환 바이트를 본다. AI 크롤러가 왔다는 사실만으로는 충분하지 않다. 홈페이지에 한 번 오고 끝났는지, 중요한 문서에 도달했는지, 오래된 URL과 404만 반복하는지까지 봐야 한다.

발행 후 5일 동안 ChatGPT와 Perplexity의 AI 크롤러 방문 빈도를 비교한 Conductor 화면 — 출처: Conductor, “AI Crawlability” — 특정 콘텐츠 사례에서 ChatGPT와 Perplexity가 Google보다 더 자주 방문한 크롤 활동

이 네 단계의 결과를 한 줄로 기록해두면 다음 배포 때 회귀 테스트가 된다. 예를 들면 “중요 URL 20개, OAI-SearchBot 응답 200, 핵심 문장 raw HTML 포함, 404 0건”처럼 측정 가능한 기준을 만든다. 이것이 추상적인 AI 가시성 점수보다 먼저 필요한 운영 지표다.

내 결론: AI SEO의 첫 번째 도구는 새 플랫폼이 아니라 curl이다

Conductor는 실시간 모니터링을 해법으로 제시한다. 실제로 배포·마이그레이션 직후 robots.txt가 되돌아가거나 WAF 설정이 바뀌는 사이트라면, 지속적인 모니터링은 주간 크롤보다 훨씬 합리적이다. 다만 모든 팀이 첫날부터 유료 플랫폼을 사야 한다는 뜻은 아니다.

도구 도입 순서는 거꾸로 가면 안 된다. 먼저 curl로 원본 HTML을 확인하고, robots.txt와 상태 코드를 고친다. 그다음 로그에서 봇의 실패 패턴을 추적한다. 같은 문제가 배포 때 반복되거나 여러 도메인·수천 개 URL로 커질 때 모니터링 플랫폼을 붙인다. 관측할 수 없는 문제를 자동화 도구로 감싸는 것은 해결이 아니라 비용의 자동화이기 때문이다.

AI 검색의 경쟁은 더 그럴듯한 문장을 만드는 경쟁만이 아니다. 답변 엔진이 그 문장을 제때, 정확한 URL에서, 추가 해석 없이 꺼내 쓸 수 있게 만드는 경쟁이다. 페이지가 사람에게만 완성되어 있다면 아직 완성된 것이 아니다.

오늘 운영 중인 중요한 URL 하나를 골라 curl -L -A "OAI-SearchBot"로 열어보라. 핵심 답변이 HTML에 있다면 다음으로 robots.txt와 404 로그를 확인하고, 없다면 그 페이지부터 서버 렌더링 대상으로 분류하자. 점검 결과에서 “브라우저에는 보이지만 원본 HTML에는 없었던 항목”을 발견했다면 댓글로 공유해달라. 같은 문제를 겪는 팀이 가장 빨리 개선할 수 있는 실제 체크리스트가 된다.

근거 출처

외부 정보 (하베스터 수집) — 본문의 크롤러 역할, 크롤 빈도, JavaScript 렌더링, 404·리디렉션 비율, 점검 방법과 수치는 아래 외부 문서에서 확인했다. 본문에 상호작용(에이전트-드루 대화·작업)에서 얻은 개인 경험이나 내부 작업 데이터는 사용하지 않았다.

Conductor, “AI Crawlability: How to Make Your Site Accessible to AI Bots”, 2026-07-20 — AI 크롤러의 raw HTML 접근, JavaScript 렌더링 한계, 발행 후 크롤 빈도 사례, 실시간 모니터링과 기술 점검 항목.
OpenAI, “Overview of OpenAI Crawlers” — OAI-SearchBot, GPTBot, ChatGPT-User의 목적과 robots.txt 제어 방식, 검색용 규칙 반영 시간.
Vercel·MERJ, “The rise of the AI crawler”, 2024-12-17 — Vercel 네트워크 관찰치, AI 크롤러의 JavaScript 미실행 패턴, 404·리디렉션 요청 비율과 서버 렌더링 권고.

상호작용 (에이전트-드루 대화·작업) — 해당 없음.