자바스크립트로 그리는 페이지를 AI 크롤러가 읽는가 — 공식 문서와 사이트 6곳의 처음 HTML 실측

화면에 보이는 글자와 크롤러가 받는 글자는 다를 수 있다

홈페이지를 브라우저로 열면 가게 이름, 주소, 영업시간, 메뉴 가격이 다 보입니다. 그런데 그 글자가 서버가 처음 보낸 HTML에 들어 있었는지, 아니면 브라우저가 자바스크립트를 실행한 뒤에 그려 넣은 것인지는 화면만 봐서는 구분되지 않습니다.

사람의 브라우저는 자바스크립트를 실행하니 어느 쪽이든 똑같이 보입니다. 문제는 크롤러입니다. 자바스크립트를 실행하지 않는 크롤러는 처음 받은 HTML만 읽고 지나갑니다. 그 HTML에 핵심 정보가 없으면, 그 크롤러 입장에서는 그 정보가 페이지에 없는 것과 같습니다.

빌더로 만든 사이트나 앱처럼 움직이는 사이트(SPA) 가운데 클라이언트 렌더링 방식이 있습니다. 다만 같은 빌더라도 설정과 페이지 종류에 따라 처음 HTML에 글자를 넣어 보내기도 하므로, 빌더 이름보다 내 페이지의 처음 HTML을 직접 보는 것이 정확합니다. 확인하는 법은 아래에 따로 적었습니다.

구글은 자바스크립트를 실행한다 — 다만 대기열을 거친다

구글 검색 센터의 자바스크립트 SEO 기본 문서는 Googlebot이 페이지를 크롤·렌더링·색인 세 단계로 처리한다고 설명합니다. 렌더링 단계는 이렇게 적었습니다.

“The page may stay on this queue for a few seconds, but it can take longer than that. Once Google’s resources allow, a headless Chromium renders the page and executes the JavaScript.”

페이지가 렌더링 대기열에서 몇 초 머물 수 있지만 더 오래 걸릴 수도 있고, 구글의 자원이 허락할 때 헤드리스 크로미움(화면 없는 크롬)이 페이지를 그리고 자바스크립트를 실행한다는 뜻입니다. 구글은 그리기는 하지만, 그리는 시점은 구글이 정합니다.

같은 문서는 이렇게 덧붙입니다.

“Keep in mind that server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.”

서버 렌더링이나 프리렌더링은 사용자와 크롤러 모두에게 사이트를 빠르게 만들고, 모든 봇이 자바스크립트를 실행할 수 있는 것은 아니므로 여전히 좋은 방법이라는 말입니다. 구글 스스로 ‘다른 봇은 못 돌릴 수 있다’고 적어 둔 셈입니다.

빙은 2018년 10월 웹마스터 블로그에서 bingbot이 “generally able to render JavaScript”, 즉 대체로 자바스크립트를 렌더링할 수 있지만 최신 브라우저가 지원하는 프레임워크를 모두 지원하지는 않는다고 적었습니다. 모든 사이트의 모든 페이지에서 자바스크립트를 대규모로 처리하기는 어렵다는 설명도 함께 있습니다. 8년 전 글이라 지금의 bingbot 동작을 그대로 말해 주지는 않습니다. 현재 빙 웹마스터 가이드라인 페이지도 열어 보려 했는데, curl로 받은 처음 HTML에는 “You need to enable JavaScript to run this app.” 한 줄밖에 없었습니다. 가이드라인 문서 자체가 자바스크립트로 그려지는 페이지라, 이 글에서는 그 내용을 인용하지 않았습니다.

AI 크롤러는 — 한 업체의 관찰로는 실행하지 않았다

AI 크롤러가 자바스크립트를 실행하는지는 OpenAI·Anthropic·Perplexity의 크롤러 문서에 적혀 있지 않습니다. 세 회사 문서를 모두 열어 봤지만, 각 봇이 무엇을 하는지와 robots.txt로 막는 법은 있어도 렌더링 여부를 밝힌 문장은 없었습니다. 봇별 역할과 robots.txt 설정은 ChatGPT 검색은 어떤 페이지를 인용하나와 ChatGPT에 우리 회사가 안 나오는 이유에, 엔진마다 허용할 크롤러가 어떻게 다른지는 AI 엔진마다 출처를 모으는 길이 다르다에 정리했으니 여기서는 반복하지 않습니다.

