웹닷
메뉴 열기

JSON-LD 구조화 데이터 작성법: 스키마 마크업 예시와 페이지별 적용

JSON-LD는 페이지의 정보를 검색엔진이 읽기 쉬운 데이터로 따로 적어 두는 방식이며, 구글이 권장하는 구조화 데이터 형식입니다. 이 가이드는 기업 홈페이지 담당자와 개발자가 회사·제품·공지 페이지에 어떤 스키마를 어떻게 넣어야 하는지 구글 검색 센터 문서를 기준으로 정리했습니다. 예시 코드, 페이지 유형별 매핑표, 테스트와 Search Console 확인 방법, 2026년에 바뀐 FAQ 리치 결과 현황까지 다룹니다.

ℹ️ 참고

이 글은 2026년 10월 1일 기준으로 구글 검색 센터 문서를 확인해 작성했습니다. 구조화 데이터 지원 유형은 해마다 추가되거나 종료되므로, 적용 전에 해당 유형의 공식 문서를 한 번 더 확인하세요. 메타태그 등 다른 검색 최적화 항목은 SEO 최적화 방법 체크리스트 (온페이지, 테크니컬, 오프페이지)에 정리되어 있습니다.

JSON-LD와 구조화 데이터란?

구조화 데이터는 「이 페이지는 어떤 회사의 어떤 제품을 다루는가」 같은 정보를 정해진 어휘로 표기한 데이터이고, JSON-LD는 그 데이터를 <script type="application/ld+json"> 태그 안에 JSON 형식으로 적는 방법입니다. 화면에 보이는 HTML과 분리해서 쓰기 때문에 디자인을 건드리지 않고 넣고 고칠 수 있습니다.

어휘는 구글, 마이크로소프트, 야후, 얀덱스가 함께 만든 schema.org를 씁니다. 「Organization(조직)」, 「Product(제품)」, 「Article(기사)」 같은 유형(@type)과 「name」, 「logo」 같은 속성이 정해져 있습니다. 흔히 말하는 「스키마 마크업(schema markup)」은 이 schema.org 어휘로 구조화 데이터를 넣는 작업을 가리킵니다. JSON-LD 자체는 W3C 권고안(JSON-LD 1.1)으로 정의된 형식입니다.

📌 용어 설명: 리치 결과(Rich Results)

구글 검색 결과에서 일반적인 파란 제목과 설명 외에 별점, 가격, 이동 경로, 이미지 등이 추가로 표시되는 결과를 말합니다. 구조화 데이터를 올바르게 넣으면 리치 결과 「자격」이 생기지만, 실제 표시 여부는 구글이 판단합니다.

구글은 구조화 데이터 형식으로 JSON-LD, 마이크로데이터, RDFa 세 가지를 지원하며, 그중 JSON-LD를 권장합니다. 사이트 규모가 커져도 구현하고 유지하기 가장 쉽다는 이유입니다. 자바스크립트로 페이지에 삽입한 JSON-LD도 읽을 수 있다고 안내합니다.

구조화 데이터를 넣으면 무엇이 달라지나

구조화 데이터는 검색 순위를 직접 올리는 장치가 아니라, 페이지 내용을 검색엔진이 정확하게 해석하도록 돕고 리치 결과 자격을 얻는 수단입니다. 구글은 문서에서 마크업을 정확하게 넣어도 검색 결과에 표시된다고 보장하지 않는다고 명시합니다.

그래도 넣는 이유는 분명합니다. 구글 문서에 소개된 사례에서 네슬레는 리치 결과로 표시된 페이지의 클릭률이 일반 페이지보다 82% 높았고, 로튼토마토는 구조화 데이터를 넣은 페이지에서 클릭률이 25% 높았다고 밝혔습니다. 또 회사 로고, 사이트 이름, 이동 경로처럼 검색 결과에서 회사가 어떻게 보이는지를 정하는 데 쓰입니다.

⚠️ 주의

