AI 답변에 인용되기 쉬운 글쓰기: GEO와 SEO를 나눠 설계한다

한 줄 요약

GEO(Generative Engine Optimization, 생성형 검색 최적화)는 검색 순위가 아니라 AI 답변에 인용되는 것을 목표로 하며, 크롤러가 읽을 수 있는 정적 HTML 위에 답을 먼저 제시하는 구조·출처·엔티티를 얹고 학습봇과 검색봇 접근을 따로 통제해야 달성된다.

검색 상위에 올랐는데도 ChatGPT나 AI Overviews 답변에는 내 글이 한 줄도 인용되지 않는다면, 순위 문제가 아니라 인용 경계 문제다. GEO는 SEO를 대체하지 않는다. 일부 업계 분석에 따르면 1위 페이지의 AI 인용률이 33%, 10위는 13% 수준으로 알려져 있어, 검색 순위는 여전히 인용의 토대다. 둘은 대체 관계가 아니라 보완 관계로 놓고 설계한다.

개인 사이트를 Cloudflare에 올려 운영하며, 검색봇을 막아둔 줄 모르고 한동안 AI 답변에 전혀 잡히지 않은 적이 있다. robots.txt를 손댄 기억도 없는데 그랬다. 이 글은 그때 되짚은 순서 — 크롤러가 읽을 수 있는가, 봇을 학습용과 검색용으로 나눴는가, 답을 먼저 주는 구조인가, 엔티티가 연결됐는가 — 를 구현 관점으로 정리한다. 정적 배포 맥락은 Firestore 인덱스 배포 사고 글과 이어진다.

창가 자연광이 드는 홈오피스에서 개발자가 표가 그려진 종이 문서와 노트북 화면을 번갈아 살펴보며 골똘히 생각하는 장면

SEO와 GEO는 무엇이 다르고 왜 둘 다 필요한가?

SEO(Search Engine Optimization, 검색 엔진 최적화)의 목표는 검색 결과 페이지 상위 노출이고, GEO(Generative Engine Optimization, 생성형 검색 최적화)의 목표는 생성형 답변 안에 출처로 인용되는 것이다. GEO는 2023년 Princeton 등이 제시한 용어로, 생성형 엔진이 답을 만들 때 근거로 삼을 문서에 내 글이 뽑히게 하는 최적화를 말한다. 목표가 다르니 지표도 다르다. 순위와 클릭이 SEO의 성적표라면, GEO는 “몇 개의 AI 답변이 내 페이지를 근거로 삼았는가”로 측정한다.

그럼에도 GEO는 SEO 위에 세워진다. 생성형 엔진은 후보 문서를 대개 검색 인덱스에서 끌어오기 때문에, 인덱싱조차 안 되는 페이지는 인용 후보에도 들지 못한다. 그래서 GEO는 SEO를 버리는 전략이 아니라, SEO로 확보한 색인 가능성 위에 “인용되기 쉬운 형태”를 추가로 얹는 작업이다.

SEO 상위인데 왜 AI 답변엔 안 잡히나?

가장 흔한 원인은 봇 분리다. AI 회사의 크롤러는 하나가 아니라 용도별로 나뉜다. 모델 학습용 봇을 막아도 검색·인용용 봇을 열어두지 않으면 AI 검색 노출은 사라진다. GPTBot을 차단해도 OAI-SearchBot을 허용하면 ChatGPT 검색에는 잡히는 식이다. robots.txt에서 이 둘을 한 덩어리로 막아버리는 실수가 잦다.

제공자	학습용 봇(차단 검토)	검색·인용용 봇(허용 권장)
OpenAI	GPTBot	OAI-SearchBot
Anthropic	ClaudeBot	Claude-SearchBot / Claude-User
Perplexity	PerplexityBot	Perplexity-User