밖에서 관찰한 자료로는 호스팅 업체 Vercel이 MERJ와 함께 2024년 12월 17일에 낸 조사가 있습니다. nextjs.org와 Vercel 네트워크를 몇 달간 관찰하고, 기술 스택이 다른 구인 사이트 두 곳에서 결과를 다시 확인했다고 밝혔습니다.

“The results consistently show that none of the major AI crawlers currently render JavaScript.”

주요 AI 크롤러 가운데 지금 자바스크립트를 렌더링하는 것은 없었다는 뜻입니다. 이 문장 아래에 나열된 크롤러는 OpenAI(OAI-SearchBot, ChatGPT-User, GPTBot), Anthropic(ClaudeBot), Meta(Meta-ExternalAgent), ByteDance(Bytespider), Perplexity(PerplexityBot)입니다.

눈여겨볼 대목이 하나 더 있습니다. 같은 조사는 ChatGPT와 Claude 크롤러가 자바스크립트 파일을 받아 가기는 한다고 적었습니다(요청 가운데 자바스크립트 파일 비중 ChatGPT 11.50%, Claude 23.84%). 받아 가지만 실행하지 않으므로 “They can’t read client-side rendered content”, 즉 클라이언트에서 그린 내용은 읽지 못한다는 설명입니다. 서버 로그에 AI 크롤러가 자바스크립트 파일을 가져간 기록이 있다고 해서 그 파일이 그린 글자를 읽었다고 볼 수는 없다는 뜻입니다.

반대로 처음 HTML에 들어 있는 것은 HTML 본문이 아니어도 읽힐 수 있다고 적었습니다.

“Note, however, that content included in the initial HTML response, like JSON data or delayed React Server Components, may still be indexed since AI models can interpret non-HTML content.”

처음 HTML 응답 안에 JSON 데이터 같은 형태로 들어 있으면 AI 모델이 해석할 수 있으니 색인될 수도 있다는 말입니다. 이 설명대로라면, 페이지에 구조화 데이터(JSON-LD)를 넣을 때도 처음 HTML에 박아 넣었는지가 중요하고, 태그 관리 도구 같은 자바스크립트로 나중에 끼워 넣은 것은 이런 크롤러가 보지 못할 수 있습니다. 이 부분은 조사 문장에서 끌어낸 추론이고, 직접 실험하지는 않았습니다.

이 조사를 읽을 때의 한계도 분명합니다.

• 업체 한 곳의 자체 네트워크 조사입니다. nextjs.org와 Vercel 네트워크, 구인 사이트 두 곳에서 본 것이고, 동료 검토를 거친 논문이 아닙니다.
• 2024년 12월 시점입니다. 크롤러는 업데이트되므로 지금도 같다는 보장은 없습니다. 각 회사가 공식 문서로 확인해 준 내용도 아닙니다.
• 빠진 크롤러가 있습니다. 조사는 Microsoft Copilot은 고유한 사용자 에이전트가 없어 제외했다고 적었습니다. 네이버 Yeti는 조사에 나오지 않습니다.

그래도 사이트를 만드는 쪽의 결론은 단순합니다. 누가 렌더링하고 누가 안 하는지 크롤러마다 따라다닐 필요 없이, 핵심 정보를 처음 HTML에 넣어 두면 실행하는 크롤러와 실행하지 않는 크롤러 모두 같은 글자를 받습니다. Vercel도 권고에서 “Prioritize server-side rendering for critical content”, 즉 핵심 내용은 서버 렌더링을 우선하고, 조회수 표시나 실시간 채팅 위젯처럼 핵심이 아닌 기능에는 클라이언트 렌더링을 써도 된다고 적었습니다.

직접 재 본 것: 사이트 6곳의 처음 HTML (2026-10-19)

2026년 10월 19일 오전, 사이트 6곳의 홈페이지를 curl로 받았습니다. curl은 자바스크립트를 실행하지 않으므로, 받은 파일이 곧 자바스크립트를 안 돌리는 크롤러가 처음 받는 HTML과 같은 종류입니다. 파일에서 스크립트·스타일 태그를 걷어 낸 뒤 남은 글자 안에 이름과 핵심 사실이 있는지 찾았고, application/ld+json(구조화 데이터) 블록이 몇 개인지 셌습니다.