생성형 AI 기능(AI 개요·AI 모드)에 나오기 위한 특별한 스키마는 없습니다. 구글의 생성형 AI 기능 최적화 문서는 구조화 데이터가 생성형 AI 검색의 필수 요건이 아니며 따로 추가할 schema.org 마크업도 없다고 적고, 리치 결과 자격을 위해 기존처럼 쓰는 것을 권합니다. 「스키마를 넣으면 AI 답변에 노출된다」는 설명은 공식 문서와 맞지 않습니다.

기업 홈페이지에 맞는 스키마 유형

구글 검색 센터의 구조화 데이터 검색 갤러리에는 2026년 10월 현재 25개 기능이 올라 있습니다. 레시피, 영화, 숙박처럼 업종이 정해진 유형이 많고, 일반 기업 홈페이지에 실제로 쓰는 유형은 많지 않습니다.

유형 용도 구글 필수 속성 기업 홈페이지 적용
Organization 회사 로고·정보를 검색엔진에 전달 없음 (해당 속성 추가) 필수급
WebSite 검색 결과에 표시되는 사이트 이름 name, url 필수급 (메인만)
BreadcrumbList 이동 경로 표시 itemListElement (position, name, item) 하위 페이지 전체
Product 제품 정보, 가격·리뷰 표시 name + review·aggregateRating·offers 중 1개 제품 상세
Article 기사·글의 제목·이미지·날짜 없음 (해당 속성 추가) 공지·뉴스·블로그 상세
LocalBusiness 매장·지점 영업 정보 name, address 방문형 사업장이 있을 때
JobPosting 구글 채용 정보 노출 title, description, datePosted, hiringOrganization, jobLocation 등 채용 공고가 있을 때

지원이 끝난 유형도 알아 두어야 합니다. 사이트링크 검색창(WebSite의 SearchAction)은 2024년 11월 구글 검색에서 표시가 중단되었고, 2025년에는 도서 액션, 강좌 정보, 예상 급여, 학습 동영상, 차량 목록 등이 정리되었습니다. 예전 블로그 글의 예시 코드를 그대로 가져오면 더 이상 쓰이지 않는 마크업이 들어갈 수 있습니다.

기업 홈페이지 페이지 구조별 JSON-LD 스키마 유형 배치 도식: 메인 Organization·WebSite, 제품 상세 Product, 하위 페이지 BreadcrumbList

JSON-LD 기본 문법과 넣는 위치

JSON-LD는 @context, @type, 속성 세 부분으로 구성되고, HTML의 <head> 또는 <body> 어디에 넣어도 됩니다. 가장 단순한 형태는 아래와 같습니다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "한빛정밀",
  "url": "https://example.co.kr/"
}
</script>
  • @context: schema.org 어휘를 쓴다는 선언입니다. 항상 https://schema.org입니다.
  • @type: 이 데이터가 무엇인지 나타냅니다. 대소문자를 구분합니다.
  • 속성: 유형별로 정해진 이름(name, logo 등)과 값입니다. 값 안에 다른 유형을 넣을 수도 있습니다(주소 안에 PostalAddress).

한 페이지에 여러 유형을 넣을 때: @graph와 @id

제품 상세 페이지처럼 Organization, BreadcrumbList, Product가 함께 필요하면 @graph 배열로 묶어 스크립트 하나로 출력하는 방식이 관리하기 쉽습니다. 구글은 여러 항목을 따로 넣는 것도 허용하며, @id로 항목끼리 연결하면 관계를 이해하는 데 도움이 된다고 안내합니다.

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.co.kr/#org", "name": "한빛정밀" },
    { "@type": "Product", "name": "진공 챔버 플랜지",
      "manufacturer": { "@id": "https://example.co.kr/#org" } }
  ]
}

💡 실무 팁

페이지마다 JSON을 손으로 쓰면 반드시 어긋납니다. 회사 정보·제품 데이터를 넘기면 JSON-LD를 만들어 주는 함수(헬퍼)를 하나 두고 모든 페이지가 그것을 쓰게 하세요. 회사 전화번호가 바뀌어도 한 곳만 고치면 됩니다.

