
먼저 세 줄로 보기
구글에서 우리 제품 이름을 검색하면 소개 페이지가 잘 나오는데 ChatGPT에 같은 제품을 물으면 몇 년 전 보도자료 내용만 돌아오는 경우가 있습니다.
React나 Vue로 홈페이지를 새로 만든 회사라면 “구글은 되는데 AI는 왜 못 읽지?”라는 질문이 개발팀과 마케팅팀 사이를 오갔을 겁니다.
아래에서는 React 단일 페이지 앱으로 만든 B2B SaaS 홈페이지를 예시로 듭니다. 제품 소개 페이지 12개, 탭으로 나눈 요금 비교, 아코디언 FAQ, 무한 스크롤 고객 사례 목록을 가진 사이트이며 설명을 위한 가상의 조건입니다.
자바스크립트 사이트도 원본 HTML에 본문이 들어 있으면 AI 크롤러가 읽을 수 있습니다. 하지만 자바스크립트가 실행된 뒤에야 본문이 나타나는 구조라면 상당수 AI 크롤러는 그 본문을 받지 못합니다.
크롤러가 스크립트를 실행하지 않으면 손에 남는 것은 처음 받은 HTML뿐입니다.
예시 사이트의 제품 소개 페이지를 ‘페이지 소스 보기’로 열었을 때 <div id="root"></div>와 스크립트 태그만 보인다면, 스크립트를 실행하지 않는 크롤러에게 이 페이지는 제목 정도만 있는 빈 문서입니다.
AEO(답변 엔진 최적화)에서 본문 접근이 먼저인 이유도 여기에 있습니다. 답변을 만드는 쪽이 읽지 못한 문장은 인용될 수 없습니다.
구글봇은 자바스크립트를 실행해 페이지를 그려 본 뒤 색인합니다. 반면 2024년 말 공개된 관찰에서는 OpenAI와 Anthropic, Perplexity의 크롤러가 자바스크립트를 실행하지 않았습니다.
구글 Search Central의 자바스크립트 SEO 기본 안내(2026년 3월 4일 갱신)는 구글이 자바스크립트 웹 앱을 크롤링, 렌더링, 색인의 세 단계로 처리하고 200 상태 코드 페이지를 렌더링 대기열에 넣는다고 설명합니다.
같은 문서는 서버 사이드 렌더링이나 사전 렌더링을 권하면서 모든 봇이 자바스크립트를 실행할 수 있는 것은 아니라고 적어 두었습니다.
AI 크롤러 쪽 근거는 공식 문서보다 관찰 자료에 가깝습니다. Search Engine Journal이 2024년 12월 19일 보도한 Vercel 분석은 주요 AI 크롤러가 자바스크립트 파일을 가져가기는 하지만 렌더링하지는 않는다고 정리했습니다.
Vercel 원문은 자사 네트워크에서 몇 달간 관찰한 결과로, 국가를 나누지 않은 데이터입니다. 여기서 ChatGPT 크롤러 요청의 11.50%, Claude 크롤러 요청의 23.84%가 자바스크립트 파일이었지만 실행은 하지 않았습니다. Gemini는 구글봇 인프라를 써서 렌더링한다고 적었습니다.
| 크롤러 | 자바스크립트 실행 | 근거와 시점 |
|---|---|---|
| 구글봇 (구글 검색) | 렌더링 대기열을 거쳐 실행합니다 | 구글 공식 문서, 2026년 3월 갱신 |
| Gemini | 구글봇 인프라를 써서 렌더링한다고 관찰됐습니다 | Vercel 관찰, 2024년 12월 |
| OpenAI 크롤러 (GPTBot, OAI-SearchBot, ChatGPT-User) | 파일은 가져가지만 실행하지 않는 것으로 관찰됐습니다 | Vercel 관찰, 2024년 12월 |
| ClaudeBot, PerplexityBot | 실행하지 않는 것으로 관찰됐습니다 | Vercel 관찰, 2024년 12월 |
OpenAI의 크롤러 안내 문서는 OAI-SearchBot이 ChatGPT 검색 기능에 사이트를 노출하는 데 쓰인다고 밝히지만 자바스크립트를 렌더링하는지는 적어 두지 않았습니다.
관찰 시점이 2024년 말이라 그 뒤에 동작이 바뀌었을 수 있습니다. 어느 크롤러가 렌더링하는지 확신할 수 없다면 원본 HTML에 본문을 두는 쪽이 가장 덜 위험합니다.
AI 크롤러가 본문을 놓치는 경우들의 공통점은 첫 HTML 응답 뒤에 스크립트 실행이나 사용자 동작이 있어야 본문이 생긴다는 데 있습니다.
| 경우 | 예시 사이트에서 보이는 모습 | 먼저 고려할 수정 |
|---|---|---|
| 1. 클라이언트에서만 그리는 본문 | 제품 소개 페이지 12개의 원본 HTML이 빈 root 요소뿐입니다 | 해당 경로를 서버 렌더링이나 정적 생성으로 바꿉니다 |
| 2. 클릭해야 불러오는 내용 | 자세히 보기 버튼을 눌러야 API를 호출해 기능 설명을 가져옵니다 | 설명을 처음부터 HTML에 넣고 화면에서만 접어 둡니다 |
| 3. 무한 스크롤 목록 | 고객 사례가 스크롤할 때마다 6개씩 이어 붙습니다 | 사례마다 고유 URL을 주고 페이지 번호 링크를 함께 둡니다 |
| 4. 탭을 눌러야 생기는 내용 | 요금제 비교표가 탭을 누르는 순간 만들어집니다 | 모든 탭 내용을 HTML에 넣고 CSS로 전환합니다 |
| 5. 모달 안의 본문 | FAQ 답변이 팝업 창을 열 때 불러와집니다 | 답변을 페이지 본문이나 독립 URL로 옮깁니다 |
| 6. 해시(#) 주소로 나눈 화면 | /#/pricing처럼 해시 뒤만 바뀌며 화면이 전환됩니다 | History API로 /pricing 같은 실제 경로를 씁니다 |
| 7. 자바스크립트로만 만든 링크 | 메뉴가 onclick으로만 이동하고 href가 없습니다 | href가 있는 a 요소로 바꿉니다 |
| 8. 스크립트로 넣는 제목과 구조화 데이터 | title, 메타 설명, JSON-LD를 실행 후에 주입합니다 | 서버 응답 HTML에 처음부터 넣습니다 |
3번과 4번은 구글 문서에도 근거가 있습니다. 구글의 지연 로딩 안내(2025년 12월 10일 갱신)는 구글 검색이 페이지와 상호작용하지 않으니 스크롤이나 클릭에 의존해 콘텐츠를 불러오지 말라고 하고, 무한 스크롤은 덩어리마다 고유 URL을 주라고 권합니다.
6번과 7번은 앞의 자바스크립트 SEO 기본 안내가 근거입니다. 해시 조각으로 다른 페이지 내용을 불러오지 말고 링크는 href가 있는 a 요소로 만들라고 적혀 있습니다.
💡 화면에서 접어 둔 내용도 안 읽히나요? 아코디언이나 탭이라도 내용이 원본 HTML에 이미 들어 있고 CSS로만 숨긴 경우라면 크롤러가 받는 문서에는 그 문장이 있습니다. 문제는 클릭하는 순간 내용을 새로 불러오는 구조입니다.
사이트 구조 전체를 AI가 읽기 좋은 형태로 바꾸는 범위가 궁금하다면 리드젠랩 웹사이트 GEO에서 진단 항목을 확인해 보세요.
AI 크롤러에 빈 페이지로 보이는지는 원본 HTML에서 그 페이지의 핵심 문장을 찾아보는 것만으로 대부분 가려낼 수 있습니다.
curl -s URL로 받은 HTML에서 그 문장을 검색합니다. 개발자 도구의 요소 패널은 실행 뒤 화면이라 이 확인에 쓰지 않습니다.2단계에서 사용자 에이전트를 바꿔 curl -A "GPTBot" URL로 받아 보는 방법도 쓰이는데요, 이것은 서버가 봇에게 다른 HTML을 주는지 확인하는 용도일 뿐 AI 크롤러의 실제 동작을 재현하지는 않습니다.
수정 뒤 효과를 볼 때는 지표를 나눠 기록해 보세요. 답변에 브랜드명이 나온 비율인 언급률, 우리 URL이 출처로 채택된 비율인 출처 인용률, 언급이나 인용이 하나라도 확인된 고유 질문의 비율인 질문 커버리지는 서로 다른 숫자입니다.
렌더링 수정은 출처로 채택될 수 있는 페이지를 늘리는 작업이라 출처 인용률을 따로 보는 편이 맞습니다. 다만 같은 기간에 콘텐츠를 함께 고쳤다면 그 변화를 렌더링 수정 하나의 결과로 보기는 어렵습니다.
사이트 전체를 서버 사이드 렌더링(SSR)으로 바꿀 필요는 없고, AI 답변에 인용되길 바라는 페이지만 서버에서 완성된 HTML을 내려보내도 충분합니다.
| 방식 | 원본 HTML의 본문 | 렌더링하지 않는 크롤러 | 개발 부담 | 어울리는 페이지 |
|---|---|---|---|---|
| 클라이언트 렌더링(CSR) | 비어 있거나 일부만 있습니다 | 본문을 받지 못합니다 | 추가 작업 없음 | 로그인 뒤 대시보드, 계정 설정 |
| 서버 사이드 렌더링(SSR) | 요청마다 완성된 본문이 들어갑니다 | 본문을 받습니다 | 서버 운영과 캐시 설정이 필요합니다 | 재고나 가격이 자주 바뀌는 페이지 |
| 정적 생성(SSG) | 빌드 시점에 완성된 본문이 들어갑니다 | 본문을 받습니다 | 내용을 바꿀 때마다 다시 빌드합니다 | 제품 소개, 블로그, FAQ |
| 혼합 방식 (증분 재생성, 부분 하이드레이션) | 핵심 본문은 서버에서, 부가 기능은 브라우저에서 만듭니다 | 핵심 본문은 받습니다 | 프레임워크 지원 범위에 따라 다릅니다 | 사례 목록, 요금 페이지 |
예시 사이트라면 제품 소개 12개와 FAQ는 정적 생성으로, 요금 비교와 고객 사례 목록은 혼합 방식으로, 로그인 뒤 화면은 지금처럼 두는 식으로 나눌 수 있습니다.
프레임워크를 바꾸기 어렵다면 사전 렌더링 서비스로 봇에게 완성된 HTML을 주는 방법도 있습니다. 이때 봇과 사람이 받는 내용은 같아야 합니다.
페이지 유형별로 어떤 방식이 맞는지와 그 뒤 콘텐츠 작업까지 한 번에 정리하고 싶다면 리드젠랩 GEO·AEO 서비스 구성을 참고해 보세요.
구글에 잘 나온다고 해서 AI 크롤러도 같은 본문을 읽는다고 볼 수는 없습니다. 구글봇은 자바스크립트를 렌더링한 뒤 색인하므로 원본 HTML이 비어 있는 페이지도 구글 검색에는 정상으로 보일 수 있습니다. 원본 HTML에 핵심 문장이 있는지를 따로 확인하세요.
SPA라는 사실보다 원본 HTML에 본문이 있는지가 인용 가능성을 가릅니다. 서버 렌더링을 지원하는 프레임워크라면 설정에 따라 본문을 담을 수 있으니 실제 응답을 확인해 보세요.
robots.txt 허용은 접근을 막지 않았다는 뜻일 뿐이라 본문 전달 여부는 따로 봐야 합니다. 서버 로그에서 AI 봇 요청의 응답 코드를 확인하고, 그다음 원본 HTML에 본문이 있는지 보세요. OpenAI는 robots.txt 변경이 검색 결과에 반영되기까지 약 24시간이 걸릴 수 있다고 안내합니다.
자바스크립트 AI 크롤러 문제는 원본 HTML에 본문이 있는지로 대부분 판가름 납니다. 인용되길 바라는 페이지부터 핵심 문장이 원본 HTML에 들어 있는지 확인하고, 빠져 있다면 그 페이지만 서버 렌더링이나 정적 생성으로 바꾸는 것으로 시작하면 됩니다.
리드젠랩은 워드프레스와 스키마, 코어 웹 바이탈을 코드 단계에서 직접 구현해 온 팀이라 렌더링 진단 결과를 개발팀이 바로 적용할 수 있는 수정안으로 정리하고, 워드프레스 사이트라면 수정까지 직접 맡습니다. 수정한 페이지가 AI 답변의 출처로 잡히는지는 직접 개발해 운영하는 SOHA로 질문마다 기록해 수정 전과 비교합니다. 대표 포함 15인 팀 안에 개발과 콘텐츠 담당이 함께 있어, 렌더링을 고친 페이지의 문장까지 같은 일정 안에서 다듬습니다.
우리 사이트의 주요 페이지 주소 몇 개를 보내 주시면, 원본 HTML에 본문이 들어 있는지와 어떤 페이지부터 렌더링 방식을 바꿔야 할지 정리해 드립니다.