자바스크립트 링크, AI 크롤러가 못 읽는 이유

결론부터 말하면 이렇다. 챗GPT·클로드·퍼플렉시티의 크롤러는 자바스크립트를 실행하지 않는다. 페이지의 메뉴·링크·본문 콘텐츠가 자바스크립트로 화면에 그려지는 구조라면, 이 크롤러들은 처음 받은 뼈대뿐인 HTML만 보고 돌아간다. 사람 눈에는 멀쩡히 보이는 링크와 글이, AI 입장에서는 애초에 존재하지 않는 페이지인 셈이다.

이 문제는 생각보다 흔하다. 리액트·뷰·앵귤러 같은 프레임워크로 만든 사이트, 또는 메뉴나 상품 목록을 자바스크립트로 나중에 채워 넣는 사이트라면 예외 없이 해당될 수 있다. 검색엔진 최적화(SEO)에서는 오래전부터 다뤄온 주제지만, AI 검색·생성형 엔진 최적화(GEO)로 넘어오면서 문제의 성격이 조금 다르게 바뀌었다.

구글은 자체 렌더링 서비스를 두고 자바스크립트를 실행해 페이지를 읽어낼 수 있지만, AI 검색 크롤러 대부분은 그런 여유가 없다. 이 글은 어떤 AI 크롤러가 자바스크립트를 못 읽는지, 내 사이트가 이 문제를 겪고 있는지 어떻게 확인하는지, 그리고 서버사이드 렌더링(SSR)·정적 사이트 생성(SSG)·프리렌더링 중 무엇을 골라야 하는지를 단계별로 정리한다.

이 글의 핵심만 먼저 추리면 이렇다.

• GPTBot·ClaudeBot·PerplexityBot 등 주요 AI 크롤러는 자바스크립트를 실행하지 않는다 — 최초 HTML만 읽는다
• 구글봇·제미나이만 예외적으로 구글의 렌더링 서비스를 통해 자바스크립트를 실행할 수 있다
• 메뉴·내부 링크·핵심 문단이 자바스크립트로 그려지면 AI 검색 답변·인용에서 통째로 빠질 수 있다
• 가장 근본적인 해결책은 서버사이드 렌더링(SSR) 이나 정적 사이트 생성(SSG) 이다
• 프리렌더링·동적 렌더링은 구글이 "장기 해법이 아닌 임시 우회책"이라 밝힌 방식이지만, 자바스크립트를 아예 실행 못 하는 AI 크롤러에는 여전히 실용적인 다리 역할을 한다

AI 봇은 왜 자바스크립트를 실행하지 않을까?

가장 큰 이유는 비용과 속도다. 자바스크립트를 실행하려면 크롬 같은 브라우저 엔진을 띄워 페이지를 실제로 그려봐야 한다. 이 작업(헤드리스 브라우저 렌더링)은 단순히 HTML 문서를 내려받는 것보다 서버 자원을 훨씬 많이 쓰고 시간도 오래 걸린다.

구글은 검색 하나만을 위해 이 비용을 감당할 만큼 오래 렌더링 인프라(웹 렌더링 서비스)에 투자해 왔다. 반면 챗GPT·클로드·퍼플렉시티의 크롤러는 웹 전체를 빠르게 훑어 텍스트 데이터를 모으는 것이 우선이다. 페이지마다 브라우저를 띄워 렌더링하면 같은 예산으로 수집할 수 있는 페이지 수가 크게 줄어든다. 그래서 대부분 원본 HTML만 받아오고, 자바스크립트 파일은 실행하지 않는 방식을 택하고 있다.

실제로 이 문제를 다룬 여러 업계 분석에서 비슷한 결론이 반복해서 나온다. 버셀(Vercel)이 실제 크롤러 트래픽을 분석한 자료에 따르면, GPTBot은 요청의 일부에서 자바스크립트 파일 자체는 내려받았지만 실행까지는 하지 않았고, ClaudeBot도 마찬가지였다. 5억 건이 넘는 GPTBot 요청을 분석한 별도 조사에서도 자바스크립트를 실행한 흔적은 발견되지 않았다는 보고가 있다. AI 크롤러에게 자바스크립트는 "받기만 하고 열어보지 않는 파일"에 가깝다.

