AI 크롤러는 JavaScript를 실행하지 않는다

결론부터 말하면

AI 크롤러는 JavaScript를 실행하지 않는다. GPTBot, ClaudeBot, PerplexityBot이 페이지를 요청할 때 하는 일은 평범한 HTTP GET이며, 서버가 돌려준 바이트를 받아 텍스트로 파싱하는 것이 전부다. 브라우저도 없고, DOM 구성도 없고, 하이드레이션도 없으며, XHR이 해소되기를 기다리는 일도 없다. Vercel과 MERJ가 한 달 동안 5억 6,900만 건의 GPTBot 요청과 3억 7,000만 건의 ClaudeBot 요청을 처리하는 네트워크를 대상으로 수행한 공동 분석에서, 주요 AI 크롤러가 JavaScript를 실행한다는 증거는 하나도 발견되지 않았다. 스크립트 파일 자체를 내려받는 경우는 있다. GPTBot은 요청의 11.50%에서, ClaudeBot은 23.84%에서 JavaScript를 받아 갔다. 그리고 결코 그것을 실행하지 않는다.

예외는 Google이며, 이토록 많은 팀이 이 문제를 눈치채지 못한 이유도 바로 거기에 있다. Googlebot은 헤드리스 Chromium 렌더링 서비스를 운영하고, Gemini는 그 인프라 위에 근거를 둔다. 그래서 클라이언트 측에서 렌더링되는 파라메트릭 카탈로그가 Google 검색에서는 아무 문제 없이 상위에 오르면서도, ChatGPT와 Claude, Perplexity에서는 완전히 사라져 있을 수 있다. 그리고 이 둘은 더 이상 같은 독자가 아니다. Forrester의 2026년 구매자 조사에서 기업 구매 담당자의 94%가 구매 과정에서 AI를 사용한다는 사실이 확인됐고, Adobe는 소매 사이트로 유입되는 AI 경유 트래픽이 2026년 1분기에 전년 대비 393% 증가했다고 측정했다.

GPTBot이 실제로 받아 가는 것

여기서는 관련된 두 개의 문서를 정확히 구분해 두는 편이 좋다. 대부분의 카탈로그 담당 팀은 두 번째 문서만 들여다보기 때문이다.

원본 HTML은 오리진 서버가 응답에 써 내려가는 바이트 스트림이다. curl이 출력하는 것이고, view-source:가 보여 주는 것이며, 텍스트만 다루는 HTTP 클라이언트가 파싱하는 것이다.

렌더링된 DOM은 브라우저가 그 HTML을 파싱하고, 모든 스크립트를 내려받아 실행하고, 모든 fetch() 호출을 해소하고, 모든 변경을 적용한 뒤에 메모리에 존재하는 것이다. 브라우저 개발자 도구의 Elements 패널에 보이는 것이 바로 이쪽이다.

요즘의 SPA 카탈로그에서 이 두 문서는 공통점이 거의 없다. 원본 HTML은 껍데기다. <div id="root"> 하나와 프리로드 매니페스트, 그리고 100킬로바이트 남짓의 번들 참조가 전부다. 의미 있는 문자열은 부품 번호, 패키지, 공차, 동작 온도 범위, RoHS 상태, 수명 주기 상태, 재고, 수량별 단가까지 하나도 빠짐없이 나중에, 크롤러가 결코 호출하지 않을 API를 통해 도착한다.

AI 크롤러는 당신의 원본 HTML만 볼 뿐, 그 밖의 것은 아무것도 보지 못한다. 어떤 사양이 서버가 돌려주는 바이트 안에 없다면, 모델에게 그 사양은 존재하지 않는 것이다.

렌더링하는 클라이언트와 그렇지 않은 클라이언트

