전통 SEO 점수와 AI 검색 가시성 점수 사이의 39점 갭은 두 시스템이 완전히 다른 신호 세트를 소비한다는 사실을 노출한다. Googlebot 기반 SEO는 링크 권위·Core Web Vitals·meta 태그를 색인 신호로 사용하는 반면, ChatGPT Search·Perplexity·Google AI Overviews가 인용 출처를 결정할 때는 AI 크롤러 접근성·JSON-LD 스키마 깊이·직접 답변 밀도를 별도로 평가한다. SEO 93점 사이트가 AI 검색에서 54점에 머무는 원인은 기술 부채가 아니라 최적화 대상이 다른 두 시스템 간 구조적 격차다.
점수 격차의 기술 레이어 진단
AI 검색 가시성 측정 도구(Profound·BrightEdge Generative Parser·Semrush AI Overview Tracker 기준)가 54점을 산정하는 데 기여한 결함은 세 레이어로 분류된다.
- 크롤러 접근성 레이어: robots.txt에서 GPTBot·ClaudeBot·PerplexityBot이 차단된 상태. SEO 도구는 Googlebot 접근성만 평가하므로 이 차단이 SEO 점수에 반영되지 않는다. AI 인용 파이프라인의 첫 관문은 해당 봇의 크롤링 허용 여부이며, 차단 상태에서는 인용 자체가 불가능하다.
- 구조화 데이터 레이어: Organization 스키마만 존재하고 Article·FAQPage·Speakable·HowTo 스키마가 전무하다. AI 시스템은 콘텐츠 유형과 답변 범위를 스키마로 추론하는데, 타입이 없으면 범용 텍스트로 처리되어 인용 후보 분류 단계에서 우선순위가 낮아진다.
- 콘텐츠 밀도 레이어: 페이지당 평균 키워드 밀도는 2.1%(SEO 권장 범위)이지만 직접 답변 문장(질문-사실-출처 3요소 포함)의 비율은 전체 단어 수 대비 7%에 불과하다. LLM은 인용 생성 시 문장 단위로 팩트를 추출하므로 답변 밀도가 낮으면 인용 후보에서 탈락한다.
SEO 신호 vs AI 검색 신호 비교
| 신호 유형 | 전통 SEO | AI 검색 (AEO/GEO) |
|---|---|---|
| 크롤러 | Googlebot, Bingbot | GPTBot, ClaudeBot, PerplexityBot, anthropic-ai |
| 핵심 랭킹 신호 | 백링크 권위, Core Web Vitals, E-E-A-T | 직접 답변 밀도, 구조화 데이터 깊이, 도메인 신뢰 |
| 구조화 데이터 유형 | Organization, BreadcrumbList, Product | Article, FAQPage, Speakable, HowTo, ClaimReview |
| 크롤러 제어 파일 | robots.txt, sitemap.xml | robots.txt (AI 봇 항목), llms.txt |
| 콘텐츠 품질 기준 | 키워드 밀도, 문서 구조, 인바운드 링크 | 팩트 밀도, 출처 명시, 질문-답변 패턴 |
| 측정 도구 | Google Search Console, Ahrefs, Semrush | Profound, BrightEdge GEO, Semrush AI Tracker |
크롤러 접근성 수정 — robots.txt 및 llms.txt 구현
가장 빠른 승점 포인트는 robots.txt에서 AI 크롤러를 명시 허용하는 것이다. 진단 대상 사이트의 기존 설정은 다음과 같이 광범위한 와일드카드 차단 구조였다.
# 기존 설정 — GPTBot 등 전체 차단 상태
User-agent: *
Disallow: /
User-agent: Googlebot
Allow: /
이 설정은 Googlebot만 허용하고 나머지 모든 봇을 차단한다. 수정 후 설정은 다음과 같다.
# 수정된 robots.txt — AI 크롤러 명시 허용
User-agent: Googlebot
Allow: /
User-agent: GPTBot
Allow: /
User-agent: ClaudeBot
Allow: /
User-agent: PerplexityBot
Allow: /
User-agent: anthropic-ai
Allow: /
User-agent: cohere-ai
Allow: /
# 관리·API 경로는 모든 봇에 차단 유지
User-agent: *
Disallow: /admin/
Disallow: /api/
Disallow: /private/
Allow: /
Sitemap: https://example.com/sitemap.xml
robots.txt 수정과 병행해 llms.txt를 도메인 루트에 추가한다. llms.txt는 LLM 크롤러가 사이트 콘텐츠 계층을 빠르게 파악하도록 돕는 비공식 표준(llmstxt.org 사양)으로, 색인 우선순위와 콘텐츠 요약을 기계가 읽기 쉬운 Markdown 형식으로 제공한다.
# https://example.com/llms.txt
## example.com
전기 설비 진단 전문 플랫폼. 주요 콘텐츠: KEC 기반 기술 가이드, 설비 점검 체크리스트, 법령 해설.
## 핵심 콘텐츠
- [전기 설비 기술 가이드](https://example.com/guides/) — 200+ 문서, 전문가 검수
- [KEC 기준 점검 체크리스트](https://example.com/checklist/)
- [실무 FAQ](https://example.com/faq/) — 질문-답변 구조화
## 색인 제외
- https://example.com/admin/
- https://example.com/user-data/
JSON-LD 스키마 업그레이드 — FAQPage + Speakable 추가
Organization 스키마만 있는 상태에서 FAQPage와 Speakable 스키마를 추가한다. Speakable은 Google Assistant 및 AI Overviews가 직접 인용을 위해 우선 파싱하는 섹션을 cssSelector로 지정하는 타입이다.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "배선 차단기 정격 전류 선정 기준",
"author": {
"@type": "Person",
"name": "김전기",
"jobTitle": "전기기사"
},
"publisher": {
"@type": "Organization",
"name": "ElectroAssist",
"url": "https://example.com"
},
"datePublished": "2026-05-10",
"dateModified": "2026-06-01",
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": ["#summary", "#key-facts"]
}
}
</script>
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "20A 차단기에 2.5mm² 전선을 연결해도 되는가?",
"acceptedAnswer": {
"@type": "Answer",
"text": "KEC 212.5.2 기준, 2.5mm² 전선의 허용 전류는 공중 배선 환경에서 26A이므로 20A 차단기 조합은 보호 협조 측면에서 적합하다. 단, 매입·다조 설치 환경에서는 허용 전류 보정 계수(0.7~1.0)를 반드시 적용해야 한다."
}
}
]
}
</script>
흔한 오해: "AI 크롤러를 허용하면 인용이 자동으로 늘어난다"
크롤러 허용은 필요조건이지 충분조건이 아니다. GPTBot이 콘텐츠를 수집했더라도 LLM이 응답 생성 시 해당 페이지를 인용할지는 별개의 랭킹 과정을 거친다. 인용 결정은 수집된 콘텐츠 중 답변의 정확성·직접성·출처 신뢰도를 기준으로 이루어지며, FAQPage 스키마 없이 Q&A 콘텐츠가 일반 단락으로 존재하면 LLM이 해당 내용을 답변 후보로 인식할 확률이 낮다. 올바른 처리 순서는 다음과 같다.
- 크롤러 허용 — robots.txt에 AI 봇 명시 허용, llms.txt 추가. 왜: 색인 자체가 선행되어야 인용 후보군에 들어간다. 어떻게: 위 robots.txt 예시 적용 후 Google Search Console과 동일하게 Fetch as Bot으로 접근 확인.
- 콘텐츠 구조화 — FAQPage·Article·Speakable 스키마 추가. 왜: 스키마 타입이 없으면 LLM이 콘텐츠 용도를 추론해야 하므로 인용 우선순위가 하락한다. 어떻게: schema.org 검증기(validator.schema.org)로 파싱 오류 없음 확인.
- 팩트 밀도 개선 — 핵심 단락에 질문-사실-출처 트리플 패턴 적용. 왜: LLM은 문장 단위로 팩트를 추출하며, 출처가 명시된 사실 문장을 우선 인용한다. 어떻게: 기존 단락 앞에 직접 답변 문장(1~2문장)을 삽입하고 법령 조항·수치·측정 기준을 인라인 명시.
GPTBot을 robots.txt에서 허용하면 OpenAI가 콘텐츠를 학습 데이터로 사용할 수 있나요?
OpenAI는 GPTBot을 두 가지 목적으로 운용한다고 밝혔다: ChatGPT Search 실시간 색인 갱신, 그리고 미래 모델 학습 데이터 수집. robots.txt Allow는 두 목적 모두에 적용된다. 학습 데이터 수집만 선택적으로 차단하고 검색 색인만 허용하는 공식 기술 메커니즘은 2026년 현재 존재하지 않는다. 이용약관에 크롤링 금지 조항을 명시하거나 법적 조치를 취하는 방법이 있으나, robots.txt 자체는 기술적 권고 수준으로 법적 구속력이 없다. AI 검색 가시성 확보와 학습 데이터 제공 차단 사이에는 현재 구조상 트레이드오프가 존재한다.
Speakable 스키마를 추가하면 Google AI Overviews 인용률에 직접적인 영향을 미치나요?
Google은 Speakable을 Google Assistant 음성 응답 최적화 신호로 공식 문서화했으며, AI Overviews 인용에 Speakable이 직접 가중치로 작용한다는 공식 확인은 없다. 그러나 Speakable이 cssSelector로 지정하는 영역(#summary, #key-facts 등)은 통상 콘텐츠의 핵심 팩트 밀집 구간이고, AI Overviews 파싱 시 이 구간에서 직접 인용 후보를 추출하는 패턴이 실무 사례에서 반복 관찰된다. Speakable 추가 자체보다 Speakable이 가리키는 섹션에 질문-답변-출처 구조를 갖춘 콘텐츠를 배치하는 것이 인용률 개선의 실질적 원인이라고 보는 것이 더 정확하다.
참고 자료
이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.