자바스크립트를 아예 안 받는 것이 아니다. 파일은 다운로드하지만, 그 코드를 실행해서 화면을 그려보는 단계까지는 가지 않는다는 뜻이다. 결과적으로 코드가 만들어낼 콘텐츠는 크롤러 눈에 없는 것과 같다.

GPTBot·클로드봇·퍼플렉시티봇, 어떻게 다를까?

셋 다 자바스크립트를 실행하지 않는다는 점에서는 같다. 다만 어디서 쓰이는 크롤러인지, 어떤 목적으로 수집하는지는 조금씩 다르다. 아래 표로 정리했다.

크롤러	운영사	용도	자바스크립트 실행
GPTBot, OAI-SearchBot	오픈AI	모델 학습, 챗GPT 검색	미실행
ClaudeBot, Claude-SearchBot	앤트로픽	모델 학습, 클로드 검색 인용	미실행
PerplexityBot, Perplexity-User	퍼플렉시티	실시간 검색 답변 생성	미실행
Googlebot	구글	검색 색인	실행 가능(구글 웹 렌더링 서비스)
제미나이(Gemini)	구글	AI 오버뷰, AI 모드	실행 가능(구글봇 인프라 활용)

예외는 구글 계열뿐이다. 구글봇은 자체 웹 렌더링 서비스를 통해 크롬 브라우저로 페이지를 실제 그려본 뒤 색인한다. 제미나이 기반 AI 검색(AI 오버뷰, AI 모드)도 이 구글봇 인프라를 그대로 가져다 쓰기 때문에 자바스크립트로 그려지는 콘텐츠까지 볼 수 있다.

반대로 오픈AI·앤트로픽·퍼플렉시티 크롤러는 별도의 렌더링 인프라를 공개적으로 운영한다고 밝힌 적이 없다. 세 회사 모두 검색·답변 서비스의 크롤러 정책 문서에서 "표준 HTML을 수집한다" 는 취지로만 설명하고 있고, 자바스크립트 실행 여부에 대한 명시적인 언급은 없다. 업계에서 실제 트래픽을 분석해 "실행하지 않는다"는 결론을 내리는 이유다. 크롤러 정책은 회사 사정에 따라 바뀔 수 있으므로, 중요한 의사결정 전에는 최신 공식 문서를 다시 확인하는 것이 안전하다.

이 표를 볼 때 흔히 하는 오해가 하나 있다. "챗GPT나 퍼플렉시티가 결국 구글 검색 결과를 가져다 쓰기도 하니, 구글에만 잘 보이면 되는 것 아니냐"는 생각이다. 절반만 맞다. 퍼플렉시티나 챗GPT 검색은 상황에 따라 빙(Bing)이나 자체 인덱스를 함께 참고하기도 하지만, 모델을 학습시키는 단계의 크롤러(GPTBot, ClaudeBot)는 검색 결과와 별개로 웹을 직접 훑는다. 이 학습용 크롤러가 자바스크립트를 실행하지 못하면, 그 회사의 모델 자체가 애초에 학습 데이터 단계에서부터 해당 콘텐츠를 접하지 못했을 가능성이 있다. 검색 노출과 모델 학습 데이터 반영은 서로 다른 경로라는 점을 구분해서 봐야 한다.

우리 사이트가 이 문제를 겪고 있는지 어떻게 확인하나?

가장 빠른 방법은 자바스크립트를 꺼놓고 사이트를 열어보는 것이다. 크롬 개발자 도구에서 설정(⋮ 메뉴) → More tools → Rendering → "Disable JavaScript"를 켜고 새로고침해 보면 된다. 메뉴가 사라지거나, 본문이 텅 비거나, 링크를 눌러도 페이지가 안 넘어간다면 AI 크롤러도 똑같은 상태로 이 페이지를 보고 있다는 뜻이다.

두 번째 방법은 "페이지 소스 보기"(Ctrl+U 또는 Cmd+Option+U)를 열어 원본 HTML을 직접 확인하는 것이다. 이 화면은 브라우저가 자바스크립트를 실행하기 전, 서버가 맨 처음 보내준 문서 그대로다. 여기에 원하는 링크의 <a href="..."> 태그와 본문 텍스트가 실제로 들어 있는지 확인한다. 개발자 도구의 Elements 탭에 보이는 것은 "실행 후" 화면이라 다르다는 점에 주의해야 한다.

