「Google에서 검색」이 「AI에게 질문」으로 급격히 대체되고 있습니다. 2025년 조사에서는 생성형 AI로부터 SMB 사이트로 유입되는 소개 트래픽이 전년 대비 +123%라는 수치를 기록했습니다. 반면, 기존 방식의 검색 클릭 수는 감소 추세에 있습니다.

이러한 변화를 바탕으로 등장한 것이 **AEO(Answer Engine Optimization)**라는 개념입니다. SEO가 「검색 결과에서의 순위」를 최적화하는 것에 반해, AEO는 「AI가 답변을 생성할 때, 자사 사이트를 정보원으로 인용하도록 하는 것」을 목표로 합니다.

하지만 일본어권에서는 AEO에 관한 실천적인 정보가 아직 부족합니다. 본 기사에서는 AEO 대응 체크리스트를 7가지 구현 단계로 나누어, 코드 레벨에서 구체적으로 해설합니다.

대상 독자:

• 자사 사이트의 AI 검색 대응을 이제 시작하려는 개발자

• AEO라는 용어는 들어봤지만, 무엇부터 손을 대야 할지 모르는 분

• SEO 지식은 있지만, AEO 특유의 대응책을 알고 싶은 분

• AEO란 무엇인가, 왜 지금 필요한가

• 단계 1: AI 크롤러의 액세스 허용 상태를 확인

• 단계 2: robots.txt를 AI 대응으로 수정

• 단계 3: Cloudflare의 함정을 회피하기

• 단계 4: llms.txt를 도입하기

• 단계 5: 구조화 데이터(JSON-LD)를 정비하기

• 단계 6: 콘텐츠의 AEO 최적화(E-E-A-T + Q&A 형식)

• 단계 7: 효과 측정과 지속적 개선

• 요약: AEO 대응 체크리스트

AEO는 「SEO의 대체」가 아니라 「SEO 위에 올라가는 추가 레이어」로 이해하는 것이 정확합니다. 양쪽을 병행하여 진행해야 합니다.

3가지 관측 가능한 변화가 있습니다:

검색 행동의 이전: 2024~2025년에 걸쳐, 젊은 층을 중심으로 「구글링」에서 「ChatGPT에게 묻기」로의 이전이 진행 중.

Google AI Overviews의 본격 전개: Google 검색 결과 상단에 AI가 생성한 답변이 표시되는 케이스가 증가. 클릭하기 전에 답이 완결되어 버림.

CTR의 구조적 저하: 검색 순위 1위라도, AI 답변에 인용되지 않으면 트래픽이 늘어나기 어려워지고 있음.

즉 「검색 결과에 표시되는 것」만으로는 불충분하며, 「AI에 인용되는 것」이 중요해지고 있습니다.

본 기사에서 다루는 7단계를 먼저 정리합니다:

[기반 레이어]
단계 1: AI 크롤러의 액세스 가능 여부를 확인
단계 2: robots.txt를 AI 대응으로 정비
...

AEO 대응의 대전제는 AI 크롤러가 자사 사이트에 액세스할 수 있어야 한다는 것입니다. 액세스가 거부된 사이트는 아무리 양질의 콘텐츠를 가지고 있어도 인용 대상에서 제외됩니다.

답변 엔진(live querying)

방법 A: robots.txt를 수동 확인

curl -s https://example.com/robots.txt

각 크롤러 이름으로 Disallow 규칙이 없는지 확인합니다. 단, User-agent: *의 글로벌 규칙도 반드시 체크해야 합니다.

방법 B: 실제 요청을 보내서 검증

curl -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.2; +https://openai.com/gptbot" \
-I https://example.com/

상태 코드(Status Code)가 200이면 OK, 403이나 429라면 차단되었을 가능성이 높습니다. robots.txt에서 허용했더라도 Cloudflare와 같은 중간 레이어에서 거부되는 케이스가 빈번하게 발생하므로, 실제 통신 테스트는 필수입니다.

방법 C: 전용 도구를 사용

