AI 크롤러는 자바스크립트를 렌더링할까? 342개 런치 사이트 감사 (2026)

2026년 10월, 우리는 JavaScript를 실행하지 않는 크롤러가 하는 방식으로 aat.ee에 런칭된 365개의 제품 사이트에 요청을 보내고, 돌아온 HTML의 텍스트를 세어 보았다. HTTP 200으로 응답한 342개 중 37개(10.8%)가 본문 텍스트가 50단어 미만이었다. 그중 거의 전부가 여전히 title과 meta description을 갖고 있었기 때문에, 링크 미리보기에서는 페이지가 멀쩡해 보이지만 콘텐츠 자체는 JavaScript가 실행된 후에야 도착한다. 같은 37개 페이지를 실제 브라우저에서 로드했을 때, 로딩이 완료된 30개 중 23개가 150단어 이상을 보여주었다.

이것이 중요한 이유는 ChatGPT, Claude, Perplexity 뒤에 있는 크롤러들이 JavaScript를 실행하지 않는 것으로 관찰되었기 때문이다. 제품 설명이 렌더링된 페이지에만 존재한다면, 그 시스템들은 그것을 결코 보지 못할 수 있다. 아래에는 수치, 원인, 그리고 자신의 사이트에서 2분 만에 실행할 수 있는 점검이 있다.

어떤 크롤러가 JavaScript를 실행하는가

OpenAI, Anthropic, Meta, ByteDance, Perplexity는 자신들의 크롤러가 JavaScript를 렌더링하는지 문서화하지 않는다. 이용 가능한 최선의 증거는 Vercel과 MERJ가 2024년 12월에 수행한 연구다. 이 연구는 조사한 주요 AI 크롤러 중 어느 것도 JavaScript를 렌더링하지 않는다는 것을 발견했다: OpenAI의 OAI-SearchBot, ChatGPT-User, GPTBot, Anthropic의 ClaudeBot, Meta-ExternalAgent, ByteDance의 Bytespider, PerplexityBot. ChatGPT와 Claude의 크롤러는 JavaScript 파일을 다운로드했지만(각 요청의 11.50%와 23.84%), 실행하지는 않았다. Googlebot의 인프라를 사용하는 Gemini는 렌더링했다. AppleBot도 마찬가지였다.

Googlebot은 JavaScript를 렌더링하지만, 별도의 단계에서 한다. Google의 JavaScript SEO 가이드에 따르면 페이지는 대기열에 들어가며 "Google의 리소스가 허용되면, 헤드리스 Chromium이 페이지를 렌더링하고 JavaScript를 실행한다." Google은 여전히 서버 측 렌더링 또는 사전 렌더링을 권장하는데, "그것이 사용자와 크롤러 모두에게 웹사이트를 더 빠르게 만들고, 모든 봇이 JavaScript를 실행할 수 있는 것은 아니기" 때문이다.

이 연구는 거의 2년 전의 단일 관찰이며, 크롤러 동작은 예고 없이 바뀔 수 있다. 그래도 여전히 이용 가능한 최선의 데이터이고, 어느 회사도 그것을 반박하지 않았다.

측정 방법

표본: 감사 전 120일 동안 aat.ee에 런칭된 제품 중에서 무작위로 추출한 400개의 프로젝트 URL. 호스트명당 하나의 URL만 유지했고, 제품 자체 사이트가 아닌 GitHub, 앱 스토어, Hugging Face를 가리키는 14개의 링크를 제외하여 365개 사이트가 남았다. 342개가 HTTP 200을 반환했으며 아래 수치의 기반이 된다.
요청: OpenAI의 OAI-SearchBot 토큰을 담은 user agent로 사이트당 한 번의 GET, 리다이렉트를 따르고, JavaScript를 실행하지 않음.
측정: <script>, <style>, <noscript>, <template>, <svg> 요소를 제거한 후의 보이는 본문 텍스트 단어 수. 또한 HTML에 title, meta description, canonical 링크, JSON-LD, <h1>이 포함되어 있는지도 기록했다.
한계: 우리는 창업자가 제출한 URL, 보통 홈 페이지만 가져왔다. 우리의 요청은 OpenAI의 IP 대역이 아닌 우리 자체 네트워크에서 나왔으므로, 검증된 크롤러를 다르게 취급하는 사이트는 그들에게 다른 것을 제공할 수 있다. script 태그 안의 텍스트는 세지 않았다. Vercel 연구는 초기 HTML에 내장된 데이터, 예컨대 JSON이 "여전히 색인될 수 있다"고 지적하므로, 일부 프레임워크의 경우 우리의 집계는 크롤러가 받는 것보다 적게 잡을 수 있다. 아래의 빈 페이지 대부분은 콘텐츠가 별도의 JavaScript 번들에 있는 단일 페이지 앱이며, 이 연구는 이 크롤러들이 그 번들을 다운로드하지만 실행하지는 않는다는 것을 발견했다.

결과

원본 HTML의 본문 단어 수	사이트	342개 중 비율
20 미만	35	10.2%
20–49	2	0.6%
50–149	3	0.9%
150–399	23	6.7%
400 이상	279	81.6%