셋째, 서버 응답을 직접 확인하는 방법도 있다. 터미널에서 curl 내도메인.com 명령으로 받아오는 응답이 AI 크롤러가 실제로 받는 원본 HTML과 같다. 링크·본문이 빈 <div id="root"></div> 같은 껍데기만 있고 실제 텍스트는 안 보인다면, 자바스크립트가 실행돼야만 콘텐츠가 채워지는 구조라는 신호다.

리액트·뷰·앵귤러로 만든 사이트라고 무조건 문제인 것은 아니다. 서버에서 완성된 HTML을 먼저 보내주는 방식(SSR·SSG)이면 이 세 가지 점검을 모두 통과한다. 문제는 프레임워크 자체가 아니라 "HTML이 완성돼서 오는가, 브라우저가 자바스크립트로 채워야 완성되는가" 다.

넷째로, 구글 서치 콘솔의 URL 검사 도구를 활용하는 방법도 있다. "테스트된 페이지 보기"를 누르면 구글봇이 렌더링을 마친 뒤의 HTML과 스크린샷을 확인할 수 있다. 다만 이 도구는 구글봇 기준 렌더링 결과라서, 자바스크립트를 실행하지 못하는 AI 크롤러가 보는 화면과는 다르다는 점을 기억해야 한다. 구글 서치 콘솔에서 정상으로 보인다고 해서 AI 크롤러 문제까지 해결됐다고 판단하면 안 된다. 둘은 서로 다른 질문에 답하는 도구다.

링크가 안 보이면 실제로 무엇을 잃게 되나?

가장 직접적인 손실은 인용과 유입이다. AI 검색이 답변을 만들 때는 여러 페이지를 훑어 근거로 쓸 문장을 고른다. 자바스크립트로 그려지는 문단은 이 후보군에 아예 오르지 못한다. 같은 정보를 담고 있어도, 서버가 완성된 HTML로 보내주는 경쟁사 페이지만 인용되는 상황이 벌어질 수 있다.

두 번째 손실은 사이트 안 다른 페이지로의 연결이다. 크롤러는 한 페이지를 읽고 나면 그 안의 링크를 따라 다음 페이지로 이동하며 사이트를 넓혀간다. 메뉴나 "관련 글" 목록이 자바스크립트로만 그려진다면, 크롤러는 첫 페이지에서 더 나아가지 못하고 그 자리에서 멈춘다. 사이트 안에 아무리 좋은 글이 많아도 크롤러가 도달하는 경로 자체가 끊기는 셈이다.

세 번째는 엔티티 정보의 누락이다. 회사 소개, 서비스 설명, 연락처 같은 핵심 정보가 자바스크립트로 나중에 채워지는 페이지라면, AI가 "이 회사가 무엇을 하는 곳인지" 파악할 재료 자체가 부족해진다. AI 검색에 정확히 인용되려면 우선 AI가 그 내용을 읽을 수 있어야 한다는, 가장 기본적인 전제가 무너지는 것이다.

해결책 1 — 서버사이드 렌더링(SSR)이 가장 근본적인 이유

서버사이드 렌더링(SSR)은 사용자나 크롤러가 요청할 때마다 서버가 완성된 HTML을 만들어 보내주는 방식이다. 브라우저가 자바스크립트를 실행해야 콘텐츠가 채워지는 게 아니라, 서버가 미리 다 채워서 내려보낸다. Next.js, Nuxt, 앵귤러 유니버설 같은 프레임워크가 이 방식을 기본으로 지원한다.

이 방식이 근본적인 이유는 간단하다. 자바스크립트를 실행하는 크롤러(구글봇)든, 실행하지 않는 크롤러(GPTBot·클로드봇·퍼플렉시티봇)든 상관없이 똑같이 완성된 HTML을 받기 때문이다. 렌더링 능력이 있는지 없는지를 따질 필요 자체가 사라진다. 사람이 보는 화면과 크롤러가 받는 문서가 항상 같다는 점도 유지보수를 단순하게 만든다.

