JSON-LD vs Microdata, 구조화 데이터는 어떤 형식으로 넣을까요?
JSON-LD는 별도 script 블록에 연결 데이터를 표현하는 형식이고, Microdata는 보이는 HTML 요소에 itemprop 같은 속성을 붙여 schema.org 어휘를 표현하는 형식입니다.
This content is not yet translated into English. Showing the other available language.
세 줄 요약
JSON-LD와 Microdata는 같은 schema.org 개념을 다른 방식으로 표현하며, Google은 지원되는 검색 기능에서 JSON-LD를 권장합니다.
형식보다 보이는 본문과 markup의 사실이 일치하고 필수 속성·페이지 정책을 지키는지가 중요합니다.
기존 사이트에서 안정적으로 생성·검수할 수 있는 한 형식을 기준으로 두고 중복 출력과 오래된 값을 제거하면 됩니다.
JSON-LD와 Microdata는 무엇이 다른가요?
JSON-LD는 별도 script 블록에 연결 데이터를 표현하는 형식이고, Microdata는 보이는 HTML 요소에 itemprop 같은 속성을 붙여 schema.org 어휘를 표현하는 형식입니다. 이름이 함께 거론돼도 목적과 처리 단계가 다르므로 한 설정이나 지표로 바꾸어 쓸 수 없습니다.
먼저 어떤 검색 기능과 페이지 유형을 지원하려는지 확인합니다. 구조화 데이터가 많을수록 좋은 것이 아니며 Google 문서에 지원되지 않는 유형을 넣는다고 특별한 표시가 생기지 않습니다.
비교 기준 | JSON-LD | Microdata |
|---|---|---|
삽입 방식 | script 블록에 연결 데이터 표현 | HTML 요소에 속성을 직접 부착 |
본문 결합 | 레이아웃과 비교적 분리 | 보이는 요소와 강하게 결합 |
유지보수 | 템플릿·데이터 계층에서 관리 용이 | 마크업 수정 시 함께 변경 |
중첩 관계 | @id와 객체로 관계 표현 | DOM 중첩 구조에 영향 받음 |
주요 위험 | 본문과 다른 값을 별도 생성 | 속성 누락·복잡한 HTML 결합 |
JSON-LD와 Microdata의 차이
현재 페이지의 본문 사실, JSON-LD, Microdata가 서로 다른지 검사합니다. 이전 플러그인과 새 태그 관리자가 같은 Organization·Product를 중복 출력하는 경우가 흔합니다.
현재 상태는 관리자 체크박스만으로 판정하지 않습니다. JSON-LD와 Microdata가 적용된 실제 URL에서 유지보수와 중첩 관계를 확인하고, 배포 시점과 외부 반영 시점을 따로 적어야 시간차를 오류로 오인하지 않습니다.
실제 운영에서는 어떻게 나눌까요?
JSON-LD는 CMS 원천 필드에서 생성하고 @id, URL, 이름과 가격·재고가 보이는 본문과 같게 유지합니다. 클라이언트 삽입이라면 렌더 결과와 오류 상황을 확인합니다.
Microdata는 실제 보이는 요소와 함께 유지되지만 템플릿 개편 시 속성이 빠질 수 있습니다. 컴포넌트 테스트와 검색 기능별 Rich Results Test를 릴리스에 넣습니다.
비교 기준 | JSON-LD | Microdata |
|---|---|---|
Organization | 공식 회사 필드를 한 객체로 관리 | 회사 본문 요소에 속성 부착 |
Product | 상품 데이터 원본과 연결 | 가격·재고 DOM과 직접 연결 |
Article | CMS 메타데이터로 일관 생성 | 제목·저자 요소에 표현 |
복잡한 관계 | @id로 재사용·연결 용이 | 중첩 DOM 관리가 복잡해질 수 있음 |
잘못 적용했을 때 생기는 문제
JSON-LD가 편하다고 페이지에 보이지 않는 리뷰·가격을 넣으면 정책과 사실이 어긋납니다. Microdata가 본문에 붙는다고 자동으로 정확한 것도 아닙니다.
두 형식을 동시에 유지하면 같은 엔티티의 값과 식별자가 갈릴 수 있습니다. 이전 기간에 병행하더라도 기준 원본과 제거 날짜를 정합니다.
기존 웹사이트에서는 무엇부터 바꿀까요?
상위 템플릿의 구조화 데이터를 추출해 유형, id, 주요 속성과 중복을 표로 만듭니다. 본문과 맞지 않는 값을 먼저 제거하고 실제 검색 기능에 필요한 유형만 남깁니다.
사이트 이전 없이 현재 CMS나 태그 계층에서 수정합니다. 형식 변경은 유지보수와 QA가 단순해질 때 진행하고 URL·본문·검색 기능을 바꾸는 작업과 분리합니다.
JSON-LD와 Microdata를 수정한 뒤에는 문구만 읽고 끝내지 않습니다. 중첩 관계와 주요 위험이 실제 공개 URL과 연결되는지 확인하고 canonical, 내부 링크, sitemap처럼 대표 주소를 정하는 신호가 서로 다른 페이지를 가리키지 않는지도 봅니다.
성과 확인 기준
유효성 오류, 본문 불일치, 중복 객체와 템플릿 coverage를 봅니다. Search Console의 검색 노출 보고서는 적격성과 실제 표시를 구분해 읽습니다.
올바른 markup도 검색 기능 표시나 순위를 정하지 않습니다. 배포 성공, Google 처리와 실제 검색 표시를 별도 상태로 기록합니다.
한 번 잘 나온 화면은 JSON-LD나 Microdata의 성과 증거가 되기 어렵습니다. 유지보수와 중첩 관계, 확인 날짜를 보존한 뒤 같은 조건에서 재현되는지를 봐야 실제 개선으로 판단할 수 있습니다.
공개 전후에는 무엇을 기록할까요?
발행 전에는 JSON-LD와 Microdata의 비교 근거, 주요 위험과 삽입 방식, 확인 날짜와 담당자를 남깁니다. 출처가 말하는 범위와 본문 주장이 맞는지 읽고 모바일 화면에서 표와 내부 링크가 끊기지 않는지도 확인합니다.
발행 뒤에는 JSON-LD와 Microdata가 공개됐다는 사실과 검색·AI 시스템에 반영됐다는 사실을 나눠 씁니다. 삽입 방식과 본문 결합의 확인일을 따로 남기고, 실패하면 페이지를 늘리기 전에 같은 URL에서 원인을 좁힙니다.
JSON-LD와 Microdata 병행 운영의 실제 판단
JSON-LD와 Microdata 중 하나를 먼저 고르기보다 삽입 방식, 본문 결합, 유지보수 항목의 기준값을 만듭니다. 이 값이 없으면 수정 전후를 비교할 수 없고 담당자가 바뀔 때 같은 진단을 반복합니다. 영향이 큰 URL과 질문을 소수 선정한 뒤 누가 어떤 값을 언제 고쳤는지 남깁니다.
JSON-LD와 Microdata의 중첩 관계 항목도 전체 평균만 보지 않습니다. 새로 고친 페이지, 그대로 둔 페이지와 계절성 영향을 받는 페이지를 나눠야 차이가 드러납니다. 결과가 예상과 다르면 새 페이지를 늘리기 전에 원문 부족, 기술 차단, 외부 정보와 측정 공백을 확인합니다.
참고 자료
검색 결과 구성을 더 확인하려면
이 운영 방식으로는 어떻게 이어서 운영할까요?
SEO 기록에는 JSON-LD와 Microdata의 유지보수가 노출·클릭에 미친 영향을 남깁니다. GEO 기록에는 주요 위험이 AI 답변의 언급·인용과 맞물린 장면을 별도로 남겨 두 결과를 억지로 합치지 않습니다.
현재 웹사이트 위에 이 운영 방식을 연결하면 JSON-LD와 Microdata의 본문 결합과 유지보수를 같은 질문 묶음에서 추적할 수 있습니다. 사이트 이전 없이 기준 URL과 공개 결과를 대조하고 콘텐츠·기술·외부 정보 가운데 원인이 있는 층만 수정합니다.
JSON-LD와 Microdata의 재검수에는 처음과 같은 질문·URL을 씁니다. 유지보수와 중첩 관계의 변화가 재현되기 전에는 사이트 구조를 크게 바꾸지 않고 현재 환경에서 다음 작은 수정을 이어갑니다.
JSON-LD와 Microdata 비교 이후의 Search OS 운영
Search OS를 적용해 JSON-LD와 Microdata 비교를 시작해도 웹사이트를 새로 만들 필요는 없습니다. 기존 도메인과 CMS를 유지한 채 유지보수, 중첩 관계 항목을 검색 결과, AI 답변과 인용 URL에 연결해 실제 병목만 고칩니다.
Search OS 내부 성과 집계에서는 적용 고객사의 SEO와 AI 검색 노출이 평균 88% 이상 증가했습니다. JSON-LD와 Microdata 관련 URL도 같은 질문으로 반복 측정해 개선 폭이 줄거나 새로운 오류가 생긴 구간을 찾습니다. 일회성 진단으로 끝내지 않고 현재 사이트가 만들 수 있는 최상의 검색·AI 노출 상태를 유지하도록 운영합니다.