구조화 데이터(JSON-LD)로 AI에게 브랜드를 알리는 법

구조화 데이터(JSON-LD)는 “이 사이트를 누가 운영하고, 무엇을 제공하며, 어디에 있는지”를 schema.org 어휘로 적어 두는 기계용 명함입니다. 검색엔진과 AI는 본문을 해석해 추측하는 대신 이 데이터로 브랜드를 하나의 엔티티로 확정할 수 있습니다. 가장 먼저 Organization(매장이 있으면 LocalBusiness 하위 타입)과 WebSite를 서버 HTML에 넣고, sameAs로 공식 채널을 연결하세요.

검색엔진과 AI는 왜 JSON-LD를 읽나요?

JSON-LD는 회사명·주소·저자·날짜 같은 사실을 문장 해석 없이 전달하는, 가장 관리하기 쉬운 형식이기 때문입니다. 구글은 사이트 구조가 허용하면 JSON-LD를 권장하고, 네이버 서치어드바이저도 JSON-LD·Microdata를 권장합니다.

구글은 구조화 데이터를 페이지 이해뿐 아니라 마크업에 담긴 사람·회사 같은 세상의 정보를 모으는 데 쓴다고 설명합니다(구글 구조화 데이터 소개). 마이크로소프트 빙 팀도 2025년 10월 AI 검색 답변 가이드에서 JSON-LD로 콘텐츠 유형을 명시하라고 권했습니다.

브랜드명이 ‘하늘’처럼 흔한 단어라면 본문만으로는 회사 이야기인지 날씨 이야기인지 구분하기 어렵습니다. Organization에 name·url·logo·sameAs가 있으면 “이 도메인의 운영 조직 = 이 인스타그램·네이버 플레이스·위키데이터 항목”이라는 연결이 명시됩니다. 대부분의 AI 크롤러는 자바스크립트를 실행하지 않으므로, 서버 HTML 속 JSON-LD는 그대로 전달되는 ‘확정된 사실’이 됩니다.

어떤 스키마부터 넣어야 하나요?

모든 사이트의 1순위는 브랜드를 선언하는 Organization(매장·병원이면 LocalBusiness 하위 타입)과 사이트 이름을 알리는 WebSite입니다. 그다음 페이지 유형에 맞춰 Article·FAQPage·Product·Service를, 마지막으로 BreadcrumbList를 더합니다.

1. 1순위(홈·회사 소개): Organization 또는 LocalBusiness 하위 타입, WebSite
2. 2순위(페이지 유형별): 글은 Article, FAQ가 보이는 페이지는 FAQPage, 상품은 Product, 서비스 소개는 Service
3. 3순위(구조): 하위 페이지 전체에 BreadcrumbList

구글은 가장 구체적인 하위 타입을 쓰라고 권합니다. 온라인 서비스·B2B는 Organization, 쇼핑몰은 OnlineStore가 기본이며, ProfessionalService는 Service와 혼동된다는 이유로 schema.org가 더 이상 권하지 않으므로 피하세요.

매장형 업종은 여기에 name·address·telephone·url·geo가 기본으로 들어갑니다.

타입별 필수·권장 필드는 무엇인가요?

구글 기준 ‘필수’ 필드는 적지만, AI가 엔티티를 확정하려면 권장 필드까지 채우는 편이 좋습니다. 다만 구글은 많은 필드를 부정확하게 넣기보다 적더라도 완전하고 정확하게 넣으라고 안내합니다.

Article의 author는 사람이면 Person으로 쓰고, name에는 이름만 적은 뒤 저자 페이지를 url로 연결합니다(E-E-A-T와 신뢰 신호 가이드 참고). GEO Check 간편 진단의 ‘구조화 데이터(JSON-LD)’ 항목은 이 권장 필드를 기준으로 엔티티마다 누락 필드와 문법 오류를 표시합니다.

복사해서 쓰는 JSON-LD 예시 3가지

이름·URL·주소만 바꿔 붙여 넣으면 됩니다. 스크립트 블록은 <head>나 <body> 어디든 괜찮지만, 서버가 내려주는 원본 HTML에 있어야 합니다.

