한 가지만 기억한다면 이것이면 충분합니다. AI 엔진이 내용을 명확히 읽고 인용하게 하려면 JSON-LD를 사용하세요. 동일한 schema.org 마크업을 Microdata나 RDFa로 작성해도 Google이 거부하지는 않습니다. 다만 AI 크롤러는 HTML 곳곳에 흩어진 속성을 다시 모아 하나의 엔티티로 조합해야 합니다. 단계가 하나 늘어날 때마다 누락되거나 잘못 해석될 가능성도 커집니다.
세 형식이 표현하는 어휘 체계는 같습니다
먼저 자주 혼동하는 부분부터 짚겠습니다. JSON-LD, Microdata, RDFa는 서로 다른 세 가지 데이터가 아니라 schema.org 어휘를 웹페이지에 작성하는 세 가지 문법입니다. 표시하려는 엔티티는 모두 같습니다. Organization, Product, Article, FAQPage, HowTo 역시 어느 형식에서나 같은 어휘입니다. 차이는 속성을 어디에, 어떤 형태로 담느냐에 있습니다. Schema.org는 세 형식을 모두 공식 지원하며 Google도 모두 파싱할 수 있습니다. 따라서 이 글의 비교 기준은 ‘사용할 수 있는가’가 아니라 ‘기계가 얼마나 쉽게 읽을 수 있는가’입니다.
핵심 차이: 구조화 데이터와 HTML의 결합 방식
세 형식의 가장 중요한 차이는 구조화 데이터가 HTML에 얼마나 밀접하게 결합되어 있느냐입니다. Microdata는 itemscope, itemtype, itemprop 속성을 div, span, h1 같은 HTML 요소에 단계별로 추가해 마크업합니다. RDFa도 비슷한 방식으로 기존 태그에 vocab, typeof, property 등의 속성을 넣어 의미를 표현합니다. 의미 표현력은 더 풍부하지만 문법도 그만큼 복잡합니다. JSON-LD는 정반대입니다. 엔티티 전체를 독립된 JSON으로 작성한 뒤 type이 application/ld+json인 script 태그에 넣으며, 화면에 표시되는 HTML과 분리합니다.
- JSON-LD: 엔티티를 완결된 JSON 객체로 작성해 script 태그 안에 모아 둡니다. 레이아웃과 분리되어 유지보수와 프로그래밍이 가장 쉽고, Google이 명확히 우선 권장하는 형식이기도 합니다.
- Microdata: itemscope, itemprop 등의 속성을 화면에 보이는 HTML에 삽입합니다. 마크업이 콘텐츠와 결합되어 있어 레이아웃을 변경할 때 속성이 손상되기 쉽습니다.
- RDFa: vocab, typeof, property 속성을 HTML에 삽입합니다. 의미 표현력이 가장 뛰어나고 W3C의 연결 데이터 이상에 가깝지만, 문법이 가장 복잡해 오류도 발생하기 쉽습니다.
AI 크롤러가 JSON-LD를 선호하는 이유
AI 크롤러가 JSON-LD를 더 쉽게 읽는 이유는 명확합니다. 하나의 엔티티가 완결된 JSON 객체이며 필드, 값, 중첩 관계가 모두 같은 블록 안에 들어 있기 때문입니다. 파서가 이를 읽으면 곧바로 정돈된 객체 트리가 되므로 전체 DOM을 다시 훑을 필요가 없습니다. 반면 Microdata와 RDFa는 전체 HTML을 순회하면서 서로 다른 태그에 흩어진 속성을 하나씩 수집한 뒤, 중첩 관계에 따라 엔티티를 재구성해야 합니다. 페이지가 복잡하고 레이아웃 계층이 깊을수록 재구성 과정에서 오류가 발생할 가능성도 높아집니다.
실무에서는 두 가지 요인이 이 차이를 더 벌립니다. 첫째는 JavaScript 렌더링입니다. 많은 AI 크롤러는 Googlebot보다 보수적으로 JS를 실행합니다. 프런트엔드 프레임워크가 Microdata를 DOM에 동적으로 삽입한다면 크롤링 시점에 마크업이 아직 생성되지 않았을 수 있습니다. 반면 JSON-LD는 서버에서 완성된 문자열로 출력하는 방식이 일반적이므로 수집 즉시 사용할 수 있습니다. 둘째는 유지보수 비용입니다. JSON-LD는 한곳에 모여 있어 FAQPage를 새로 추가하거나 제품 가격을 바꿀 때 JSON 한 블록만 수정하면 되며 레이아웃에는 영향을 주지 않습니다. 인라인 마크업은 화면을 개편할 때마다 속성이 이동하거나 삭제되지 않았는지 다시 확인해야 합니다.
Microdata와 RDFa는 여전히 유효할까요?
그렇다고 Microdata와 RDFa가 잘못된 형식이라는 뜻은 아닙니다. 오래된 CMS나 이커머스 테마를 사용한다면 기본 구조화 마크업이 Microdata일 가능성이 높습니다. 정상적으로 작동한다면 굳이 바꿀 필요는 없습니다. RDFa는 공공 개방 데이터나 학술 출판처럼 여러 어휘 체계에 걸쳐 복잡한 연결 데이터를 표현해야 하는 상황에서 여전히 가치가 있습니다. 다만 ‘AI 엔진에 인용되는 것’이 구체적인 목표라면 두 형식의 장점은 거의 활용되지 못하고 단점은 더 두드러집니다.
JSON-LD로 이전할 때 먼저 피해야 할 실수
- 마크업과 화면 콘텐츠가 일치하지 않음: JSON-LD에 작성한 평점, 가격, 작성자는 사용자가 실제로 보는 콘텐츠와 같아야 합니다. 일치하지 않으면 스팸으로 판단될 수 있습니다.
- script는 있지만 필수 필드가 누락됨: 예를 들어 Product에 name이나 offers가 없거나 FAQPage의 질문에 해당 답변이 없으면 기계가 엔티티 전체를 건너뛸 수 있습니다.
- @id로 엔티티를 연결하지 않음: Organization, WebSite, Article이 서로 관련되어 있다면 @id로 참조 관계를 설정하세요. AI가 더 완전한 브랜드 지식 지도를 구성하는 데 도움이 됩니다.
- 검증 없이 배포함: 배포 후 Search Console에서 오류를 찾는 것보다 사전에 Google 리치 결과 테스트나 schema.org 검사기로 확인하는 편이 훨씬 빠릅니다.
놓치기 쉬운 중요한 원칙이 있습니다. 구조화 데이터의 목적은 기계를 속이는 것이 아니라, 기계가 화면에서 읽은 내용을 확인하도록 돕는 데 있습니다. 가장 안정적인 방법은 JSON-LD가 화면에 보이는 콘텐츠를 그대로 반영하도록 만드는 것입니다. 화면에 있는 내용만 마크업에 작성하고, 마크업에 선언한 모든 내용은 화면에서도 확인할 수 있어야 합니다. 이러한 일관성은 AI 엔진이 페이지의 신뢰도와 인용 가치를 판단하는 기반입니다.
구조화 데이터가 빈약한 콘텐츠를 인용할 만한 페이지로 바꿔 주지는 않습니다. 본래 역할은 인용할 가치가 있는 페이지가 기계의 이해 부족으로 누락되지 않도록 하는 것입니다.— Tenten GEO Technical Audit Team
웹사이트 점검 방법
자사 웹사이트로 돌아가 다음 세 가지부터 확인해 보세요. 주요 페이지는 어떤 형식을 사용하고 있습니까? 동일한 엔티티가 중복 마크업되어 있습니까? JSON-LD 필드는 화면 콘텐츠와 일치합니까? 대다수 B2B SaaS 웹사이트의 구조화 데이터는 여러 시기와 외주 작업을 거치며 누적됩니다. 형식이 뒤섞이거나 필드가 빠지는 일도 흔합니다. AI 엔진에는 이런 빈틈 하나하나가 해당 페이지를 건너뛸 이유가 됩니다. AI 크롤러가 자사 웹사이트를 어떻게 보고 있는지, 어떤 엔티티를 놓치고 있는지 알고 싶다면 30분 GEO 진단을 예약하세요. 실제 페이지를 함께 보며 직접 점검해 드립니다.