유형별 JSON-LD 예시 코드

아래 예시는 B2B 제조 기업을 가정해 작성했습니다. 회사명과 주소, 연락처는 예시 값이니 실제 정보로 바꿔 쓰고, 화면에 실제로 보이는 정보만 넣으세요.

Organization (메인 또는 회사소개)

구글은 Organization을 메인 페이지나 회사를 설명하는 한 페이지(회사소개 등)에 넣으라고 안내합니다. 필수 속성은 없고, 해당하는 속성을 추가하는 방식입니다. 로고는 최소 112×112픽셀이어야 하고 크롤링과 색인이 가능한 주소여야 합니다.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.co.kr/#org",
  "name": "한빛정밀",
  "alternateName": "Hanbit Precision",
  "url": "https://example.co.kr/",
  "logo": "https://example.co.kr/images/logo.png",
  "description": "반도체 장비용 정밀 가공 부품 제조 기업",
  "telephone": "+82-31-000-0000",
  "email": "sales@example.co.kr",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "○○로 00",
    "addressLocality": "화성시",
    "addressRegion": "경기도",
    "postalCode": "00000",
    "addressCountry": "KR"
  },
  "sameAs": [
    "https://blog.naver.com/example",
    "https://www.youtube.com/@example"
  ]
}

국제 전화번호는 국가번호를 붙인 형식(+82-31-...)으로 씁니다. sameAs에는 회사가 실제로 운영하는 공식 채널만 넣습니다.

WebSite (메인 페이지만)

검색 결과 상단에 표시되는 사이트 이름을 지정합니다. 필수 속성은 name과 url이고, 도메인 또는 서브도메인의 메인 페이지에만 넣어야 합니다. /company 같은 하위 디렉터리 단위는 지원하지 않습니다.

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "한빛정밀",
  "alternateName": ["Hanbit Precision", "한빛"],
  "url": "https://example.co.kr/"
}

BreadcrumbList (하위 페이지)

각 항목에 position(1부터 시작), name, item(주소)을 넣습니다. 마지막 항목은 현재 페이지라 item을 생략할 수 있습니다. 화면에 보이는 이동 경로와 같은 순서여야 합니다.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "홈", "item": "https://example.co.kr/" },
    { "@type": "ListItem", "position": 2, "name": "제품", "item": "https://example.co.kr/products" },
    { "@type": "ListItem", "position": 3, "name": "진공 챔버 플랜지" }
  ]
}

Product (제품 상세)

제품 스니펫 리치 결과를 받으려면 name과 함께 review, aggregateRating, offers 중 하나 이상이 필요합니다. 온라인에서 바로 구매하는 페이지라면 판매자 등록정보(merchant listing) 기준을 따릅니다.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "진공 챔버 플랜지 VF-200",
  "description": "반도체 진공 챔버용 알루미늄 플랜지. 공차 ±0.005mm.",
  "image": "https://example.co.kr/images/products/vf-200.webp",
  "sku": "VF-200",
  "category": "챔버 부품",
  "brand": { "@type": "Brand", "name": "한빛정밀" },
  "manufacturer": { "@id": "https://example.co.kr/#org" }
}

⚠️ 주의

가격을 공개하지 않는 B2B 제품은 offers가 없어 제품 리치 결과 자격이 생기지 않을 수 있습니다. 그렇다고 화면에 없는 가격이나 직접 만든 리뷰를 마크업에 넣으면 안 됩니다. 구글은 화면에 보이지 않는 내용을 마크업하지 말라고 명시하며, 스팸성 구조화 데이터에는 리치 결과 자격을 없애는 수동 조치를 내립니다. 리치 결과가 없어도 제품명, 규격, 제조사 정보를 정확히 전달하는 것만으로 의미가 있습니다.

Article (공지·뉴스·블로그 상세)

