구조화 데이터
structured data
뜻과 개념
페이지의 대상과 속성을 기계가 읽기 쉬운 형식으로 표현한 데이터입니다.
어떻게 작동하나요?
구조화 데이터는 페이지에 있는 정보의 종류와 관계를 기계가 읽을 수 있게 표시하는 데이터입니다. 글 제목, 작성자, 상품 가격처럼 화면에서 사람이 이해하는 내용을 정해진 속성으로 표현합니다. Schema.org는 이런 표현에 쓸 수 있는 어휘를 제공하고, Google은 그중 일부 유형을 검색 기능에 활용합니다. 두 범위는 완전히 같지 않습니다.
왜 알아야 하나요?
정보가 명확히 표시되면 검색 시스템이 페이지의 대상을 해석하는 데 도움이 됩니다. 특정 검색 기능의 자격을 갖추기 위한 조건이기도 합니다. 다만 마크업을 넣었다는 이유만으로 순위가 오르거나 확장된 검색 결과가 반드시 표시되지는 않습니다.
실무에서 적용하는 방법
먼저 페이지의 실제 목적에 맞는 유형을 고릅니다. 상품 판매 페이지라면 상품 정보를, 글이라면 글의 정보를 표시합니다. 화면에 없는 후기나 가격을 별도로 만들어 넣지 말고 관리자가 수정하는 원본 데이터와 마크업을 함께 갱신하도록 설계합니다.
Google의 해당 기능 문서에서 필수 속성과 정책을 확인하고 리치 결과 테스트로 검사합니다. 문법 오류를 고친 뒤에는 배포된 URL에서도 값을 확인하세요. 테스트 통과와 실제 검색 표시를 나누어 기록하면 왜 기능이 보이지 않는지 판단하기 쉽습니다.
콘텐츠 수정 권한과 검수 절차도 설계합니다. 편집자가 작성자를 바꾸었는데 마크업은 이전 이름을 유지하거나 상품 옵션마다 다른 가격을 하나로 표현하는 문제가 생길 수 있습니다. 대표 페이지 몇 개를 표본으로 삼아 화면 값과 데이터 값을 비교하고, 수정 전후에 검사 결과를 보관하면 템플릿 오류를 빠르게 발견할 수 있습니다.
실무에서는 이렇게 봅니다
강의 판매 페이지에 가격과 신청 가능 여부를 표시하는 상황을 생각해 보세요. 화면 가격만 수정하고 구조화 데이터에는 옛 가격이 남으면 두 정보가 충돌합니다. 하나의 가격 필드로 화면과 마크업을 모두 생성하면 이런 불일치를 줄일 수 있습니다. 품절 상태와 변경 날짜도 같은 관점으로 점검합니다.
기사 페이지라면 작성자, 발행일, 수정일이 무엇을 의미하는지 먼저 정해야 합니다. 사소한 디자인 수정 날짜를 글의 실질적인 갱신 날짜처럼 표시하면 독자가 정보의 최신성을 잘못 판단할 수 있습니다. 데이터의 정확성은 코드 문법뿐 아니라 편집 기준에도 달려 있습니다.
주의할 점
Schema.org에 존재하는 모든 유형이 Google의 특별한 표시 기능으로 이어지는 것은 아닙니다. 지원 여부와 기능 정책은 바뀔 수 있으므로 오래된 구현 예제만 따라서는 안 됩니다. 관련 없는 유형을 많이 넣는 것보다 정확한 정보를 유지하는 편이 중요합니다.
자주 묻는 질문
JSON-LD가 화면 디자인을 바꾸나요?
그 자체로 화면을 꾸미는 기능은 아닙니다. 페이지 정보의 의미를 기계에 전달하는 데이터이며 사용자에게 보이는 내용과 일치해야 합니다.
오류가 없는데 리치 결과가 안 나오는 이유는 무엇인가요?
검사 통과는 기술적인 자격의 일부입니다. 검색 상황과 지원 유형, 정책 등 표시 조건이 따로 있으므로 노출을 보장하지 않습니다.
스키마 검증과 리치 결과 테스트는 같은가요?
검사 범위가 다를 수 있습니다. Schema.org 어휘가 올바른지와 Google이 지원하는 특정 검색 기능 조건을 충족하는지를 나누어 확인하면 문제를 정확히 파악할 수 있습니다.