두 개의 SEO 감사 도구가 동일한 사이트 — 바로 제 사이트 — 에 대해 매우 다르게 들리지만 서로 연관된 두 가지 문제를 지적했습니다. 하나는 146개의 유효하지 않은 구조화된 데이터 (Structured Data) 항목이었고, 다른 하나는 도구가 허용 가능한 임계값으로 간주하는 80% 미만인 79%의 "AI 검색 건강도 (AI Search Health)" 점수였습니다.

첫 번째 문제는 언젠가 예상했던 것이었습니다. 두 번째 문제는 더 새로운 것이며, 만약 당신이 2026년에 콘텐츠를 출시하고 있다면 이해할 가치가 있습니다. 왜냐하면 "Google을 위한 최적화 (optimize for Google)"와 "AI 검색을 위한 최적화 (optimize for AI search)"는 더 이상 완전히 동일한 작업이 아니기 때문입니다.

조용히 고장 나는 구조화된 데이터 (Structured Data)

JSON-LD (Google에게 "이것은 제품(Product)입니다", "이것은 리뷰(Review)입니다", "이것은 기사(Article)입니다"라고 알려주는 블록)는 특정한, 짜증 나는 방식으로 실패합니다. 즉, 페이지를 깨뜨리지 않는다는 점입니다. 페이지는 정상적으로 렌더링됩니다. 사용자들은 아무런 문제도 발견하지 못합니다. 오직 검증기(Validator) — 또는 리치 결과 (rich-results) 기능이 조용히 나타나지 않는 현상 — 만이 무언가 잘못되었다는 것을 알려줍니다.</p> <p>모든 리뷰 페이지에 Product + AggregateRating 스키마 (schema)가 적용된 비교 사이트에서, 저는 스키마가 기술적으로는 유효한 JSON이지만 Google에게 중요한 의미에서 의미론적(semantically)으로 잘못되었다는 것을 발견했습니다. 해당 스키마에는 Merchant Listing (판매자 목록)에 필요한 필드(offers 내부의 image, hasMerchantReturnPolicy, shippingDetails, availability)가 없는 offers 객체가 포함되어 있었습니다. Google은 JSON을 거부한 것이 아니라, 단지 해당 페이지를 유효하지 않은 merchant listing으로 분류하고 리치 결과 (rich result)를 보여주는 것을 중단했을 뿐입니다.</p> <p>해결책은 "누락된 필드를 추가하는 것"이 아니었습니다. 제3자 소프트웨어 리뷰 사이트로서, 저희는 직접 판매하지 않는 제품에 대한 실제 반품 정책 (return policies)이나 배송 상세 정보 (shipping details)를 가지고 있지 않기 때문입니다.

해결 방법은 offers를 완전히 제거하고 Product + AggregateRating만 유지하는 것이었습니다. 이는 트랜잭션(transactions)을 처리하지 않는 리뷰 사이트에 대해 Google이 실제로 권장하는 스키마 (schema)입니다.</p> <p>jsonc<br> // 리뷰 사이트에 잘못된 방식 (Merchant Listing 검증을 트리거함)<br> {<br> "@type": "Product",<br> "name": "...",<br> "offers": { "price": "...", "priceCurrency": "USD" }, // ← 직접 판매하는 것이 아니라면 추가하지 마세요<br> "aggregateRating": { ... }<br> }</p> <p>// 리뷰/비교 사이트에 올바른 방식<br> {<br> "@type": "Product",<br> "name": "...",<br> "image": "...",<br> "aggregateRating": { ... }<br> }</p> <p>교훈: 더 많은 스키마 (schema) 필드가 자동으로 더 나은 것은 아닙니다. offers를 추가하는 것이 "추가적인 풍부한 데이터 (extra rich data)"처럼 느껴졌지만, 이는 콘텐츠가 충족할 수 없는 요구사항을 가진 스키마 카테고리로 모든 페이지를 조용히 재분류해 버렸습니다.</p> <p>AI 검색 건강도 (AI Search Health)는 진정으로 다른 체크리스트를 가집니다</p> <p>새로운 신호 — ChatGPT, Perplexity, 그리고 Google의 AI Overviews에 의해 크롤링(crawled)되고 인용되는 사이트들 — 는 기존의 Googlebot과는 별개의 자체 유저 에이전트 (user-agents)를 가지고 있습니다:</p> <p>User-agent: Googlebot<br> Allow: /</p> <p>User-agent: Google-Extended<br> Allow: /</p> <p>User-agent: GPTBot<br> Allow: /</p> <p>User-agent: ChatGPT-User<br> Allow: /</p> <p>User-agent: OAI-SearchBot<br> Allow: /</p> <p>와일드카드(wildcard) User-agent: * / Allow: / 는 기술적으로 기본적으로 이 모든 것을 포함하지만, 명시적으로 작성하는 것은 모호함을 제거하며, 더 중요한 것은 각 에이전트가 당신의 사이트를 크롤링하기를 원하는지 실제로 고민하게 만든다는 점입니다.</p>

Google-Extended는 인덱싱 (indexing) 여부와는 별개로, 당신의 콘텐츠가 Gemini 학습에 사용될 수 있는지 여부를 구체적으로 제어합니다. 이는 많은 robots.txt 파일들이 구분하지 못하는 차이점입니다.</p> <p>또 다른 떠오르는 관습은 llms.txt입니다. 이는 robots.txt나 sitemap.xml과 유사하게 루트 디렉토리에 위치하는 일반 텍스트 (plain-text) 파일이지만, 전통적인 검색 인덱서 (search indexers) 대신 LLM 기반의 크롤러/에이전트 (crawlers/agents)를 대상으로 합니다. 아직 단일하게 승인된 사양 (spec)은 없지만, 나타나고 있는 형태는 단순합니다:</p> <h1> <a name=

다음과 같은 상황에서만 알게 됩니다:</p> <p>리치 결과 검증기 (rich-results validator)가 오류를 표시할 때<br> 전문적인 감사 도구 (Screaming Frog, Semrush, Ahrefs)가 이를 크롤링할 때<br> 트래픽이 예상했던 곳에 조용히 나타나지 않을 때</p> <p>콘텐츠 비중이 높은 사이트를 운영하고 있다면, 시각적으로 정확성을 검사할 수 없는 코드를 린트 (lint) 하는 것과 마찬가지로, 이미 사용 중인 콘텐츠 CI/QA 프로세스에 구조화된 데이터 (structured-data) 검증 및 AI 크롤러 접근성 (AI-crawler-accessibility) 체크를 추가할 가치가 있습니다. 실패 모드는 동일합니다: 기술적으로는 존재하지만, 조용히 잘못되어 있으며, 뒤늦게 발견하면 비용이 많이 듭니다.</p> <p>현재 독립적인 SaaS 비교 사이트인 PilotStack에서 정확히 이런 종류의 정리 작업을 수행하고 있습니다. 만약 유사한 감사를 수행하고 발견한 내용에 대해 의견을 나누고 싶다면, 다른 사이트에서는 무엇이 나타나는지 궁금합니다.</p>