12종의 AI 크롤러를 한꺼번에 진단하고 싶다면, AI 크롤러 체커(AI Crawler Checker)를 사용하여 robots.txt와 실제 통신(Real Communication) 모두를 한 번에 검증할 수 있습니다 (무료, 회원가입 불필요).

구현 팀에서 현황을 파악할 때의 체크 항목:

• robots.txt가 존재하며, HTTP 200을 반환하는가
• 주요 5대 크롤러(GPTBot, ClaudeBot, PerplexityBot, Google-Extended, OAI-SearchBot)가 명시적으로 허용되어 있거나, Disallow 되어 있지 않은가
• 실제 요청(User-Agent 교체) 시 403/429 에러가 반환되지 않는가
• CDN/WAF 레이어에서 차단되지 않았는가

여기서 단 몇 건이라도 차단되고 있다면, 다음 단계로 넘어갑니다.

학습과 검색을 모두 허용하는 가장 심플한 패턴:

# robots.txt — 모든 AI 허용 패턴
User-agent: GPTBot
Allow: /
...

콘텐츠가 학습 데이터로 사용되는 것을 원하지 않을 경우:

# 학습용 크롤러는 차단
User-agent: GPTBot
Disallow: /
...

이 전략의 장점:

• 모델 학습 데이터에 대한 기여는 최소한으로 억제할 수 있음
• ChatGPT / Claude / Perplexity의 검색 기능(Search Functionality)을 통한 인용은 유지됨 - 실시간성이 있는 AI 답변에서의 노출이 확보됨

주의 사항:

• 규칙 기술은 위에서부터 순서대로 평가되므로, 더 구체적인 User-agent를 먼저 작성해야 함
• Allow: / 보다 'Disallow가 없는' 상태가 트러블이 적음 (일부 크롤러에서 Allow 해석이 다를 수 있음)
• 변경 후에는 반드시 curl https://example.com/robots.txt로 반영 여부를 확인해야 함

사이트에 관리자 페이지나 검색 결과 페이지 등, AI에게 보여줄 필요가 없는 경로가 있는 경우:

User-agent: GPTBot
Disallow: /admin/
Disallow: /search?
...

2024년 후반, Cloudflare는 신규 존(Zone)에 대해 AI 크롤러를 기본적으로 차단(Block) 하는 설정을 도입했습니다. 이로 인해 사이트 운영자가 인지하지 못한 채 다음과 같은 상황이 발생할 수 있습니다:

• GPTBot, ClaudeBot, PerplexityBot 등이 403 에러로 차단됨
• robots.txt에서는 Allow 하고 있음에도, Cloudflare의 에지(Edge)에서 거부됨
• 결과적으로 AI 검색 엔진에서의 인용 기회를 완전히 상실함

Cloudflare 대시보드에서의 확인 방법:

• Cloudflare 대시보드 → 해당 존(Zone)
• Security → Bots 또는 AI Audit (플랜에 따라 표기 다름)
• 「AI Bots」 설정이 Block으로 되어 있지 않은지 확인

또는, 커맨드 라인(Command Line)에서 검증:

# GPTBot인 것처럼 가장하여 요청
curl -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.2; +https://openai.com/gptbot" \
-I https://example.com/
...

응답 헤더(Response Header)에 cf-ray가 포함되어 있고, 상태 코드가 403인 경우 Cloudflare에서 차단되었을 가능성이 높습니다.

단계 1: Cloudflare의 자동 차단(Auto Block)을 Off로 설정

• 대시보드 → Security → Bots → AI Audit
• 「Block AI Bots」가 활성화되어 있다면 비활성화로 변경
• 또는, 특정 크롤러별로 Allow / Block을 개별 설정

단계 2: WAF 규칙 재검토

Cloudflare의 「커스텀 WAF 규칙(Custom WAF Rules)」에서 User-Agent 차단을 설정한 경우, AI 크롤러 이름이 포함되어 있는지 확인합니다. 자주 발생하는 설정 오류:

# 잘못된 예: "bot"을 포함하는 User-Agent를 일괄 차단 → GPTBot, ClaudeBot도 함께 차단됨
http.user_agent contains "bot"

좋은 예: 명시적인 악성 봇만 차단

http.user_agent contains "BadBot" or http.user_agent contains "ScraperX"

단계 3: Cache 설정 확인

에지 캐시 (Edge Cache)가 오래된 403 응답을 유지하고 있을 수 있습니다. Cloudflare → Caching → Configuration → Purge Everything에서 한 번 캐시를 삭제합니다.

수정 후, 다시 실제 통신 테스트를 수행합니다:

for ua in "GPTBot" "ClaudeBot" "PerplexityBot"; do
echo -n "$ua: "
curl -A "Mozilla/5.0 (compatible; ${ua}/1.0; +https://example.com)" \
...

모두 200이 반환되면 성공입니다.

2024년 9월에 Jeremy Howard 씨가 제안한 새로운 표준으로, 사이트의 콘텐츠 구조를 Markdown 형식으로 AI (LLM)에게 전달하는 파일입니다. 사이트의 루트 (example.com/llms.txt)에 배치합니다.

robots.txt와 llms.txt의 역할 차이:

두 가지를 병용하는 것이 이상적입니다. robots.txt로 "액세스해도 좋다"라고 알리고, llms.txt로 "중요한 곳은 여기입니다"라고 안내합니다.

# 사이트 이름
> 사이트 전체에 대한 간결한 소개 (1~2문장)
## Docs
...

구현 시 체크 항목:

• H1은 1개: 사이트 이름만
• blockquote: H1 직후에 사이트 개요를 1~2문장으로 작성
• 페이지 수는 30개 이하: AI가 처리하기 쉬운 양
• 절대 URL: 상대 경로는 불가
• HTML은 사용하지 않음: 순수 Markdown만 사용
• 중요도가 낮은 페이지는 Optional 섹션: 이용약관, 개인정보 처리방침 등
• 월 1회 업데이트: 신규 페이지 추가 및 폐지에 대응

실제 사이트에서의 구현 예시 (단축 버전):

# Example 주식회사 | SaaS 인사 관리 툴
> 중소기업용 클라우드 인사 관리 SaaS. 근태 관리, 급여 계산, 연말 정산을 일원화.
## Docs
...

수동으로 유지보수하는 것은 현실적이지 않으므로, 자동 생성 도구를 사용하는 것을 권장합니다. 사이트맵을 분석하여 자동으로 llms.txt를 생성할 수 있는 llms.txt 제너레이터를 사용하면, AI가 각 페이지의 일본어 요약까지 만들어 줍니다 (무료, Claude Haiku 4.5 사용).

Next.js 13+의 경우, public/llms.txt에 배치하는 것만으로 https://example.com/llms.txt에서 접속 가능해집니다:

project-root/
├── public/
│ ├── llms.txt ← 여기에 배치
...

WordPress의 경우, 테마의 functions.php에 다음을 추가:

