구조화 데이터는 AI 검색에 정말 효과가 있나요?
먼저 기대치를 정확히 잡는 것부터 시작하겠습니다. schema.org 구조화 데이터는 AI 노출의 전제가 아니라 보조 신호입니다. 실제로 인용 여부를 좌우하는 것은 robots.txt에서 AI 봇을 허용했는지, 본문이 서버 렌더링으로 HTML에 실려 나오는지, 그리고 그 본문이 발췌하기 좋은 형식인지입니다. 이 세 가지가 비어 있으면 마크업을 아무리 정교하게 붙여도 인용될 재료 자체가 없습니다.
그럼에도 구조화 데이터를 챙기는 이유는 그 위에 얹는 마감재이기 때문입니다. schema.org는 검색 인덱스가 페이지를 정확히 분류하고 엔티티를 명확히 하는 데 기여하고, 그 인덱스를 원료로 쓰는 AI 검색 답변에 간접적으로 작용합니다. 특히 브랜드명이 동명의 다른 대상과 충돌할 때, "이 이름은 이 도메인의 이 사업"이라는 연결을 기계가 읽을 수 있게 남기는 거의 유일한 정형 수단입니다. 파일이나 코드 한 덩어리로 끝나는 저비용 작업이라, 앞의 세 전제를 갖춘 사이트라면 붙여 두는 손해가 거의 없습니다.
이 글은 그 마감재를 실제 코드로 정리합니다. 어떤 타입부터, 어떻게 넣고, 무엇을 착각하면 안 되는지를 다룹니다.
JSON-LD가 무엇이고 왜 이 형식을 쓰나요?
구조화 데이터를 페이지에 심는 방식은 세 가지입니다. 태그 속성에 심는 Microdata와 RDFa, 그리고 본문과 분리된 스크립트 블록으로 넣는 JSON-LD입니다. 결론부터 말하면 JSON-LD를 권장합니다. 구글이 공식적으로 권장하는 형식이고(Google 구조화 데이터 소개), 본문 HTML 구조를 건드리지 않는 한 덩어리로 관리되기 때문입니다.
방식별 차이를 정리하면 다음과 같습니다.
| 방식 | 심는 위치 | 관리 난이도 |
|---|---|---|
| JSON-LD | <script type="application/ld+json"> 블록 하나 |
낮음 (본문과 분리) |
| Microdata | 각 HTML 태그에 itemprop 속성 삽입 | 높음 (본문 구조와 얽힘) |
| RDFa | 각 HTML 태그에 property 속성 삽입 | 높음 (본문 구조와 얽힘) |
JSON-LD는 페이지 어디에 두어도 되지만, 보통 <head> 안이나 <body> 끝에 스크립트 블록으로 넣습니다. 본문 마크업과 섞이지 않으므로, 디자인을 바꿔도 구조화 데이터가 깨지지 않습니다. 이 글의 예시는 모두 JSON-LD로 씁니다.
어떤 schema.org 타입부터 넣어야 하나요?
schema.org에는 수백 개의 타입이 있지만, AI 검색 노출 관점에서 우선순위가 높은 것은 소수입니다. 각 타입이 AI에게 무엇을 알려주는지를 기준으로 추리면 다음과 같습니다.
| 타입 | AI에게 알려주는 것 | 우선순위 |
|---|---|---|
| Organization | 브랜드명·도메인·공식 프로필의 연결(신원) | 1순위 (모든 사이트) |
| FAQPage | 질문과 답변 쌍의 경계 | 1순위 (FAQ가 있으면) |
| Article / BlogPosting | 글의 제목·발행일·작성자(최신성·신원) | 1순위 (블로그·가이드) |
| LocalBusiness | 위치·영업시간·연락처 | 지역 사업 필수 |
| Product | 상품명·가격·재고·평점 | 커머스 필수 |
| BreadcrumbList | 사이트 내 페이지의 위계 | 보조 |
핵심 원칙 하나만 기억하면 됩니다. 화면에 실제로 있는 정보만 마크업합니다. 사용자가 페이지에서 볼 수 없는 FAQ를 FAQPage에 넣거나, 본문과 다른 가격을 Product에 적으면 스팸으로 간주됩니다. 마크업은 본문을 기계가 읽기 쉽게 번역하는 자리이지, 본문에 없는 내용을 지어내는 자리가 아닙니다.
Organization — "이 이름은 이 도메인의 이 사업"
브랜드명이 흔한 단어이거나 동명의 다른 회사·제품이 있으면, AI는 문서가 더 많은 쪽을 그 이름의 주인으로 답합니다. 이 엔티티 충돌을 정형 신호로 완화하는 것이 Organization 마크업입니다. 핵심은 name·url과 함께 sameAs에 공식 프로필 링크를 나열해, "이 브랜드는 여기저기서 같은 실체로 등장한다"를 기계가 잇게 하는 것입니다.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "GEO Doctor",
"url": "https://geodoctor.io",
"description": "한국 브랜드를 위한 AI 검색 노출 무료 진단 도구",
"sameAs": [
"https://www.threads.net/@브랜드공식계정",
"https://www.linkedin.com/company/브랜드공식계정"
]
}
sameAs에는 브랜드가 공식으로 운영하는 프로필만 넣습니다. 위키피디아 문서가 있다면 그 링크가 특히 강한 신원 신호가 되지만, 없는 문서를 지어낼 수는 없습니다. 이 마크업은 사이트의 대표 페이지(보통 홈)에 한 번 두면 충분합니다. 브랜드명 단독이 흔한 단어라면, 마크업의 description에도 카테고리 수식어("AI 검색 노출 진단 도구")를 같은 표기로 반복해 두는 것이 충돌 완화에 도움이 됩니다.
FAQPage — 질문-답변을 통째로 발췌 가능하게
AI는 답변을 조립할 때 그대로 뽑아 쓸 수 있는 단위를 선호합니다. FAQ는 그 자체로 "질문 하나에 답변 하나"라는 발췌 단위를 갖고 있어, 경계를 기계에 명시하면 통째로 인용되기 좋습니다. FAQPage 마크업은 그 경계를 표시합니다.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "구조화 데이터만 넣으면 AI에 인용되나요?",
"acceptedAnswer": {
"@type": "Answer",
"text": "아니요. schema.org 마크업은 보조 신호이지 전제가 아닙니다. 실제 노출은 robots.txt 허용과 서버 렌더링, 콘텐츠 형식이 좌우합니다."
}
},
{
"@type": "Question",
"name": "JSON-LD와 Microdata 중 무엇을 쓰나요?",
"acceptedAnswer": {
"@type": "Answer",
"text": "JSON-LD를 권장합니다. 구글이 공식 권장하는 형식이고 본문 구조와 분리되어 관리가 쉽습니다."
}
}
]
}
주의할 점은 마크업의 text가 화면 본문의 답변과 일치해야 한다는 것입니다. 화면에는 없는 답변을 마크업에만 넣으면 규칙 위반입니다. 그래서 FAQPage는 실제로 FAQ 섹션이 노출되는 페이지에만 붙입니다. 답변 문장은 앞뒤 문맥 없이 떼어 읽어도 성립하도록 자기완결형으로 쓰는 것이 인용에 유리합니다.
Article / BlogPosting — 글의 신원과 최신성
블로그나 가이드 글에는 Article(또는 하위 타입 BlogPosting)을 붙여 제목·발행일·수정일·작성자를 명시합니다. 특히 datePublished와 dateModified가 중요합니다. AI 인용은 최신성 편향이 강해 오래된 문서가 인용 자리에서 밀려나는데, 수정일을 정직하게 갱신해 두면 그 글이 관리되고 있다는 신호가 됩니다.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "AI 검색에 인용되는 구조화 데이터 — schema.org JSON-LD 실전 가이드",
"datePublished": "2026-08-06",
"dateModified": "2026-08-06",
"author": { "@type": "Organization", "name": "GEO Doctor" },
"publisher": { "@type": "Organization", "name": "GEO Doctor" },
"mainEntityOfPage": "https://geodoctor.io/blog/schema-org-json-ld-geo-guide"
}
dateModified를 실제 갱신 없이 날짜만 미래로 바꾸는 것은 권하지 않습니다. 본문 내용은 그대로인데 날짜만 새것으로 표시하면 신뢰 신호가 아니라 조작 신호가 됩니다. 수치나 사례를 실제로 손볼 때 함께 갱신하는 것이 원칙입니다.
LocalBusiness와 Product는 언제 쓰나요?
지역 기반 사업이라면 LocalBusiness가 지역 질문("○○동 필라테스 어디가 좋아?")과의 매칭에 직접 작용합니다. 위치(address), 영업시간(openingHours), 연락처(telephone)를 담아 두면, AI가 지역 질의에 답을 만들 때 이 정보를 근거로 쓰기 쉽습니다. 커머스라면 Product에 상품명·가격(offers)·평점(aggregateRating)을 담아 "얼마야?" 같은 질문의 직답 재료를 제공합니다.
두 타입 모두 같은 원칙이 적용됩니다. 화면 본문에 실제로 있는 값만 넣고, 값이 바뀌면 마크업도 함께 바꿉니다. 존재하지 않는 평점을 aggregateRating에 적는 것은 스팸이며, 적발되면 마크업 전체의 신뢰가 무너집니다.
구조화 데이터가 인용을 보장하지 않는 이유
여기까지 정리하면 마크업이 만능처럼 보일 수 있지만, 세 가지 한계를 분명히 해야 합니다.
첫째, 본문 우선입니다. schema.org는 본문을 번역하는 신호일 뿐, 본문이 부실하면 번역할 원문이 없습니다. 검증 가능한 통계·수치, 출처가 명시된 인용, 명확한 구조화를 더한 콘텐츠가 AI 답변 인용 가시성을 30~40% 높였다는 연구(Princeton GEO 연구, Aggarwal et al., KDD 2024)는 마크업이 아니라 본문 형식을 말합니다. 마크업은 그 본문 위의 마감재입니다.
둘째, 일치 원칙입니다. 마크업 내용은 화면 본문과 정확히 같아야 합니다. 어긋나면 도움이 아니라 감점 요인이 됩니다.
셋째, 간접성입니다. 주요 AI 엔진이 schema.org를 공식적으로 읽어 답변에 반영한다고 확인된 바는 없습니다. 마크업의 효과는 검색 인덱스의 분류·엔티티 명확화를 거쳐 간접적으로 나타납니다. 그래서 "마크업을 붙였으니 인용될 것"이 아니라 "인덱스가 우리를 더 정확히 이해하도록 도왔다" 정도로 기대치를 잡는 것이 정확합니다.
마크업을 넣은 다음, 무엇을 확인해야 할까요?
구조화 데이터는 넣고 끝나는 것이 아니라 검증까지가 한 세트입니다. 순서는 다음과 같습니다.
| 단계 | 확인할 것 |
|---|---|
| 1. 문법 검증 | JSON-LD가 문법 오류 없이 파싱되는가 (구글 리치 결과 테스트 등) |
| 2. 본문 일치 | 마크업의 값이 화면 본문과 같은가 |
| 3. 전제 점검 | robots.txt가 AI 봇을 허용하고 본문이 서버 렌더링되는가 |
| 4. 실측 | AI 엔진이 실제로 브랜드를 언급·인용하는가 |
1번과 2번은 오늘 직접 할 수 있고, 3번은 llms.txt와 robots.txt AI 봇 설정에서 다룬 기술 전제입니다. 그리고 이 모든 작업의 효과는 4번에서만 드러납니다. 마크업을 정확히 붙이고 전제를 갖췄어도, 실제 AI 답변에 변화가 없다면 병목은 다른 곳에 있습니다.
측정할 수 없으면 최적화할 수 없습니다. 구조화 데이터를 손보기 전에도, 손본 뒤에도, 지금 내 브랜드가 ChatGPT·Perplexity·Gemini·네이버 AI 브리핑 4개 엔진에서 언급되는지, 내 도메인이 출처로 인용되는지부터 실측으로 확인해야 우선순위를 정할 수 있습니다. 내 브랜드가 지금 어디에 서 있는지는 GEO Doctor 무료 진단으로 약 3분 만에 확인할 수 있습니다.