Article은 필수 속성이 없고 headline, image, datePublished, dateModified, author를 권장합니다. 유형은 Article, NewsArticle, BlogPosting 중에서 고릅니다. 날짜는 ISO 8601 형식으로 시간대까지 씁니다.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "2026 반도체 장비 전시회 참가 안내",
  "image": ["https://example.co.kr/images/news/expo-2026.webp"],
  "datePublished": "2026-09-15T09:00:00+09:00",
  "dateModified": "2026-09-20T14:30:00+09:00",
  "author": { "@type": "Organization", "name": "한빛정밀", "url": "https://example.co.kr/" }
}

작성자가 개인이면 Person, 회사 명의면 Organization을 씁니다. author.name에는 이름만 넣고 직함이나 회사명을 붙이지 않습니다.

제품 상세 페이지 화면 요소와 JSON-LD Product·BreadcrumbList 속성의 대응 관계 도식

FAQPage는 아직 써야 하나? (2026년 FAQ 리치 결과 종료)

FAQ 리치 결과는 2026년 5월 7일부터 구글 검색에 표시되지 않습니다. 구글은 2023년 8월 FAQ 리치 결과를 잘 알려진 정부·건강 분야 사이트로 제한했고, 2026년 5월 8일 검색 센터 변경 로그에서 기능 종료를 알렸습니다. 6월 15일에는 FAQ 구조화 데이터 문서도 삭제되어, 지금은 검색 갤러리에서도 찾을 수 없습니다. 네이버 역시 2026년 7월 9일부터 웹 검색결과의 FAQ 노출을 종료했습니다.

그렇다면 이미 넣어 둔 FAQPage 마크업은 지워야 할까요? 지우지 않아도 됩니다. FAQPage는 schema.org의 유효한 유형이고, 구글이 쓰지 않는 구조화 데이터가 검색에 불이익을 주지는 않습니다. 다만 새로 구조화 데이터를 설계한다면 FAQPage에 시간을 쓰기보다, 자주 묻는 질문을 화면의 본문으로 충실하게 쓰는 편이 낫습니다. 질문을 제목(H2·H3)으로, 답을 바로 아래 문단으로 두면 사람과 검색엔진 모두 읽기 쉽습니다.

페이지 유형별 스키마 매핑표

스키마는 페이지마다 즉흥적으로 넣지 말고, 사이트를 설계할 때 「어떤 페이지에 어떤 유형을 넣는다」를 표로 정해 두는 것이 좋습니다. 아래는 일반 기업 홈페이지 기준의 매핑표입니다.

페이지 넣을 유형 핵심 속성 비고
메인 Organization, WebSite name, url, logo, address, telephone, sameAs WebSite는 메인에만
회사소개 Organization (메인에 없으면), BreadcrumbList description, foundingDate, address Organization은 한 곳에 정확하게
사업 영역·서비스 Service, BreadcrumbList name, provider, areaServed, description Service는 리치 결과 대상 아님
제품 목록 BreadcrumbList (필요 시 ItemList) 각 상세 페이지 URL 제품 목록 ItemList는 리치 결과 대상 아님
제품 상세 Product, BreadcrumbList name, image, description, sku, brand, manufacturer 가격·리뷰가 있어야 제품 리치 결과 자격
공지·뉴스 상세 Article(또는 NewsArticle), BreadcrumbList headline, image, datePublished, dateModified, author dateModified는 실제 수정 시각
채용 공고 상세 JobPosting, BreadcrumbList title, datePosted, validThrough, hiringOrganization 마감 공고는 내리거나 validThrough 지정
문의 Organization의 contactPoint telephone, email, contactType 별도 페이지 유형 불필요

💡 실무 팁

값이 없는 속성은 빈 문자열이나 「N/A」로 채우지 말고 아예 빼세요. 날짜 속성(dateModified)에 배포 시각을 넣으면 내용을 고치지 않았는데도 모든 페이지가 「오늘 수정됨」이 됩니다. 데이터베이스에 저장된 실제 수정 시각을 쓰고, 사이트맵의 lastmod와 같은 값을 쓰면 둘이 어긋나지 않습니다.