단점은 매 요청마다 서버가 페이지를 새로 그려야 해서 서버 자원이 더 든다는 것이다. 트래픽이 많은 사이트라면 캐싱 전략을 함께 설계해야 한다.

해결책 2 — 정적 사이트 생성(SSG)은 언제 적합한가?

정적 사이트 생성(SSG)은 배포하는 시점에 미리 모든 페이지를 HTML 파일로 구워두는 방식이다. 사용자나 크롤러가 요청하면 서버는 이미 만들어진 HTML 파일을 그대로 내려주기만 하면 된다. 요청마다 새로 계산하지 않으니 속도가 빠르고, 크롤러 입장에서도 항상 완성된 문서를 받는다.

블로그·회사 소개·서비스 안내 페이지처럼 콘텐츠가 자주 실시간으로 바뀌지 않는 페이지에 특히 잘 맞는다. 요청마다 새로 계산하지 않아도 되니 크롤러 입장에서 가장 안정적으로 읽히는 방식이기도 하다. 이 글이 실려 있는 이루웹 블로그도 마크다운 파일을 기반으로 정적으로 페이지를 만들어 서버 컴포넌트로 내려주는 구조를 쓰고 있는데, 바로 이런 이유에서다. 반대로 로그인 후 개인화된 대시보드처럼 사용자마다 내용이 완전히 달라지는 페이지에는 SSG보다 SSR이나 다른 방식이 더 맞다.

실무 기준으로 보면 "콘텐츠가 방문자마다 다르지 않다"면 SSG, "방문자·시점마다 달라진다"면 SSR을 우선 검토하는 것이 합리적인 출발점이다.

개발자가 아니어도 이해할 수 있게, 실제로는 어떻게 적용하나?

결론부터 말하면 개발 프레임워크 선택과 설정의 문제이지, 디자인이나 기획을 갈아엎어야 하는 일이 아니다. Next.js 같은 프레임워크는 페이지마다 렌더링 방식을 지정할 수 있게 돼 있다. 예를 들어 상품 상세·블로그 글처럼 내용이 자주 안 바뀌는 페이지는 정적 생성(SSG)으로, 로그인 후 대시보드처럼 매번 달라지는 페이지는 서버사이드 렌더링(SSR)으로 지정하는 식이다. 같은 사이트 안에서도 페이지 성격에 따라 두 방식을 섞어 쓰는 경우가 오히려 일반적이다.

기존에 클라이언트사이드 렌더링(CSR)으로만 만들어진 사이트를 한 번에 전면 전환하는 것은 비용과 리스크가 크다. 실무에서는 보통 AI 검색·SEO에 중요한 페이지(홈, 서비스 소개, 블로그, 상품 목록)부터 우선순위를 매겨 순서대로 전환하는 방식을 쓴다. 로그인 뒤에만 보이는 내부 관리 화면처럼 애초에 검색·AI 노출이 필요 없는 페이지까지 무리해서 바꿀 필요는 없다.

담당 개발자에게 "우리 사이트, 페이지 소스 보기로 봤을 때 본문 텍스트가 그대로 보이나요?"라고 물어보는 것만으로도 대화를 시작할 수 있다. 이 질문에 "아니요, 자바스크립트가 실행돼야 보입니다"라는 답이 돌아온다면, 우선순위 페이지부터 SSR·SSG 전환을 검토할 시점이다.

해결책 3 — 프리렌더링·동적 렌더링, 여전히 쓸 만할까?

프리렌더링(동적 렌더링)은 크롤러로 인식되는 요청에만 미리 렌더링해 둔 HTML 스냅샷을 보여주는 방식이다. 자바스크립트 기반 사이트 구조를 그대로 두면서, 봇에게만 완성된 문서를 따로 내주는 우회책이다.

여기서 정확히 짚어야 할 점이 있다. 구글은 2022년 이후 공식 문서에서 동적 렌더링을 "장기적인 해법이 아니라 임시방편" 이라고 밝히고, 검색을 위한 권장 방식에서 제외했다. 자바스크립트를 실행할 수 있는 구글봇 입장에서는 애초에 SSR이나 SSG로 근본 해결하는 편이 낫기 때문이다.

