SEO는 통과했는데 AI한테는 안 보인다고요? — 지금 점검해야 할 AEO·GEO 체크리스트

핵심 요약

이 글은 AEO·GEO 체크리스트 8가지를 실제 기사 두 건과 함께 정리한 글입니다.

• AEO·GEO는 SEO를 대체하는 개념이 아니라, SEO 위에 한 겹 더 얹는 습관에 가깝습니다.
• 실제로 발행된 기사 두 건(사례 A·B)을 직접 기술 감사해서, 무엇이 AI 답변 인용 여부를 가르는지 비교했습니다.
• 오늘부터 바로 적용할 수 있는 체크리스트 8가지와, FAQPage·QAPage 스키마를 어떻게 써야 하는지까지 정리했습니다.

---

지금 왜 이 이야기를 해야 할까

검색엔진 최적화(SEO)는 다들 압니다. 문제는 요즘 사람들이 검색을 “구글에 검색어를 치고 링크를 클릭하는” 방식으로만 하지 않는다는 것입니다.

ChatGPT에게 물어보고, Perplexity가 정리해준 답을 읽고, Claude가 요약해주는 내용을 그대로 신뢰합니다. 이때 내 콘텐츠가 클릭되는 게 아니라 AI 답변 안에 인용되느냐 마느냐가 새로운 승부처가 됩니다.

• SEO(검색엔진 최적화): 검색 결과 순위에서 사람이 클릭하게 만드는 것
• AEO(Answer Engine Optimization): ChatGPT·Perplexity·Claude 같은 AI가 답변을 생성할 때 내 콘텐츠를 출처로 인용하게 만드는 것
• GEO(Generative Engine Optimization): AI가 내 콘텐츠를 검색·수집·해석하기 쉽게 만드는 것 (AEO의 기술적 전제조건에 가깝습니다)

어떤 채널에 먼저 힘을 쏟을지 아직 정리가 안 됐다면, 병원마케팅 | 네이버 vs 구글 어디에 집중해야 할까? 글에서 채널 우선순위부터 먼저 잡고 오는 것도 방법입니다.

이게 막연한 트렌드 얘기가 아니라는 증거가 최근에 나왔습니다. 구글 크롬의 웹사이트 진단 도구인 라이트하우스(Lighthouse)가 2026년 5월 7일 공식 릴리스한 13.3 버전부터, 기존 4개 진단 항목(성능·접근성·베스트 프랙티스·SEO)에 “Agentic Browsing”이라는 5번째 카테고리를 추가했습니다.

Chrome 공식 문서에 따르면 AI 에이전트가 웹사이트에 와서 콘텐츠를 이해하고 실제로 작업을 수행할 수 있는지를 점검 항목 4가지(접근성 트리 구조, WebMCP, llms.txt, 레이아웃 안정성)로 평가합니다.

(참고: 저희가 직접 만든 라이트하우스 점수 확인 도구로 API를 실시간 테스트해본 결과, 이 글 작성 시점 기준으로 구글의 PageSpeed Insights API 응답에는 아직 이 카테고리가 반영되지 않았습니다. 크롬 자체와 개발자도구(DevTools)에는 먼저 반영되고, PSI API 등 다른 채널로는 시차를 두고 확산되는 것으로 보입니다.)

중요한 건 숫자가 아니라 방향입니다. 구글 스스로 “이 사이트, AI가 와서 쓸 수 있게 준비돼 있나?”를 정식 진단 항목에 넣기 시작했다는 것 — 이게 지금 AEO/GEO를 무시할 수 없는 이유입니다.

그런데 여기서 재미있는 반전이 하나 있습니다. Agentic Browsing의 4개 평가 항목 중 하나가 llms.txt(사이트를 AI에게 설명하는 텍스트 파일)인데, 정작 구글의 검색 담당자 존 뮬러(John Mueller)는 이 파일에 대해 회의적입니다.

Search Engine Journal 보도에 따르면 뮬러는 llms.txt를 과거 검색엔진이 폐기한 “keywords 메타태그”에 비유하며 이렇게 말했습니다:

“You’re telling these systems, like, I have the best website ever…by design, [they] can’t trust what is here as a way of differentiating between different websites.”

