AI 크롤러는 우리 사이트에서 빈 페이지를 봤다 — SPA 정적 프리렌더 도입기

문은 열려 있는데 안이 비어 있었다

지난 글에서 AI 크롤러 허용 설정을 다뤘습니다. 그런데 robots.txt를 아무리 완벽하게 열어도 크롤러가 읽을 본문이 없다면 소용이 없습니다. 저희 사이트가 정확히 그 상태였습니다. marketing-pivot.com은 React 기반 클라이언트 렌더링(CSR) SPA입니다. 사람의 브라우저는 자바스크립트를 실행해 화면을 그리지만, 자바스크립트를 실행하지 않는 크롤러가 받는 HTML은 <div id="root"></div> 한 줄이 전부였습니다.

저희는 2026년 8월 30일과 9월 8일 두 차례 이 문제를 진단했습니다. GPTBot, ClaudeBot, PerplexityBot 같은 크롤러가 자바스크립트를 실행하지 않는 경우, 이 사이트는 AEO·GEO를 이야기하는 사이트이면서 정작 AI에게는 빈 페이지였던 셈입니다.

왜 이런 일이 생기는가

CSR SPA는 서버가 껍데기 HTML과 스크립트만 내려주고, 실제 본문은 브라우저에서 자바스크립트가 실행된 뒤에야 만들어집니다. 사람에게는 차이가 없지만, 렌더링을 하지 않는 수집기에게는 본문이 존재하지 않습니다. 일반적으로 AI 학습·검색용 크롤러 상당수가 자바스크립트를 실행하지 않는 것으로 알려져 있으나, 이는 서비스마다 다르고 바뀔 수 있습니다. 그래서 실행해 준다고 가정하는 대신, 실행하지 않아도 본문이 보이도록 만들어 두는 것이 안전한 설계입니다.

직접 확인하는 방법

간단합니다. 브라우저의 요소 검사(개발자 도구)가 아니라 소스 보기 또는 curl 응답을 봅니다. 요소 검사는 자바스크립트가 실행된 뒤의 결과라 판단 기준이 되지 않습니다. 원본 응답에서 본문 핵심 문장을 검색해 보고, 찾을 수 없다면 자바스크립트를 실행하지 않는 크롤러에게도 보이지 않는다고 봐야 합니다.

선택지 비교

방식	장점	부담
SSR로 전환 (Next.js 등)	요청마다 서버에서 완성된 HTML 제공	구조 전환 비용이 크고 서버 운영이 필요
빌드 시점 정적 프리렌더	기존 SPA 구조를 유지하고 빌드 때 정적 HTML 생성	자주 바뀌는 데이터 중심 페이지에는 부적합
동적 렌더링 (크롤러 판별 후 별도 제공)	크롤러에게만 렌더링 결과 제공	판별 로직 관리가 복잡하고 내용 불일치 위험

저희는 두 번째를 택했습니다. 페이지 대부분이 블로그·가이드·제품 소개 같은 정적인 마케팅 콘텐츠이고, 앱 구조를 바꾸는 비용을 피하고 싶었기 때문입니다.

저희가 한 방식

빌드가 끝난 뒤 스크립트가 sitemap.xml에 등록된 모든 라우트를 로컬 미리보기 서버에서 헤드리스 브라우저로 열고, 렌더링이 끝난 결과를 정적 HTML로 저장해 배포 폴더에 덮어씁니다. Vercel은 라우팅 규칙보다 정적 파일을 우선 제공하기 때문에 SPA 구조를 전혀 바꾸지 않고도 크롤러가 완성된 본문을 받게 됩니다. 처음에는 56개 라우트였고, 현재는 68개 라우트를 빌드 때마다 새로 생성합니다.

중간에 막힌 곳도 있었습니다. 로컬에서는 잘 되던 빌드가 Vercel 빌드 컨테이너에서 실패했습니다. 번들된 Chromium이 요구하는 공유 라이브러리가 컨테이너에 없었고, root 권한이 없어 설치도 불가능했기 때문입니다. 그래서 Vercel 빌드에서만 서버리스 환경용으로 정적 빌드된 별도 Chromium 패키지를 쓰도록 분기했습니다.

도입하며 함께 발견한 문제들

프리렌더는 사이트를 크롤러의 눈으로 처음 제대로 보게 만들었고, 그 과정에서 평소엔 보이지 않던 결함이 여럿 드러났습니다.

발견된 문제	원인과 조치
블로그 글 title이 빈 문자열	React 19의 title 처리가 단일 텍스트 자식만 지원하는데 제목과 고정 문구로 자식이 둘로 쪼개져 있었음. 하나의 문자열로 합쳐 수정
페이지마다 기본 메타 태그가 중복	index.html의 기본 title·description·canonical과 페이지별 값이 head에 함께 남아 있었음. 종류별로 하나만 남기도록 정리
신규 글이 프리렌더 대상에서 누락	사이트맵에 빠진 글은 프리렌더 대상에서도 빠져 크롤러에게 홈 셸이 서빙됨. 사이트맵 자동 생성을 빌드에 연결
llms.txt가 실제로는 홈 HTML을 반환	파일이 없어 SPA의 전체 캐치올 규칙에 걸려 index.html이 응답되고 있었음. 실제 파일을 추가
FAQ 답변이 DOM에 없음	접힌 상태에서는 답변이 마운트되지 않아 크롤러가 질문만 봄. 항상 렌더링하고 접힘은 스타일로만 처리

이 목록이 말해 주는 것은, 렌더링 문제는 단독으로 오지 않는다는 점입니다. 크롤러 관점에서 한 번 점검하면 메타 태그, 사이트맵, 정적 파일 처리 같은 주변 결함이 함께 드러납니다.

아직 모르는 것

정직하게 짚어야 할 부분이 있습니다. 저희는 프리렌더 도입 전후로 AI 답변 속 인용이 어떻게 달라졌는지 아직 측정하지 못했습니다. 크롤러가 본문을 읽을 수 있게 된 것은 사실이지만, 그것이 곧 인용 증가로 이어진다는 근거는 없습니다. 프리렌더는 인용을 만드는 장치가 아니라, 인용될 수 있는 최소 조건을 갖추는 작업으로 보는 것이 맞습니다.

자가진단 — 지금 어디서 시작할지

먼저 핵심 페이지를 curl로 받아 본문이 보이는지 확인하세요. 그다음 AEGIS Insight의 구조 진단으로 AI 크롤러 허용 상태를 점검하면 됩니다. 구조 진단은 인용 준비도를 보여주는 선행 지표일 뿐 인용 자체를 집계하지는 않는다는 점은 AEO KPI 설계 글에서 다뤘습니다.

마치며

AI 크롤러 대응은 허용 설정으로 끝나지 않습니다. 열어 준 문 안에 크롤러가 읽을 본문이 실제로 있는지까지 확인해야 설정이 의미를 갖습니다. SPA 사이트라면 지금 소스 보기를 한 번 열어 보세요. 빈 껍데기가 보인다면 그것이 AEO 작업의 첫 번째 할 일입니다.