다만 AI 크롤러 상황은 다르다. GPTBot·클로드봇·퍼플렉시티봇은 자바스크립트를 아예 실행하지 않으므로, 구글봇처럼 "언젠가는 알아서 렌더링해서 읽어줄" 여지가 없다. 당장 SSR·SSG로 전면 전환하기 어려운 기존 사이트라면, 프리렌더링은 이 크롤러들에게 최소한의 콘텐츠를 보여줄 수 있는 실용적인 다리 역할을 한다. 다만 이는 근본 해결책을 준비하는 동안의 임시 조치로 접근하는 것이 맞다. 봇 판별 로직을 새 크롤러가 나올 때마다 계속 갱신해줘야 하는 유지보수 부담도 따라온다.

여기서 걱정이 하나 따라온다. "봇에게만 다른 페이지를 보여주면 클로킹(위장 기법)으로 페널티를 받지 않나?"라는 질문이다. 구글은 동적 렌더링을 정당한 기술로 공식 문서에서 인정해 왔다. 클로킹은 검색엔진과 사용자에게 서로 다른 내용을 보여줘 순위를 조작하는 행위를 가리킨다. 반면 동적 렌더링·프리렌더링은 사람이 자바스크립트 실행 후 보는 것과 같은 내용을, 크롤러에게는 미리 렌더링해 둔 형태로 전달할 뿐이다. 콘텐츠 자체가 같다면 클로킹으로 보지 않는다는 것이 핵심 구분 기준이다.

다만 이 구분을 지키려면 몇 가지는 반드시 챙겨야 한다. 봇에게 보여주는 스냅샷에 사용자에게는 없는 숨김 텍스트나 링크를 추가로 끼워 넣지 않아야 하고, 콘텐츠가 바뀌면 봇용 캐시도 함께 갱신해야 한다. 이 원칙만 지키면 프리렌더링은 안전하게 쓸 수 있는 임시 조치다.

정적 링크를 함께 두는 것만으로 충분할까?

당장 전체 구조를 바꾸기 어렵다면, 핵심 링크만이라도 순수 HTML <a href> 태그로 병행해 두는 것이 가장 빠른 응급조치다. 자바스크립트로 동작하는 메뉴 옆에, 눈에는 안 보여도 되니 실제 <a href="/서비스경로"> 링크가 원본 HTML 안에 존재하도록 만드는 방식이다. 완전한 해법은 아니지만 크롤러가 사이트 안쪽 페이지로 넘어갈 최소한의 통로는 확보된다.

다만 이 방법은 본문 콘텐츠 자체가 자바스크립트로 그려지는 문제까지는 해결하지 못한다. 링크는 보여도 그 링크를 눌러 이동한 페이지의 본문이 여전히 자바스크립트로 채워진다면 같은 문제가 반복된다. 정적 링크 병행은 SSR·SSG로 가는 과정의 보조 수단이지, 그 자체로 끝이 아니다.

아래는 실제 마크업에서 자주 보는 나쁜 예와 좋은 예를 비교한 것이다.

나쁜 예: <div onclick="location.href='/services'">서비스 보기</div> — 겉보기엔 링크처럼 동작하지만, 원본 HTML에는 href 속성 자체가 없다. 자바스크립트가 실행돼야만 클릭이 이동으로 이어진다. 크롤러는 이 div를 그냥 텍스트 조각으로만 본다.

좋은 예: <a href="/services">서비스 보기</a> — 원본 HTML 단계에서부터 목적지 주소가 명확히 존재한다. 자바스크립트가 실행되지 않아도 이 태그 하나만으로 링크의 존재와 목적지를 크롤러가 그대로 읽어낼 수 있다.

발행 전 점검 체크리스트

• 핵심 메뉴·내부 링크가 원본 HTML(페이지 소스 보기 기준)에 <a href>로 존재하는가
• 자바스크립트를 꺼도 본문 텍스트가 화면에 그대로 보이는가
• curl로 받은 응답에 실제 콘텐츠 텍스트가 들어 있는가
• 새로 만드는 페이지는 SSR·SSG 중 콘텐츠 성격에 맞는 방식을 우선 적용하는가
• 당장 구조를 못 바꾸는 레거시 페이지는 프리렌더링으로 최소한의 임시 조치를 해뒀는가

