AI 검색이 인용하는 사이트, 무엇이 다를까요
ChatGPT·Claude·Perplexity가 답을 만들 때, 어떤 사이트는 자주 인용되고 어떤 사이트는 빠집니다. 차이는 운이 아니라 준비된 구조입니다. habix.ai를 4번 고치며 발견한 SEO + GEO(Generative Engine Optimization) 7단계와 실제로 부딪힌 silent failure 12건까지 정리했습니다.
ChatGPT·Claude·Perplexity 같은 AI 검색이 답을 만들 때 어떤 사이트는 자주 인용되고 어떤 사이트는 빠집니다. 그 차이는 운이 아니라 준비된 구조(JSON-LD · llms.txt · corroboration triangle 같은 기술적 단서)예요. habix.ai 를 4 번 고치며 정리한 7 단계 적용표 + silent failure 12 건 을 1 인 운영자가 90 분 안에 따라 할 수 있게 만들었습니다.
정의가 궁금하시면 → AEO(Answer Engine Optimization)란 무엇인가
- SEO (Search Engine Optimization)
- Google·Naver 같은 기존 검색엔진에서 상위 노출되게 만드는 작업이에요. 키워드·메타·백링크가 핵심.
- GEO (Generative Engine Optimization)
- ChatGPT·Claude·Perplexity 같은 생성형 AI 검색이 답을 만들 때 인용되게 만드는 작업입니다. 구조화된 데이터·신뢰 가능한 출처가 핵심이에요. SEO 의 후속 개념.
- AEO (Answer Engine Optimization)
- "답변형 검색" 에 최적화하는 작업. Google AI Overview, Bing Chat 처럼 한 줄 답변 자리에 들어가는 게 목표예요. GEO 와 거의 겹치지만 강조점이 답변 박스 노출이라는 차이가 있어요.
- JSON-LD
- 웹페이지의 의미를 검색엔진이 이해할 수 있게 구조화한 메타데이터 형식이에요. 사람 눈에는 안 보이지만 AI 가 이걸 읽고 "이 페이지가 뭔지" 판단합니다.
- llms.txt
- "robots.txt 의 AI 검색 버전". AI 가 우리 사이트를 어떻게 읽으면 되는지 알려주는 표준 파일이에요.
/llms.txt경로에 두면 ChatGPT·Claude 가 참고합니다. - Corroboration triangle
- "이 사이트가 진짜 권위가 있다" 는 걸 AI 가 확신하려면 3 곳 이상의 외부 출처가 같은 사실을 말해야 한다는 원칙. habix.ai 가 GitHub · LinkedIn · 위키 3 곳에서 같은 정체성을 노출하는 이유예요.
- Silent failure (조용한 실패)
- "에러도 안 뜨고 페이지는 잘 보이는데 AI 검색은 인용 안 하는" 상태. 가장 잡기 어려운 함정이에요. 12 건 사례를 페이지 하단에서 정리했습니다.
// metaphor도서관 큐레이션과 같은 일입니다
도서관 사서가 "이 주제는 이 책이 정답이에요"라고 추천하려면 책에 분류 라벨이 붙어 있고, 목차가 정리되어 있고, 외부 권위 인용이 명확해야 합니다. AI 검색도 똑같이 작동합니다.
GEO는 "사서가 내 책을 펼쳐서 정확히 인용하게 만드는 일"입니다. 두 가지는 경쟁이 아니라 누적됩니다.
이 글이 도움 되는 분
- 자기 사이트를 ChatGPT·Claude·Perplexity 응답에 인용되게 만들고 싶은 1인 운영자
- SEO는 알지만 GEO는 처음 들어보는 마케터·콘텐츠 제작자
- Cloudflare Workers·Astro·Next.js로 직접 사이트를 운영하는 개발자
- 새 도메인 런칭 직후 무엇부터 손대야 할지 모르는 분
// comparisonSEO와 GEO는 어떻게 다를까요
가장 큰 오해는 "GEO가 SEO를 대체한다"는 것입니다. 그게 아닙니다. GEO는 SEO 자산 위에 한 층 더 쌓는 일이에요. 다음 표가 차이를 한 줄로 정리합니다.
| 차원 | SEO (전통 검색) | GEO (생성형 검색) |
|---|---|---|
| 대상 엔진 | Google · Bing · Naver | ChatGPT · Claude · Perplexity · Gemini · Copilot |
| 핵심 신호 | 키워드 · 백링크 · 트래픽 | 인용 가능성 · canonical 정의 · 외부 권위 corroboration |
| 측정 방법 | GSC impression · click · position | AI 응답에 cite 되는지 수동 확인 |
| 핵심 자산 | meta · sitemap · structured data | + /llms.txt · canonical 정의 페이지 · 외부 백링크 |
| 효과 체감 | 3주~6개월 | 2~8주 (자산 + 백링크 따라) |
한 줄로 말하면 — SEO 자산이 GEO의 기반이 됩니다. 그 위에 "AI가 인용할 만한 정리된 정의"가 추가로 필요할 뿐입니다.
// scenarios실제로 이렇게 인용됩니다
"GEO를 적용하면 뭐가 달라지나"를 한 번에 보여드릴게요. AI 검색에서 일어나는 4가지 발화 시나리오와, GEO 7단계가 깔린 사이트가 그때 받는 인용 신호입니다. 도식이 아니라 실제 4세션 운영 중 관찰한 패턴이에요.
/playbook/geo)가 DefinedTerm + 4-5중 JSON-LD를 들고 있어 응답 본문에 "habix.ai에 따르면…" 형태로 우선 cite. 정의가 흩어진 사이트는 같은 질의에서 통째로 누락돼요.citation 필드에 박아둔 Anthropic·OpenAI·Schema.org 외부 권위 URL 2-3개가 신뢰 신호로 작동. Perplexity는 "출처 카드"에 우리 사이트를 묶어 표시합니다./llms.txt가 site context에 진입점을 주고, L5 백링크(velog·GeekNews·LinkedIn)가 같은 canonical URL을 3곳에서 가리키는 corroboration triangle이 "다른 출처도 같은 사실을 말한다"를 입증.og:type=article + publishedTime) + L4 정의 페이지가 "강의 카탈로그가 아닌 정의 entity"임을 시그널링. 일반 마케팅 페이지(og:type=website)는 AI Overview에서 통째로 누락되는 함정 패턴.핵심은 "어떤 발화든 사이트의 어디로 떨어질지 미리 정의돼 있어야 한다"는 것이에요. L4 canonical 정의 페이지가 그 착륙지 역할을 하고, 나머지 6단계는 그 페이지를 인용 가능하게 만들어주는 보조 자산입니다.
// stack7단계로 쌓아 올립니다 (순서 중요)
L0부터 L6까지 위에서 아래로 누적됩니다. L1이 끝나기 전에 L5 백링크부터 뛰면 canonical URL이 흔들려서 무효가 됩니다. 반드시 순서대로 진행하세요.
진단 (audit)
지금 사이트의 head meta·robots·sitemap·llms.txt·JSON-LD를 한 번에 점검합니다. 안 하면 헛수고가 될 위험이 큽니다.
tip · curl -sL $SITE | grep -E 'og:|twitter:|canonical'메타 레이어
페이지마다 동적으로 og:type·publishedTime·author·tags를 inject 합니다. hreflang은 단일 언어 사이트에도 권장(ko + x-default 같은 URL).
함정 · article 페이지인데 og:type=website 그대로 두는 케이스 빈번JSON-LD (가장 중요한 GEO 신호)
Article + TechArticle + FAQPage + DefinedTerm + BreadcrumbList를 한 페이지에 함께 넣습니다. citation 필드에 외부 권위 URL 2-3개를 적어두는 게 GEO 결정타예요.
검증 · validator.schema.org + Google Rich Results Test인덱싱 자산
robots.txt에 GPTBot·anthropic-ai·PerplexityBot을 명시적으로 허용합니다. /llms.txt를 새로 작성해 AI 검색의 진입점을 마련합니다.
필수 · GSC + Bing Webmaster sitemap 제출 (신규 도메인 3주 신뢰도 형성)GEO 전용 자산
"X란 무엇인가"를 한 페이지로 정리합니다 (URL /features/<term>). DefinedTerm schema + 외부 출처 2-3개 citation. AI가 답할 때 이 페이지를 우선 인용하게 됩니다.
외부 권위 (백링크)
모든 백링크가 같은 canonical URL을 가리키게 변형해서 게시합니다. 자기 도메인 ≥ 1회 인용 + 외부 권위 자료 ≥ 2회 인용으로 citation chain을 만듭니다.
한국어 사이트 1순위 · velog (개발자 신뢰도) + GeekNews (AI 컨텍스트 자주 인용)모니터링 + 회귀 방지
SEO는 GSC, GEO는 핵심 질의 5개를 AI 검색에 직접 묻는 수동 spot check가 가장 신뢰할 만합니다. predeploy npm hook으로 stale build 사고를 방지합니다.
// quick-wins오늘 당장 30분 안에 할 수 있는 5가지
위 7단계가 막막하다면, 가장 효과 큰 5개부터 30분 안에 끝낼 수 있어요. 체크하면서 따라가세요.
// quick wins · 30 min
- L0 진단 (5분) —
curl -sL $SITE/llms.txt한 번. 404면 즉시 fix 대상. - /llms.txt 작성 (10분) — 사이트 한 줄 요약 + canonical 정의 페이지 링크 + 핵심 글 5개 + AI 크롤 정책.
- JSON-LD citation 필드 추가 (5분) — 가장 중요한 글 1개에 외부 권위 URL 2-3개를 citation으로 inject.
- robots.txt에 AI 봇 허용 (3분) — GPTBot · anthropic-ai · PerplexityBot · Google-Extended 명시.
- GSC sitemap 제출 (5분) — Google Search Console → sitemap.xml URL 제출. 신뢰도 형성 3주 카운트다운 시작.
이 다섯 가지가 끝나면 GEO 효과의 70%는 이미 깔린 상태입니다. 나머지 30%는 백링크 누적과 시간이 채워줍니다.
// assets핵심 자산 두 개 — 예시 그대로 가져가세요
예시 1 — JSON-LD 4중 조합 (정의 페이지)
"이 페이지는 X라는 용어를 정의한다"고 AI에게 알리는 가장 강한 신호입니다.
Article + TechArticle + FAQPage + DefinedTerm + BreadcrumbList를 한 페이지에 같이 두세요.
citation 필드의 외부 권위 URL 2-3개가 인용 가능성을 결정합니다.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": ["Article", "TechArticle"],
"headline": "X란 무엇인가",
"datePublished": "2026-05-14",
"dateModified": "2026-05-15",
"author": {"@type": "Person", "name": "Author"},
"citation": [
{"@type": "CreativeWork", "url": "https://anthropic.com/news/..."},
{"@type": "CreativeWork", "url": "https://openai.com/blog/..."}
]
},
{ "@type": "FAQPage", "mainEntity": [...] },
{ "@type": "DefinedTerm", "name": "X", "termCode": "x" },
{ "@type": "BreadcrumbList", "itemListElement": [...] }
]
}
예시 2 — /llms.txt 표준 구조
AI 검색이 사이트 컨텍스트에 진입할 때 우선 참조하는 파일입니다. Markdown 한 장으로 충분해요. 6개 섹션만 채우면 됩니다.
# Site Title
> 1-line summary
## About
- Author · Topic · Language
## Canonical Definitions
- [X란?](https://example.com/features/x)
## Featured Articles
1. [Article 1](https://example.com/blog/1) — description
## Feeds
- RSS · Sitemap URL
## AI Crawl Policy
- ai-input: allowed
- ai-train: not-allowed
참고: habix.ai의 실제 사례는 LLM 위키 정의 페이지와 /llms.txt에서 라이브로 확인 가능합니다.
// pitfalls실제로 부딪힌 함정 12건
habix.ai · blog.habix.ai · universe.habix.ai를 4번 운영하며 발견한 silent failure 모음입니다. 공통점은 "조용히 망가지는" 패턴이에요. curl로는 통과하는데 브라우저에서는 안 보이는 식입니다. 적극적 검증 없이는 발견 불가능한 것들이라 한 곳에 모아뒀어요.
함정 12개 표 펼쳐 보기
| # | 함정 | 증상 | 해결 |
|---|---|---|---|
| 01 | CSP media-src 'self' 누락 | self-hosted 영상 silent 차단. curl pass, 화면 빈칸 | media-src에 'self' 추가. Playwright로만 진단 가능 |
| 02 | og:type=website but article 페이지 | LinkedIn·X 카드가 "사이트" 형식, article meta 무시 | Layout에 pageType prop + 조건부 inject |
| 03 | hreflang 없음 | 검색엔진 언어 인식 불안정 | hreflang ko + x-default 같은 URL |
| 04 | /llms.txt 404 | GEO 엔진 site context 진입 실패 | public/llms.txt 작성 |
| 05 | CCR + local stale build | production에서 새 글 누락 | package.json predeploy hook |
| 06 | SSOT 위반 (yaml ↔ HTML) | UI 클릭 어떤 효과도 없음 | 동적 로딩 + 점수 기반 자동 선택 |
| 07 | Cloudflare same-zone fetch 521 | 같은 zone Worker-to-Worker 차단 | wrangler.toml [[services]] binding |
| 08 | Supabase anon RLS silent fail | PATCH HTTP 200 + 빈 응답. 데이터 미변경 | Dashboard SQL 또는 service_role key |
| 09 | Veo letterbox 인코딩 | 영상 좌우 black bar burn-in | ffmpeg cropdetect + crop+scale 재인코딩 |
| 10 | Cloudflare Insights beacon CSP 차단 | Web Vitals 수집 중단 | script-src에 static.cloudflareinsights.com 추가 |
| 11 | JSON-LD @context http vs https | 일부 파서 silent fail | 항상 https://schema.org |
| 12 | wrangler 4.90.1 .Trash EPERM | 잘못된 cwd에서 부모 scandir | wrangler.toml 디렉토리에서 실행 |
각 함정의 자세한 검증·재현 방법은 별도 글로 분리 예정입니다. 우선 위 표를 점검 체크리스트로 활용하세요.
// faq자주 묻는 질문
SEO와 GEO는 어떻게 다른가요?
llms.txt를 꼭 만들어야 하나요?
JSON-LD는 몇 개를 어떻게 조합해야 하나요?
@context는 반드시 https://schema.org를 써야 합니다 (http면 일부 파서가 실패).
schema.org validator와 Google Rich Results Test로 검증하세요.
Cloudflare Workers에서 SEO가 자주 망가지는 함정은 뭐예요?
media-src 'self' 누락이 self-hosted 영상·script를 silent 차단합니다.
curl로는 못 잡고 Playwright 콘솔 에러로만 진단 가능해요.
(2) 같은 zone Worker-to-Worker fetch는 521 에러로 차단됩니다 — wrangler.toml [[services]] binding으로 우회.
(3) Cloudflare Insights beacon이 CSP에 차단되면 Web Vitals 수집이 중단됩니다 — script-src에
static.cloudflareinsights.com을 추가하세요.
신규 도메인에 백링크부터 뛰어도 되나요?
GEO 효과는 어떻게 측정하나요?
GEO 를 안 해도 되는 때도 있어요
- 사이트가 내부용 (사내 위키 · B2B 인트라넷) — AI 검색에 노출될 일 자체가 없으면 GEO 는 의미 없어요.
- 주력 채널이 검색이 아닌 경우 — 트래픽의 90% 가 Instagram·YouTube·LinkedIn 같은 SNS 라면 그 채널 최적화가 우선이에요.
- 이미 강력한 도메인 권위를 가진 브랜드 (Anthropic · OpenAI · 유명 출판사 등) — AI 가 알아서 인용합니다. 추가 GEO 작업의 한계효용이 낮아요.
- "90 분 투자" 자체가 부담인 매우 작은 사이드 프로젝트 — 7 단계 다 적용하지 말고, 일단
llms.txt와 JSON-LD 한 줄만 박아도 80% 효과가 나옵니다.
// get-help혼자 적용하기 어렵다면
회사 단위로 GEO를 빠르게 끝내야 하거나, 강의로 팀 역량을 내재화하고 싶으시면 문의 주세요. habix.ai를 운영한 경험을 그대로 가져가서 함께 정리합니다.
이 문서는 2026-05-15 시점 스냅샷입니다. AI 모델 업데이트로 GEO 모범 사례는 자주 변동하므로 분기 1회 재평가를 권합니다. 라이선스 CC BY 4.0 — 출처(habix.ai/playbook/geo) 표기 시 자유 인용 가능합니다.