구조화 데이터 JSON-LD 적용법: 스키마 선택과 검증

검색 결과에서 별점이나 가격, 질문 목록이 함께 보이는 항목을 본 적이 있을 것입니다. 이런 표시는 페이지가 구조화 데이터를 제공했을 때 나타납니다. 사람이 읽는 본문과 별개로, 이 페이지가 무엇에 관한 것이고 어떤 값을 담고 있는지 기계가 읽을 수 있는 형식으로 함께 적어 주는 것입니다.

AI 검색이 늘면서 이 작업의 성격도 조금 달라졌습니다. 예전에는 검색 결과를 눈에 띄게 만드는 장식에 가까웠다면, 지금은 언어 모델이 페이지 내용을 오해 없이 파악하게 하는 수단에 가깝습니다. 이 글은 JSON-LD 형식으로 구조화 데이터를 넣는 방법과 유형 선택 기준, 검증 절차를 정리합니다.

왜 JSON-LD 형식을 쓰나요

구조화 데이터를 표기하는 방법은 세 가지가 있습니다. HTML 태그에 속성을 직접 붙이는 마이크로데이터와 RDFa, 그리고 별도의 스크립트 블록에 넣는 JSON-LD입니다. 셋 다 인식되지만 실무에서는 JSON-LD가 압도적으로 편합니다.

이유는 본문 마크업과 분리되기 때문입니다. 마이크로데이터는 값을 표시하는 HTML 요소마다 속성을 붙여야 해서, 디자인을 바꾸면 구조화 데이터도 함께 깨집니다. JSON-LD는 head나 body 어딘가에 스크립트 블록 하나로 들어가므로 화면 구조와 독립적으로 관리됩니다.

형식은 단순합니다. type이 application/ld+json인 script 태그 안에 JSON 객체를 넣고, 맨 위에 context를 schema.org로 지정한 뒤 type으로 유형을 밝히면 됩니다. 한 페이지에 여러 개의 블록을 넣어도 되고, 배열로 여러 유형을 묶어도 됩니다.

어떤 유형을 골라야 하나요

schema.org에는 수백 개의 유형이 있지만 실제로 자주 쓰는 것은 열 개 남짓입니다. 사이트 성격에 따라 기본 조합이 정해집니다.

모든 사이트에 공통으로 들어가는 것은 Organization과 WebSite입니다. Organization에는 회사명, 로고, 주소, 연락처, 사업 영역을 담고 WebSite에는 사이트 이름과 주소를 담습니다. 이 둘은 검색엔진이 브랜드를 하나의 개체로 인식하는 기반이 되므로 홈페이지에 반드시 넣는 것이 좋습니다.

콘텐츠 페이지에는 Article이나 BlogPosting을 씁니다. 제목, 작성일, 수정일, 작성자, 대표 이미지가 주요 속성입니다. 여기에 BreadcrumbList를 더하면 검색 결과에 경로가 함께 표시되어 페이지의 위치를 알리기 좋습니다.

질문과 답변이 있는 페이지에는 FAQPage를 씁니다. 다만 화면에 실제로 보이는 질문과 답변만 넣어야 합니다. 상품을 파는 페이지는 Product와 Offer, 서비스를 소개하는 페이지는 Service, 문의 페이지는 ContactPage가 어울립니다. 단계별 안내를 담은 글이라면 HowTo가 맞습니다.

잘못 넣으면 생기는 문제

가장 흔한 실수는 화면에 없는 내용을 구조화 데이터에만 넣는 것입니다. FAQ 스키마에 질문 열 개를 적어 두었는데 실제 페이지에는 세 개만 보이는 식입니다. 이것은 정책 위반으로 취급되어 리치 결과 표시가 중단될 수 있고, 반복되면 사이트 전체에 수동 조치가 내려지기도 합니다. 구조화 데이터는 화면 내용의 사본이어야 합니다.

두 번째는 필수 속성 누락입니다. 유형마다 반드시 있어야 하는 속성이 정해져 있는데, 예를 들어 Product에 name과 offers가 없으면 리치 결과 대상에서 제외됩니다. 값을 넣을 수 없다면 그 유형 자체를 쓰지 않는 편이 낫습니다.

세 번째는 유형을 과하게 붙이는 것입니다. 관련 없는 유형을 여러 개 넣는다고 평가가 올라가지 않습니다. 오히려 페이지 성격을 흐리게 만들고 관리 부담만 늘어납니다. 페이지가 실제로 무엇인지에 맞는 유형만 정확히 넣는 것이 원칙입니다.

네 번째는 값이 오래되는 것입니다. 가격이나 재고, 수정일 같은 값을 화면과 따로 관리하면 시간이 지나면서 어긋납니다. 구조화 데이터는 화면을 그리는 것과 같은 데이터에서 생성되도록 만들어야 어긋나지 않습니다.

넣은 뒤에는 반드시 검증합니다