자주 묻는 질문

리액트로 만든 사이트는 무조건 AI 검색에서 불리한가?

아니다. 리액트 자체가 문제가 아니라 렌더링 방식이 문제다. Next.js처럼 서버에서 완성된 HTML을 먼저 내려주는 프레임워크·설정을 쓰면 리액트로 만들어도 크롤러는 완성된 문서를 받는다. 반대로 순수 클라이언트사이드 렌더링(CSR)만 쓰는 리액트 앱이라면 이 글에서 설명한 문제를 그대로 겪는다.

사이트맵을 제출하면 이 문제가 해결되나?

아니다. 사이트맵은 "이런 페이지들이 있다"는 목록을 알려줄 뿐, 그 페이지 안의 콘텐츠를 대신 읽어주지는 않는다. 사이트맵에 링크가 올라가 있어도, 그 페이지를 열었을 때 본문이 자바스크립트로 채워지는 구조라면 AI 크롤러는 여전히 빈 화면을 보게 된다. 사이트맵과 렌더링 방식은 서로 다른 문제이며 둘 다 챙겨야 한다.

워드프레스나 카페24 같은 빌더로 만든 사이트도 해당하나?

워드프레스나 국내 빌더형 플랫폼은 기본적으로 서버에서 완성된 HTML을 내려주는 구조가 많아 이 문제에서 비교적 자유로운 편이다. 다만 특정 테마나 플러그인이 메뉴·상품 목록을 자바스크립트로 나중에 그리도록 설정돼 있다면 같은 문제가 생길 수 있다. 플랫폼 종류와 무관하게, 이 글에서 소개한 점검 방법으로 직접 확인해 보는 것이 정확하다.

지금 당장 무엇부터 해야 하나?

가장 먼저 페이지 소스 보기로 핵심 페이지 몇 개를 열어, 메뉴 링크와 본문 텍스트가 원본 HTML에 있는지부터 확인하는 것이 순서다. 문제가 발견되면 새로 만드는 페이지부터 SSR이나 SSG로 전환하고, 당장 손대기 어려운 기존 페이지는 정적 링크 병행이나 프리렌더링으로 최소한의 통로를 먼저 열어두는 것이 현실적인 순서다.

프리렌더링을 쓰면 구글에서 클로킹으로 페널티를 받지는 않나?

봇에게 보여주는 콘텐츠가 사용자가 자바스크립트 실행 후 보는 콘텐츠와 같다면 클로킹이 아니다. 구글도 동적 렌더링을 정당한 기법으로 문서에서 다뤄 왔다. 다만 봇용 스냅샷에 사용자에게는 없는 숨김 텍스트나 링크를 몰래 추가하거나, 콘텐츠가 바뀌었는데 봇용 캐시만 예전 상태로 남겨두는 경우는 문제가 될 수 있다. "같은 내용을 형태만 다르게 준다"는 원칙만 지키면 안전하다.

AI 검색에 노출되면 실제 방문자 유입에도 도움이 되나?

이 글의 핵심 범위를 벗어나는 별도 주제이긴 하지만 간단히 답하면, AI 검색 답변에 출처로 인용되면 그 링크를 타고 들어오는 방문이 새로 생긴다는 보고가 여러 업계 분석에서 공통적으로 나온다. 다만 인용된다고 항상 클릭으로 이어지는 것은 아니며, 유입 규모는 주제·업종마다 차이가 크다. 먼저 인용 대상이 될 자격(크롤러가 콘텐츠를 읽을 수 있는 상태)부터 갖추는 것이 순서다.

---

자바스크립트 렌더링 구조를 점검하고 SSR·SSG 기반으로 사이트를 새로 정리하고 싶으시다면 이루웹이 도와드리고 있습니다. 검색과 AI 노출을 함께 고려한 홈페이지 제작부터 기술 SEO·GEO 점검까지 진행해 드립니다. 구조화 데이터가 궁금하시다면 JSON-LD 스키마 마크업 가이드와 홈페이지 구조 설계 가이드도 함께 참고해 보시기 바랍니다. 궁금하신 점은 무료 상담으로 편하게 문의해 주시기 바랍니다.