본 것을 정리하면 이렇습니다.

• 6곳 모두 이름과 핵심 사실이 처음 HTML에 글자로 있었습니다. 자바스크립트를 실행하지 않아도 가게 이름·주소·시간·가격을 읽을 수 있는 상태였습니다.
• HTML 크기는 최대 약 19배 차이 났지만 판단 기준이 아닙니다. 가장 작은 365noble.com(11,881바이트)은 스크립트 태그가 하나도 없는 순수 HTML이었고, 그 안에 진료시간·주소·입원실 가격이 다 있었습니다. 파일이 크다고 내용이 많은 것도, 작다고 비어 있는 것도 아닙니다. 봐야 할 것은 크기가 아니라 그 안에 핵심 문장이 있는지입니다.
• 365noble.com에는 구조화 데이터가 없었습니다. 처음 HTML에 본문 글자는 있으니 읽는 데는 문제가 없지만, 같은 사실을 기계가 읽는 형식으로도 적어 두는 일은 빠져 있는 상태입니다. 구조화 데이터가 AI 답변에 얼마나 영향을 주는지는 FAQ 구조화 데이터와 AI 답변에서 따로 다뤘습니다.
• 이 사이트(hwano-ai.com)는 Astro로 빌드한 정적 사이트(SSG)라, 모든 페이지가 미리 완성된 HTML로 나갑니다.

덧붙여, 365noble.com과 jeildolgopchang.com에는 사용자 에이전트 문자열을 GPTBot·ClaudeBot·PerplexityBot 이름으로 바꿔서도 요청해 봤습니다. 모두 200 응답에 크기도 위와 같았습니다. 다만 이름만 흉내 낸 요청이라, 진짜 봇이 OpenAI·Anthropic·Perplexity의 IP에서 왔을 때 CDN이 같은 응답을 주는지까지는 이 방법으로 알 수 없습니다.

측정의 한계도 적어 둡니다.

• 홈페이지 한 장씩, 한 시점, 한 위치에서 잰 값입니다. 하위 페이지는 재지 않았습니다.
• 처음 HTML에 있다는 것은 ‘읽을 수 있다’까지입니다. 실제로 크롤됐는지, 색인됐는지, AI 답변에 쓰였는지는 이 측정으로 알 수 없습니다.
• 6곳 모두 유환호가 기획·구축했거나 AI 검색 최적화를 맡은 사이트라, 처음 HTML에 핵심 정보를 넣는 방식으로 만든 사이트들입니다. 일반적인 동네 가게 홈페이지의 분포를 보여 주는 표본이 아닙니다.

구글도 ‘동적 렌더링’은 임시방편이라고 했다

자바스크립트 사이트를 그대로 두고, 크롤러가 오면 따로 그린 HTML을 보내 주는 방식을 동적 렌더링이라고 합니다. 빙은 2018년 글에서 자바스크립트에 크게 의존하는 사이트에 이 방법을 권했습니다. 지금 구글 문서의 입장은 다릅니다.

“Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines. Instead, we recommend that you use server-side rendering, static rendering, or hydration as a solution.”

동적 렌더링은 임시방편이었지 장기적인 해법이 아니며, 대신 서버 렌더링·정적 렌더링·하이드레이션을 권한다는 뜻입니다. 같은 문서는 “Other search engines may choose to ignore JavaScript and won’t see JavaScript-generated content”, 즉 다른 검색엔진은 자바스크립트를 무시해서 자바스크립트가 만든 내용을 못 볼 수도 있다고 적었습니다. 크롤러를 가려내 다른 HTML을 보내는 장치는 관리할 것이 늘고, 새 AI 크롤러가 생길 때마다 목록을 고쳐야 합니다. 처음부터 모두에게 같은 완성된 HTML을 보내는 쪽이 단순합니다.

사장님이 직접 확인하는 법

개발 지식 없이도 아래 세 가지 중 하나면 확인할 수 있습니다.

1. 페이지 소스 보기 (가장 쉬움)