인프라 차원의 차단도 있다. Cloudflare는 2025년 7월 1일 Content Independence Day를 기점으로 AI 크롤러 차단을 기본값 쪽으로 옮겨, 새로 만든 존은 AI 크롤러가 기본 차단돼 있을 수 있으니 설정을 직접 확인해야 한다. 이 차단은 robots.txt와 무관하게 ML 지문과 WAF(Web Application Firewall, 웹 방화벽) 규칙으로 동작하므로, robots를 아무리 열어둬도 엣지에서 막히면 크롤러는 문 앞에서 되돌아간다. 자동화 인프라를 다루는 감각은 Slack 봇 업무 자동화 구축기의 접근 통제 관점과도 통한다.

크롤러가 내 페이지를 제대로 읽고 있나?

대부분의 AI 크롤러는 자바스크립트를 실행하지 않는다. Gemini만 예외로 알려져 있다. 클라이언트 렌더링(CSR, Client-Side Rendering)에 의존하는 페이지는 크롤러에게 사실상 빈 문서로 보이므로, 본문이 처음부터 정적 HTML로 존재하는 SSG(Static Site Generation, 정적 사이트 생성)·SSR(Server-Side Rendering, 서버 렌더링)이 사실상 전제 조건이다. 정적 생성 방식이면 이 조건은 자연히 충족된다.

검증할 때 curl -A "GPTBot" 같은 User-Agent 위조로는 아무것도 확인되지 않는다. Cloudflare는 UA가 아니라 IP·ASN, TLS 지문, Web Bot Auth 같은 신호로 봇을 판정하기 때문이다. 실제 통과 여부는 대시보드의 Security > Events 로그에서 어떤 봇이 어떤 판정으로 들어왔는지 직접 확인해야 한다.

늦은 오후 햇살이 드는 홈오피스에서 개발자가 노트북 화면을 확인하는 오버숄더 장면

AI가 인용하는 글은 어떤 구조인가?

핵심은 답을 먼저 주는 구조다. Princeton의 GEO 논문(arXiv 2311.09735)은 출처·통계·인용구를 본문에 넣으면 생성형 가시성이 약 40% 오른다고 보고했다. 반대로 키워드 스터핑은 효과가 없다. 일부 업계 분석에 따르면 표를 포함한 콘텐츠는 그렇지 않은 콘텐츠보다 약 2.5배 더 자주 인용된다고 알려져 있다. 신선도도 무겁게 작동하는 것으로 보이는데, AI가 인용한 페이지의 76%가 최근 30일 안에 업데이트된 글이었다는 분석도 있다.

구현 규칙은 단순하다. 각 섹션 첫머리에 40～60단어의 직답을 놓는 BLUF(Bottom Line Up Front, 결론 먼저), 문단을 2～3문장으로 잘게 끊는 청킹, 질문형 헤딩, 번호 리스트와 HTML 표, 그리고 페이지당 H1 하나. 이 여섯 가지가 “인용 가능한 단위”를 만든다. 이 글 자체도 각 H2 아래에 직답을 먼저 두는 방식으로 쓰였다.

책상 위 노트에 답을 먼저 적고 그 아래로 근거와 출처를 정리하는 손, 옆에는 표가 그려진 문서가 놓인 장면

엔티티와 스키마는 어떻게 연결하나?

구조화 데이터는 흩어진 블록보다 연결된 그래프가 낫다. @id와 @graph로 Article → Person → Organization → WebSite를 하나의 그래프로 묶으면, 개별 JSON-LD(JavaScript Object Notation for Linked Data, 연결 데이터용 구조화 표기) 블록을 따로 뿌리는 것보다 엔티티 인식에 효과적이다. 저자가 누구이고 어느 조직의 어떤 사이트에 속한 글인지를 기계가 한 번에 잇게 만드는 것이 핵심이다.