기업 홈페이지 페이지 유형별 구조화 데이터 매핑 일러스트: 페이지 카드마다 Organization, Product, Article 등 스키마 배지

테스트와 Search Console 확인 방법

구조화 데이터는 넣은 뒤 반드시 도구로 검사합니다. 문법 오류 하나로 스크립트 전체가 무시될 수 있기 때문입니다. 구글이 안내하는 확인 단계는 세 가지입니다.

  1. 리치 결과 테스트: URL이나 코드를 넣으면 구글이 지원하는 리치 결과 유형을 기준으로 오류와 경고를 보여 줍니다. 배포 전에는 코드 붙여넣기로, 배포 후에는 URL로 검사합니다.
  2. URL 검사(Search Console): 구글이 실제로 크롤링한 페이지에서 구조화 데이터를 찾았는지 확인합니다. 자바스크립트로 넣은 JSON-LD가 렌더링 후 보이는지도 여기서 봅니다.
  3. 리치 결과 상태 보고서(Search Console): 사이트 전체에서 유형별 유효·무효 항목 수를 보여 줍니다. 대부분 왼쪽 메뉴의 「개선사항(Enhancements)」 아래에 있고, 제품 스니펫과 판매자 등록정보는 「쇼핑(Shopping)」 아래에 있습니다.

Search Console 보고서는 구글이 리치 결과를 지원하는 유형에만 있습니다. 이동 경로(Breadcrumbs), 제품 스니펫, 판매자 등록정보, 리뷰 스니펫, 채용 정보 등은 보고서가 있지만, Organization과 Article은 별도 보고서가 없습니다. 보고서에서 「무효」는 리치 결과로 표시될 수 없는 치명적 문제가 있다는 뜻이고, 「항목 표시 개선」 표의 경고는 표시는 가능하지만 권장 속성이 빠졌다는 뜻입니다. Search Console의 다른 기능은 구글 서치콘솔 사용법 핵심 기능별 가이드를 참고하세요.

리치 결과 테스트는 구글 지원 유형만 검사하므로, Service처럼 구글이 리치 결과로 쓰지 않는 유형은 schema.org 공식 검사 도구인 Schema Markup Validator로 문법을 확인합니다.

구글 리치 결과 테스트 결과 화면: 이동 경로와 제품 스니펫이 유효한 항목으로 감지된 예시 (예시 일러스트)

자주 하는 실수

  • 화면과 다른 정보: 페이지에 없는 별점, 가격, 수상 내역을 마크업에만 넣는 경우입니다. 구글 가이드라인 위반입니다.
  • 모든 페이지에 같은 Product: 회사소개 페이지에 대표 제품 Product를 넣는 등 페이지 주제와 맞지 않는 마크업은 구조화 데이터가 페이지 내용을 정확히 나타내야 한다는 원칙에 어긋납니다.
  • JSON 문법 오류: 마지막 항목 뒤 쉼표, 따옴표 누락, 한글 큰따옴표(“ ”) 사용이 흔합니다. 워드프로세서에서 복사한 코드는 따옴표가 바뀌어 있는지 확인하세요.
  • 플러그인 중복 출력: 워드프레스에서 SEO 플러그인 두 개가 각각 Organization을 출력해 값이 서로 다른 경우입니다. 페이지 소스에서 application/ld+json을 검색해 몇 개가 나오는지 확인하세요.

자주 묻는 질문

JSON-LD를 넣으면 검색 순위가 오르나요?

구조화 데이터는 순위를 직접 올리는 요소가 아닙니다. 검색엔진이 페이지를 정확하게 이해하고 리치 결과 자격을 얻도록 돕는 역할입니다. 리치 결과로 표시되면 클릭률이 오를 수 있지만, 표시 여부는 구글이 결정합니다. 순위에 영향을 주는 요소는 구글 SEO 최적화 핵심 전략에서 다룹니다.