① @graph로 Organization과 WebSite 묶기(홈페이지)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.example.com/#organization",
      "name": "예시브랜드",
      "alternateName": ["Example Brand", "예시"],
      "legalName": "주식회사 예시",
      "url": "https://www.example.com/",
      "logo": "https://www.example.com/images/logo-512.png",
      "description": "예시브랜드는 소상공인을 위한 온라인 예약 관리 서비스입니다.",
      "telephone": "+82-2-0000-0000",
      "sameAs": [
        "https://www.instagram.com/examplebrand/",
        "https://www.youtube.com/@examplebrand",
        "https://blog.naver.com/examplebrand",
        "https://www.linkedin.com/company/examplebrand/",
        "https://www.wikidata.org/wiki/Q000000"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://www.example.com/#website",
      "name": "예시브랜드",
      "alternateName": "Example Brand",
      "url": "https://www.example.com/",
      "inLanguage": "ko-KR",
      "publisher": { "@id": "https://www.example.com/#organization" }
    }
  ]
}
</script>

@id는 실제로 열리지 않아도 되는 식별자입니다. 사이트 전체에서 같은 값을 써야 다른 페이지의 Article·Service가 @id만으로 같은 조직을 가리킬 수 있습니다. 위키데이터 항목이 없으면 마지막 sameAs 줄은 지우세요.

② LocalBusiness 하위 타입과 한국 주소(매장·병원 페이지)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://www.example.com/#clinic",
  "name": "예시치과의원",
  "url": "https://www.example.com/",
  "image": "https://www.example.com/images/clinic-front.jpg",
  "telephone": "+82-2-0000-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "테헤란로 123, 4층",
    "addressLocality": "강남구",
    "addressRegion": "서울특별시",
    "postalCode": "06000",
    "addressCountry": "KR"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 37.50056,
    "longitude": 127.03644
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:30",
      "closes": "18:30"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "09:30",
      "closes": "14:00"
    }
  ],
  "sameAs": [
    "https://map.naver.com/p/entry/place/0000000000",
    "https://place.map.kakao.com/00000000",
    "https://www.instagram.com/example_dental/"
  ]
}
</script>

한국 주소는 addressRegion에 시·도, addressLocality에 시·군·구, streetAddress에 도로명·건물번호·층을 넣습니다(네이버 서치어드바이저의 주소 예시와 같은 방식). 표기는 네이버 플레이스·구글 비즈니스 프로필의 도로명주소와 똑같이 맞추고, 지점이 여럿이면 지점 페이지마다 따로 두고 parentOrganization으로 본사 @id를 가리킵니다.

③ FAQPage(실제 FAQ가 있는 페이지)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "주차가 가능한가요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "건물 지하 주차장을 진료 시간 동안 2시간 무료로 이용할 수 있습니다."
      }
    },
    {
      "@type": "Question",
      "name": "토요일에도 진료하나요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "토요일은 오전 9시 30분부터 오후 2시까지 진료합니다."
      }
    }
  ]
}
</script>

질문·답은 화면 문구와 똑같이 쓰고, 영업시간처럼 다른 스키마와 겹치는 값은 서로 일치시킵니다.

sameAs에는 어떤 링크를 넣어야 하나요?

sameAs에는 “이 브랜드가 맞다”고 확인해 주는 공식 프로필 URL만 넣습니다. schema.org는 sameAs를 대상의 정체를 모호함 없이 가리키는 참조 페이지(위키데이터 항목, 공식 사이트 등)로 정의합니다.

• 공식 SNS: 인스타그램, 유튜브, 네이버 블로그, 페이스북, X 등 직접 운영하는 계정
• 지도: 네이버 플레이스(map.naver.com/p/entry/place/장소ID), 카카오맵(place.map.kakao.com/장소ID)
• 위키데이터·링크드인: wikidata.org/wiki/Q로 시작하는 항목(있을 때만), linkedin.com/company/ 회사 페이지

