SEO 구조화 데이터는 기계가 읽을 수 있는 방식으로 웹페이지의 개체와 그 관계를 설명합니다. 예를 들어 페이지가 기사, 제품 또는 브레드크럼 탐색을 소개하는지 나타냅니다. 검색 엔진은 이를 통해 콘텐츠를 이해하는 데 도움을 받을 수 있습니다. 특정 요건을 충족하는 페이지는 리치 검색 결과에 표시될 가능성도 있지만, 마크업을 추가한다고 해서 특별한 형식으로 표시되거나 순위가 높아지는 것이 보장되지는 않습니다.
구현할 때 가장 중요한 판단 기준은 ‘얼마나 많은 필드를 마크업할 수 있는가’가 아니라 페이지에 실제로 무엇이 표시되는지, 검색 엔진이 무엇을 이해하기를 바라는지, 그리고 대상 검색 엔진이 해당 검색 표시 방식을 지원하는지입니다. 스페인어권에서 사용되는 datos estructurados seo도 이러한 구조화 데이터 활용 방법을 가리킵니다.
Schema.org는 Article, Product, Organization 등 웹페이지 콘텐츠를 설명하는 어휘를 제공합니다. JSON-LD와 Microdata 등은 이러한 어휘를 담는 형식입니다. Google은 일반적으로 페이지 코드에 별도로 삽입하고 유지 관리하기 쉬우며, 페이지의 콘텐츠 태그를 하나씩 수정할 필요가 없는 JSON-LD 사용을 권장합니다.
Schema.org에 특정 유형이 있다고 해서 Google이 반드시 해당 유형을 리치 검색 결과로 표시하는 것은 아닙니다. 구현 전에 Schema.org의 유형 정의와 Google 검색 센터의 해당 기능 문서를 함께 확인하여 필수 속성, 권장 속성 및 콘텐츠 정책을 파악해야 합니다. 테스트 도구에서 마크업이 유효하다고 표시되어도 실제 표시 여부는 페이지 품질과 검색어 등의 요소를 바탕으로 검색 엔진이 판단합니다.
Article: 기사 및 뉴스 페이지. 제목, 작성자, 게시일, 수정일, 이미지 등의 정보를 표시하는 데 사용할 수 있습니다. 기사 페이지에는 해당 내용이 실제로 표시되어야 하며, 날짜도 페이지에 표시된 내용 및 실제 수정 내역과 일치해야 합니다. 오래된 기사를 새것처럼 보이게 하려고 마크업의 날짜만 수정해서는 안 됩니다.
예를 들어 페이지의 주제별 콘텐츠가 공공기관 재정 예산 집행률 제고 방안 연구인 경우, 해당 페이지에 실제로 담긴 콘텐츠를 기준으로 유형을 판단해야 합니다. 완성된 기사라면 Article을 고려할 수 있지만, 링크 제목만으로 대상 페이지가 특정 마크업에 적합한지는 판단할 수 없습니다.
Product: 구체적인 제품 페이지. 명확한 제품 정보를 표시하는 페이지에 적합하며, 이름, 이미지, 브랜드 등을 설명할 수 있습니다. 실제 판매 가격이 있는 경우 Offer를 사용해 가격, 통화 및 재고를 설명할 수도 있습니다. 견적 문의 방식의 웹사이트에서 가격을 공개하지 않는다면 허위 가격을 입력해서는 안 되며, ‘가격 문의’를 구체적인 금액으로 바꾸어서도 안 됩니다. 제품 관련 검색 기능마다 요구하는 속성이 다르므로 가격 등의 정보가 없을 때 해당 페이지가 관련 리치 검색 결과 표시 자격을 갖췄다고 가정해서는 안 됩니다.
Organization: 기업 정보. 홈페이지나 기업을 소개하는 대표 페이지에 적용하여 기업명, 웹사이트, 로고 및 공개 연락처를 설명할 수 있습니다. 검색 엔진이 웹사이트를 운영하는 조직을 이해하는 데 도움이 되지만, 기업 정보가 반드시 지식 패널에 표시되는 것은 아닙니다. 다국어 사이트에서는 기업명, 웹사이트 및 연락처의 일관성에 유의해야 합니다.
BreadcrumbList: 브레드크럼 탐색. ‘홈—제품 카테고리—제품 상세 정보’와 같이 웹사이트 계층 구조에서 페이지의 위치를 나타내는 데 사용됩니다. 마크업 순서는 사용자에게 보이는 탐색 순서와 일치해야 하며, 각 노드의 링크는 해당 페이지를 가리켜야 합니다. 키워드를 넣기 위해 존재하지 않는 계층을 만들어서는 안 됩니다.
FAQPage: 질문과 답변 콘텐츠. 페이지에 해당 질문과 답변이 실제로 포함된 경우에만 사용해야 합니다. Google은 FAQ 리치 검색 결과의 표시 범위를 엄격하게 제한하고 있으므로, 일반 상업용 웹사이트는 유효한 마크업을 추가하더라도 질문과 답변이 펼쳐지는 형식으로 표시될 것이라고 기대해서는 안 됩니다. 적용하기 전에 Google의 최신 지원 범위를 확인하세요.
기사 페이지를 예로 들면, 먼저 페이지에 이미 표시된 제목, 작성자, 날짜 및 이미지를 확인한 다음 해당 속성에 매핑합니다. 아래는 간략한 예시입니다. URL, 날짜 및 이름은 예시이므로 게시할 때 실제 페이지 정보로 바꿔야 합니다.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "산업 장비 유지보수 가이드",
"author": {
"@type": "Organization",
"name": "예시 기업"
},
"datePublished": "2025-01-10",
"dateModified": "2025-02-15",
"image": "https://example.com/images/guide.jpg"
}
</script>이 코드는 페이지 HTML의 head 또는 body에 넣을 수 있습니다. 웹사이트 구축 시스템을 사용하는 경우, 먼저 구조화 데이터 기능이 이미 있는지 확인할 수 있습니다. 시스템이 Article을 자동 생성하는데 내용이 충돌하는 Article을 추가로 삽입하면 페이지 정보를 판단하기 어려워질 수 있습니다. 일괄 적용하는 템플릿은 모든 기사에 같은 제목, 작성자 또는 날짜를 사용하지 말고 콘텐츠 관리 시스템에서 실제 필드를 가져와야 합니다.
JSON-LD에서는 Article로 기사 콘텐츠를 표시하고 BreadcrumbList로 탐색을 표시하는 것처럼 여러 마크업을 사용해 한 페이지를 설명할 수 있습니다. 각 마크업은 서로 다른 역할을 해야 하며, 같은 개체가 반복해서 나타나는 경우 이름과 URL 등의 속성을 일관되게 유지해야 합니다. 웹사이트의 모든 제품 가격을 홈페이지에 일괄 입력하거나 카테고리 목록 페이지를 단일 제품 상세 페이지로 잘못 표시해서는 안 됩니다.