표에 적힌 "안 함"은 모두 Vercel과 MERJ의 데이터셋에서 실측된 동작이지 추론이 아니다. "함"은 모두 운영 주체가 문서로 밝힌 내용이다. Google은 자사 렌더링 파이프라인을 공개하고 있고, Apple의 크롤러 문서에는 Applebot이 "브라우저 안에서 웹사이트의 콘텐츠를 렌더링할 수 있다"고 적혀 있다. Anthropic의 더 새로운 에이전트인 Claude-SearchBot과 Claude-User는 이 연구보다 뒤에 나와 별도로 측정되지 않았고, 그 이후로 이들에 대해 렌더링 파이프라인을 발표한 운영 주체도 없다.

실무적인 귀결은 달갑지 않은 방향으로 비대칭적이다. 크롤링에서 비용이 드는 부분이 바로 렌더링이고, 그 렌더링을 건너뛴 운영 주체들이 하필 지금 당신의 제품과 구매자 사이에 앉아 있다.

파라메트릭 카탈로그가 유독 더 크게 무너지는 이유

Adobe가 2026년 4월에 내놓은 분석은 소매 페이지의 기계 가독성을 점수화했고, 제품 상세 페이지가 66%로 모든 페이지 유형 가운데 최하위라는 결과를 내놓았다. 홈페이지(75%), 카테고리 페이지(74%), 심지어 FAQ 페이지(80%)보다도 낮다. 이 순서는 우연이 아니다. 가장 구조화되어 있고, 가장 값어치가 크며, 의사결정에 가장 직결되는 데이터를 담은 페이지가 곧 JavaScript로 가장 많이 조립된 페이지이기 때문이다.

피해의 대부분은 다섯 가지 패턴으로 설명된다.

1. 01필터 상태가 클라이언트에 있다. 파라메트릭 셀렉터는 로컬 스토어를 읽는 React 컴포넌트일 뿐이다. "0603, 100nF, X7R, 50V"에 해당하는 서버 렌더링 URL이 존재하지 않으므로, 크롤러가 가져갈 것도 없고 인용할 것도 없다.
2. 02사양 표가 API 응답이다. 페이지 껍데기가 먼저 그려지고, 그다음 /api/product/attributes로 보낸 요청이 표를 채운다. 크롤러는 껍데기에서 멈춘다.
3. 03가격과 재고를 의도적으로 클라이언트 측에 둔다. 캐싱 관점에서는 합리적이다. 그러나 기계 가시성에는 치명적이다. 재고를 볼 수 없는 모델은 그 부품을 추천하지 않기 때문이다.
4. 04탭과 아코디언이 내용 로딩을 미룬다. 데이터시트, 애플리케이션 노트, 적합성 인증서, CAD 링크는 클릭하는 시점에 불러오는 경우가 많다. 크롤러는 클릭하지 않는다.
5. 05무한 스크롤이 페이지네이션을 대체한다. 51번째 제품부터는 크롤링할 수 있는 URL이 아예 없다.

Partsgraph는 2026년 8월 북미와 유럽, 아시아에 걸친 전 세계 984개 유통사·제조사 도메인을 감사했다. AI 가시성 점수의 중앙값은 100점 만점에 50점이었고, 대상군의 70%가 D 또는 F 등급을 받았다. 대략 절반은 표준적인 비브라우저 클라이언트에 읽을 수 있는 카탈로그 페이지를 단 한 장도 내주지 못했다. 가장 취약한 부문은 전자부품 유통으로, 중앙값이 34였다.

AI 크롤러가 우리 카탈로그를 읽을 수 있는지 어떻게 확인하는가

이 점검은 자사 오리진을 대상으로 실시하라. 크롤러 사용자 에이전트를 위장해 경쟁사 사이트를 시험하면 잘못된 음성 결과가 나온다. 기업용 봇 관리 솔루션은 사용자 에이전트 문자열이 아니라 출발지 IP로 크롤러를 검증하기 때문이다. 알려지지 않은 주소에서 온 위장 헤더는 robots.txt에 무엇이 적혀 있든 차단 검사를 받는다.

