가장 중요한 결론부터 말씀드리겠습니다. 현재 주류 AI 크롤러는 거의 모두 JavaScript를 실행하지 않습니다. 페이지 콘텐츠가 브라우저에서 JS를 실행한 뒤에야 생성된다면 GPTBot, ClaudeBot, PerplexityBot에는 빈 페이지로 보입니다. 이는 순위의 문제가 아닙니다. 콘텐츠가 보이느냐, 아예 존재하지 않는 것으로 처리되느냐의 문제입니다.
많은 사람이 Googlebot의 작동 방식을 기준으로 AI 크롤러를 판단합니다. 오해는 여기서 시작됩니다. Googlebot은 오랜 기간 JavaScript 렌더링 역량을 고도화해 왔습니다. 순수 클라이언트 사이드 렌더링을 사용해도 속도가 느리고 리소스가 더 들 뿐, 콘텐츠를 가져갈 가능성이 높습니다. 그러나 AI 크롤러는 다르게 작동합니다. 대부분 서버가 반환한 원본 HTML을 가져와 읽고 바로 떠납니다. 브라우저를 열거나 JS 실행을 기다리거나 두 번째 렌더링을 수행하지 않습니다.
AI 크롤러와 Googlebot은 작동 방식이 다릅니다
Googlebot의 크롤링은 두 단계로 진행됩니다. 첫 단계에서는 원본 HTML을 읽고 즉시 가져갈 수 있는 콘텐츠를 수집합니다. 두 번째 단계에서는 페이지를 렌더링 대기열에 넣은 뒤 Chrome과 같은 헤드리스 브라우저로 JavaScript를 실행해 동적으로 생성되는 콘텐츠를 채웁니다. 많은 컴퓨팅 리소스가 필요한 방식이지만, 검색이 핵심 사업인 Google은 이 비용을 감당합니다.
AI 기업의 크롤러에는 이러한 두 번째 단계가 없습니다. OpenAI의 GPTBot, Anthropic의 ClaudeBot, Perplexity의 크롤러, ChatGPT의 실시간 검색을 담당하는 OAI-SearchBot은 현재 HTML을 읽는 단계에서 작업을 끝냅니다. 이유는 현실적입니다. 웹 전체를 대상으로 헤드리스 브라우저를 실행하려면 막대한 비용이 들기 때문입니다. 이들이 원하는 것은 사이트의 화면을 재현하는 것이 아니라 ‘모델이 바로 읽을 수 있는 텍스트’입니다. 프런트엔드 인터랙션, 애니메이션, 지연 로딩에 사용한 JavaScript는 이들에게 노이즈나 빈 공간에 불과합니다. 유일한 예외는 Google의 기존 검색 색인을 기반으로 하며 Googlebot의 렌더링 역량을 활용하는 Google AI Overviews입니다. 그러나 ChatGPT, Perplexity, Claude까지 고려한다면 JavaScript가 실행될 것이라고 기대해서는 안 됩니다.
SSG·SSR·CSR, AI가 읽는 결과는 어떻게 다를까?
같은 콘텐츠라도 어떤 렌더링 전략으로 전달하느냐에 따라 AI 크롤러가 받는 결과는 크게 달라집니다. 판단 기준은 하나입니다. 콘텐츠가 ‘서버에서 HTML에 포함되어 전달되는가’, 아니면 ‘브라우저에서 JS 실행이 끝난 뒤 나타나는가’입니다.
- SSG(정적 생성): 빌드할 때 각 페이지의 완성된 HTML을 생성해 정적 파일로 저장합니다. 서버가 완성된 결과물을 바로 반환하므로 AI 크롤러가 전체 본문을 수집할 수 있습니다. 판독 가능성이 가장 높고 로딩 속도도 가장 빠릅니다.
- SSR(서버 사이드 렌더링): 요청이 들어올 때마다 서버가 완성된 HTML을 실시간으로 구성해 반환합니다. AI 크롤러도 전체 본문을 읽을 수 있지만, 매 요청마다 서버 연산이 필요합니다. 트래픽이 많다면 서버 부하를 살펴야 합니다.
- CSR(순수 클라이언트 사이드 렌더링): 서버는 내용이 거의 없는 HTML 골격만 반환합니다. 실제 콘텐츠는 브라우저가 JS를 내려받아 실행한 뒤 채워집니다. AI 크롤러가 JS를 실행하지 않으면 인용할 텍스트가 거의 없는 빈 골격만 보게 됩니다.
간단히 말해 AI 크롤러 관점에서 SSG와 SSR은 본질적으로 다르지 않습니다. 두 방식 모두 서버 측에서 콘텐츠를 HTML에 넣습니다. 차이는 ‘언제 연산하느냐’뿐입니다. SSG는 미리 생성하고 SSR은 요청 시 생성합니다. 실제 경계선은 CSR입니다. 단일 페이지 애플리케이션(SPA) 프레임워크에 서버 사이드 렌더링을 적용하지 않으면 최초 HTML에는 빈 루트 컨테이너 div와 여러 script 태그만 남는 경우가 많습니다. AI 크롤러는 텍스트 없이 이 HTML만 읽습니다.
30초 자가 점검법
별도 도구나 엔지니어의 도움 없이도 사이트 상태를 판단할 수 있습니다. 브라우저에서 중요한 페이지를 연 뒤 마우스 오른쪽 버튼을 클릭하고 ‘페이지 소스 보기’를 선택합니다. 개발자 도구의 Elements 패널과 혼동하면 안 됩니다. Elements 패널에는 JS 실행이 끝난 뒤의 결과가 표시되므로 실제 원본 HTML을 확인하기 어렵습니다. ‘페이지 소스 보기’에 표시되는 내용이 서버가 처음 반환하고 AI 크롤러가 실제로 읽는 원본 HTML입니다.
CSR 사이트를 개선하는 방법
CSR을 사용하고 있다는 사실을 확인해도 프런트엔드 전체를 폐기하고 새로 만들 필요는 없습니다. 투입 비용이 낮은 순서대로 일반적으로 세 가지 방법을 검토할 수 있습니다.
- 프리렌더링: 크롤러가 방문하면 미리 생성한 정적 HTML 스냅샷을 반환합니다. 기존 SPA를 최소한으로 수정해 빠르게 개선할 수 있는 방법입니다. 다만 콘텐츠 변경에 맞춰 스냅샷을 갱신하고 관리해야 합니다.
- SSR/SSG 지원 프레임워크로 전환: Next.js, Nuxt, SvelteKit 같은 프레임워크를 사용하면 프런트엔드 인터랙션은 유지하면서 첫 화면의 핵심 콘텐츠를 서버에서 렌더링할 수 있습니다. 대부분의 B2B 고객에게 기본적으로 권장하는 가장 안정적인 방식입니다.
- 핵심 페이지부터 SSR 적용: 리소스가 제한적이라면 사이트 전체를 한 번에 전환할 필요가 없습니다. 제품 페이지, 플랜 안내 페이지, 가격 페이지, 심층 아티클처럼 AI가 출처로 활용해야 할 페이지부터 서버 사이드 렌더링으로 바꾸십시오. 관리 백엔드와 인터랙티브 도구는 계속 CSR로 운영해도 무방합니다.
모든 페이지에 SSR이 필요한 것은 아닙니다
렌더링 전략은 신념이 아니라 선택과 균형의 문제입니다. 로그인 후 사용하는 대시보드, 내부 도구, 상호작용이 많은 설정 페이지는 AI 답변에 인용될 콘텐츠가 아닙니다. 이런 페이지는 CSR을 유지하는 편이 합리적이며, 무리하게 SSR을 적용하면 서버 부하만 늘어납니다. 집중해야 할 대상은 ‘AI가 답변의 출처로 활용하기를 원하는 페이지’입니다. 어떤 문제를 해결하는지, 왜 필요한지, 다른 선택지와 무엇이 다른지를 설명하는 페이지가 여기에 해당합니다. 판단 기준은 간단합니다. 이 페이지의 콘텐츠가 ChatGPT나 Perplexity의 답변에 나오기를 원한다면 전체 내용이 서버 측 HTML에 들어 있어야 합니다.
Googlebot은 JavaScript 실행이 끝날 때까지 기다리지만 AI 크롤러는 기다리지 않습니다. AI가 인용할 출처를 결정하는 환경에서는 보이지 않는 콘텐츠는 존재하지 않는 것과 같습니다.— Tenten GEO
대만 B2B 웹사이트에서 흔히 발견되는 크롤링 문제는 콘텐츠의 완성도가 아니라, 콘텐츠 자체가 AI에 전달되지 않는 데 있습니다. 원인은 대개 프레임워크 선택과 렌더링 설정에 숨어 있습니다. 사람의 눈에는 사이트가 정상으로 보이지만 ‘페이지 소스 보기’를 열어야 문제가 드러납니다. 중요한 페이지를 AI가 읽을 수 있는지 확신하기 어렵다면, 30분 GEO 진단에서 실제 URL을 기준으로 첫 화면 HTML에 콘텐츠가 포함되어 있는지 확인하고 서버 사이드 렌더링을 우선 적용할 페이지를 안내해 드립니다.
