GEO 체크리스트 테크니컬편 : 좋은 글을 써도 AI에 안 나오는 이유?

GEO 체크리스트 테크니컬편

콘텐츠가 아무리 좋아도 AI 크롤러가 사이트에 접근조차 못 하거나 본문을 읽어내는 데 실패하면 인용 후보에 오를 수 없습니다. AI 검색이 본격화되면서 SEO 실무 환경에서는 "콘텐츠 작성보다 기술적 진단이 우선"이라는 기조가 강화되고 있습니다. AI 생태계에 내 사이트를 노출하기 위해 반드시 점검해야 할 핵심 기술 항목 네 가지를 정리했습니다.

1. 크롤링 — Robots.txt, WAF, 사이트맵, 그리고 렌더링 환경

1-1. Robots.txt 및 WAF 보안 정책 점검

robots.txt는 사이트 루트 경로(도메인/robots.txt)에서 크롤러의 수집 권한을 제어하는 파일입니다. 기본적으로 전체 허용(User-agent: * / Allow: /)을 유지하되, 주요 AI 크롤러가 차단 목록에 들어있지 않은지 점검해야 합니다. AI 크롤러는 목적에 따라 크게 세 가지로 나뉩니다 — 모델 학습에 쓰이는 학습용 봇, 검색 답변에 출처로 인용하기 위한 검색·인용용 봇, 그리고 사용자가 실시간으로 질문했을 때만 방문하는 사용자 요청용 봇입니다. AI 크롤러마다 개별적으로 User-agent를 지정해야 하는데, 이를 모르고 User-agent: * 하나로 뭉뚱그려 차단 규칙을 걸면 학습·검색·인용용 봇이 한꺼번에 차단되니 주의해야 합니다.

[표] 주요 AI 크롤러

민감 페이지 처리 원칙

모든 페이지를 열어둘 필요는 없습니다. 로그인 후에만 보이는 마이페이지, 결제·주문 페이지, 회원 전용 콘텐츠처럼 보안이 필요한 영역은 robots.txt에서 Disallow 처리하거나, 애초에 로그인 보호(인증 절차) 뒤에 두어 크롤러가 접근할 수 없는 구조로 만드는 것이 좋습니다. 두 방식 다 가능하지만, robots.txt는 크롤러의 '자발적 준수'에 의존하는 규칙일 뿐 강제력이 없기 때문에, 실제로 노출되면 안 되는 정보라면 로그인 보호처럼 기술적으로 막는 방식이 더 안전합니다.

실무 주의사항 (WAF 및 방화벽 이슈)

robots.txt에서 접근을 허용했더라도 Cloudflare, AWS WAF 등의 보안 솔루션이 AI 크롤러의 IP나 User-Agent를 '해로운 봇'으로 오인해 403 Forbidden 또는 503 Service Unavailable 에러를 반환할 수 있습니다. 실제로 브랜드A 사례에서는 WAF가 크롤러 요청에 502 오류를 반환해, robots.txt는 정상인데도 AI 크롤러가 페이지를 전혀 수집하지 못하고 있던 것이 뒤늦게 발견된 적이 있습니다. robots.txt만 확인하고 넘어가지 말고, 서버 로그에서 해당 봇들이 실제로 크롤링 중이고 우선순위 페이지들이 정상적으로 200 응답을 받는지까지 검증해야 합니다.

• IP 대역·User-Agent 화이트리스트 : 보안 정책 설정에서 주요 AI 봇을 화이트리스트에 등록해 두는 것이 안전합니다.
• 노출 제어 메타태그 확인 : nosnippet, data-nosnippet, max-snippet, noindex는 구글이 명시한 AI 노출 제어 수단입니다. 의도치 않게 걸려 있지 않은지 확인이 필요합니다.
• 4xx/5xx 오류 정리 : 깨진 링크나 서버 오류가 누적되면 크롤링 신뢰도가 떨어집니다.

1-2. XML Sitemap 최신화

사이트맵(Sitemap)이란 사이트 안의 페이지 목록을 크롤러가 읽기 쉬운 형식으로 정리해 둔 파일입니다. XML 형식이 표준으로 쓰이며, 각 페이지의 URL과 최종 수정일 등의 정보를 담고 있어 크롤러가 사이트 구조와 최신 상태를 빠르게 파악하는 데 도움을 줍니다.

도메인/sitemap.xml 경로를 통해 XML 사이트맵 제공 여부를 점검합니다. 구글 서치 콘솔(Google Search Console)에 등록하는 것뿐만 아니라, robots.txt 하단에 사이트맵 경로를 명시해 두어야 AI 봇이 새로운 페이지를 더 빠르게 감지할 수 있습니다. 페이지 업데이트 시 lastmod 태그가 실제 수정 날짜와 일치하도록 자동 반영 로직을 구축하는 것을 권장합니다.