1. 01원본 HTML을 가져온다. 가장 값어치 있는 제품 페이지 하나를 고른다.

curl -sS --compressed -o page.html -w "status=%{http_code} bytes=%{size_download}" "https://example.com/products/part-number"

1. 01바이트 안에서 부품 번호를 찾는다. 브라우저가 아니라 파일에서 찾아야 한다.

grep -c "MPN-12345" page.html

이 명령이 0을 돌려주면, 어떤 AI 크롤러도 그 페이지가 해당 부품에 관한 것임을 알아볼 수 없다.

1. 01엔지니어가 필터에 쓸 법한 파라메트릭 값 세 개를 찾는다.

grep -oiE "operating temperature|tolerance|package|rohs|lifecycle" page.html | sort | uniq -c

1. 01구조화 데이터 블록의 개수를 센다.

grep -c "application/ld+json" page.html

0이면 기계가 읽을 수 있는 제품 레코드가 없다는 뜻이다. 1개 이상이라면 그 내용을 꺼내어, 단순한 브레드크럼 경로가 아니라 sku, mpn, gtin, brand, offers와 핵심 additionalProperty 항목을 실제로 담고 있는지 검증해야 한다.

1. 01렌더링된 페이지와 비교한다. JavaScript를 끈 브라우저에서 같은 URL을 열어 본다. 거기서 살아남는 것이 대체로 크롤러가 받는 것이다. 그것과 평소 페이지의 격차가 곧 당신의 비가시성이다.

1. 01한 페이지가 아니라 경로 전체를 확인한다. 카테고리 페이지, 검색 결과 페이지, 데이터시트 링크, CAD 다운로드에 대해서도 같은 절차를 반복하라. 제품 페이지는 읽을 수 있어도 크롤링 가능한 카테고리 목록에서 그 페이지에 도달하지 못하는 크롤러는 여전히 막혀 있는 셈이다.

통과하는 페이지라면 부품 번호가 수십 번 등장하고, 파라메트릭 항목명이 텍스트로 존재하며, JSON-LD 블록이 최소 하나는 나온다. 참고로 잘 만들어진 제품 페이지는 대개 전체 사양 표를 담은 60~200KB의 HTML을 돌려주고, 망가진 SPA 껍데기는 번들 참조 말고는 아무것도 없는 4~15KB를 돌려준다.

사이트를 다시 만들지 않고 어떻게 고치는가

플랫폼을 갈아엎을 필요는 없다. 오리진이 내보내는 바이트 안에 사실이 담기게 하면 된다. 경로는 네 가지이며, 서로 배타적이지 않다.

제품·카테고리 라우트에 서버 사이드 렌더링을 적용하는 것이 오래가는 답이다. 이미 이를 지원하는 프레임워크를 쓰고 있다면, 카탈로그 라우트를 서버 컴포넌트나 증분 재검증을 갖춘 정적 생성으로 옮기는 일은 대개 분기 단위가 아니라 몇 주 단위의 작업이다. 데이터 계층은 이미 존재하고, 다만 잘못된 쪽에서 호출되고 있을 뿐이기 때문이다.

프리렌더링은 정직한 임시방편이다. 각 제품 페이지를 빌드 시점이나 일정 주기로 한 번 렌더링해 그 HTML을 엣지에 캐시하고, 모두에게 그것을 제공하라. 사람에게든 기계에든 같은 문서를 내주어야 한다. 크롤러에만 다른 페이지를 보여 주는 클로킹은 정책상 위험할뿐더러 실제로도 자기 발등을 찍는 일이다. 모델은 자신이 받은 버전을 그대로 인용하기 때문이다.