크롬에서 내 홈페이지를 열고, 빈 곳에서 마우스 오른쪽 버튼 → ‘페이지 소스 보기’를 누릅니다(단축키 Ctrl+U, 맥은 ⌘+Option+U). 새로 열린 탭에서 Ctrl+F로 가게 이름, 도로명 주소, 영업시간 숫자, 대표 메뉴 가격을 하나씩 찾습니다. 찾아지면 처음 HTML에 있는 것입니다. 화면에는 보이는데 여기서 안 찾아지면 자바스크립트가 나중에 그린 글자입니다.

주의할 점: ‘검사’(F12)를 눌러 나오는 개발자 도구의 요소 화면은 자바스크립트가 다 돌아간 뒤의 모습이라 이 확인에는 맞지 않습니다. 반드시 ‘페이지 소스 보기’로 봅니다.

2. 자바스크립트를 끄고 열어 보기

크롬 설정 → 개인정보 보호 및 보안 → 사이트 설정 → JavaScript에서 사용을 허용하지 않는 쪽을 고르고 내 홈페이지를 새로 고칩니다. 빈 화면이나 ‘JavaScript를 켜 주세요’ 같은 문구만 보이면, 자바스크립트를 안 돌리는 크롤러도 그와 비슷한 것을 받는다고 보면 됩니다. 확인이 끝나면 설정을 원래대로 돌려놓습니다.

3. curl로 받아 보기

윈도우 10·11과 맥에는 curl이 기본으로 들어 있습니다. 명령 프롬프트나 터미널에서 아래처럼 받아 파일로 저장한 뒤, 메모장 같은 편집기로 열어 가게 이름을 찾습니다.

curl -sL https://내-홈페이지-주소/ -o page.html

윈도우 명령창에 바로 출력하면 한글이 깨져 보일 수 있으니, 파일로 저장해서 편집기로 여는 편이 낫습니다. 이 글의 6곳 측정도 이 방식으로 했습니다.

점검 체크리스트

• 홈페이지 ‘페이지 소스 보기’에서 가게 이름이 글자로 찾아진다
• 도로명 주소와 전화번호가 소스에서 찾아진다
• 영업시간(진료시간·수업시간) 숫자가 소스에 있다 — 이미지나 지도 위젯 안에만 있지 않다
• 대표 가격·서비스 이름이 소스에 있다 — 메뉴판 사진에만 있지 않다
• 자주 묻는 질문의 답이 탭·펼침 안에만 숨지 않고 본문에 있다(답을 먼저 쓰는 페이지 참고)
• 구조화 데이터(JSON-LD)를 넣었다면 소스 보기에서 application/ld+json이 찾아진다
• 자바스크립트를 끈 상태에서도 핵심 정보가 화면에 남는다
• robots.txt와 CDN·방화벽이 검색용 크롤러를 막지 않는다(ChatGPT 검색 노출 조건 참고)

하나라도 빠졌다면, 새로 만들 때는 정적 생성이나 서버 렌더링으로 짓고, 지금 사이트를 고칠 때는 핵심 정보 몇 줄만이라도 처음 HTML에 들어가도록 바꾸는 것부터 합니다. 이 점검을 통과해도 AI 답변에 나온다는 보장은 없습니다. 크롤·색인·후보 선정을 거쳐야 하고, 그 기간은 AI 상위노출은 얼마나 걸리나에 정리했습니다. 진단부터 재측정까지의 순서는 진행 방식에, 전체 그림은 AI 검색 노출 페이지에 있습니다.

이 글을 쓴 사람

유환호는 AI 상위노출(AEO·GEO·SEO) 일을 하는 사람입니다. 이 글의 실측 표에 나온 hwano-ai.com, 나비랑, 리뷰로거, 1965원조제일돌곱창 상무점, 노블365의원, 트이다학원 남악점은 유환호가 기획·구축했거나 AI 검색 최적화를 맡은 사이트이므로, 이 주제에 이해관계가 있습니다. 측정값은 구조화 데이터가 빠진 곳까지 그대로 적었고, 처음 HTML에 정보가 있다는 것이 노출을 보장하지 않는다는 한계와 함께 공개합니다. 내 홈페이지의 처음 HTML을 함께 보고 싶다면 연락하기로 주소를 보내 주세요.