한때 표준처럼 언급된 llms.txt는 기대만큼의 근거가 없다. 일부 분석에서는 실제 요청 비중이 0.1% 안팎으로 알려져 있고, Google·OpenAI 모두 공식 지원하지 않으며, 효과를 입증한 근거도 없다. 저비용이라 만들어두는 정도의 의미는 있지만, 여기에 GEO의 무게를 실을 이유는 없다.

FAQ 스키마도 오해 없이 정리해야 한다. 구글이 2026년 5월 7일 폐지한 것은 검색 결과에 FAQ를 접었다 펴는 리치 결과 노출이지, 질문–답 구조 자체가 무용해진 것이 아니다. 따라서 FAQPage 마크업을 리치 스니펫 노출용으로 붙이는 목적만 무의미해졌을 뿐, 마크업 자체는 무해하다. 오히려 화면에 노출되는 질문형 FAQ 섹션은 LLM(Large Language Model, 대규모 언어모델)이 질문–답 쌍을 파싱해 AI 답변을 구성하기 좋은 형태이므로 그대로 유지한다. 목적이 리치 결과에서 LLM 파싱으로 옮겨간 것뿐이다.

AI Overviews에서 클릭은 어떻게 움직이나?

AI Overviews는 일부 집계에서 전체 쿼리의 약 48%에 표시된다고 알려져 있다. 표시될 때 기존 1위의 클릭률이 34.5% 떨어진다는 Ahrefs 실측이 있는 한편, 특정 분석 기준으로는 AIO(AI Overviews) 안에 인용되면 오히려 클릭률이 35%가량 오른다는 결과도 함께 보고된다. 다만 이는 인용을 정량적으로 보장한다는 뜻이 아니라 방향을 가리키는 참고치다. 그래서 목표는 요약을 막는 것이 아니라 요약 안에 인용되는 것이 된다.

토대가 되는 기술 지표는 Core Web Vitals(핵심 웹 지표)다. LCP(Largest Contentful Paint, 최대 콘텐츠 렌더 시간)는 2.5초 이하, INP(Interaction to Next Paint, 다음 상호작용 반응 지연)는 200ms 이하, CLS(Cumulative Layout Shift, 누적 레이아웃 이동)는 0.1 이하가 기준이며 모바일 우선, 28일 롤링 데이터로 평가된다. 정적 사이트 생성 방식이면 이 기준은 대체로 쉽게 달성된다.

신규 도메인이라면 인내도 변수다. 새 도메인은 3～6개월, 경쟁이 심한 분야는 9～12개월의 샌드박스 기간을 겪고 초기에는 롱테일 쿼리에서만 노출된다고 알려져 있다. 여기에 더해 E-E-A-T(Experience·Expertise·Authoritativeness·Trustworthiness, 경험·전문성·권위·신뢰) 평가는 2025년 12월부터 YMYL(Your Money or Your Life, 돈·건강 등 민감 주제) 밖 일반 주제로도 확장돼, 1인칭 실경험이 담긴 글의 비중이 오르고 범용 리스티클은 내려가는 흐름이다. 자동화 구현의 실경험을 남긴 Slack Events API 안정화 가이드처럼, 직접 겪은 디테일이 인용 경쟁에서 유리하다.

흐린 창가 도시 전경을 배경으로 두 손으로 스마트폰을 들고 검색 결과를 살펴보는 클로즈업 장면

배포 전 점검표

학습용 봇과 검색·인용용 봇을 robots에서 따로 통제하는가(GPTBot은 막아도 OAI-SearchBot은 여는가)?
Cloudflare 등 엣지에서 AI 크롤러 기본 차단이 켜져 있지 않은지 확인했는가?
본문이 정적 HTML로 존재하는가(CSR 의존이 아닌 SSG·SSR인가)?
크롤러 통과 여부를 UA 위조가 아니라 Security > Events 로그로 검증했는가?
각 섹션이 40～60단어 직답으로 시작하고, 페이지에 H1이 하나뿐인가?
출처·통계·인용구가 본문에 들어가 있고, 표를 인용 단위로 배치했는가?
@graph로 Article–Person–Organization–WebSite를 연결했는가?
Core Web Vitals(LCP 2.5s / INP 200ms / CLS 0.1) 기준을 모바일에서 만족하는가?