중앙값 사이트는 약 1,180단어를 반환했으므로, 대부분의 런칭 사이트는 양호한 상태다. 문제는 집중되어 있다: 37개 사이트, 거의 전부가 본문에 아무것도 없다.

head는 채워져 있고 body는 비어 있다. 37개의 빈약한 페이지 중 36개는 <title>이 있었고 34개는 meta description이 있었다. <h1>이 있는 것은 4개뿐이었고, 링크가 5개 이상인 것도 4개뿐이었다. 이 HTML을 읽는 크롤러는 제품 이름과 한 줄짜리 소개 문구를 알게 될 뿐, 기능, 가격, 누구를 위한 것인지에 대해서는 아무것도 알지 못한다.

하나의 패턴이 대부분을 설명한다. 37개 중 30개가 빈 <div id="root"> 또는 <div id="app">을 제공하고 브라우저에서 전체 페이지를 구축했는데, 이는 Vite나 Create React App으로 만든 단일 페이지 앱의 기본값이다. 12개는 Vite 빌드였다. 반면, 표본의 165개 Next.js 사이트 중 빈약한 것은 1개뿐이었다. Next.js는 기본적으로 서버에서 페이지를 렌더링하므로 콘텐츠가 첫 응답에 들어 있다.

템플릿이 새어 나온다. 37개 중 16개가 여전히 Create React App의 기본 meta description인 "Web site created using create-react-app"을 갖고 있었다. 이 16개는 유사한 제품군을 런칭한 세 개의 제출자 계정에서 나왔으므로 전체를 부풀린다. 이들을 제외하면 빈약한 비율은 326개 중 21개, 즉 6.4%다. 그래도 약 16번의 런칭 중 1번꼴이다.

브라우저에서는 콘텐츠가 있다

그다음 우리는 37개의 빈약한 페이지를 헤드리스 Chromium에서 로드하고, load 이벤트 후 5초를 기다린 뒤, 보이는 텍스트를 다시 세었다. 30개 페이지가 로딩을 완료했다. 7개는 세 번의 시도 후 타임아웃되었다.

JavaScript 실행 후 본문 단어 수	사이트 (30개 중)
150 이상	23
50–149	2
50 미만	5

중앙값 페이지는 원본 HTML에서 0단어였던 것이 렌더링 후 약 475단어가 되었다. 따라서 이 사이트들 대부분의 경우 카피는 존재하며, 브라우저의 방문자는 그것을 본다. 다만 서버가 보내는 HTML에는 없을 뿐이고, 렌더링하지 않는 크롤러가 읽는 것은 바로 그 부분뿐이다. 50단어 미만에 머문 5개는 로그인 화면, 빈 화면으로 렌더링된 페이지, 그리고 매우 짧은 세 개의 페이지였다. 이들은 크롤러뿐 아니라 모든 사람에게 빈약하다.

부수적 발견: 일부 봇 보호가 크롤러도 차단한다

세 개 사이트가 우리의 OAI-SearchBot 요청에 HTTP 403으로 응답했고, 동일한 요청을 Chrome user agent로 보냈을 때는 200으로 응답했다. 그중 두 개는 Cloudflare 챌린지(cf-mitigated: challenge)를 반환했다. 그들의 robots.txt 파일 중 어느 것도 AI 크롤러를 차단하지 않았으므로, 소유자들은 아마도 차단할 의도가 없었을 것이다.

이것만으로 OpenAI의 실제 크롤러가 차단되는지는 알 수 없다. Cloudflare 같은 봇 보호는 IP 주소로 검증된 봇을 인식할 수 있으며, 우리의 요청은 OpenAI의 것이 아니었다. 이것을 살펴볼 이유로 삼아라: Cloudflare를 사용한다면 대시보드의 AI 크롤러 및 봇 파이트 설정을 확인하고, 그것이 robots.txt가 말하는 것과 일치하는지 확인하라.

2분 만에 자신의 사이트 점검하기

크롤러가 하는 방식으로 가져오기.

UA='Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)'
curl -sL -A "$UA" -o raw.html -w '%{http_code}\n' https://yoursite.com
grep -c 'a sentence from your hero section' raw.html

UA='Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)'
curl -sL -A "$UA" -o raw.html -w '%{http_code}\n' https://yoursite.com
grep -c 'a sentence from your hero section' raw.html

200이 아닌 상태는 보통 크롤러가 콘텐츠 대신 오류나 챌린지 페이지를 받는다는 뜻이다. 0이라는 집계는 그 정확한 문장이 HTML에 없다는 뜻이다. 마크업이 긴 문장을 나눌 수 있으므로 짧은 구절을 골라라.

JavaScript 없이 페이지를 보기. Chrome DevTools에서 명령 메뉴(Ctrl+Shift+P 또는 Cmd+Shift+P)를 열고 "Disable JavaScript"를 실행한 뒤 새로고침하라. 보이는 것이 대략 렌더링하지 않는 크롤러가 읽는 것이다.
Google은 따로 확인하기. Search Console의 URL Inspection은 Googlebot이 렌더링한 HTML을 보여준다. 그것은 Google에 대해서만 알려준다.
홈 페이지뿐 아니라 가격 및 기능 페이지에도 반복하라. 어시스턴트가 제품을 설명하는 데 필요한 페이지가 바로 그것들이다.

