JSON-LD는 데이터의 의미와 대상 간 관계를 JSON 문법으로 표현하는 형식입니다. W3C가 표준으로 정했습니다. 웹페이지에서는 주로 <script type="application/ld+json"> 안에 Schema.org 유형과 속성을 적어 페이지의 구조화 데이터를 제공합니다.
JSON과 JSON-LD의 차이
JSON은 이름과 값의 쌍, 배열 등으로 데이터를 표현하는 문법입니다. JSON-LD는 여기에 각 항목을 어떤 의미로 읽어야 하는지 정하는 규칙을 더합니다. @context는 용어의 의미를 정의하고, @type은 대상의 유형을, @id는 대상을 구별하는 식별자를 나타냅니다.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "AVCD",
"url": "https://avcd.kr"
}
예시의 @context는 Schema.org의 어휘로 데이터를 해석하라는 뜻입니다. @type의 Organization은 조직을 나타내고, name과 url은 그 조직의 이름과 웹사이트 주소를 설명합니다.
Microdata보다 관리하기 쉬운 이유
Microdata는 본문의 HTML 요소마다 itemprop 같은 속성을 붙입니다. JSON-LD는 본문 마크업과 별도로 한 스크립트에 데이터를 모을 수 있으므로, 화면 구성을 바꿀 때 구조화 데이터까지 여러 곳에서 수정할 부담이 적습니다.
Google은 JSON-LD, Microdata, RDFa를 지원하며 구현과 유지관리가 쉬운 JSON-LD를 권장합니다. 네이버는 JSON-LD 또는 Microdata를 권장합니다.
코드를 별도로 관리하더라도 가격, 평점과 작성자 등 핵심 정보는 실제 페이지에서 확인할 수 있어야 합니다. 화면과 구조화 데이터에 서로 다른 값을 넣지 않습니다.
작성하고 확인하는 순서
- 페이지가 설명하는 주요 대상을 정합니다. 글과 작성자처럼 여러 대상을 함께 설명한다면 각각의 관계도 정리합니다.
- Schema.org에서 내용에 맞는 구체적인 유형과 속성을 고릅니다. Google 검색 기능을 목표로 한다면 해당 기능의 필수 속성과 지침도 확인합니다.
- JSON-LD를 페이지의
<head>나<body>안에 넣습니다. - Schema Markup Validator에서 구문 오류와 잘못된 속성 사용을 확인합니다.
- Google이 지원하는 검색 기능은 리치 결과 테스트로 필수 속성 누락과 기능별 오류를 검사합니다.
- 배포 뒤 Search Console URL 검사로 Google이 읽은 HTML에 코드와 값이 제대로 들어 있는지 확인합니다.
쉼표가 빠지거나 따옴표를 잘못 닫으면 블록 전체를 읽지 못할 수 있습니다. CMS에서 자동 생성한다면 본문과 JSON-LD가 같은 원본 데이터를 사용하게 구성합니다. 가격이나 작성자를 수정할 때 화면만 바뀌고 구조화 데이터에는 예전 값이 남는 문제를 줄일 수 있습니다.
자주 묻는 질문
JSON-LD를 넣으면 검색 순위가 오르나요?
JSON-LD는 검색엔진이 페이지의 내용을 이해하고 지원하는 검색 기능에 활용할 수 있도록 정보를 제공하는 형식입니다. 같은 내용을 Microdata 대신 JSON-LD로 작성했다고 순위가 더 높아지는 것은 아닙니다. 올바르게 작성했더라도 리치 결과가 반드시 표시되지는 않습니다.
화면에 보이지 않는 정보도 넣어도 되나요?
@context나 @id처럼 데이터를 해석하거나 식별하기 위한 값까지 화면에 그대로 보여 줄 필요는 없습니다. 그러나 가격, 리뷰, 행사 일정처럼 페이지의 내용을 설명하는 정보는 독자가 실제 페이지에서도 확인할 수 있어야 합니다. JSON-LD에만 가짜 평점이나 별도의 가격을 넣어서는 안 됩니다.
함께 알아두면 좋은 용어
- Schema.org: 사람, 조직, 상품 등을 설명할 유형과 속성을 정의한 공용 어휘
- 마이크로데이터: HTML 요소에 속성을 붙여 구조화 데이터를 표현하는 방식
- 스키마 마크업 검사기: Schema.org 구조화 데이터의 구문과 속성을 검사하는 도구