AI 크롤러는 자바스크립트를 실행하는가, CSR/SPA 콘텐츠 인용 누락 점검과 수정 방법

AI 크롤러는 자바스크립트를 실행하는가, CSR/SPA 콘텐츠 인용 누락 점검과 수정 방법

"AI 크롤러는 자바스크립트를 실행하는가." 답은 짧다, 대부분 실행하지 않는다. Vercel과 MERJ가 nextjs.org를 포함한 자사 네트워크의 크롤러 요청 로그를 분석한 결과 OpenAI, Anthropic, Perplexity, Meta, ByteDance의 크롤러 중 자바스크립트를 렌더링하는 봇은 하나도 없었다^[1]. 그런데 많은 팀이 이 사실을 모른 채 구글 서치 콘솔의 초록색 색인 상태만 보고 "우리 페이지는 문제없다"고 판단한다. 구글은 렌더링을 해주기 때문이다. 이 글은 그 비대칭이 어디서 생기고, 우리 사이트가 사각지대인지 어떻게 3분 만에 확인하고, 무엇을 어떤 순서로 고치는지를 한 페이지에서 끝낸다.

30초 정의

• 클라이언트 사이드 렌더링(CSR) 은 브라우저에서 자바스크립트를 실행해 화면 내용을 만드는 방식이다.
• 서버 사이드 렌더링(SSR) 은 서버가 요청 시점에 HTML을 완성해 보내는 방식이다.
• 정적 렌더링(SSG) 은 빌드 시점에 HTML을 미리 완성해 파일로 두는 방식이다.
• 하이드레이션(hydration) 은 서버가 보낸 완성 HTML 위에 브라우저가 자바스크립트 동작만 덧붙이는 방식이다.
• 렌더링 사각지대 는 브라우저에는 보이지만 원본 HTML에는 없어서 자바스크립트를 실행하지 않는 크롤러가 수집하지 못하는 콘텐츠 영역이다.

크롤러별 자바스크립트 실행 여부

여덟 줄 중 다섯 줄이 미실행이다. 본문을 클라이언트 렌더링에 맡긴 사이트라면, 이 다섯 개 크롤러에게는 해당 페이지의 내용이 하나도 전달되지 않는다.

근거, 숫자로 확인한 것

Vercel과 MERJ는 nextjs.org와 자사 네트워크에 들어온 크롤러 요청을 콘텐츠 타입별로 갈라 분석했다. 아래 비중은 nextjs.org 기준 수치이고, ChatGPT 계열은 GPTBot, OAI-SearchBot, ChatGPT-User를 합산한 값이다. 결론은 두 가지다. 첫째, 주요 AI 크롤러는 자바스크립트를 렌더링하지 않는다. 둘째, 그럼에도 자바스크립트 파일 자체는 상당한 비율로 내려받는다^[1]. 파일을 가져가되 실행하지 않으니, 서버 로그에 JS 요청이 찍혔다는 사실만으로 "봇이 우리 앱을 렌더링했다"고 해석하면 오독이다.

규모도 참고할 만하다. 같은 분석 기간 한 달 동안 GPTBot은 5억 6,900만 건, Claude 계열은 3억 7,000만 건을 요청했고 Googlebot은 45억 건이었다(Vercel, MERJ, 2024)^[1]. AI 크롤러 트래픽은 이미 무시할 규모가 아니고, 그 전량이 원본 HTML만 읽고 지나간다.

반대편 근거도 공식 문서에 있다. 구글은 자바스크립트 앱을 크롤링, 렌더링, 색인의 3단계로 처리하며 렌더링에는 에버그린 버전의 Chromium을 쓴다고 밝히고 있다(Google Search Central, 2026)^[2]. Applebot도 "웹사이트 콘텐츠를 브라우저 안에서 렌더링할 수 있다"고 명시하고, JS와 CSS가 robots.txt로 차단되면 제대로 렌더링하지 못한다고 경고한다(Apple, 2026)^[7]. Bingbot은 "일반적으로 자바스크립트를 렌더링할 수 있지만 모든 사이트의 모든 페이지에서 대규모로 처리하기는 어렵다"고 스스로 적었다(Bing Webmaster Blog, 2018)^[8]. OpenAI 문서는 GPTBot(모델 학습), OAI-SearchBot(ChatGPT 검색 노출), ChatGPT-User(사용자 트리거 방문)의 역할을 구분해 설명하지만 렌더링에 대한 언급은 없다(OpenAI 크롤러 문서, 2026년 9월 확인)^[6].

왜 구글에서는 멀쩡한데 AI 답변에서는 사라지는가

원인은 처리 단계 수의 차이다. Googlebot은 HTTP 200을 받은 페이지를 렌더링 대기열에 넣고, 순서가 오면 헤드리스 Chromium이 자바스크립트를 실행한 뒤 그 결과 HTML로 색인한다^[2]. 대기 시간이 몇 초에서 그보다 길어질 수 있다는 단서가 붙지만, 어쨌든 실행은 된다.

로그 분석에서 렌더링이 확인되지 않은 AI 크롤러에는 그 두 번째 단계가 없다(Vercel, MERJ, 2024)^[1]. 요청, 응답, 파싱까지가 전부다. 그래서 다음과 같은 비대칭이 생긴다. 구글 검색에서는 상위에 노출되는 페이지가, ChatGPT나 Perplexity 답변에서는 근거 문서 목록에 아예 등장하지 않는다. 이 현상을 두고 콘텐츠 품질이나 프롬프트 탓을 하다가 몇 달을 보내는 팀이 많다. 실제 원인은 HTML 한 줄이다.

