구조화 데이터, 구글은 정말 추천하지 않을까

Q: Q. Wikidata 항목이 없는 신규 브랜드는 sameAs를 어떻게 처리해야 하는가?

Wikipedia 등재 없이도 Wikidata에 엔티티 항목을 직접 생성하고 해당 QID URL을 sameAs에 넣을 수 있다. Wikidata는 편집 개방형이므로 브랜드 기본 정보(공식 URL, 설립 연도, 산업 분류)를 추가한 뒤 QID를 획득하면 된다. Google Knowledge Graph는 Wikipedia 외에 Wikidata, Crunchbase 등 복수 외부 그래프를 참조하므로 Wikidata 연결만으로도 Knowledge Panel 생성 가능성이 높아진다. 단, 검증 가능한 외부 출처(언론 보도·법인 등록·특허)를 Wikidata reference로 첨부하지 않으면 항목이 삭제될 수 있다.

구조화 데이터(Structured Data)에 대한 Google의 공식 입장은 단순하지 않다. Google은 JSON-LD 기반 Schema.org 마크업을 적극 권장하면서도, 동시에 "구조화 데이터는 core 검색 순위(ranking) 신호가 아니다"라고 명시한다. 이 간극이 실무에서 혼란을 만든다. 정확히 말하면: 구조화 데이터는 blue-link 순위에 직접 영향을 주지 않으나, Rich Results 자격 요건으로 작동하고, AI Overviews의 RAG 파이프라인에서는 엔티티 식별 신호로 별도 기능한다. 2024년 AI Overviews 전면 도입 이후 이 구분은 더욱 실무적으로 중요해졌다.

Google의 공식 입장: 순위 신호 vs 자격 신호

Google Search Central 공식 문서는 구조화 데이터의 기능을 두 가지로 분리한다.

Rich Results 자격(eligibility): FAQ 패널, 별점 카드, How-to 캐러셀, 사이트링크 검색창 등의 서식 결과를 표시하려면 해당 Schema.org 타입이 페이지에 정확히 마크업되어야 한다. Google의 파이프라인은 schema 존재 여부로 자격 후보 풀을 먼저 필터링하고, 그다음 콘텐츠 품질을 평가한다.
순위 비신호: 2023년 Gary Illyes(Google) 발언 기준, JSON-LD 추가 자체는 blue-link 순위에 직접 가중치를 주지 않는다. Rich Results로 노출되면 CTR이 높아지고 이 CTR 신호가 간접적으로 품질 신호로 기능할 수 있으나, 이는 구조화 데이터 자체의 효과가 아닌 파생 효과다.

Googlebot의 JSON-LD 파싱 메커니즘

Googlebot이 페이지를 크롤링할 때 HTML 파싱과 별도로 <script type="application/ld+json"> 블록을 추출한다. 이 과정은 JavaScript 렌더링(Second Wave) 이전 단계에서 발생하므로, CSR(Client-Side Rendering) 환경에서도 JSON-LD는 서버에서 초기 HTML에 포함시켜야 한다. 파싱된 구조화 데이터는 두 경로로 분기한다.

Knowledge Graph 보강: Organization, Person, Place, Product 타입은 sameAs 속성을 통해 Wikidata·Wikipedia 노드와 연결되며 Google Knowledge Graph에 반영된다. 이 연결이 엔티티 권위를 결정한다.
Rich Results 파이프라인: 파싱된 schema 타입이 Google 지원 목록에 있으면 eligibility queue에 진입하고, 이후 콘텐츠 품질 심사를 거쳐 서식 결과로 노출된다.

실제 JSON-LD 예시: Article + Person + Organization 조합

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "구조화 데이터, 구글은 정말 추천하지 않을까",
  "description": "Google AI Overviews RAG 파이프라인에서 구조화 데이터의 역할 분석",
  "datePublished": "2026-06-18T09:00:00+09:00",
  "dateModified": "2026-06-18T09:00:00+09:00",
  "author": {
    "@type": "Person",
    "name": "이서연",
    "url": "https://citeon.co.kr/authors/seoyeon-lee",
    "jobTitle": "GEO 전략 리드",
    "knowsAbout": ["생성형 검색 최적화", "AEO", "구조화 데이터"],
    "affiliation": {
      "@type": "Organization",
      "name": "Citeon"
    }
  },
  "publisher": {
    "@type": "Organization",
    "name": "Citeon",
    "url": "https://citeon.co.kr",
    "logo": {
      "@type": "ImageObject",
      "url": "https://citeon.co.kr/logo.png"
    },
    "sameAs": [
      "https://www.wikidata.org/wiki/Q_EXAMPLE"
    ]
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://citeon.co.kr/blog/structured-data-google"
  }
}
</script>

핵심 포인트: sameAs에 Wikidata URL을 넣으면 Google이 해당 엔티티를 Knowledge Graph 노드와 연결할 수 있다. author.knowsAbout과 jobTitle은 E-E-A-T의 Expertise 신호를 기계가 읽을 수 있는 형태로 제공한다.

AI Overviews와 구조화 데이터: GEO 관점

