ChatGPT가 우리 사이트를 못 읽는다고요? 1분 설명

작성 2026-04-18 · 업데이트 2026-04-18

관련 기술 원문: https://soyoyu.cc/blog/websites-chatgpt-cannot-read

“ChatGPT에 우리 회사 이름을 물어봤는데 ‘못 찾겠다’고 하더라.” 자주 듣는 말씀입니다. 구글에는 나오는데 ChatGPT에는 안 나오실 때가 있습니다. 이럴 때 원인은 대부분 한 가지 지점에 몰려 있습니다. 이 글은 그 원인을 요리 비유 한 번으로 풀고, 우리 사이트가 어느 쪽인지 브라우저만 갖고 1분 안에 확인하는 방법을 함께 담았습니다. 기술 용어는 모두 풀어쓰겠습니다.

먼저, 우리 사이트가 어느 쪽인지 1분 확인

본격 설명 전에, 사장님 사이트가 문제가 있는 쪽인지 먼저 판별하시는 것이 빠릅니다. 브라우저 하나면 됩니다. 개발자 도구나 명령어는 쓰지 않습니다.

  1. 우리 사이트를 브라우저에서 엽니다.
  2. 빈 영역에서 오른쪽 클릭 → “페이지 소스 보기”를 누릅니다. 단축키는 Windows·Linux에서 Ctrl+U, macOS Chrome에서 Cmd+Option+U입니다. macOS Safari는 상단 메뉴 “Develop → Show Page Source”입니다(Develop 메뉴가 안 보이시면 Safari 설정 → 고급 → “메뉴 막대에 개발용 메뉴 보기”를 체크하십시오).
  3. 새로 열린 창에서 Ctrl+F 또는 Cmd+F를 누르고, 회사명이나 대표 상품명을 검색합니다.

결과 해석은 다음과 같습니다. 한 가지 주의점이 있습니다. 검색 결과가 <script type="application/javascript"> 블록이나 __NEXT_DATA__ 같은 “하이드레이션용 데이터 덩어리” 안에서만 발견된다면 그것은 이 글의 주제에 해당합니다. 크롤러는 그런 스크립트 안 데이터를 “본문”으로 읽지 않기 때문입니다. 단, <script type="application/ld+json"> 블록(구조화 데이터)에서 회사명이 나오는 것은 예외입니다. JSON-LD는 AI·검색엔진이 의도적으로 읽어들이는 공식 신호이므로, 이 안에 회사명·업종·주소가 있는 것은 오히려 긍정 신호입니다.

  • 회사명이 <p>, <h1>, <div> 같은 본문 태그 안에 자연스럽게 섞여 나옵니다 → 안전합니다. 이 글의 문제 대상이 아닙니다.
  • 회사명이 JSON-LD(<script type="application/ld+json">) 안에도 나옵니다 → 구조화 데이터까지 있는 상태로, 더 좋은 신호입니다.
  • 회사명이 __NEXT_DATA__/__NUXT__ 같은 하이드레이션 <script> 블록 안에서만 검색되고 본문 태그에는 없습니다 → 이 글의 주제에 해당합니다(CSR + 스크립트 내 데이터).
  • 회사명이 <title>이나 메타 태그에만 있고 본문 부분은 거의 비어 있습니다 → 이 글의 주제에 해당합니다.
  • 전체 HTML이 수십 줄밖에 안 되고 <div id="root"></div> 또는 <div id="__next"></div> 같은 빈 상자만 보입니다 → 이 글의 주제에 해당합니다. 본문 설명을 이어서 읽으시면 됩니다.

브라우저 화면은 모든 조립이 끝난 모습입니다. 페이지 소스는 서버가 처음에 보낸 원본입니다. AI 크롤러가 보는 것은 후자에 가깝습니다.

왜 AI는 어떤 사이트만 못 읽나 — 차려진 밥상 vs 재료 배달

요리 비유가 가장 빠릅니다. 홈페이지를 손님에게 배달하는 방식은 크게 두 가지입니다.

첫째, 차려진 밥상으로 보내는 방식입니다. 주방(서버)에서 음식을 완성해서 포장해 보냅니다. 손님이 포장을 뜯으면 이미 상이 차려져 있습니다. 누가 받든 같은 음식이 나옵니다. 업계에선 이 방식을 SSR(Server-Side Rendering, 서버에서 완성해 보내기)이라고 부릅니다.