JSON-LD와 메타태그, OG태그는 무엇이 다른가요?

메타태그는 페이지 제목과 설명을, OG태그는 SNS 공유 시 보이는 미리보기를 정합니다. JSON-LD는 페이지가 다루는 대상(회사, 제품, 기사)과 그 속성을 구조로 표현합니다. 세 가지는 서로 대체하지 않고 함께 씁니다. 자세한 내용은 웹사이트 메타태그 종류와 작성법 총정리와 OG태그 설정 방법 가이드를 참고하세요.

워드프레스는 직접 코드를 넣어야 하나요?

Yoast SEO, Rank Math 같은 SEO 플러그인이 Organization, WebSite, BreadcrumbList, Article 같은 기본 스키마를 자동으로 출력합니다. 플러그인 설정에서 회사명과 로고를 정확히 입력하는 것이 먼저입니다. 제품의 규격·제조사처럼 플러그인이 모르는 정보는 사용자 정의 필드와 함께 테마에서 따로 출력해야 합니다.

네이버도 구조화 데이터를 읽나요?

네이버도 schema.org 구조화 데이터를 읽고, Microdata 또는 JSON-LD 형식을 권장합니다. 다만 지원 유형은 구글과 다릅니다. 서치어드바이저 가이드에 안내된 유형은 사이트 연관채널, 채용정보, 주소(Address), 사이트 이동 경로(BreadcrumbList), 하우투, 캐러셀, 평점, 레시피, 리뷰, 식당, TV 시리즈, 영화, 소프트웨어, 동영상입니다. 자주 묻는 질문(FAQ) 형식은 2026년 7월 9일부터 네이버 웹 검색결과에서도 노출이 종료되었고, 네이버는 남아 있는 FAQ 마크업이 순위나 노출에 영향을 주지 않는다고 안내했습니다. 기업 홈페이지라면 사이트 이동 경로와 주소, 채용 공고가 있을 때 채용정보부터 맞추면 됩니다.

웹닷은 홈페이지를 만들 때 페이지 유형별 스키마 매핑표를 설계 단계에서 확정하고, 회사·제품 데이터에서 JSON-LD가 자동으로 생성되도록 빌드 단계에서 함께 처리합니다. 배포 후에는 전 페이지의 구조화 데이터를 검사해 오류가 없는지 확인합니다.

정리

JSON-LD는 페이지 정보를 검색엔진이 정확하게 읽도록 돕는 구조화 데이터 형식입니다. 기업 홈페이지는 많은 유형이 필요하지 않습니다. Organization, WebSite, BreadcrumbList, Product, Article 다섯 가지를 페이지에 맞게 정확히 넣는 것이 출발점입니다.

  • 구글은 구조화 데이터 형식 중 JSON-LD를 권장하며, 마크업이 정확해도 리치 결과 표시는 보장하지 않습니다.
  • Organization은 메인 또는 회사소개에, WebSite는 메인에만, BreadcrumbList는 하위 페이지 전체에 넣습니다.
  • Product 리치 결과는 name과 함께 review·aggregateRating·offers 중 하나가 필요합니다. 화면에 없는 가격·리뷰는 넣지 않습니다.
  • FAQ 리치 결과는 2026년 5월부터 구글 검색에 표시되지 않습니다. 기존 마크업은 두어도 되지만 새로 공들일 대상은 아닙니다.
  • 페이지 유형별 매핑표를 먼저 정하고, 데이터에서 JSON-LD를 자동 생성하면 값이 어긋나지 않습니다.
  • 리치 결과 테스트, URL 검사, Search Console 리치 결과 상태 보고서로 확인합니다.
이전 가이드 llms.txt 작성법: 형식·예시와 구글 공식 입장까지 정리
다음 가이드 GEO 뜻, 생성형 엔진 최적화란? SEO·AEO와 차이 정리

이 주제에 대해 전문 상담이 필요하신가요?

웹닷이 최적의 솔루션을 제안해드립니다.

무료 상담 문의하기
개발가이드