영향은 구글 쪽으로도 번진다. 구글은 AI Overviews와 AI Mode의 지원 링크로 노출되려면 "페이지가 색인되어 있고 스니펫과 함께 구글 검색에 표시될 자격이 있어야 한다"고 규정한다(Google Search Central, 2025)^[5]. 렌더링이 실패하거나 지연되면 색인 자체가 늦어지고, 색인이 늦으면 AI 표면 노출 자격도 늦게 생긴다.

구조화 데이터는 특히 함정이다. 구글은 자바스크립트로 생성한 구조화 데이터도 렌더링 후 DOM에서 읽어들이며, 태그 매니저로 JSON-LD를 주입하는 방식도 지원한다(Google Search Central, 2025)^[4]. 그래서 리치 결과 테스트는 통과한다. 그러나 자바스크립트를 실행하지 않는 크롤러에게 그 JSON-LD는 존재하지 않는다. AEO를 위한 구조화 데이터 스키마에서 다루는 마크업 설계도, 주입 위치가 클라이언트면 AI 인용 관점에서는 무효다.

사각지대에 자주 빠지는 요소

실행, 점검에서 수정까지

1단계, 원본 HTML 점검 (3분)

브라우저 개발자 도구의 Elements 탭은 이미 렌더링이 끝난 DOM이다. 사각지대 점검에는 쓸 수 없다. 서버가 처음 내려준 HTML을 직접 봐야 한다.

# 1. 본문 핵심 문장이 원본 HTML에 있는지
curl -sL "https://example.com/product/123" | grep -c "핵심 문구"

# 2. JSON-LD가 원본 HTML에 있는지
curl -sL "https://example.com/product/123" | grep -o "application/ld+json" | wc -l

# 3. 내부 링크가 실제 앵커로 존재하는지
curl -sL "https://example.com/category/shoes" | grep -o '<a [^>]*href="[^"]*"' | wc -l

# 4. 크롤러 UA로 다른 응답을 주는지 (정확한 UA 문자열은 각 사 공식 문서 확인)
curl -sL -A "GPTBot" "https://example.com/product/123" | wc -c

1번과 2번의 결과가 0이면 그 페이지는 ChatGPT, Claude, Perplexity에게 빈 페이지다. 브라우저에서 잘 보인다는 사실은 반증이 되지 않는다.

2단계, 진단 항목 정리

4번과 5번은 구글 문서가 안내하는 URL 검사 도구와 리치 결과 테스트로 확인한다^[2]. 6번은 AI 크롤러 관리 가이드에서 봇별 허용 정책과 함께 다룬다.

3단계, 수정 우선순위

수정의 방향은 구글 문서가 명확히 정해두었다. 동적 렌더링은 "우회책이며 권장 해법이 아니고, 복잡도와 리소스 요구가 추가된다"고 못 박고, 대신 서버 사이드 렌더링, 정적 렌더링, 하이드레이션을 제시한다(Google Search Central, 2025)^[3]. 프리렌더 서비스를 붙여 급한 불을 끌 수는 있지만, 그것을 최종 아키텍처로 삼으면 유지 비용과 원본 불일치 위험이 남는다.

기준은 단순하다. 인용될 수 있는 내용은 서버가 내려주고, 인용될 일이 없는 인터랙션만 브라우저에 맡긴다. Vercel과 MERJ도 같은 결론을 냈다, 본문, 상품 정보, 문서, 메타 정보, 내비게이션은 서버 렌더링하고 비핵심 동적 요소에만 클라이언트 렌더링을 쓰라는 것이다^[1].

원본 HTML 점검을 도구로 대신하려면 GEO 무료 진단 도구 비교에서 무료로 확인되는 범위와 유료 구간의 경계를 먼저 본다. 수정 후에는 실제로 인용이 늘었는지를 따로 추적해야 한다. 원본 HTML 점검은 "읽힐 수 있는가"까지만 답하고, "인용되는가"는 답하지 않기 때문이다. 엔진별 인용 추적은 Profound, Peec AI, 국내에서는 BOIDA, 넥스트티, 리드젠랩 같은 AI 가시성 모니터링 도구를 쓰거나, 각 엔진에서 직접 질의해 근거 링크를 수집하는 방식으로 한다. 렌더링을 고쳤는데도 인용이 없다면 원인은 콘텐츠 구조 쪽이며, 퍼플렉시티가 우리 콘텐츠를 인용하지 않는 이유와 기술 GEO와 콘텐츠 GEO 프레임워크에서 다음 단계를 잇는다. 개념 정리가 먼저 필요하면 GEO란 무엇인가를 참고한다.

정리

AI 크롤러 대부분은 자바스크립트를 실행하지 않는다. GPTBot, ClaudeBot, PerplexityBot, Meta-ExternalAgent, Bytespider가 모두 여기 해당하고, 이들은 JS 파일을 내려받기는 해도 실행하지 않는다(Vercel, MERJ, 2024). 렌더링 단계를 문서로 밝힌 쪽은 Googlebot이고, Applebot은 브라우저 렌더링이 가능하다고 밝혔으며, Bingbot은 대규모 처리에 한계가 있다고 적었다. 그래서 CSR로 만든 페이지는 구글 검색에서는 살아남고 AI 답변에서는 사라지는 이중 상태에 놓인다. 확인은 브라우저가 아니라 curl로, 수정은 동적 렌더링이 아니라 서버 사이드 렌더링과 정적 렌더링으로 한다. 인용될 내용은 서버가 내려주고, 나머지만 브라우저에 맡기는 것, 이 한 줄이 사각지대를 없애는 기준선이다.