둘째, 재료 배달입니다. 재료 상자와 조리 설명서만 보냅니다. 손님 집 주방이 돌아야 요리가 나옵니다. 주방 사정에 따라 결과가 달라집니다. 이 방식은 CSR(Client-Side Rendering, 손님 쪽에서 조립)이라고 합니다.

왜 재료 배달 방식을 쓸까요. 사용자가 페이지 안에서 이리저리 움직일 때 화면 전환이 매끄럽기 때문입니다. 대시보드, SNS, 실시간 차트처럼 대화형 요소가 많은 서비스에 유리합니다. CSR이 나쁜 기술인 것은 아닙니다. 용도가 다를 뿐입니다.

문제가 생기는 지점은 여기입니다. 손님 측에서 주방을 돌려야 요리가 나오는데, 이 “주방”을 돌려주지 않는 손님이 있습니다. 바로 AI 크롤러입니다.

사람은 괜찮은데, AI 크롤러는 왜 다른가

사용자 브라우저는 재료를 받으면 주방을 돌려줍니다. 전기료도 내고 시간도 씁니다. 그래서 사용자 눈에는 멀쩡해 보입니다.

구글은 중간쯤 입니다. 2019년 이후로 Googlebot은 재료 배달도 가져가서 주방을 돌려봅니다. 다만 한 번에 끝내지 않습니다. 처음엔 재료(기본 HTML)만 보고 일단 색인 후보에 넣고, 며칠 뒤에 다시 와서 조리까지 해봅니다. 구글 공식 문서가 이를 “2단계 색인”(two-wave indexing)이라고 표현합니다. 결과적으로 구글 검색에는 늦게라도 우리가 나옵니다.

ChatGPT·Perplexity·Claude 쪽은 다릅니다. OpenAI는 ChatGPT 답변에서 사이트를 인용할 때 쓰는 OAI-SearchBot, 사용자가 ChatGPT 대화 중 특정 URL을 열어달라고 요청할 때 페이지를 가져오는 ChatGPT-User, 모델 학습용 GPTBot을 나눠서 운영합니다. Perplexity는 PerplexityBot, Anthropic은 ClaudeBot을 씁니다. 공개 문서와 각사 크롤러 동작 보고를 종합해보면, 답변 인용·학습용 배치 크롤러 (OAI-SearchBot, GPTBot, PerplexityBot, ClaudeBot)는 대체로 서버가 처음 보낸 정적 HTML을 수집하고 갑니다. 재료만 보고 가는 배달원입니다. 주방을 돌리는 일은 비용과 시간이 크게 들어서, 수십억 페이지를 도는 AI 크롤러는 그 단계를 생략합니다. 예외는 ChatGPT-User입니다. 이 UA는 사용자가 대화 중 URL을 직접 넘겼을 때만 등장하는 실시간 브라우저형 접근이라, 일반 크롤러와 달리 더 풍부하게 페이지를 받아올 수 있습니다. 정리하면 ChatGPT 답변 가시성에 핵심인 배치 크롤러는 OAI-SearchBot이고, ChatGPT-User는 별개의 사용자 주도 UA이며, GPTBot은 학습 포함 여부를 결정할 때 관련됩니다. 이 셋을 섞어 쓰면 robots.txt·로그 점검에서 정반대 결과가 나올 수 있으니 분별이 필요합니다.

비유를 정리하면 이렇습니다.

  • 사용자 브라우저: 주방을 돌려주는 손님. 재료 배달도 문제없이 먹습니다.
  • Googlebot: 한 번 재방문하는 까다로운 손님. 재료 배달도 결국 조리해서 확인합니다. 다만 늦습니다.
  • AI 크롤러: 하루 수만 집을 도는 배달 점검원. 재료만 보고 지나갑니다.

실무에서 이 차이가 만드는 결과는 명확합니다. 구글 검색에는 늦게라도 나오는 사이트가 ChatGPT 답변에서는 영영 인용되지 않는 일이 벌어집니다. 구글에 나오니 괜찮은 줄 알았는데, 정작 AI 시대의 새 유입 경로(ChatGPT·Perplexity 같은 대화형 AI 검색)에서는 사라져 있는 상태입니다.

해결 방향 3갈래 — 규모와 급한 정도에 따라 고르시면 됩니다

