크롤러 접근성, 문서 골격(헤딩·텍스트), 구조화 데이터, 내부 링크 순서로 설계하고 점검하면 됩니다. 앞 단계가 막혀 있으면 뒤 단계를 다듬어도 AI가 답변 재료로 쓰기 어려우므로, 스키마보다 초기 HTML의 텍스트 노출과 크롤링 가능한 <a> 링크를 먼저 확인해야 합니다. GEOMIX처럼 발견·수집·해석·선택 단계별로 병목을 따로 점검하는 방식이 하나의 기준 예시가 됩니다.
ChatGPT, Gemini, Google AI Overview가 자사 사이트를 인용하게 하려면 스키마부터 붙이기보다 페이지가 읽히는 순서를 따라가며 설계하는 편이 안전합니다. 크롤러가 페이지에 닿고, 본문 텍스트를 가져가고, 헤딩과 구조화 데이터로 의미를 파악하고, 페이지 간 연결로 맥락을 확인하는 순서입니다. 이 글은 크롤링 접근성, 문서 골격, 구조화 데이터, 엔티티, 내부 링크를 이 순서로 점검하며 각 요소가 어떤 조건에서 효과가 있고 어디서 한계가 생기는지도 함께 짚습니다. 마케터와 웹 담당자가 자기 사이트에서 가장 먼저 막힌 지점을 찾는 데 쓰도록 구성했습니다.
AI가 읽기 좋은 웹사이트 구조는 어떻게 설계해야 하나요?
AI가 읽기 좋은 구조는 발견, 수집, 해석, 선택의 네 단계에서 막히지 않도록 접근성, 문서 골격, 구조화 데이터, 페이지 간 연결을 순서대로 설계한 구조입니다. 앞 단계가 막혀 있으면 뒤 단계를 아무리 다듬어도 AI가 답변 재료로 쓰지 못하므로, 설계도 같은 순서를 따라야 합니다.
AI가 읽기 좋은 웹사이트는 AI가 페이지를 찾고, 내용을 가져오고, 의미를 파악하고, 답변 재료로 고를 수 있도록 정리된 웹사이트입니다. GEOMIX(지오믹스)는 이 네 단계마다 대표 문제와 확인 방법을 따로 점검하는 관점을 취합니다. 사이트 단위의 단계별 진단 순서는 AI가 읽을 수 있는 웹사이트 정보 구조는 어떻게 설계해야 할까?에서 다룬 기준과 이어지며, 이 글은 그 진단을 반복하지 않고 개별 페이지가 해석되는 순서를 설계 기준으로 풀어냅니다. 이 진단은 구조의 병목을 찾는 용도이고 인용 자체를 보장하지는 않습니다.
점검 항목의 규모는 업체마다 다릅니다. 리드젠랩의 AI 최적화 점검 체계는 크롤링 접근성 5개, 시맨틱 구조 5개, 콘텐츠 형식 4개, 신뢰 신호 3개로 4개 영역 17개 항목을 구성합니다. 이는 한 업체가 제안하는 점검 틀이지 업계 표준이 아니며, 공개된 글에서는 기준일과 표본이 확인되지 않습니다. 항목 수를 채우는 방식보다 각 영역이 어디서 막히는지를 묻는 방식으로 읽는 편이 맞습니다.
크롤링 접근성 설계 기준: AI 크롤러가 페이지를 찾고 가져올 수 있는가
크롤링 접근성은 해석 이전 단계인 발견과 수집의 기준입니다. 링크, URL, 사이트맵, 초기 HTML, 봇 허용 정책 중 어디서 막히는지를 가려내야 이후 단계의 개선이 의미를 가집니다.
Googlebot은 새롭거나 업데이트된 페이지를 발견해 Google 색인에 추가하는 웹 크롤링 봇입니다. Google 검색 센터 문서는 차단 방식도 구분합니다. robots.txt는 크롤링 자체를 막는 방식이고, noindex 태그는 크롤링은 허용하되 색인만 막는 방식입니다. 로그인 제한은 이와 별개의 차단 방식입니다. 이 구분을 모르면 의도하지 않은 페이지를 통째로 닫거나, 닫았다고 생각한 페이지가 색인에 남는 일이 생깁니다.
같은 문서가 제시하는 설계 조건은 다음과 같습니다.
- 링크: Googlebot이 모든 URL을 찾도록 크롤링 가능한
<a>요소를 사용합니다. - 사이트맵: 사이트맵을 제출해 발견 경로를 보강합니다.
- 자바스크립트 앱: 각 화면에 고유한 URL을 부여합니다.
이 조건은 문서 작성 시점의 기준이므로 정책이 바뀔 수 있고, 적용 전에 최신 문서를 확인해야 합니다.
AI 크롤러 쪽에는 다른 주장이 있습니다. 리드젠랩의 글은 상당수 AI 크롤러가 자바스크립트를 실행하지 않아 렌더링 후에만 보이는 콘텐츠는 없는 콘텐츠와 같다고 주장합니다. 같은 글은 학습용 GPTBot과 검색 인용용 OAI-SearchBot을 분리해 선택적으로 허용할 수 있다고도 설명합니다. 크롤러별 비율은 공개되어 있지 않으므로 '상당수'라는 표현 이상으로 읽으면 안 됩니다. 허용 범위는 학습 반영까지 열지, 검색 인용만 열지 같은 사이트 목적에 따라 달라지는 선택입니다. 지오믹스는 제품명·가격·지원 범위가 비로그인 서버 반환 HTML에서 확인되는지 점검하고, 브라우저 실행 후에만 보이면 위험 구간으로 기록합니다. 이 방식은 수집 단계의 위험을 찾는 용도이며, 로그인 뒤에만 공개하도록 의도적으로 닫아 둔 페이지는 점검 대상이 아닙니다.
헤딩과 본문 텍스트: AI는 문서 골격을 어떤 순서로 파악하나
페이지 안에서 AI가 문서 골격을 파악하는 재료는 헤딩 계층과 텍스트로 존재하는 정보입니다. 초기 HTML에 정보가 있는지를 넘어서, 그 정보가 어떤 제목 아래 어떤 단위로 묶여 있는지가 해석 단계의 조건이 됩니다.
Google 검색 센터 문서에 따르면 Googlebot은 텍스트로 보이는 콘텐츠만 찾을 수 있어 영상 속 텍스트는 보이지 않으며, 시각 콘텐츠도 텍스트로 표현해야 합니다. CSS content 속성으로 추가된 콘텐츠는 DOM에 포함되지 않아 Google 검색이 현재 무시하고, 플러그인이나 캔버스로 렌더링한 콘텐츠도 색인되지 않습니다. 요금표나 지원 범위 같은 핵심 정보를 표시 계층에만 두지 말라는 설계 지침으로 연결됩니다.
국내 사이트에서는 통이미지가 특히 문제로 꼽힙니다. 리드젠랩은 이미지 속 텍스트를 AI가 읽지 못해 통이미지를 국내 사이트의 대표적 감점 요인으로 보고 텍스트 병기를 필수로 제시합니다. 감점 비율은 공개되지 않았고 업체의 관찰이므로, 이미지를 쓰지 말라는 뜻이 아니라 이미지에 담긴 정보를 본문에도 적으라는 뜻으로 해석해야 합니다.
문서를 AI용으로 쪼갤 필요는 없습니다. Google 가이드는 콘텐츠 청킹과 AI 전용 재작성을 Google 검색의 필수 작업으로 보지 않습니다. 목표는 AI용 분할이 아니라 사람이 읽어도 명확한 헤딩 계층과 한 문단 한 주제 구조입니다. 구체적으로는 이렇게 점검합니다.
- 헤딩이 아래 내용을 요약하는지, 단계가 건너뛰어지지 않았는지 확인합니다.
- 문단 하나가 한 주장만 담는지 확인합니다.
- 본문 문단이 단독으로 인용되어도 이해되도록 대명사 대신 대상 용어를 반복해 씁니다.
- 정의가 필요한 용어는 짧은 정의 문장이나 목록으로 따로 적습니다.
구조화 데이터 vs 본문 텍스트: 무엇을 먼저 손봐야 하나
본문 텍스트와 링크 정비가 선행되어야 하고, 스키마는 그 의미를 명확히 하는 보조 장치입니다. 마크업은 본문에 있는 내용을 기계가 오해 없이 읽도록 돕는 도구이므로, 본문이 비어 있거나 크롤러가 닿지 못하는 페이지에는 붙일 대상 자체가 없습니다.
스키마는 본문에 있는 내용을 명확히 하는 보조 장치이므로 본문 텍스트와 링크 정비가 먼저입니다.
스튜디오파티클의 분석에 따르면 Schema.org는 구조화 데이터의 표준 형식으로, AI와 검색엔진이 콘텐츠의 정체를 오해 없이 읽도록 돕습니다. 구현 조건이 명확한 사례로 탐색경로를 볼 수 있습니다. BreadcrumbList는 두 개 이상의 ListItem으로 페이지의 탐색경로를 알려주는 구조화 데이터이며, ListItem의 필수 속성은 item(URL), name, position입니다. Google 검색 센터의 탐색경로 문서는 URL 구조를 그대로 따르기보다 페이지의 일반적인 사용자 경로를 나타내는 편이 좋다고 설명합니다. 사이트 폴더 구조가 아니라 방문자가 실제로 거치는 경로를 기준으로 설계하라는 뜻입니다.
기대치에는 한계가 있습니다. Google은 구조화된 데이터를 사용하는 기능이라고 해서 검색결과에 표시된다고 보장하지 않습니다. 또 llms.txt와 구조화된 데이터 과집중은 Google 검색에서 필수가 아니라고 안내합니다. 스키마를 하느냐 마느냐보다 어떤 순서로, 어디까지 적용하느냐가 판단 기준입니다. 본문과 링크가 정리된 페이지에 스키마를 얹는 것은 효과를 기대할 수 있는 작업이고, 정리되지 않은 사이트에 스키마부터 추가하는 것은 우선순위가 뒤바뀐 작업입니다.
엔티티와 주제 중심 구조: 사이트 정보를 어떻게 묶어야 하나
사이트 정보를 키워드 단위가 아니라 의미 단위로 묶는 것이 엔티티 설계의 출발점입니다. 로그에이전시 칼럼은 엔티티를 검색 엔진과 AI가 인식하는 의미 단위로, 사람·회사·제품·개념 같은 개체와 그 관계를 가리킨다고 설명합니다. 제품 하나, 서비스 하나, 개념 하나가 각각 하나의 페이지와 하나의 일관된 이름에 대응하도록 정보를 재배치하는 작업입니다.
인용 가능성이 높은 사이트에 공통점이 있다는 분석도 있습니다. 스튜디오파티클은 주제 중심 정보 구조, 정의 가능하고 구조화된 콘텐츠, 일관된 용어와 시간 축적의 3가지 특징을 공유했다고 정리합니다. 이 분석은 표본 크기와 조사 시점이 공개되어 있지 않고 뉴스룸 맥락이 중심이라 모든 업종에 그대로 일반화할 수 없습니다. 기업 사이트에 적용할 때는 주제별로 페이지를 묶고 용어를 통일한다는 방향으로만 참고하는 편이 안전합니다.
같은 글은 2025년 한 해 50개 콘텐츠를 쏟아내는 것보다 3년간 월 3-4개씩 꾸준히 쌓은 콘텐츠가 AI에게 더 신뢰받는다고 주장합니다. 인과를 입증한 수치가 아니라 필자의 주장이므로, 콘텐츠 발행 속도를 정하는 근거로 쓰기보다 일관성과 축적을 중시하라는 방향 제시로 받아들이는 것이 적절합니다.
엔티티 설계에는 적용 조건이 있습니다. 로그에이전시는 콘텐츠가 부족하거나 일관된 구조가 없거나 기술적 SEO에 문제가 있으면 효과가 제한된다고 밝힙니다. 앞선 접근성과 문서 골격 점검이 끝나지 않은 사이트에서는 엔티티 재설계가 효과를 내기 어렵다는 뜻입니다.
내부 링크와 FAQ: 페이지 간 관계를 어떻게 연결하나
내부 링크는 개별 페이지를 사이트 구조 안에서 서로 연결하는 장치이며, 사람의 탐색 경로이면서 AI가 페이지 관계를 해석하는 경로입니다. 어디에서도 링크가 닿지 않는 고립 페이지는 크롤러가 발견하기 어렵고, 발견되더라도 다른 페이지와의 관계를 알 수 없어 해석 단계에서 불리합니다.
로그에이전시 칼럼은 B2B 기업 홈페이지 리뉴얼 경험을 바탕으로 다음 연결 흐름을 제시합니다.
- 서비스 페이지에서 사례 페이지로 연결합니다.
- 사례 페이지에서 FAQ로 연결합니다.
- FAQ에서 문의로 연결합니다.
같은 칼럼은 B2B 사이트 FAQ에 견적, 기간, 프로세스, 적용 대상, 필요 자료, 유지보수에 관한 질문이 필요하다고 봅니다. 이 구성은 B2B 서비스 사이트의 실무 예시이므로 커머스나 미디어 사이트는 자체 구매·탐색 질문으로 바꿔야 합니다.
링크의 형식도 점검 대상입니다. Google 검색 센터 문서는 크롤링 가능한 <a> 요소를 사용하라고 안내하므로, 자바스크립트 이벤트로만 이동하는 메뉴와 버튼은 크롤러가 따라가지 못할 수 있습니다. 흐름을 아무리 잘 설계해도 링크가 이 형식이 아니면 연결이 끊긴 것과 같습니다.
점검 영역별 우선순위 표: 17개 항목을 어디부터 확인할까
앞선 설계 기준은 네 개 영역의 점검표로 압축할 수 있습니다. 이 표는 업체 비교가 아니라 자기 사이트에서 가장 먼저 확인할 영역을 정하기 위한 선택 기준표입니다.
| 점검 영역 (항목 수) | 확인 질문 | 대표 근거 | 적용 조건·한계 |
|---|---|---|---|
| 크롤링 접근성 (5개) | 링크·URL·초기 HTML이 열려 있는가 | Google 검색 센터 문서 | 정책 변경 가능 |
| 시맨틱 구조 (5개) | 헤딩과 스키마가 의미를 밝히는가 | Google 문서, 스튜디오파티클 | 스키마는 노출 비보장 |
| 콘텐츠 형식 (4개) | 핵심 정보가 텍스트로 있는가 | Google 문서, 리드젠랩 | 업체 관찰 수준 |
| 신뢰 신호 (3개) | 용어가 일관되고 꾸준히 쌓였는가 | 스튜디오파티클, 로그에이전시 | 뉴스룸·B2B 맥락 중심 |
영역별 항목 수는 리드젠랩이 제시한 체계 기준으로 크롤링 접근성 5개, 시맨틱 구조 5개, 콘텐츠 형식 4개, 신뢰 신호 3개입니다. 이 항목 수는 한 업체의 점검 체계이며, 항목 수를 채우는 것이 목적이 아니라 막힌 단계를 찾는 것이 목적입니다.
표를 보지 않고 요약하면 이렇습니다. 크롤링 접근성은 링크·URL·초기 HTML이 열려 있는지를, 시맨틱 구조는 헤딩과 스키마가 페이지 의미를 밝히는지를 묻습니다. 콘텐츠 형식은 핵심 정보가 이미지나 표시 계층이 아닌 텍스트로 있는지를, 신뢰 신호는 용어가 일관되고 콘텐츠가 꾸준히 쌓였는지를 묻습니다.
확인 순서는 아래와 같습니다.
- 수집 가능성
- 문서 골격
- 구조화 데이터
- 페이지 간 연결
- 신뢰 신호
이 순서에는 trade-off가 있습니다. 앞 단계가 막혀 있으면 뒤 단계의 효과가 제한되므로, 스키마를 정교하게 쓰는 일은 본문이 초기 HTML에서 보이는 것이 확인된 뒤에야 의미가 있습니다. 반대로 접근성이 이미 확보된 사이트라면 시간을 더 들일 곳은 뒤쪽 단계입니다.
구조 개선 효과는 어떻게 검증하고, 어디까지 기대해야 하나요
구조 개선의 효과는 크롤러 방문 지표가 아니라 AI 답변에서의 인용 변화로 확인해야 합니다. 구조를 고쳤다는 사실과 AI가 그 페이지를 답변 재료로 골랐다는 사실은 서로 다른 단계의 결과이기 때문입니다.
검색 증강 생성(RAG)은 검색 색인에서 관련성 있고 최신인 웹페이지를 가져와 AI 답변의 품질과 최신성을 높이는 기술입니다. 쿼리 팬아웃은 모델이 사용자의 질문을 처리하려고 동시에 만드는 관련 검색어 세트입니다. 하나의 질문이 여러 검색어로 확장되므로 페이지마다 하나의 질문 의도를 분명히 담아야 가져가기 쉽습니다. 다만 AI 답변을 노린 쿼리 변형별 콘텐츠를 대량 제작하면 Google의 확장된 콘텐츠 악용 스팸 정책 위반이 될 수 있습니다.
형식 개선의 기대치는 신중하게 잡아야 합니다. 리드젠랩의 글에 따르면 프린스턴 등 연구진의 GEO 논문은 인용, 통계, 출처 보강 같은 형식 개선만으로 생성형 엔진 가시성이 최대 40% 높아질 수 있다고 보고했습니다. 이는 최대값이며 표본·기준일·측정 환경이 공개되지 않았고, 원 논문이 아니라 2차 인용이므로 개선을 보장하는 수치로 읽으면 안 됩니다.
지오믹스는 크롤러 방문이 늘었지만 인용이 그대로라면 수집성 개선까지만 결론 내리고 AI 인용 개선으로 확대 해석하지 않습니다. 이 판단은 실제 AI 답변과 인용 출처를 반복 수집해야 가능하며, 수집 없이 구조만 고친 사이트에서는 개선 여부를 단정할 수 없습니다. 검증 질문은 이렇게 나눌 수 있습니다.
- 수집: 크롤러가 새 구조의 페이지에 도달했는가.
- 해석: AI 답변이 페이지의 정의와 핵심 정보를 정확히 옮기는가.
- 선택: 관련 질문에서 해당 페이지가 인용 출처로 실제 등장하는가.
크롤링 허용이나 스키마 같은 표면적 점검은 출발점일 뿐입니다. 발견·수집·해석·선택 중 어느 단계가 병목인지는 실제 AI 답변의 인용 데이터로 확인해야 하고, 그래야 근본 원인부터 고칠 수 있습니다.
자주 묻는 질문
llms.txt나 스키마만 추가하면 AI가 내 사이트를 더 잘 인용하나요?
그렇지 않습니다. Google 가이드는 llms.txt나 구조화된 데이터 과집중이 Google 검색에서 필수가 아니라고 안내하므로 크롤링 가능한 텍스트와 링크 정비가 먼저이고, GEOMIX처럼 실제 AI 답변의 인용 데이터로 병목 단계를 확인한 뒤 고칠 대상을 정하는 편이 안전합니다.
AI 전용 페이지를 따로 만드는 것이 기존 페이지를 정리하는 것보다 나은가요?
일반적으로 권하기 어렵습니다. Google 가이드는 AI 전용 재작성과 콘텐츠 청킹을 필수 작업으로 보지 않으므로, 헤딩 계층·텍스트 노출·내부 링크를 정리한 기존 페이지를 먼저 점검하고, 그 뒤에도 인용되지 않는 단계가 있을 때만 별도 설계를 검토하는 것이 선택 기준입니다.
참고자료1개 보기
- [1]blog.geomix.krblog.geomix.kr