스택별 해결 방법

스택	기본적으로 서버가 보내는 것	해결책
Vite 또는 Create React App SPA	빈 루트 `<div>`	빌드 시점에 마케팅 라우트를 사전 렌더링하거나, 서버 또는 빌드 시점에 HTML을 렌더링하는 프레임워크로 옮겨라
React Router v7	모드에 따라 다름	공개 라우트에 서버 렌더링 또는 `prerender`를 사용하는 프레임워크 모드를 사용하라
Next.js App Router	서버 렌더링된 HTML; 페이지는 Server Components	주요 카피를 마운트 후 데이터를 가져오는 클라이언트 컴포넌트 밖에 두어라
Nuxt, SvelteKit	서버 렌더링된 HTML	공개 페이지에 대해 SSR이 꺼져 있지 않은지(`ssr: false`) 확인하라
Astro, Framer, Webflow, Wix, WordPress	정적 또는 서버 렌더링된 HTML	보통 문제없음; 봇 보호와 카피가 스크립트로 로드되지 않는지 확인하라

무엇을 사용하든 세 가지 규칙이 적용된다:

사실을 첫 응답에 넣어라. 즉 제품 이름, 무엇을 하는지, 누구를 위한 것인지, 가격, 주요 링크를 서버가 반환하는 HTML에 넣어라.
봇에게도 사람과 같은 페이지를 제공하라. Google은 크롤러를 위한 별도의 사전 렌더링 버전인 동적 렌더링을 "우회 방법이며 권장되는 해결책이 아니다"라고 부른다. Microsoft의 GEO 가이드는 이렇게 말한다: "렌더링된 DOM이 소비자가 보는 것과 동일한 사실을 담도록 하라 — 봇에게 다른 HTML을 절대 제공하지 말라."
<head>에서 멈추지 마라. 좋은 title과 description은 링크 미리보기에 도움이 된다. 그것만으로는 크롤러가 제품을 설명하기에 충분하지 않다.

FAQ

Google은 내 클라이언트 렌더링 콘텐츠를 보는가? 보통은, 결국에는. Googlebot은 페이지를 렌더링 대기열에 넣고 헤드리스 Chromium으로 JavaScript를 실행한다. 그것은 Google Search와 Gemini를 커버한다. AI Overviews에서 뒷받침 링크가 되려면, 페이지가 "색인되어 있고 스니펫과 함께 Google Search에 표시될 자격이 있어야" 하므로, 느리거나 실패한 렌더링은 여전히 그곳에서 손실을 줄 수 있다. 그것은 ChatGPT, Claude, Perplexity를 커버하지 않으며, 그들의 크롤러는 렌더링하지 않는 것으로 관찰되었다.

빈 <div id="root">는 순위 페널티인가? 아니다. 그것에 페널티를 주는 것은 없다. 비용은 렌더링하지 않는 크롤러가 읽을 것이 없다는 것이며, 따라서 페이지를 인용하거나 설명할 수 없다.

내 사이트에는 좋은 meta description이 있다. 그것으로 충분하지 않은가? 그것은 크롤러에게 한 문장을 준다. 제품이 무엇을 하는지, 또는 대안과 어떻게 비교되는지 묻는 어시스턴트는 본문 카피가 필요하다: 기능, 가격, 사용 사례.

앱을 다시 만들어야 하는가? 보통은 아니다. 공개 페이지, 예컨대 홈, 가격, 기능, 문서 페이지를 사전 렌더링하는 것으로 충분하다. 로그인한 앱은 클라이언트 렌더링으로 남겨둘 수 있다.

이것을 고치면 ChatGPT가 나를 인용하게 되는가? 아무도 그것을 약속할 수 없다. 읽힐 수 있는 것이 전제 조건이다. 인용 여부는 다른 출처가 당신에 대해 무엇을 말하는지, 그리고 당신의 페이지가 질문에 얼마나 잘 답하는지에 달려 있다. 우리의 AI 검색 최적화 플레이북이 나머지를 다룬다.

출처

Vercel and MERJ: The rise of the AI crawler (2024년 12월)
Google Search Central: Understand JavaScript SEO basics
Google Search Central: Dynamic rendering as a workaround
Google Search Central: AI features and your website
Next.js: Server and Client Components
Microsoft Advertising: From discovery to influence: a guide to GEO
aat.ee: 런칭된 제품 사이트 365개(342개 분석)의 원본 HTML 감사, 2026년 10월

aat.ee의 모든 제품은 영구적이고 서버에서 렌더링되는 리스팅 페이지를 받으므로, 크롤러는 당신의 사이트가 그들을 맞이할 준비가 되기 전에도 제품 설명을 읽을 수 있다. 제품을 제출하거나 리스팅 옵션을 확인하라.

AI 크롤러가 당신의 사이트를 읽을 수 있을까? 우리는 JavaScript 없이 342개 런치 사이트를 확인했다