구글은 리치 결과 테스트와 스키마 마크업 검사 도구를 제공합니다. 앞의 것은 실제로 리치 결과 표시 대상이 되는지를 알려주고, 뒤의 것은 문법과 속성 구성을 폭넓게 검사합니다. 두 도구는 목적이 다르므로 함께 쓰는 편이 좋습니다.

schema.org 표준 자체를 확인하려면 별도의 검증기가 있습니다. 구글이 리치 결과로 지원하지 않는 유형이라도 문법이 올바른지 확인할 수 있어, AI 검색을 염두에 둔 표기를 검사할 때 유용합니다.

배포 후에는 서치콘솔에서 지속적으로 봅니다. 향상된 기능 섹션에 유형별 상태가 표시되고 오류가 생기면 알림이 옵니다. 특히 상품 가격이나 재고처럼 자주 바뀌는 값은 여기서 오류가 먼저 잡히는 경우가 많습니다.

검증 도구가 통과했다고 리치 결과가 바로 나타나지는 않습니다. 표시 여부는 검색엔진이 페이지 품질과 검색어 맥락을 함께 보고 판단하므로, 마크업은 필요조건이지 충분조건이 아닙니다.

적용 순서

먼저 사이트에서 페이지 유형을 몇 가지로 나눕니다. 홈, 서비스 소개, 블로그 글, 가격, 문의 정도로 묶으면 대부분 정리됩니다. 유형마다 어떤 스키마를 넣을지 표로 정해 두면 이후 작업이 빨라집니다.

홈페이지에 Organization과 WebSite부터 넣습니다. 주소와 연락처, 사업자 정보처럼 회사가 실재한다는 값을 최대한 채웁니다. 이 정보는 화면에도 함께 노출하는 것이 좋습니다.

블로그 글에는 BlogPosting과 BreadcrumbList를 넣습니다. 작성일과 수정일은 실제 값을 쓰고, 수정하지 않았는데 날짜만 갱신하는 일은 피해야 합니다.

구조화 데이터를 화면과 같은 데이터에서 생성하도록 코드를 구성합니다. 값을 두 곳에 따로 적어 두면 언젠가 반드시 어긋납니다.

리치 결과 테스트와 스키마 검사 도구로 확인한 뒤 배포하고, 서치콘솔의 향상된 기능 보고서를 주기적으로 봅니다.

자주 묻는 질문

구조화 데이터를 넣으면 순위가 오르나요?

직접적인 순위 상승 요인은 아닙니다. 구글도 구조화 데이터가 순위 요인이 아니라고 명시하고 있습니다. 효과는 다른 곳에서 나옵니다. 리치 결과로 표시되면 검색 결과에서 차지하는 면적이 넓어져 클릭률이 올라가고, 페이지 내용이 기계에 정확히 전달되어 AI 답변에 인용될 때 오해가 줄어듭니다. 순위보다 노출 품질을 개선하는 작업으로 보는 편이 정확합니다.

네이버도 구조화 데이터를 활용하나요?

네이버 서치어드바이저도 구조화 데이터 표기를 권장하고 일부 유형을 검색 결과에 활용합니다. 다만 지원 범위와 표시 방식은 구글과 다릅니다. 어느 쪽이든 Organization과 Article 계열은 기본으로 넣어 두는 것이 무난하고, 특정 유형의 리치 결과를 노린다면 각 검색엔진의 지원 목록을 먼저 확인해야 합니다.

스키마를 많이 넣을수록 좋은가요?

아닙니다. 페이지 성격과 맞지 않는 유형을 늘리는 것은 도움이 되지 않고 관리 부담만 커집니다. 값이 비어 있거나 화면에 없는 내용을 채운 스키마는 오히려 위험합니다. 페이지가 실제로 무엇인지에 해당하는 유형을 골라 필수 속성을 빠짐없이 채우는 쪽이 훨씬 낫습니다.

실행 체크리스트

• 페이지 유형별로 넣을 스키마를 표로 미리 정합니다.

• 홈페이지에 Organization과 WebSite를 넣고 회사 정보를 채웁니다.

• 화면에 없는 내용을 구조화 데이터에만 넣지 않습니다.

• 화면과 같은 데이터에서 생성되도록 코드를 구성합니다.

• 리치 결과 테스트로 검증하고 서치콘솔 보고서를 주기적으로 확인합니다.

정리

구조화 데이터는 순위를 올려 주는 장치가 아니라 페이지 내용을 정확히 전달하는 장치입니다. 검색 결과에서 더 많은 정보를 보여주고, AI가 페이지를 요약할 때 오해를 줄입니다.

시작은 홈페이지의 Organization과 WebSite, 블로그 글의 BlogPosting과 BreadcrumbList면 충분합니다. 여기서부터 페이지 성격에 맞는 유형을 하나씩 늘려 가되, 화면에 없는 내용은 절대 넣지 않는다는 원칙만 지키면 됩니다.