우리 사이트가 재료 배달(CSR) 방식이었다면, 고칠 길은 크게 세 가지입니다. 각각 비용과 난이도가 다릅니다.

1. 서버사이드 렌더링(SSR)으로 전환

가장 근본적인 해결입니다. 개발자에게 “첫 페이지를 서버에서 완성해서 보내 달라”고 요청하시면 됩니다. Next.js, Nuxt, SvelteKit 같은 최근 프레임워크는 SSR 모드를 지원합니다. 장점은 AI·검색엔진·사람 모두가 같은 완성본을 받는다는 점입니다. 단점은 프로젝트 구조 변경이 필요해, 작은 사이트는 1~2주, 큰 사이트는 수개월이 걸린다는 점입니다. 사이트를 새로 만드는 중이시면 이 길이 가장 깔끔합니다.

2. 프리렌더(Prerender) 서비스

크롤러가 방문할 때만, 미리 조리해둔 HTML을 꺼내서 보내주는 방식입니다. 사용자에게는 기존처럼 재료 배달이 나가고, 크롤러에게만 차려진 밥상이 나갑니다. Prerender.io 같은 외부 서비스가 대표적입니다. 장점은 코드 대규모 개편 없이 끼워 넣을 수 있다는 점입니다. 단점은 월 구독 비용과, 어느 요청이 크롤러인지 판별하는 로직을 계속 관리해야 한다는 점입니다.

3. 정적 생성(Static Generation)으로 전환

사이트 내용이 자주 바뀌지 않는다면, 빌드 시점에 모든 페이지의 HTML을 미리 만들어 정적 파일로 배포하는 방법도 있습니다. Next.js(정적 출력 모드), Gatsby, Astro, Nuxt(generate 모드) 같은 프레임워크가 이 접근을 지원합니다. 장점은 크롤러·사용자 모두가 완성된 HTML을 받는다는 점과, CDN에 올리면 운영 비용도 낮다는 점입니다. 단점은 콘텐츠가 바뀔 때마다 다시 빌드해야 한다는 점이어서, 매일 바뀌는 쇼핑몰·예약 시스템처럼 동적 데이터가 중심인 사이트에는 맞지 않습니다.

정리하면 이렇습니다.

  • 사이트를 새로 만드는 중: 1번(SSR 전환)이 가장 깔끔합니다.
  • 이미 운영 중이고 내용이 자주 바뀌지 않음: 3번(정적 생성)이 부담이 가장 낮습니다.
  • 이미 운영 중이고 내용이 자주 바뀜: 2번(프리렌더 서비스)이 현실적입니다.
  • 개발자 도움이 어려우신 1인 대표: 현 프레임워크·호스팅에 정적 생성 옵션이 있는지 확인하시거나, 외부 프리렌더 서비스 도입을 업체에 의뢰하시면 됩니다.

진단부터 해보시려면

위의 브라우저 확인으로 SSR/CSR 여부는 직접 판별하실 수 있습니다. 그 외에 AI·검색엔진이 우리 페이지를 이해하는 데 필요한 다른 기초 — 메타 정보, 구조화 데이터, 로딩 속도, 접근성 같은 요소도 함께 훑어보시려면 무료 진단 도구가 도움이 됩니다.

theXEO 진단 시작하기 →

URL을 한 번 입력하시면, 다음을 받으십니다.

  • 전체 건강 점수와, 일부 항목을 자동 보정한다고 가정했을 때의 예상 점수
  • 카테고리별 세부 점수 (메타·구조화 데이터·속도·접근성 등)
  • 놓친 점검 항목 최대 10개(스캐너 순서 기준)와, 전체 놓친 항목 개수

SSR/CSR 판별은 이 글의 브라우저 확인이 가장 빠른 방법이고, 진단 도구는 그 뒤에 남는 다른 기초를 훑는 용도로 쓰시면 됩니다.

더 깊이 알고 싶다면

개발자 관점의 기술 설명을 원하시면 AI가 당신의 웹사이트를 인용하지 않는 7가지 기술적 이유 (soyoyu.cc)를 참고하시면 좋습니다. 렌더 지연, Fetch 타이밍, 크롤 할당량 같은 맥락이 정리돼 있습니다.

같은 주제의 다른 글은 원리 허브 — AI 검색은 어떻게 작동하나에 모아뒀습니다.