자주 묻는 질문

GPTBot을 막으면 ChatGPT 검색에도 안 나오나?

아니다. GPTBot은 모델 학습용, OAI-SearchBot은 검색·인용용으로 역할이 다르다. GPTBot을 차단해도 OAI-SearchBot을 허용하면 ChatGPT의 검색 답변에는 페이지가 인용될 수 있다. 학습 사용을 막으면서 검색 노출은 유지하려면 둘을 분리해 설정한다.

FAQ 스키마는 이제 쓸모없나?

리치 스니펫 목적으로는 무의미하다. 구글이 2026년 5월 7일 FAQ 리치 결과를 폐지했기 때문이다. 다만 마크업은 무해하고, 화면에 보이는 FAQ 섹션은 LLM이 질문–답을 파싱하기 좋은 구조라 유지할 가치가 있다. 목적이 리치 결과에서 LLM 파싱으로 바뀐 것이다.

curl로 크롤러 접근을 테스트하면 되나?

정확하지 않다. Cloudflare는 User-Agent가 아니라 IP·ASN, TLS 지문, Web Bot Auth로 봇을 판정하므로 curl -A로 UA를 위조해도 실제 봇과 다르게 처리된다. 통과 여부는 대시보드 Security > Events 로그에서 실제 요청 판정을 확인해야 신뢰할 수 있다.

새 도메인인데 왜 AI 답변에 안 잡히나?

샌드박스 기간일 가능성이 있다. 신규 도메인은 3～6개월, 경쟁이 심한 분야는 9～12개월 동안 노출이 제한되고 초기에는 롱테일 쿼리에서만 잡힌다고 알려져 있다. 이 기간에는 구조와 신선도를 갖춘 글을 꾸준히 쌓으며 색인 신뢰를 확보하는 것이 현실적이다.

한계와 업데이트 예정

이 글은 특정 검색·생성 엔진의 랭킹 알고리즘을 재현하는 문서가 아니라, 크롤러 접근·구조·엔티티·인프라라는 통제 가능한 경계를 설계하는 가이드다. 여기 담은 서드파티 추정치 — 순위별 인용률, 인용 배수, 신선도 비율, 클릭률 변화, 샌드박스 기간 — 는 측정 주체와 시기에 따라 달라질 수 있고 명시된 1차 출처가 없는 경우가 많으므로, 단정하지 않고 “일부 업계 분석” 수준으로 완화해 적었다.

봇 정책은 계속 움직인다. Cloudflare는 2026년 9월 15일부터 봇을 Search·Agent·Training 세 갈래로 세분화하고, 인용용인 Search 범주는 기본 허용으로 두겠다고 예고했다. 이 변경이 적용되면 “AI 크롤러 일괄 차단” 전제 자체가 바뀌므로, 정책 반영 시점에 봇 분류 표와 점검표를 다시 정리할 예정이다.

이 글은 AI 업무 자동화 허브의 ‘개선·발견(GEO)’ 단계 사례다.

참고 자료

_{기준 시점 2026년 7월 22일 확인. 익명화한 개인 사이트 운영 경험을 바탕으로 정리했고, 사실과 출처는 사람이 검수했다. 공식 기준(Core Web Vitals·FAQ 리치 결과 폐지·크롤러 UA 판정)은 단정형으로, 명시된 1차 출처가 없는 서드파티 추정치(순위별 인용률·인용 배수·신선도 비율·클릭률 변화·샌드박스 기간)는 단정을 피해 완화해 적었다. 봇 정책과 크롤러 판정은 제공자·버전·시점에 따라 달라질 수 있으니, 적용 전 각 제공자의 최신 문서와 본인 환경의 로그를 다시 확인해야 한다.}