Bing Webmaster Tools에도 웹사이트를 함께 등록해 두는 것이 좋습니다. ChatGPT 웹검색을 비롯해 다수의 AI 검색 엔진이 Bing의 검색 인덱스를 주요 정보 출처로 활용하고 있다는 조사 결과도 있어, 구글 서치 콘솔 못지않게 필수적으로 챙겨야 할 영역입니다.

1-3. 자바스크립트 렌더링 한계 (SSR의 필요성)

구글봇과 달리 대부분의 AI 크롤러는 자바스크립트(JS)를 실행하는 렌더링 엔진 리소스가 한정되어 있습니다. 리액트(React)나 뷰(Vue) 기반의 CSR(Client-Side Rendering) 사이트는 크롤러가 방문했을 때 빈 HTML 화면만 읽고 돌아갈 가능성이 있습니다.

[표] 크롤러별 JS 실행 여부

핵심 내용과 주요 정보는 반드시 초기 HTML에 있어야 합니다. 자바스크립트 로드 이후에 추가되는 콘텐츠는 AI 크롤러에게 아예 존재하지 않는 것으로 취급될 수 있습니다. AI 크롤러가 완성된 HTML을 즉시 읽을 수 있도록 SSR(Server-Side Rendering) 또는 프리렌더링(Pre-rendering) 환경 구축을 권장합니다.

직접 확인하는 방법도 어렵지 않습니다. 브라우저에서 뷰소스(페이지 소스 보기)로 실제 노출되는 텍스트를 확인하거나, 브라우저에서 자바스크립트를 끄고 페이지를 로드해보거나, curl 명령으로 원본 HTML을 직접 받아보면 AI 크롤러가 보는 것과 동일한 화면을 확인할 수 있습니다.

2. 구조화 데이터 — 스키마(Schema) 마크업

2-1. AI 해석 관점에서의 스키마 마크업

스키마(Schema) 마크업은 웹페이지 콘텐츠의 의미와 구조를 검색엔진과 AI가 쉽고 명확하게 이해할 수 있도록 돕는 메타데이터입니다. 기존 검색엔진에서는 리치 스니펫을 위한 역할에도 사용되었지만, GEO 환경에서는 AI가 대량의 본문 데이터를 빠르고 정확하게 발췌할 수 있도록 핵심 정보를 구조화해 주는 결정적인 역할을 합니다. 다만 구글은 AI 검색에 구조화 데이터가 필수 조건은 아니라고 명시했으나, AI가 정보의 맥락을 훨씬 명확하게 파악할 수 있도록 돕는다는 점에서 적용을 권장합니다.

2-2. 주요 스키마 유형

모든 스키마를 다 적용할 필요는 없습니다. 페이지의 콘텐츠 성격에 맞는 스키마를 선택하는 것이 핵심이며, 대표적으로 다음 4가지가 실무에서 가장 많이 쓰입니다.

• FAQPage (Q&A 콘텐츠) : 사용자 질문과 답변 구조(Q&A)를 바로 읽을 수 있게 매핑합니다. AI가 특정 질문에 대한 다이렉트 앤서를 생성할 때 높은 확률로 추출해 가는 핵심 스키마입니다.
• Product / Offer (상품·서비스 페이지) : 가격, 재고, 옵션 등 상품 정보를 구조화합니다. AI가 상품 추천·비교 답변을 생성할 때 직접 인용하는 데이터입니다.
• Article / BlogPosting (블로그·뉴스 콘텐츠) : 아티클의 제목, 작성자, 발행일, 개요를 명시합니다. AI가 최신 정보인지 판단하는 근거가 되며, 환각(Hallucination) 방지를 위한 '정보 출처 검증' 과정에서 콘텐츠의 권위를 입증하는 역할을 합니다.
• LocalBusiness (지역 기반 업체 페이지) : 주소, 전화번호, 영업시간 등을 구조화합니다. "근처 OO 추천해줘" 같은 위치 기반 질문에 AI가 바로 활용하는 데이터입니다.

3. 콘텐츠 구조화 — H태그와 문맥 완결성

3-1. H태그 위계 구조 (Heading Hierarchy)

H태그(H1~H6)는 문서의 논리적 뼈대입니다. H1은 페이지당 단 하나만 선언하고, 하위 주제는 H2, H3 순으로 순차적 위계를 지켜야 합니다.

• 올바른 예시 : H1(메인 주제) → H2(소주제) → H3(세부 설명) → H2(다음 소주제)
• 잘못된 예시 : H1 → H3(H2 건너뜀) 또는 CSS 스타일 목적으로 태그 무단 혼용

3-2. 주제별 문맥 완결성 확보

