Google Search Central의 공식 발표는 대부분 Googlebot + 전통 랭킹 알고리즘을 전제로 작성된다. 그러나 현재 검색 환경에는 GPTBot·Google-Extended·PerplexityBot·ClaudeBot 등 AI 학습·RAG 파이프라인용 크롤러가 병존하며, 이들의 파싱 우선순위와 신호 처리 방식은 Googlebot 사양과 다르다. Google이 "안 해도 된다"고 밝힌 관행을 맥락 없이 전체 검색 환경에 적용하면 AI 검색 노출에서 불필요한 손실이 발생할 수 있다. 아래 5가지 항목을 전통 SEO와 GEO·AEO 두 레이어로 분리해 검증한다.
1. 메타 키워드 태그 — "Google은 완전히 무시한다"
작동 원리
2009년 9월 Matt Cutts의 공식 포스트에서 Google은 <meta name="keywords">를 랭킹 신호로 사용하지 않는다고 선언했다. Bing도 2011년 동일 선언. 이유는 스팸 남용이었다: 무관한 수천 개 키워드를 삽입해 색인을 오염시키는 패턴이 만연했기 때문이다.
재검증: 전통 SEO vs AI 파이프라인
- 전통 SEO — 사실: Googlebot은 메타 키워드를 파싱하되 랭킹 계산에 포함하지 않는다. 구현 낭비.
- GEO — 사실 (단 예외 있음): GPTBot·Google-Extended 역시
<meta name="keywords">를 RAG 청크의 임베딩 대상으로 우선 처리하지 않는다. 임베딩은<body>가시 텍스트와 JSON-LD 구조화 데이터를 중심으로 이뤄진다.- 왜: LLM 파이프라인은 시맨틱 유사도 기반 청크 검색이 목적이므로, 스팸 가능성이 높은 메타 필드를 소거한다.
- 어떻게: 메타 키워드 대신
<meta name="description">(AI Overviews 스니펫 attribution 텍스트로 활용 가능)과 JSON-LDdescription프로퍼티에 집중한다.
판정: 메타 키워드는 SEO·GEO 모두 불필요 — Google 발표 그대로 유효하다. 단 meta description과 Open Graph og:description은 별개이며 여전히 유효하다.
2. H1 단 하나만 써야 한다 — "여럿 써도 랭킹에 무관하다"
작동 원리
John Mueller는 2020년 공개 Q&A에서 "페이지에 H1이 여러 개 있어도 문제없다"고 명시했다. Googlebot은 HTML5 아웃라인 모델 기준으로 제목 계층을 파악하며 H1 개수를 패널티 신호로 처리하지 않는다.
재검증: 전통 SEO vs AI 파이프라인
- 전통 SEO — 기술적으로 사실: 다중 H1이 Google 랭킹 패널티를 발생시키지 않는다.
- AEO — 부분적으로 문제: Featured Snippet 선택 메커니즘은 질문-답변 블록의 논리적 컨테이너(H2·H3 + 직후 단락)를 기준으로 작동한다. H1이 산재하면 컨테이너 경계 탐지 정확도가 낮아진다.
- 왜: Google의 Featured Snippet 추출 파서는 제목 태그를 섹션 경계 마커로 사용하기 때문이다.
- 어떻게: H1(문서 제목) → H2(주요 섹션) → H3(하위 섹션) 단방향 계층을 유지하고, 각 H2 직하에 해당 섹션을 요약하는 1~2문장 도입 단락을 배치한다.
- GEO — 구조 손상 가능: RAG 파이프라인이 문서를 청크로 분할할 때 제목 태그를 청크 경계 신호로 사용한다. 다중 H1 배치는 청크 분할 경계를 무너뜨려 하나의 청크가 관련 없는 여러 주제를 포함하게 만든다.
- 왜: 청크 내 주제 혼재는 벡터 임베딩의 코사인 유사도 정밀도를 낮추고 인용 선택 확률을 떨어뜨린다.
- 어떻게: H1은 문서 전체의 주제를 대표하는 단 하나로 제한하고, 하위 주제는 H2로 분리한다.
판정: 다중 H1은 Google 랭킹 패널티 없음 — 발표 사실. 그러나 GEO·AEO 파이프라인에서는 논리적 계층 붕괴로 인용 정확도가 실질적으로 저하된다. 단일 H1 유지가 안전하다.
3. 키워드 밀도 규칙 — "2~3% 같은 공식은 존재하지 않는다"
작동 원리
Google은 키워드 밀도(keyword density)를 공식 랭킹 신호로 공개한 적이 없다. 2013년 Hummingbird 이후 RankBrain과 BERT가 시맨틱 매핑을 처리하므로 단어 반복 계산은 SEO 의미가 없다.
재검증: 전통 SEO vs AI 파이프라인
- 전통 SEO — 사실: "특정 단어를 N번 넣으면 색인에 유리하다"는 근거가 없다.
- GEO — 대체 개념 존재: AI 검색 파이프라인에서는 엔티티 공출현(entity co-occurrence)이 실질적인 신호로 작동한다.
- 왜: RAG 모델이 문서를 300~500 token 청크로 분할해 벡터화할 때, 동일 청크 내에서 관련 엔티티(브랜드명·기술 용어·개념)가 함께 등장하는 패턴이 해당 청크의 인용 적합도를 결정하는 데 영향을 준다.
- 어떻게: 하나의 H2 섹션 안에서 논리적으로 연관된 엔티티 군집을 함께 다룬다. 예: "SEO 감사" 섹션이라면 크롤 버짓·색인 커버리지·Core Web Vitals·robots.txt 지시어를 같은 섹션에 배치한다. 이 섹션은 해당 엔티티 군집 관련 질문에서 청크 단위로 인용될 확률이 높아진다.
판정: 전통적 키워드 밀도 규칙 — 여전히 무의미. 그러나 GEO에서 엔티티 공출현 밀도는 청크 인용 선택에 실제로 영향을 미친다. 목표가 달라졌을 뿐 "쓸 것을 정해서 집중해야 한다"는 원칙은 유효하다.
4. 사이트맵 제출 — "Googlebot은 알아서 찾는다"
작동 원리
Google Search Central 문서는 "양호한 내부 링크 구조가 있으면 사이트맵 없이도 크롤이 된다"고 명시한다. 특히 500페이지 이하 소규모 사이트에서는 사이트맵이 없어도 완전한 색인이 가능하다고 설명한다.
재검증: 전통 SEO vs AI 파이프라인
- 전통 SEO — 조건부 사실: 소규모·단순 계층 사이트에서는 사실. 대형 사이트에서는 사이트맵이 크롤 버짓 효율화에 기여한다.
- GEO — 역할이 확장됨: AI 크롤러 환경에서 사이트맵은 새로운 맥락을 가진다.
lastmod정확도가 AI 크롤러의 방문 빈도에 영향을 미치며,llms.txt와 병용 시 AI 크롤러에게 콘텐츠 우선순위를 신호하는 두 번째 레이어로 작동한다.- 왜: GPTBot과 Google-Extended는 재방문 빈도 결정 시
lastmod를 참조한다고 알려져 있다(OpenAI 공식 블로그 2023). 부정확한lastmod는 갱신된 콘텐츠가 재크롤되지 않는 원인이 된다. - 어떻게: 빌드 파이프라인에서 사이트맵
lastmod를 실제 파일 수정 시각으로 자동 갱신하고,llms.txt를 루트에 배치해 AI 크롤러가 우선 접근할 섹션을 명시한다.
- 왜: GPTBot과 Google-Extended는 재방문 빈도 결정 시
<!-- sitemap.xml: lastmod 는 실제 콘텐츠 수정 시각과 동기화 -->
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/guides/aeo-basics</loc>
<lastmod>2026-06-15</lastmod>
<changefreq>weekly</changefreq>
<priority>0.9</priority>
</url>
</urlset>
# llms.txt — AI 크롤러 전용 콘텐츠 맵 (루트에 배치)
# https://example.com/llms.txt
# Site: Example Tech Blog
# Preferred-crawl: /sitemap.xml
# Last-updated: 2026-06-15
## High-value for AI citation
- [AEO Basics](/guides/aeo-basics): Answer Engine Optimization 구현 원리
- [GEO Implementation](/guides/geo-impl): 구조화 데이터와 엔티티 신호
- [JSON-LD Reference](/guides/jsonld): 스키마 마크업 실전 예시
## Excluded
- /admin/*
- /drafts/*
- /internal/*판정: Googlebot 대상으로는 사이트맵이 선택적 — 발표 사실. 그러나 AI 크롤러 대상으로 lastmod 정확성과 llms.txt 병용은 콘텐츠가 AI 학습 파이프라인에 포함되는 빈도에 실질적 영향을 미친다.
5. robots.txt 부재 — "없으면 기본으로 전부 허용된다"
작동 원리
Robots Exclusion Protocol(RFC 9309) 사양에 따라 robots.txt가 없으면 모든 크롤러는 전체 크롤을 허용으로 간주한다. Google은 이 기본 동작을 공식적으로 확인했다.
재검증: 전통 SEO vs AI 파이프라인
- 전통 SEO — 사실: robots.txt 부재는 Googlebot 전체 허용. SEO 관점에서 선택적 도구다.
- GEO — 핵심 제어 레버로 전환됨: AI 크롤러 환경에서 robots.txt는 크롤러별 세분화 제어 도구로 기능이 확장됐다. AI 학습 데이터 수집용 크롤러(GPTBot, CCBot, Google-Extended)와 검색 색인 크롤러(Googlebot)를 분리 제어하지 않으면 콘텐츠가 의도하지 않은 AI 학습 데이터에 포함된다.
- 왜: Google-Extended는 Gemini 및 Vertex AI 학습 데이터 수집에 사용된다(Google Search Central, 2023-08). CCBot은 Common Crawl의 크롤러로, 다수의 오픈소스·상업용 LLM 학습 데이터셋의 원천이다.
- 어떻게:
User-agent별로 허용/차단을 명시적으로 선언한다. Google-Extended 차단 시 AI Overviews 인용 가능성이 낮아지므로 비즈니스 목표에 따라 결정한다.
# robots.txt — AI 크롤러 분리 제어 예시
# 검색 색인 크롤러: 전체 허용
User-agent: Googlebot
Disallow:
User-agent: Bingbot
Disallow:
# AI 학습 데이터 크롤러: 선택적 제어
User-agent: GPTBot
Disallow: / # OpenAI 학습 데이터 전체 차단
User-agent: Google-Extended
Allow: /guides/ # AI Overviews 인용 허용 섹션
Allow: /blog/
Disallow: / # 나머지 학습 데이터 제한
User-agent: Claude-Web
Disallow: /internal/
Allow: /
# Common Crawl (다수 LLM 학습 원천)
User-agent: CCBot
Disallow: /판정: robots.txt 부재 = 전체 허용 — 발표 사실. 그러나 AI 크롤러 분리 제어가 필요한 현재, robots.txt 부재는 "선택"이 아니라 "의도하지 않은 전체 허용" 상태다. 명시적 의사결정이 필요하다.
항목별 SEO·AEO·GEO 영향도 비교
| 항목 | Google 공식 발표 | 전통 SEO 실제 영향 | AEO 실제 영향 | GEO 실제 영향 |
|---|---|---|---|---|
| 메타 키워드 태그 | 무시 | 없음 | 없음 | 없음 (meta description은 유효) |
| H1 다중 사용 | 패널티 없음 | 랭킹 무관 | Featured Snippet 컨테이너 탐지 저하 | 청크 분할 경계 붕괴 → 인용 정확도 저하 |
| 키워드 밀도 규칙 | 공식 기준 없음 | 영향 없음 | 엔티티 명확성이 대체 신호 | 엔티티 공출현 밀도가 청크 인용 선택 요소 |
| 사이트맵 | 선택적 | 대형 사이트 권장 | 크롤 빈도 영향 | llms.txt 병용 시 AI 크롤러 우선순위 신호로 기능 |
| robots.txt | 없으면 전체 허용 | 선택적 차단 도구 | AI Overviews 노출 제어 레버 | LLM 학습 데이터 포함 여부를 결정하는 핵심 제어 지점 |
흔한 오해와 올바른 처리법
오해: "Google이 안 해도 된다고 했으니 GEO에서도 불필요하다."
이 오해의 근본은 Google의 가이드라인이 Googlebot + 전통 랭킹 알고리즘을 전제로 작성된다는 사실을 구분하지 못하는 데 있다. GPTBot·Google-Extended·PerplexityBot은 별도 크롤러이며, 이들의 파싱 정책은 Google Search Quality Evaluator Guidelines가 아니라 각 AI 시스템 내부 RAG 파이프라인 설계에 따른다.
올바른 처리법: Google 공식 발표를 읽을 때 "이것이 Googlebot에 한정된 이야기인가, 아니면 RFC/HTTP 표준처럼 모든 크롤러에 적용되는가"를 먼저 구분한다. Robots Exclusion Protocol·HTTP 응답 코드·Canonical URL은 대부분의 크롤러에 적용된다. 반면 랭킹 신호·Featured Snippet 선택·크롤 우선순위 관련 발표는 Googlebot에만 해당하므로, AI 크롤러 환경에서는 별도로 검증해야 한다.
기술적 FAQ
Google-Extended를 차단하면 AI Overviews 노출이 완전히 차단되나요?
Google Search Central(2023-08) 공식 문서에 따르면 Google-Extended는 Bard(현 Gemini) 및 Vertex AI 학습 데이터 수집에 사용된다. AI Overviews(구 SGE)는 Googlebot이 수집한 기존 색인 데이터를 기반으로 생성 답변을 구성한다. 따라서 Google-Extended 차단이 AI Overviews 인용을 즉시·완전히 차단하지는 않는다. 단, Google이 향후 AI Overviews 소스 선택 파이프라인을 Google-Extended 수집 데이터로 전환할 경우 영향이 발생할 수 있다. 현재로서는 Google-Extended 차단은 Gemini 답변 생성용 학습 데이터 수집을 제한하는 것으로, AI Overviews 노출 자체를 차단하는 것과 동일하지 않다.
robots.txt로 GPTBot을 차단해도 이미 학습된 데이터에서 내 콘텐츠가 제거되나요?
아니다. robots.txt는 미래의 크롤링을 제한하는 지시자이며, 이미 수집되어 LLM 학습에 사용된 데이터를 소급 삭제하지 않는다. OpenAI는 기존 학습 데이터에서의 콘텐츠 제거 요청을 별도 프로세스로 처리하며 수용 여부는 케이스별로 다르다. Google은 공개 수집 데이터의 사후 삭제 프로세스를 명확히 공개하지 않았다. 현실적 접근은 robots.txt 지시로 신규 크롤링을 차단하되, 비공개 처리가 필요한 정보는 애초에 공개 URL에 노출하지 않는 것이다. 이미 노출된 민감 정보는 404 처리 + Bing Webmaster Tools / Google Search Console의 URL 제거 도구로 색인에서 삭제 요청하는 것이 현재로서 가능한 최선이다.
참고 자료
이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.