서버 렌더링 JSON-LD는 적은 노력으로 가장 큰 효과를 내는 변경이다. 태그 매니저가 아니라 서버가 내보내는 HTML 안에 넣어라.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "sku": "MPN-12345",
  "mpn": "MPN-12345",
  "name": "100 nF 50 V X7R 0603 ceramic capacitor",
  "brand": { "@type": "Brand", "name": "Example Components" },
  "additionalProperty": [
    { "@type": "PropertyValue", "name": "Capacitance", "value": "100 nF" },
    { "@type": "PropertyValue", "name": "Voltage rating", "value": "50 V" },
    { "@type": "PropertyValue", "name": "Dielectric", "value": "X7R" },
    { "@type": "PropertyValue", "name": "Operating temperature", "value": "-55 to +125 C" }
  ],
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "0.042",
    "availability": "https://schema.org/InStock"
  }
}
</script>

마크다운 미러는 페이지를 모호하지 않게 만드는 가장 값싼 방법이다. 모든 제품 페이지에 대응하는 평문 버전을 안정적이고 링크가 걸린 URL로 제공하고, 사양 표는 마크다운 표로 렌더링하라. 텍스트만 다루는 클라이언트는 이를 완벽하게 파싱하고, 같은 데이터 소스에서 생성하는 비용은 거의 들지 않으며, 프런트엔드를 새로 디자인해도 흔들리지 않는 정규 기계 접점을 손에 넣게 된다. 다만 llms.txt는 이것과 다르다는 점에 유의하라. 2026년 현재 이를 읽겠다고 약속한 주요 AI 운영사는 없고, Google의 Search Relations 팀은 지지 의사를 명시적으로 접었다. 미러가 통하는 이유는 그것이 링크가 걸린 평범한 페이지이기 때문이다.

오버레이는 위의 모든 것을 기존 사이트 안이 아니라 그 앞단에 놓는 방식이다. 사이드카 서비스나 엣지 워커가 기존 PIM을 읽어, 서버에서 렌더링된 에이전트 가독 페이지와 JSON-LD, 마크다운 미러, 호스팅형 MCP 엔드포인트를 자사 도메인에서 제공한다. 고객이 보는 사이트는 무엇도 바뀌지 않는다. Partsgraph가 취하는 접근이 바로 이것이며, 자체 구축에 나서는 제조사도 점점 늘고 있다. Microchip은 2025년 11월 자사 제품 데이터를 위한 무료 공개 MCP 서버를 내놓았고, ECIA의 TrustedParts는 2026년 6월 재고 AI 에이전트 서비스를 시작했다.

무엇부터, 어떤 순서로 할 것인가

1. 01위의 6단계 점검을 주력 제품 10개에 실행하고 바이트 수를 기록하라.
2. 02제품 페이지의 JSON-LD를 서버에서 렌더링하라. 가장 작은 변경으로 가장 큰, 측정 가능한 효과를 낸다.
3. 03대화형 버전은 클라이언트 측에 남겨 두더라도, 모든 사양과 데이터시트 링크, CAD 링크가 최초 HTML 안에 존재하게 하라.
4. 04의미 있는 모든 파라메트릭 필터 조합에 실제로 존재하고 크롤링할 수 있는, 서버에서 렌더링된 URL을 부여하라.
5. 05제품마다 마크다운 미러를 발행하고 그 페이지에서 링크하라.
6. 06순위와 프롬프트, 답변 점유율은 그다음에 걱정하라. 인용에 앞서 수집이 있다. 콘텐츠가 응답 본문 안에 존재하기 전까지는 최적화할 대상 자체가 없다.

여기서 작동하는 메커니즘은 미묘하지도 않고 논쟁거리도 아니다. 모델은 자신이 받은 것만 인용할 수 있고, 그것이 받은 것은 당신의 원본 HTML이다. 나머지는 전부 끝내 일어나지 않은 렌더링 단계일 뿐이다.

자사 카탈로그가 어디쯤 서 있는지 알고 싶은가? 무료 Partsgraph AI 가시성 그레이더가 이 글의 점검 항목을 당신의 도메인에 그대로 실행한다. [/audit](/audit)에서 확인해 보라.