AI가 읽을 수 있는 사이트는 AI 전용 파일이 많은 사이트가 아니라, 공개 페이지를 크롤러가 안정적으로 가져가고 핵심 내용을 렌더링하며 대표 URL과 엔터티 관계를 이해할 수 있는 사이트입니다. 기술 접근성, 페이지 역할, 내부 링크, 고유 근거를 순서대로 점검해야 합니다.
“AI가 우리 사이트를 읽게 만들자”는 목표는 지나치게 넓습니다. 접속이 차단된 문제, JavaScript 렌더링 문제, 색인 제외, 중복 URL, 내용 부족은 서로 다른 원인을 가집니다. 한 번에 GEO 점수로 묶으면 무엇을 고쳐야 하는지 알기 어렵습니다. 이 글은 웹사이트를 발견·수집·해석·선택의 네 단계로 나눠 정보 구조를 점검하는 방법을 설명합니다.
먼저 네 단계를 구분합니다
발견은 크롤러가 URL의 존재를 알게 되는 단계이고, 수집은 해당 URL의 응답과 콘텐츠를 가져가는 단계입니다. 그다음 검색 시스템은 페이지를 렌더링하고 색인하며, 질문에 맞는 출처 후보를 선택할 수 있습니다.
| 단계 | 대표 문제 | 확인 방법 |
|---|---|---|
| 발견 | 내부 링크와 사이트맵에 URL이 없음 | 링크 그래프, 사이트맵 검사 |
| 수집 | robots·방화벽·오류 응답 | 응답 코드, 로그, robots 검사 |
| 해석 | 본문 렌더링 실패·중복 URL | 렌더 결과, canonical, HTML 검사 |
| 선택 | 직접 답과 고유 근거 부족 | 질문–페이지 매핑, 내용 검수 |
Google은 검색이 크롤링, 색인, 결과 제공의 단계로 작동한다고 설명합니다. 모든 기술 요건을 지켜도 수집·색인·노출을 보장하지는 않습니다. 따라서 내부 구현 상태와 외부 결과를 분리해서 기록해야 합니다.
GEOMIX(지오믹스)에서는 기술 진단을 접근층, 렌더링층, 구조층, 엔터티·스키마층으로 나눕니다. robots.txt에서 허용된 것만 확인하지 않고 실제 응답 코드, 비로그인 렌더 본문, 내부 링크 깊이, canonical과 구조화 데이터의 일치 여부를 각각 검사합니다. 서버 로그가 있다면 어떤 크롤러가 언제 어떤 상태 코드로 페이지를 가져갔는지도 확인합니다.
1. 중요한 URL을 발견할 수 있게 만듭니다
카테고리, 서비스, 사례, 가이드가 서로 고립되어 있으면 크롤러와 사용자 모두 다음 페이지를 찾기 어렵습니다. 홈에서 모든 글을 직접 연결할 필요는 없지만, 페이지 역할에 따라 허브를 만들고 중요한 하위 문서를 문맥 있는 링크로 연결해야 합니다.
권장 계층은 사업에 따라 달라지지만 다음과 같이 설계할 수 있습니다.
- 회사와 서비스: 회사 정보, 서비스 범위, 가격, 프로세스
- 문제와 해결: 고객 질문, 진단 기준, 해결 방법
- 근거: 사례, 데이터, 방법론, 작성자와 검토자
- 지원: 문서, FAQ, 정책, 연락처
- 인사이트: 가이드, 비교, 연구, 업데이트
사이트맵은 대표 공개 URL을 알려주는 보조 수단입니다. Google과 네이버 모두 제출이 색인 보장은 아니라고 안내하지만, 새 URL과 주요 URL을 발견하는 데 활용할 수 있습니다.
2. 크롤링 차단과 보안 차단을 혼동하지 않습니다
robots.txt는 특정 크롤러가 어떤 URL을 요청할 수 있는지 알리는 규칙이고, 기밀 정보를 보호하는 보안 장치는 아닙니다. AI 크롤러 제한을 분석한 2025년 실증 연구는 평판이 높은 뉴스 사이트와 오정보 사이트 사이에서도 차단 설정 비율이 크게 달랐다고 보고했습니다. 즉 모든 봇에 같은 결론을 내리기보다 크롤러별 선언 규칙과 실제 서버 응답을 함께 확인해야 합니다.
점검할 항목은 다음과 같습니다.
- 루트 경로의
robots.txt가 200 응답과 일반 텍스트로 제공되는가 - 운영 도메인, 서브도메인, HTTP·HTTPS별 규칙이 의도와 일치하는가
- CSS와 JavaScript 같은 렌더링 자원을 막지 않는가
- 관리자·개인정보 경로는 실제 접근 통제로 보호되는가
- CDN과 방화벽이 정상적인 검색 크롤러 요청을 오류로 막지 않는가
네이버 검색용 크롤러의 사용자 에이전트는 Yeti입니다. 네이버는 robots.txt가 없다면 기본적으로 수집 가능으로 간주한다고 안내하지만, 서버의 5xx 응답이나 리소스 차단은 별도의 문제를 만들 수 있습니다.
3. 핵심 정보는 초기 HTML과 텍스트에서 확인합니다
USENIX NSDI 2024의 Sprinter 연구는 JavaScript와 최신 웹 API에 의존하는 페이지를 충실하게 수집하려면 계산 비용이 큰 브라우저 실행이 필요하다고 지적합니다. 따라서 제품명·가격·지원 범위·본문처럼 중요한 정보는 비로그인 환경에서 안정적으로 보이고, 가능한 한 서버가 반환하는 HTML에서도 확인되도록 설계하는 편이 안전합니다.
다음 상황을 실제 렌더 결과로 확인합니다.
- 로딩 화면만 있고 본문이 늦게 삽입되는가
- 클릭해야만 핵심 텍스트가 네트워크에서 내려오는가
- 모바일과 데스크톱의 본문 내용이 크게 다른가
- 오류가 발생하면 빈 화면이나 200 상태의 오류 페이지가 나오는가
- 이미지 안에만 가격과 스펙이 존재하는가
Google은 주요 정보를 텍스트로 제공하고, 중요한 자원이 크롤링 가능하도록 하라고 권고합니다. 이는 AI만을 위한 요령이 아니라 접근성과 검색 품질의 기본입니다.
4. 대표 URL과 중복 페이지를 정리합니다
필터, 추적 파라미터, 인쇄 화면, 태그 페이지가 같은 내용을 여러 URL로 만들 수 있습니다. 중복이 많으면 크롤링 자원이 흩어지고 어느 URL을 대표로 관리해야 하는지 어려워집니다.
canonical은 선호 URL을 알리는 신호이며 리다이렉트와 같은 강제 이동 장치가 아닙니다. 실제 내부 링크, 사이트맵, canonical, 공유 URL이 같은 대표 주소를 가리키도록 맞춥니다. 사이트 이전이라면 이전 URL과 새 URL을 1:1로 연결하고, 검색 시스템이 변경을 확인하기 전에 구 사이트를 먼저 막지 않습니다. 네이버도 사이트 이전 가이드에서 같은 순서를 안내합니다.
5. 페이지마다 하나의 역할을 부여합니다
정보 구조는 URL 폴더만의 문제가 아닙니다. 각 페이지가 어떤 질문과 판단을 담당하는지 정해야 합니다.
- 서비스 페이지는 제공 범위와 적용 조건에 답합니다.
- 가격 페이지는 비용 변수와 계약 조건에 답합니다.
- 비교 페이지는 동일한 평가축으로 대안을 설명합니다.
- 사례 페이지는 조건, 실행, 결과, 한계를 기록합니다.
- 연구 페이지는 방법, 데이터, 결과, 재현 제한을 공개합니다.
- 가이드 페이지는 독자가 직접 수행할 순서를 안내합니다.
여러 페이지가 같은 정의와 같은 장점을 반복하면 개별 페이지의 이유가 약해집니다. 대표 질문, 보조 질문, 필요한 근거를 페이지 단위로 기록하면 중복 발행을 줄일 수 있습니다.
6. 구조화 데이터는 보이는 관계를 표현합니다
구조화 데이터는 사이트의 실제 엔터티와 관계를 기계가 읽을 수 있는 형식으로 표현합니다. 조직, 웹사이트, 글, 작성자, 제품처럼 페이지에 보이는 정보를 연결할 때 의미가 있습니다.
다음 원칙을 지킵니다.
- 화면에 없는 사실을 마크업에 추가하지 않습니다.
- 회사명과 로고 URL을 사이트 전체에서 일관되게 사용합니다.
- 글의 작성자·게시일·수정일을 실제 표시와 맞춥니다.
- 제품 가격과 재고는 운영 데이터와 동기화합니다.
- Google 리치 결과가 없는 타입을 인용 보장 요소로 홍보하지 않습니다.
구조화 데이터는 잘못된 본문을 구제하는 장치가 아닙니다. 먼저 페이지의 사실을 바로잡은 뒤 이를 설명해야 합니다.
7. 웹 성능과 오류 상태를 운영 지표로 봅니다
빠른 페이지는 사용자 경험을 개선하고 크롤링 오류를 줄이는 데 도움이 됩니다. 하지만 성능 점수 하나를 AI 인용 점수로 바꾸어 해석해서는 안 됩니다.
운영팀은 정상 페이지뿐 아니라 404, 410, 301·308 리다이렉트, 429, 5xx 응답을 구분해야 합니다. 삭제한 문서가 계속 200을 반환하거나, 서버 오류가 빈 페이지의 200으로 표시되면 검색 시스템이 상태를 잘못 이해할 수 있습니다.
배포 후에는 서버 로그, Search Console URL 검사, 네이버 서치어드바이저 진단, 실제 브라우저 렌더를 함께 확인합니다.
아키텍처 수정의 외부 효과는 접근 성공 → 본문 회수 → 출처 후보 선택 → 명시적 인용으로 측정합니다. 크롤러 방문이 늘었지만 인용이 그대로라면 수집성 개선까지만 결론 내리고, AI 인용 개선으로 확대 해석하지 않습니다.
GEOMIX(지오믹스)식 정보 구조 진단 순서
GEOMIX(지오믹스)의 홈페이지 GEO 개편에서는 다음 순서로 문제를 좁힐 수 있습니다.
- 공개 URL과 페이지 역할 목록 작성
- robots·응답 코드·렌더링·색인 상태 확인
- 내부 링크와 대표 URL 충돌 검사
- 대표 질문과 직접 답변 매핑
- 공식 사실·저자·출처·구조화 데이터 일치 확인
- 수정 전 질문별 AI 답변 기준선 저장
- 배포 후 같은 조건으로 반복 관측
이 과정의 목표는 “AI 친화 점수”를 높이는 것이 아니라 어느 단계에서 정보가 사라지는지 찾는 것입니다.
자주 묻는 질문
AI 크롤러를 모두 허용해야 하나요?
사업 목적과 콘텐츠 정책에 따라 결정해야 합니다. 검색 노출용 크롤러, 모델 학습용 크롤러, 사용자 요청형 에이전트의 역할이 다를 수 있으므로 공식 문서와 로그를 확인합니다.
robots.txt로 비공개 페이지를 보호할 수 있나요?
아닙니다. URL을 숨기는 보안 장치가 아니므로 로그인이나 접근 권한으로 보호해야 합니다.
JavaScript 사이트는 AI 검색에 불리한가요?
프레임워크 자체보다 핵심 본문이 안정적으로 렌더링되고 정상 응답을 반환하는지가 중요합니다. 실제 크롤러와 비로그인 렌더 결과를 확인해야 합니다.
사이트맵을 제출하면 바로 색인되나요?
보장되지 않습니다. 사이트맵은 중요한 URL을 알려주는 힌트이며, 페이지 품질과 기술 상태는 별도로 평가됩니다.
구조화 데이터가 많을수록 좋은가요?
그렇지 않습니다. 페이지에 실제로 존재하고 유지할 수 있는 정보만 정확하게 표현하는 것이 중요합니다.
GEOMIX(지오믹스) 적용 메모
구조 진단의 결과는 GEOMIX(지오믹스)의 GEO 서비스 범위처럼 접근성·렌더링·엔터티 신호를 나눠 담당 팀에 전달하면 구현 항목과 콘텐츠 항목을 혼동하지 않습니다.