어떤 스키마를 쓸까 — 업종·페이지별 구조화 데이터.

현장에서 가장 많이 받는 질문은 “스키마를 더 넣으면 검색에 더 잘 나오나요?”입니다. 답은 “아니요”에 가깝습니다. 스키마는 점수를 올리는 마법이 아니라, 페이지의 정체를 정확히 말해주는 라벨입니다. 라벨이 틀리거나 화면과 다르면 안 넣느니만 못합니다. 그래서 먼저 “이 페이지는 무엇인가”를 정하고, 그에 맞는 타입을 고르는 순서가 맞습니다.

스키마 타입, 왜 골라 써야 하나요?

검색엔진과 AI는 페이지를 읽을 때 “이건 회사 소개구나”, “이건 글이구나”를 추측합니다. 스키마는 그 추측을 추측이 아니라 확정으로 바꿔줍니다. 그런데 회사 소개 페이지에 Product를 붙이면 라벨이 어긋납니다. 타입을 고른다는 건 결국 “이 페이지의 정체를 정직하게 선언한다”는 뜻입니다.

가장 자주 쓰는 8타입, 언제 무엇을

아래가 실무 빈도가 높은 핵심입니다. 이 안에서 대부분 해결됩니다.

• Organization — 회사·브랜드 그 자체. 사이트 전역의 ‘우리 회사’ 엔티티. 로고·연락처·sameAs(공식 채널)를 담습니다.
• LocalBusiness — 오프라인 매장·지역 영업점. 주소·영업시간·전화로 손님이 찾아오는 곳. Restaurant·Dentist 등 하위 타입이 더 정확합니다.
• Article — 블로그 글·인사이트·뉴스. 제목·저자·발행일·발행사를 담습니다.
• FAQPage — 페이지에 ‘질문–답’ 묶음이 실제로 보일 때. 보이지 않는데 넣으면 정책 위반입니다.
• Product — 판매 상품. 이름·이미지·가격(offers)·재고·리뷰를 담습니다.
• Service — 형체 없는 서비스 제공(컨설팅·제작·수리 등). 제공자·제공 지역·서비스 종류를 담습니다.
• BreadcrumbList — 홈 → 카테고리 → 현재로 이어지는 경로. 검색결과의 경로 표시에 쓰입니다.
• Person — 저자·대표·전문가 개인. Article의 author로 연결해 신뢰(E-E-A-T)를 보강합니다.

업종·페이지별로 정리하면?

LocalBusiness, 직접 한번 만들어볼까요?

가장 문의가 많은 게 지역 업종입니다. 아래 예시를 그대로 복사해 본인 정보로 바꾸면 시작점이 됩니다. (값은 화면에 실제로 보이는 정보와 같아야 합니다.)

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "내 가게",
  "address": { "@type": "PostalAddress", "addressLocality": "서울 강남구" },
  "telephone": "+82-2-000-0000",
  "openingHours": "Mo-Fr 09:00-18:00",
  "url": "https://example.com/"
}

여러 개일 때 @graph로 어떻게 묶나요?

실제 페이지는 보통 한 가지가 아닙니다. 글 페이지라면 Article + Person(저자) + BreadcrumbList가 함께 있죠. 이때 블록을 따로따로 흩어 놓지 말고 @graph 배열 하나에 담습니다. 그리고 핵심은 @id입니다. 저자를 "@id":"https://example.com/#founder"처럼 한 번 정의하고, Article에서는 "author":{"@id":"https://example.com/#founder"}로 참조만 하면, 검색엔진과 AI가 “이 글의 저자 = 이 사람”이라는 관계를 정확히 잇습니다. 같은 회사 정보를 페이지마다 풀어 쓸 필요도 없어집니다.

스키마가 정확하면 AI는 무엇을 더 잘하나요?

두 가지가 좋아집니다. 첫째, 검색에서 리치 결과(평점 별점·FAQ 펼침·경로·사이트링크 등)로 나올 ‘자격’이 생깁니다. 둘째, ChatGPT·Perplexity 같은 AI 답변 엔진이 “이 회사는 무엇을 하고, 어디 있고, 이 글은 누가 썼는지”를 헷갈리지 않고 인용합니다. 자연어 문장은 해석이 갈리지만, @id로 묶인 구조화 데이터는 사실 관계를 못 박아 줍니다.

흔히 하는 실수는 무엇인가요?

가장 잦은 실수는 ‘없는 걸 넣는 것’입니다. FAQ가 화면에 안 보이는데 FAQPage를 넣거나, 리뷰가 없는데 평점을 넣으면 정책 위반입니다. 그다음은 타입 선택 오류(회사인데 Product), 필수 속성 누락(Product의 offers 없음), 그리고 화면 값과 마크업 값의 불일치입니다. 원칙은 하나입니다 — 마크업은 사용자가 실제로 보는 것과 같아야 한다.

작성한 다음, 어떻게 검증하나요?

코드를 넣었다고 끝이 아닙니다. ① 구글 리치 결과 테스트에 URL이나 코드를 붙여 오류·경고를 확인합니다. ② Schema.org Validator로 타입·속성 유효성을 봅니다. ③ 빠르게 자가 점검하려면 JSON이 문법적으로 유효한지(괄호·쉼표)부터 확인하세요. 배포 후에도 검색엔진 콘솔에서 적용 상태를 주기적으로 봅니다.

설명한 ‘여러 개를 @graph로 묶기’가 실제로 어떤 모양인지 보여드리는 게 빠릅니다. 글 페이지의 Article + Person + BreadcrumbList를 한 덩어리로 묶은 예시입니다.

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Person",
      "@id": "https://example.com/#founder",
      "name": "Findable" },
    { "@type": "Article",
      "headline": "글 제목",
      "author": { "@id": "https://example.com/#founder" },
      "datePublished": "2026-06-24" },
    { "@type": "BreadcrumbList",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "홈", "item": "https://example.com/" },
        { "@type": "ListItem", "position": 2, "name": "인사이트", "item": "https://example.com/insights/" }
      ] }
  ]
}

저자를 @id로 한 번 정의하고 Article이 참조만 하니, 관계가 끊기지 않고 회사 정보를 페이지마다 풀어 쓸 필요도 없습니다.

타입을 고를 때 가장 자주 빠뜨리는 게 ‘필수 속성’입니다. 그래서 저는 타입별로 빠지면 안 되는 핵심 속성을 표로 옆에 두고 점검합니다.

필수 속성 누락과 ‘화면에 없는 걸 넣기’가 검증에서 가장 자주 걸립니다. 이 표로 먼저 거르면 리치 결과 테스트를 한 번에 통과하기 쉽습니다.

정리하면, 어디서부터 시작할까요?

“이 페이지는 무엇인가”를 먼저 정하고, 위 8타입 중 해당하는 것만 고르세요. 여러 개면 @graph로 묶고 @id로 잇고, 마지막에 리치 결과 테스트로 검증. 이 순서만 지켜도 대부분의 사이트는 “찾아지는 구조”를 갖춥니다. 무엇을 어디에 넣을지 막막하면 Findable이 페이지별로 설계해 드립니다.