검사할 때는 먼저 최종 페이지 코드를 확인하여 페이지가 로드될 때 마크업이 포함되어 있고 검색 엔진이 페이지와 관련 리소스에 접근할 수 있는지 확인합니다. JavaScript로 삽입한 마크업은 렌더링 후에도 존재하는지, 내용이 완전한지도 확인해야 합니다. 로컬 미리보기에서 정상적으로 보인다고 해서 온라인 버전에도 적용되었다는 뜻은 아닙니다.
그런 다음 Google의 ‘리치 검색 결과 테스트’를 사용해 지원되는 리치 결과 유형을 확인하고, Schema Markup Validator로 Schema.org 마크업 구조를 검사할 수 있습니다. 두 도구의 용도는 다릅니다. 전자는 Google이 지원하는 검색 기능에 중점을 두고, 후자는 어휘와 구조를 검사하며, 페이지가 Google의 표시 요건을 충족하는지는 증명하지 않습니다. 테스트할 때는 오류를 수정하는 것뿐 아니라, 실제 페이지 콘텐츠를 바탕으로 누락된 권장 필드를 보완할 수 있는지도 검토해야 합니다.
페이지를 게시하고 크롤링을 허용한 뒤에는 Google Search Console의 URL 검사 도구를 사용하여 Google이 페이지에 접근할 수 있는지 확인할 수 있습니다. 해당 기능의 보고서가 제공되는 경우 감지된 항목과 오류도 확인하세요. 보고서가 나타나지 않거나 검색 결과에 변화가 없더라도 코드가 유효하지 않다는 뜻은 아닙니다. 관련 보고서와 표시 여부는 지원되는 유형, 크롤링 상태 및 검색 엔진의 판단에 영향을 받습니다.
유지 관리의 핵심은 페이지가 변경될 때 데이터를 함께 업데이트하는 것입니다. 제품 판매가 중단되면 페이지 표시 내용과 재고 마크업을 적시에 업데이트해야 합니다. 가격을 조정할 때는 통화와 금액이 일치해야 합니다. 다국어 페이지에는 해당 언어 버전에 실제로 표시되는 이름과 콘텐츠, 해당 URL을 사용해야 합니다. 문법은 맞지만 실제 내용과 다른 마크업을 유지하는 것보다 페이지에 더 이상 존재하지 않는 리뷰, 할인 또는 질문과 답변을 삭제하는 것이 중요합니다.
관련 기사
관련 제품