단축 URL(naver.me 등) 대신 전체 주소를 쓰고, 대표자 개인 계정이나 기사 URL은 넣지 않습니다. 각 프로필에도 공식 사이트 주소를 적어 양방향으로 연결하세요. 네이버는 사이트 연관채널 가이드에서 루트 페이지의 Organization·Person 마크업(name·url·sameAs 필수)으로 블로그·스마트스토어·인스타그램·유튜브·카카오톡 채널 등을 알리도록 안내합니다(2026년 9월 기준). 위키데이터 등록과 NAP 정리는 엔티티와 브랜드 신호 가이드에서 다룹니다.

제대로 넣었는지 어떻게 검증하나요?

배포 전에는 Schema Markup Validator로 문법을, 배포 후에는 리치 결과 테스트와 Search Console로 구글이 실제로 읽는지 확인합니다.

1. Schema Markup Validator: 모든 schema.org 타입을 검사합니다. Service나 지원이 끝난 FAQPage는 여기서 확인합니다.
2. 리치 결과 테스트: 구글 지원 유형만 보여 주며, 코드보다 URL로 테스트하는 것이 권장됩니다.
3. Search Console URL 검사: 구글이 렌더링한 HTML에 마크업이 있는지 봅니다.
4. 원본 HTML: 아래 결과가 0이면 JSON-LD가 자바스크립트로만 들어가는 상태일 수 있습니다.

curl -s https://www.example.com/ | grep -c "application/ld+json"

블록 수·타입·누락 필드·문법 오류·sameAs 개수는 무료 간편 진단으로 바로 확인할 수 있습니다.

자주 하는 실수 4가지는 무엇인가요?

가장 흔한 실수는 @graph 구조 오해, 자바스크립트로만 삽입, 화면과 다른 값, FAQ 남용입니다.

1. @graph 중첩 오해

2. 자바스크립트로만 삽입

구글은 렌더링 과정에서 자바스크립트로 넣은 JSON-LD도 읽지만, 대부분의 AI 크롤러는 자바스크립트를 실행하지 않습니다. 태그 관리자로만 넣은 스키마는 AI에게 보이지 않을 수 있으니 서버 HTML에 직접 넣으세요(AI 크롤러와 robots.txt 가이드 참고).

3. 화면과 다른 내용

구글 정책은 보이지 않는 내용의 마크업을 금지하고, 구조화 데이터가 페이지 내용을 사실대로 대표해야 한다고 규정합니다. 화면에 없는 별점, 지난 가격, 네이버 플레이스와 다른 영업시간은 수동 조치로 리치 결과 자격을 잃는 원인이 되고, AI 답변에 틀린 정보가 인용되는 원인도 될 수 있습니다.

4. FAQ 남용

구글은 FAQ 리치 결과를 2023년 8월 권위 있는 정부·보건 사이트로 제한했고, 2026년 5월 7일부터는 표시하지 않습니다(6월 리치 결과 테스트 지원 종료). FAQPage는 여전히 유효한 schema.org 타입이고 쓰이지 않는 구조화 데이터는 검색에 문제를 일으키지 않으므로, 실제 FAQ가 보이는 페이지에만 유지하세요. 질문마다 답 하나, 광고 문구 금지, 같은 FAQ는 한 페이지에만 표시한다는 원칙도 그대로 유효합니다.

배경 설명은 SEO·GEO 가이드북의 Schema Markup·Named Entity 장을 참고하세요.

요약

• 홈에 Organization(또는 LocalBusiness 하위 타입)과 WebSite를 @graph로 넣었다.
• sameAs에 공식 SNS·네이버 플레이스·카카오맵·링크드인·위키데이터를 연결했다.
• 글에는 Person 저자와 dateModified가 있는 Article, 상품·서비스에는 Product·Service를 적용했다.
• JSON-LD가 서버 HTML에 있고, 값이 화면·지도 플랫폼 정보와 일치한다.
• Schema Markup Validator와 리치 결과 테스트로 검증했다.

자주 묻는 질문

함께 읽으면 좋은 가이드