Google AI Overviews는 Gemini 모델이 색인 코퍼스에서 청크를 검색(Retrieve)하고 합성(Generate)하는 RAG 파이프라인으로 동작한다. 구조화 데이터는 이 파이프라인에서 다음 세 가지 역할을 한다.

엔티티 명확화(Entity Disambiguation): "구글"이 검색엔진인지 알파벳 자회사인지 RAG가 판단할 때, Organization schema의 legalName·sameAs가 ambiguity를 해소한다. LLM이 청크를 scoring할 때 엔티티가 명확한 문서를 선호하기 때문이다.
저자 자격 신호(Author Credential): Person schema의 jobTitle·knowsAbout·affiliation은 E-E-A-T의 Experience·Expertise 신호를 구조화된 형태로 제공한다. 비구조화 바이오 텍스트보다 RAG 인덱서가 더 높은 confidence로 파싱한다.
FAQPage schema → 직접 인용 가능성: FAQPage의 acceptedAnswer.text는 질문-답변 쌍이 명확히 구조화되어 있어 AI Overviews의 인용 청크로 추출되기 쉬운 형태다. 동일한 내용이 산문 형태일 때보다 인용 확률이 추정상 높다.

검증 및 측정 방법

Rich Results Test: URL 또는 코드를 입력해 Google이 파싱하는 schema 타입과 오류를 확인한다. @type 인식 여부, 필수 필드 누락, 경고 항목을 JSON 형태로 반환한다.
Search Console 서식 결과 보고서: 유효·오류·경고 URL 수, 노출수, 클릭수를 schema 타입별로 확인한다. "유효" 상태여도 Rich Results로 실제 노출되려면 콘텐츠 품질 기준을 추가로 통과해야 한다.
Schema Markup Validator: Google 독립적으로 schema.org 명세 준수 여부를 검증한다. Google이 지원하지 않는 확장 타입도 명세 오류 여부 확인이 가능하다.

SEO·AEO·GEO 맥락별 구조화 데이터 역할 비교

관점	구조화 데이터의 역할	핵심 schema 타입	효과 측정 위치
SEO (기존 검색)	Rich Results 자격 요건; 순위 비신호	Product, Review, FAQPage, HowTo, BreadcrumbList	Search Console 서식 결과 보고서
AEO (답변 엔진)	질문-답변 구조 명확화; Featured Snippet 인용 가능성 증가	FAQPage, QAPage, HowTo	Featured Snippet 노출 추적 (Search Console CTR)
GEO (생성형 AI 검색)	엔티티 권위 강화; 저자 자격 신호; 인용 청크 품질 향상	Article, Person, Organization(sameAs), Speakable	AI Overviews 인용 모니터링(수동 검색 추적)

흔한 오해: "구조화 데이터 추가 = 순위 상승"

가장 빈번한 실무 오해는 JSON-LD를 페이지에 삽입하면 즉시 검색 순위가 오른다는 가정이다. Google은 이를 명시적으로 부인한다. 구조화 데이터가 순위에 영향을 주는 경로는 간접적이다: JSON-LD 추가 → Rich Results 자격 획득 → 서식 결과 노출 → CTR 증가 → 품질 신호 간접 기여. 이 경로에서 Rich Results 노출 자체가 보장되지 않으며, 노출되더라도 CTR 개선이 항상 발생하지 않는다. 올바른 접근: 구조화 데이터를 "순위 도구"가 아닌 "특정 기능 자격 요건 충족 도구"로 정의하고, KPI를 Rich Results 노출수·서식 결과 CTR로 분리 측정한다. GEO 맥락에서는 AI Overviews 인용 여부를 별도 추적한다.

Q. JSON-LD와 Microdata 중 어느 것을 써야 하는가?

Google은 공식 문서에서 JSON-LD를 권장 구현 방식으로 명시한다(2024년 기준). 이유는 두 가지다. 첫째, HTML 콘텐츠와 마크업이 분리되어 유지보수가 단순하다. 둘째, SPA·Next.js 등 JavaScript 렌더링 환경에서 <script> 태그로 서버사이드 동적 삽입이 가능하다. Microdata는 HTML 속성에 직접 삽입되므로 콘텐츠 변경 시 마크업도 함께 수정해야 하는 결합도 문제가 있다. 기존 Microdata가 이미 운영 중인 사이트라면 전면 교체보다 JSON-LD 병행 삽입(Google은 두 방식 동시 허용)이 현실적인 전환 경로다.

Q. Wikidata 항목이 없는 신규 브랜드는 sameAs를 어떻게 처리해야 하는가?

Wikipedia 등재 없이도 Wikidata에 엔티티 항목을 직접 생성하고 해당 QID URL을 sameAs에 넣을 수 있다. Wikidata는 편집 개방형이므로 브랜드 기본 정보(공식 URL, 설립 연도, 산업 분류)를 추가한 뒤 QID를 획득하면 된다. Google Knowledge Graph는 Wikipedia 외에 Wikidata, Crunchbase 등 복수 외부 그래프를 참조하므로 Wikidata 연결만으로도 Knowledge Panel 생성 가능성이 높아진다. 단, 검증 가능한 외부 출처(언론 보도·법인 등록·특허)를 Wikidata reference로 첨부하지 않으면 항목이 삭제될 수 있다.

참고 자료

이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.