이런 시스템에게 “내 사이트가 최고다”라고 스스로 말하는 셈인데, 사이트 운영자가 자기 사이트를 써놓은 내용을 AI가 사이트 간 우열을 가리는 신뢰 가능한 기준으로 쓸 수는 없다는 뜻입니다.

즉 구글은 라이트하우스에 llms.txt 감사 항목을 넣었지만, 동시에 “이 파일이 있다고 AI가 당신 사이트를 더 신뢰하지는 않는다”고도 말하고 있는 셈입니다. 결론적으로 llms.txt 같은 개별 파일 하나보다, 이 글에서 다루는 8가지처럼 콘텐츠 자체의 구조와 근거를 탄탄히 하는 쪽이 훨씬 확실한 투자입니다.

---

실제로 비교해봤습니다: 같은 주제, 다른 결과

이해를 돕기 위해 최근 발행된 실제 기사 두 건을 직접 기술적으로 감사(HTML·메타태그·구조화 데이터·robots.txt까지 전부 확인)해서 비교했습니다.

사례 A는 해외 유력 매체의 에이전틱 브라우저 관련 기사, 사례 B는 국내 스타트업 뉴스레터의 라이트하우스 Agentic Browsing 해설 기사입니다 — 공교롭게도 둘 다 AI·에이전트 관련 주제라 기술 수준을 나란히 비교하기 좋았습니다.

항목	사례 A	사례 B
제목 태그 위계	H1→H4 (H2·H3 실종)	H1→H2→H3 완벽
메타 description	없음	있음
본문 내 외부 출처 링크	0건	25건 (본문 인라인) + 참고 출처 12건(접이식)
이미지 alt 텍스트	40% (30개 중 18개 누락)	100% (6개 전부)
데이터를 실제 table로 마크업	없음 (텍스트만)	있음 (3개)
robots.txt의 AI 크롤러 대응	별도 언급 없음(차단은 안 됨)	GPTBot·ClaudeBot·PerplexityBot 등 8종 개별 명시 허용
목차(TOC)	없음	있음 (앵커 링크형)

콘텐츠 자체의 전문성은 두 글 다 훌륭했습니다. 차이는 콘텐츠를 AI가 읽기 좋은 형태로 “포장”했는가에서 갈렸습니다. 잘 쓴 글이 AI 답변에 안 뽑히는 이유는 대부분 이겁니다.

---

오늘부터 바로 체크할 수 있는 8가지

1. 제목 태그 위계를 절대 건너뛰지 않기

소제목을 H2, 그 아래 소소제목을 H3로 순서대로 씁니다. 디자인이 예뻐 보인다고 H4를 바로 쓰거나, 굵은 글씨(bold)로만 처리하면 안 됩니다.

Google 공식 SEO 스타터 가이드도 헤딩을 “큰 논문의 개요를 짜듯” 본문의 주요 포인트·하위 포인트에 맞춰 순서대로 배치하라고 명시합니다.

사례 A는 실제 소제목 8개가 전부 H4로만 마크업돼 있고(H2·H3는 본문과 무관한 위젯에만 쓰임), 이 때문에 검색엔진과 AI 모두 문서를 섹션 단위로 나눠 읽을 때 기준으로 삼는 위계 자체가 없는 상태였습니다.

정직하게 짚자면, 존 뮬러는 헤딩 개수·순서 자체가 직접적인 검색 순위 요인은 아니라고 여러 차례 확인했습니다.

그럼에도 여전히 지켜야 하는 이유는 랭킹이 아니라 이해에 있습니다 — 뮬러 본인이 설명하듯 구글은 헤딩을 “페이지의 각 부분이 어떤 맥락인지 더 잘 이해하기 위해” 사용합니다.

그리고 이 “구조를 보고 맥락을 이해하는” 방식은 전통적 검색 랭킹보다 AI 답변 생성 쪽에서 훨씬 더 결정적입니다. AI가 “제목 태그 위계를 지키는 법”이라는 질문에 답할 때, 이 글의 어느 섹션에서 답을 가져와야 할지 판단하는 근거가 바로 그 위계 구조이기 때문입니다.