각 섹션은 첫 문장에서 결론이나 답부터 제시하고, 그다음 부연 설명이 이어지는 두괄식 구조가 좋습니다. AI 검색 엔진은 페이지를 특정 글자 수로 인위적으로 쪼개 읽기보다는 전체 흐름 속에서 맥락을 종합해 추출하기 때문에, 글자 수를 기계적으로 맞추기보다는 첫 문장만 읽어도 질문에 대한 답을 알 수 있는지를 기준으로 삼는 것이 바람직합니다. 여기에 데이터를 명확히 보여주는 표(Table)와 불릿 포인트를 조합하면 AI가 핵심 정답을 발췌하기 훨씬 용이해집니다.

핵심 콘텐츠(서비스 설명, 가격, FAQ, 고객 사례 등)가 로그인 뒤에 숨겨져 있거나, 팝업으로만 노출되거나, 이미지 속 텍스트로만 존재하지 않도록 주의해야 합니다. AI 크롤러는 이런 형태로 존재하는 콘텐츠를 읽지 못합니다.

4. 페이지 성능 — Core Web Vitals, TTFB, 그리고 DOM 최적화

4-1. TTFB(Time to First Byte)와 수집 안정성

AI 크롤러는 방대한 웹을 수집해야 하므로 페이지 응답 대기 시간에 엄격한 기준을 적용합니다. 서버가 첫 번째 바이트를 반환하는 시간인 TTFB가 과도하게 지연되면 크롤러는 타임아웃 처리 후 수집을 포기할 수 있습니다. 고성능 호스팅 환경 구축, 서버 캐싱 전략, CDN 도입을 통해 TTFB를 최우선으로 개선해야 합니다.

실제로 12만 9천여 개 도메인을 분석한 조사에서는 FCP(First Contentful Paint) 0.4초 미만인 페이지가 평균 6.7회 인용된 반면, 1.1초를 넘는 페이지는 2.1회에 그쳤습니다. 속도가 곧 인용 가능성과 직결된다는 것을 보여주는 수치입니다.

4-2. Core Web Vitals 주요 지표

Core Web Vitals란 구글이 정의한 웹페이지의 사용자 경험 측정 지표입니다. 원래는 SEO에서 페이지 로딩 속도와 안정성을 가늠하는 용도로 쓰였지만, GEO에서는 AI 크롤러의 수집 안정성과도 맞닿아 있는 요소로 함께 봐야 합니다. 구성은 아래 3개와 같습니다.

• LCP (Largest Contentful Paint) : 메인 콘텐츠 렌더링 시간 (2.5초 이내 권장)
• INP (Interaction to Next Paint) : 사용자 상호작용 반응 속도 (200ms 이내 권장)
• CLS (Cumulative Layout Shift) : 로딩 중 레이아웃 흔들림 수치 (0.1 이하 권장)

4-3. DOM 구조 최적화 (파싱 효율성)

웹페이지 빌더 등을 과도하게 사용하면 의미 없는 div 태그가 수십 겹으로 중첩되는 'DOM 깊이 폭발' 현상이 발생합니다. 불필요하게 복잡하고 깊은 DOM 구조는 AI가 HTML을 파싱하고 유의미한 본문 텍스트를 추출하는 과정을 방해합니다. 깔끔하고 경량화된 DOM 트리를 유지하는 것이 기술적 GEO의 마지막 완성입니다.

자주 묻는 질문 (FAQ)

Q1. 이 체크리스트 항목을 다 지키면 AI 인용이 보장되나요?

아닙니다. 이 항목들은 AI가 우리 사이트를 읽을 수 있는 '자격'을 만드는 것이지, 인용을 보장하지는 않습니다. 기술 조건을 충족한 다음은 콘텐츠 품질과 관련성의 영역입니다.

Q2. robots.txt와 사이트맵 중 하나만 관리해도 되나요?

둘 다 필요합니다. robots.txt는 크롤러에게 "어디를 봐도 되는지" 허용·차단을 알려주는 규칙이고, 사이트맵은 "어떤 페이지들이 있는지" 목록을 제공하는 역할입니다. robots.txt만 열어둬도 사이트맵이 없거나 오래됐으면 새 페이지를 크롤러가 늦게 발견하고, 반대로 사이트맵만 잘 관리해도 robots.txt에서 막혀 있으면 애초에 접근이 안 됩니다.

Q3. AI 크롤러 수집은 확인되었는데, 왜 AI 답변에는 아직 우리 브랜드가 안 나올까요?

크롤링(수집)과 인용(답변 반영)은 완전히 별개의 프로세스이기 때문입니다. AI 크롤러가 페이지를 가져간 후에도 데이터의 정확성과 맥락 연관성을 평가하는 내부 검증 단계가 진행되며, AI 엔진별 인덱싱 반영 주기에 따라 시차가 발생할 수 있습니다. 만약 기술적 요건을 모두 갖췄음에도 노출되지 않는다면, 질문 의도에 대한 콘텐츠의 직접적인 답변성이 부족하거나 정보의 구체성이 떨어질 수 있어 콘텐츠 점검을 고려해야 합니다.