add_action('template_redirect', function() {
if (­$_SERVER['REQUEST_URI'] === '/llms.txt') {
header('Content-Type: text/plain; charset=UTF-8');
...

구조화 데이터 (Structured Data)는 AI 검색 엔진이 정보를 정확하게 추출하기 위한 최우선 시그널입니다:

• AI 답변 엔진이 가격, 저자, 공개일 등의 구체적인 정보를 인용할 때 구조화 데이터를 참조함
• 동일한 내용의 페이지가 2개 있을 경우, 유효한 schema를 가진 쪽이 인용될 확률이 높음
• 리치 결과 (Rich Results: FAQ, 브레드크럼, 평가 등) 표시 요건이기도 함

기업 사이트 / SaaS

1. Organization # 회사 정보, 로고, SNS 링크
2. SoftwareApplication # 제품 정보, 가격, 대응 OS
3. FAQPage # 자주 묻는 질문
...

EC 사이트

1. Product # 상품 정보, 가격, 재고
2. Offer # 판매 조건
3. AggregateRating # 평가 (실제 데이터만)
...

미디어 / 블로그

1. Article # 기사
2. NewsArticle # 뉴스 기사
3. Author / Person # 저자 정보 (E-E-A-T 중시)
   ...

가장 도입 효과가 높은 것이 FAQPage입니다. 코드 레벨에서의 구현:

<script type="application/ld+json">
{
"@context": "https://schema.org",
...

// app/faq/page.tsx
export default function FaqPage() {
const faqSchema = {
...

구현 시 주의해야 할 오류:

@context
의 지정 누락 → "@context": "https://schema.org" 필수

• 필수 속성 누락 → Article은 headline / author / datePublished가 필수
• 마크업과 표시 내용의 불일치 → JSON-LD에 "가격 1000엔"이라고 적고 실제로는 "1500엔"으로 표시하는 것은 NG
• 테마/플러그인에 의한 중복 출력 → 동일한 schema가 여러 번 출력되면 일부가 무시됨
• Google 리치 결과 (Rich Results) 요건 미충족 → schema.org에서는 유효하더라도 Google 표시 대상에서 제외되는 케이스

구조화 데이터 (Structured Data) 검증은 반드시 2단계로 진행합니다:

단계 1: schema.org 규격 준수

Schema.org Markup Validator 또는, AI의 일본어 해설과 함께 검증하고 싶다면 구조화 데이터 검증 도구를 사용합니다.

단계 2: Google 리치 결과 대상 판정

Google 리치 결과 테스트 (Google Rich Results Test) 에서, 실제로 Google 검색 결과에 표시되는 대상인지 확인합니다.

AI 검색 엔진은 "신뢰할 수 있는 정보원"을 우선합니다. E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness)의 강화가 중요합니다.

체크 항목:

• 저자 정보 명시: 각 기사에 저자명, 직함, 프로필 페이지로의 링크
• 운영자 정보 충실: 회사 개요, 소재지, 법인 번호 (일본의 경우), 연락처
• 업데이트 날짜 표시: "최종 수정일"을 기사에 명기
• 참고 문헌 명시: 출처·인용 원문으로의 링크
• 전문가 리뷰: 의료·법률 등 전문 분야에서는 감수자를 명기

Organization schema에서의 구현:

<script type="application/ld+json">
{
"@context": "https://schema.org",
...

AI 답변 엔진은 질문에 대한 명확한 답을 추출하기 쉬운 구조를 선호합니다. 콘텐츠를 다음과 같은 패턴으로 구성하면 인용되기 쉬워집니다:

나쁜 예 (산문형):

웹사이트의 퍼포먼스를 개선하기 위해서는 다양한 방법이 있으며, 각각의 상황에 따라 적절한 대응을 취하는 것이 중요하고, 우선 가장 먼저に取り組むべき(해야 할) 것은...

좋은 예 (Q&A 형식):

웹사이트의 표시 속도를 개선하려면? 가장 먼저 해야 할 것은 이미지 최적화입니다. 구체적으로는 다음 3가지:

• 이미지를 WebP 형식으로 변환
• lazy loading (지연 로딩) 구현
• CDN을 통한 배포

이를 통해 일반적으로 Largest Contentful Paint (LCP)가 30~50% 개선됩니다.

"자사가 누구인가"를 AI에게 명확히 전달하기 위한 요소:

• 회사명·서비스명을 일관된 표기로 사용 (표기 불일치 방지)
• 메인 키워드를 제목·H1·첫 번째 단락에 배치
• 관련 있는 다른 엔티티 (Entity)와의 관계를 명시 ("○○사의 서비스", "△△ 업계용")

AI 답변 엔진은 사이트 내 관련 페이지 간의 연결성도 평가합니다:

• 토픽별로 허브 앤 스포크 (Hub & Spoke) 구조를 구축 (중심 페이지에서 관련 기사로 링크)
• 오래된 기사에서 새로운 기사로, 새로운 기사에서 오래된 기사로, 양방향 내부 링크 구축
• 앵커 텍스트는 구체적으로 ("여기"가 아니라 "llms.txt 구현 방법")

AEO의 효과 측정은 기존의 SEO보다 어렵지만, 다음 지표를 추적합니다:

GA4에서 AI 경유 트래픽을 식별하기 위한 커스텀 리포트:

차원 (Dimensions):

• 세션 소스 / 매체 (Session source / medium)
• 랜딩 페이지 (Landing page)
  ...

이 세그먼트를 월 단위로 확인하여 AI 트래픽의 추이를 파악합니다.

권장 운영 사이클:

주간:

• 서버 로그를 통해 AI 크롤러 (AI Crawler) 접속 확인
• 403/429 에러의 급증 여부 확인
• Google Search Console에서 구조화 데이터 (Structured Data) 에러 체크

월간:

• AI 크롤러 체커 (AI Crawler Checker)로 현황 확인
• llms.txt 내용을 최신 페이지에 반영
• 신규 기사에 구조화 데이터 구현
• AI 유래 트래픽 리포트

분기:

• AEO 전략 전체 재검토
• 경쟁 사이트의 llms.txt 구현 상황 체크
• 신규 AI 검색 엔진 등장에 대응 (크롤러 추가 등)

마지막으로, 본 기사에서 다룬 모든 체크 항목을 정리합니다. 자사 사이트에 대해 모두 체크해 보고, 미대응 항목부터 시작해 보세요.

• robots.txt가 존재하며, HTTP 200을 반환함

• 주요 5대 크롤러 (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, OAI-SearchBot)가 허용됨

• 실제 통신 테스트 (User-Agent 교체) 시 403/429가 반환되지 않음

• Cloudflare의 「Block AI Bots」 설정이 꺼져 있음

• WAF 규칙에서 User-Agent 차단 설정을 하지 않음 (또는 제외 설정 완료)

• /llms.txt가 배치되어 있음

• llms.txt가 30페이지 이하로 압축되어 있음

• llms.txt의 각 섹션 (Docs/Tools/Blog/About/Optional)이 정리되어 있음

• 주요 스키마 (Schema) 타입 (Organization, FAQPage, Article, BreadcrumbList)이 구현되어 있음

• 구조화 데이터가 Schema.org Validator와 Google Rich Results Test를 모두 통과함

• 모든 기사에 저자 정보가 명시되어 있음

• 운영자 정보 (회사 개요, 소재지, 연락처)가 충실함

• 중요 기사에 Q&A 형식의 섹션이 있음

• 내부 링크가 허브 앤 스포크 (Hub & Spoke) 구조로 되어 있음

• 각 페이지에 최종 업데이트 날짜가 명시되어 있음

• 서버 로그로 AI 크롤러 접속을 정기적으로 확인

• GA4로 AI 유래 트래픽을 월간 리포트

• llms.txt를 월 1회 업데이트

• 신규 페이지에 구조화 데이터 필수 구현

AEO 대응은 SEO와 달리 "이것이 정답"이라는 베스트 프랙티스 (Best Practice)가 아직 확립되지 않은 영역입니다. AI 검색 엔진 자체가 매일 진화하고 있으며, 오늘의 베스트 프랙티스가 반년 후에는 바뀌어 있을 가능성도 충분합니다.

하지만 본 기사에서 다룬 7단계는 어떤 방향으로 진화하더라도 기반으로서 유효한 내용입니다:

• AI 크롤러가 접속할 수 있는 상태를 확보한다
• 사이트 구조를 기계 판독 가능한 (Machine-readable) 형태로 제공한다
• 콘텐츠의 신뢰성을 시그널 (Signal)로 강화한다

이 세 가지 축을 파악하고 있다면 AEO 트렌드 변화에도 쉽게 대응할 수 있습니다.

본 기사에서 소개한 도구군 (AI 크롤러 체커, llms.txt 제너레이터, 구조화 데이터 검증 도구)은 모두 무료이며 회원 가입 없이 이용할 수 있습니다. 상세한 설명을 참고하여 AEO 대응의 각 단계를 구현할 때 꼭 활용해 보시기 바랍니다.