2. 메타 description을 반드시 채우기

비워두면 구글이나 SNS 공유 시 엉뚱한 문장이 잘려서 노출됩니다. Google 공식 가이드는 페이지마다 고유하고 정확한 요약을 쓰고, 키워드를 억지로 반복하거나 여러 페이지에 같은 설명을 복붙하지 말라고 안내합니다.

글의 핵심을 2~3문장으로 직접 요약해서 넣어야 합니다. 사례 A는 이 태그 자체가 아예 없었고, 사례 B는 핵심 내용을 정확히 요약한 메타 description을 갖추고 있었습니다.

3. 주장에는 반드시 출처 링크를 답니다

“~라고 합니다”, “~한다는 예측이 있습니다” 같은 문장 뒤에 근거 링크가 없으면, AI 입장에서는 검증할 수 없는 주장입니다. 이건 감으로 하는 말이 아니라 구글이 콘텐츠 품질을 평가하는 E-E-A-T(경험·전문성·권위성·신뢰성) 기준 중 신뢰성(Trustworthiness)과 직접 맞닿아 있습니다.

사례 A는 “2028년 크롬 점유율이 60%대로 하락한다”는 구체적 수치 예측에도 근거 링크가 없었던 반면, 사례 B는 같은 유형의 주장마다 Chrome 공식 문서나 업계 보도를 바로 그 문장에 걸어뒀습니다.

AI는 1차 출처를 직접 인용하는 콘텐츠를 우선적으로 인용하는 경향이 있습니다.

4. 이미지에는 alt 텍스트를 씁니다

접근성뿐 아니라, 이미지가 담고 있는 정보를 텍스트로 한 번 더 설명해주는 효과가 있습니다.

이 글 상단의 SEO·GEO·AEO 다이어그램에도 “SEO는 사람이 클릭하게, GEO는 AI가 읽기 쉽게, AEO는 AI 답변에 인용되게 만드는 것”이라는 alt 텍스트를 넣어, 이미지를 못 보는 환경(스크린 리더, 이미지 로드 실패, 텍스트만 읽는 크롤러)에서도 같은 정보가 전달되도록 했습니다.

5. 비교/수치 데이터는 진짜 표(table)로 만듭니다

디자인상 표처럼 보이게만 만들면 안 됩니다. 실제 table 태그로 마크업해야 검색엔진과 AI가 “이건 정형 데이터”라고 인식합니다. 사례 A의 브라우저 유형별 비교는 시각적으로만 표처럼 보였고 실제 table 태그는 0개였습니다.

저희 블로그의 피부과 마케팅 | 네이버 플레이스 순위, 리뷰 개수로 정해지지 않는다 글도 이 원칙을 적용해, 순위 요인을 나열식 텍스트가 아니라 표로 정리해 두었습니다.

6. robots.txt에서 AI 크롤러를 막고 있지 않은지 확인

OpenAI가 공식 문서에서 밝힌 GPTBot, Anthropic이 공식 안내하는 ClaudeBot, PerplexityBot, Google이 별도로 문서화한 Google-Extended 같은 AI 크롤러를 실수로 차단해두면, 콘텐츠를 아무리 잘 써도 애초에 AI가 읽어가지 못합니다.

사례 B의 robots.txt는 ChatGPT-User, PerplexityBot, GPTBot, Google-Extended, ClaudeBot, anthropic-ai, CCBot, Applebot-Extended까지 8종을 개별로 나열해 전부 명시적으로 허용하고 있었습니다.

워드프레스라면 랭크매쓰(RankMath) 같은 SEO 플러그인의 robots.txt 편집 기능으로 직접 확인·수정할 수 있습니다.

7. 글 맨 위에 목차(TOC)를 달기

소제목이 3개 이상인 글이라면, H1 바로 아래에 각 소제목으로 이동하는 목차를 넣습니다. 사람에게는 “이 글에 뭐가 담겨 있는지” 한눈에 보여주는 역할이고, AI에게는 “이 문서가 어떻게 나뉘어 있는지”를 알려주는 지도 역할을 합니다.

사례 B는 H1 바로 아래에 nav 태그로 8개 소제목 전부를 앵커 링크로 걸어뒀습니다. 워드프레스는 랭크매쓰의 목차 블록이나 관련 플러그인으로 쉽게 추가할 수 있습니다.

8. 인용한 출처를 글 끝에 따로 한 번 더 정리하기

본문 곳곳에 링크를 거는 것과 별개로, 글 끝에 “참고 출처” 섹션을 두고 이 글이 근거로 삼은 자료를 목록으로 다시 정리해줍니다.

사례 B는 본문에 녹인 인라인 링크와 별도로, 글 끝에 접이식(펼쳐보기) “참고 출처 (12)” 섹션을 따로 뒀습니다 — 가독성을 해치지 않으면서도 AI 입장에서는 “이 글이 어떤 근거들로 구성됐는지”를 한 번에 파악할 수 있는 명확한 신호가 됩니다.

---

한 번 더, 빠르게 짚고 갈게요

• 제목은 H1→H2→H3 순서를 절대 건너뛰지 않기 — AI가 문서 구조를 이해하는 기준입니다
• 메타 description을 페이지마다 직접 쓰기 — 비워두면 검색·공유 시 문장이 엉뚱하게 잘립니다
• 주장에는 그 자리에 바로 출처 링크 걸기 — 끝에 몰아넣지 말고 인라인으로
• 이미지 alt 텍스트, 실제 table 마크업, robots.txt의 AI 크롤러 허용 여부까지 챙기기
• 목차와 참고 출처 리스트로 글의 구조와 근거를 한눈에 보여주기
• FAQPage 스키마는 넣되, 리치 결과가 아니라 AI 답변 추출을 위한 것으로 이해하기 — 2026년 5월 구글이 FAQ 리치 결과를 폐지했기 때문입니다

다음 글에서는 조금 더 기술적인 이야기 — 구조화 데이터(JSON-LD)에 본문 전체를 포함시키는 고급 기법 — 을 다뤄보겠습니다.

---

자주 묻는 질문

---

참고 출처 (15)

Agentic Browsing / 라이트하우스

• Chrome for Developers — Lighthouse Agentic Browsing Scoring — Agentic Browsing 4개 평가 영역의 1차 공식 출처
• GoogleChrome/lighthouse 공식 changelog (GitHub) — 13.3.0 정식 릴리스 날짜 확인
• 자체 테스트: 저희가 직접 구축한 라이트하우스 점수 확인 도구로 PageSpeed Insights API를 실시간 호출해 Agentic Browsing 카테고리 반영 여부 확인 (2026년 8월 기준 미반영)
• Search Engine Journal — “Google’s Mueller Says llms.txt Can’t Help LLMs Differentiate Sites” — llms.txt 신뢰성에 대한 존 뮬러 실제 발언

SEO/AEO 기준 공식 문서

• Google 검색 센트럴 — SEO 스타터 가이드 — 제목 태그 위계 권고
• Google 검색 센트럴 — 메타 description 작성 가이드
• Google 검색 센트럴 블로그 — E-E-A-T 가이드라인 업데이트
• Search Engine Land — “If Google says H1s don’t matter for rankings, why should you use them?” — 헤딩과 순위·이해의 관계에 대한 존 뮬러 실제 발언
• Search Engine Journal — “Google Drops FAQ Rich Results From Search” — 2026년 5월 7일 FAQ 리치 결과 완전 폐지 보도
• Google 검색 센트럴 — QAPage 구조화 데이터 공식 문서 — QAPage와 FAQPage의 용도 구분

AI 크롤러 공식 문서

• OpenAI — 크롤러(GPTBot 등) 공식 문서
• Anthropic — ClaudeBot 크롤링 정책 공식 안내
• Google — Google-Extended 등 크롤러 공식 개요

이 글의 기술 감사 대상

• 사례 A — MIT 테크놀로지 리뷰 코리아, “에이전틱 브라우저, AI가 웹을 ‘사용’하는 시대”
• 사례 B — cowork.Makers, “크롬 Agentic Browsing으로 무얼 체크할 수 있을까요?” — AEO/GEO 모범 사례로도 인용