schema.org와 JSON-LD 완벽 가이드 — GEO·AEO를 위한 구조화 데이터 실무

schema.org와 JSON-LD, 결론부터 말하면 무엇인가요?

schema.org는 웹 페이지의 내용을 기계가 해석할 수 있게 정리해 둔 공통 어휘집이고, JSON-LD는 그 어휘를 실제 페이지에 코드로 싣는 표기 형식입니다. 예를 들어 ‘이 페이지는 회사 소개다’라는 사실을 사람은 로고와 문장으로 알아채지만, 기계는 "@type": "Organization"이라고 적혀 있을 때 훨씬 적은 오해로 받아들입니다. 어휘(schema.org)가 ‘무엇을 말할 수 있는지’를 정하고, 형식(JSON-LD)이 ‘어떻게 적을지’를 정합니다.

GEO·AEO 맥락에서 이게 왜 중요한지는 두 문장으로 정리됩니다. 첫째, 검색엔진과 AI 답변 엔진은 페이지의 글자만이 아니라 ‘이 페이지가 무엇에 대한 것인지’를 명시된 데이터로 읽을 때 오해 없이 인용합니다. 둘째, 회사명·저자·발행일·질문과 답 같은 항목이 본문 어딘가에 흩어져 있을 때보다 구조화된 형태로 선언돼 있을 때, 그 값을 그대로 가져다 쓰는 쪽이 기계 입장에서 비용이 훨씬 낮습니다.

그럼에도 구조화 데이터를 권하는 이유는 비용 대비 확실성에 있습니다. 콘텐츠 품질이나 링크는 결과가 확률적이지만, 스키마는 ‘넣었거나 안 넣었거나’가 명확하고 검증 도구로 즉시 확인됩니다. AI 답변 엔진이 페이지를 파싱할 때 발행일이 dateModified로 선언돼 있으면 최신성을 판단할 재료가 생기고, 저자가 Person 노드로 연결돼 있으면 ‘누가 쓴 글인지’를 따로 추론하지 않아도 됩니다. 이 차이가 인용 여부를 결정한다고 단정할 수는 없지만, 적어도 잘못 읽힐 여지를 줄이는 작업인 것은 분명합니다.

누가 이 작업을 해야 하나요?

실무에서는 마케팅 담당자가 ‘무엇을 선언할지’를 정하고, 웹 담당자나 개발자가 ‘어디에 어떻게 넣을지’를 처리하는 분업이 일반적입니다. 회사명 표기, 대표 연락처, 사업 영역 키워드, 저자 정책 같은 것은 개발자가 정할 수 없습니다. 반대로 템플릿 어디에 스크립트를 주입할지는 마케터가 정할 수 없습니다. 이 경계를 흐리면 ‘누군가 하겠지’ 상태로 몇 달이 흘러갑니다.

schema.org와 JSON-LD는 어떻게 다른가요?

한 줄로 나누면, schema.org는 ‘단어장’이고 JSON-LD는 ‘문법과 표기법’입니다. 같은 어휘를 Microdata나 RDFa로 적을 수도 있고, 같은 JSON-LD 형식으로 schema.org가 아닌 다른 어휘를 실을 수도 있습니다. 둘이 자주 붙어 다니는 이유는 구글이 ‘schema.org 어휘를 JSON-LD로 표기’하는 조합을 권장해 왔기 때문입니다.

JSON-LD를 권하는 이유는 두 가지입니다. 구글이 공식적으로 JSON-LD를 권장 형식으로 안내하고, 마크업이 HTML 구조와 분리돼 있어 디자인 개편이나 템플릿 수정 때 깨지지 않습니다. Microdata는 <div> 하나만 옮겨도 마크업이 어긋나지만, JSON-LD는 스크립트 블록 하나가 독립적으로 존재합니다. 유지보수 관점에서 차이가 큽니다.

다만 이미 Microdata로 구현된 사이트를 급하게 갈아엎을 필요는 없습니다. 구글은 세 형식을 모두 읽습니다. 문제는 같은 정보를 두 형식으로 중복 선언하면서 값이 서로 다른 경우인데, 이럴 때 어느 쪽이 채택될지는 통제하기 어렵습니다. 리뉴얼 시점에 JSON-LD로 일원화하는 편이 깔끔합니다. CMS별 구현 난이도 차이가 궁금하다면 SEO·GEO 마케팅 위한 CMS 비교를 함께 보면 판단이 빠릅니다.

GEO·AEO에서 특히 중요한 스키마 타입은 무엇인가요?

전부 다 넣을 필요는 없고, 기관 정체성·문서 정체성·저자 정체성·구조 이 네 축을 덮는 7가지면 대부분의 B2B 사이트에 충분합니다. 이커머스가 아니라면 Product나 Offer는 건드릴 일이 없고, 오히려 Organization 하나를 제대로 잡는 편이 효과가 큽니다.

FAQPage는 아직 의미가 있나요?

리치 결과 노출 용도로는 사실상 끝났지만, AI 답변 엔진이 질문-답 쌍을 읽는 용도로는 여전히 유효합니다. 구글은 2023년 8월 FAQ 리치 결과 표시를 정부·의료 등 권위 있는 사이트 위주로 제한한다고 공지했습니다. 즉 일반 기업 사이트는 FAQPage를 넣어도 검색결과에 아코디언 형태가 노출되지 않습니다.

그렇다고 마크업 자체가 무용해지지는 않습니다. 구조화된 Question/Answer 쌍은 ‘이 질문에 대한 답이 여기 있다’는 사실을 가장 명시적으로 알리는 형태이고, 답변 엔진이 문서를 청크로 쪼개 색인할 때 경계가 명확한 텍스트 조각을 만들어 줍니다. 노출용이 아니라 인용용으로 유지한다는 관점으로 목적을 바꾸면 됩니다. 이 구분을 못 하고 ‘어차피 리치 결과 안 나오니 빼자’고 결정하는 경우가 실무에서 자주 보입니다.

참고로 HowTo 리치 결과도 2023년 구글 검색결과에서 제외됐습니다. 단계별 가이드 콘텐츠에 HowTo를 붙이는 작업은 우선순위를 낮춰도 무방합니다.

@id와 @graph로 노드를 잇는다는 게 무슨 뜻인가요?

@id는 각 노드에 고유 주소를 붙이는 장치이고, @graph는 여러 노드를 한 스크립트 안에 묶어 서로 참조하게 만드는 컨테이너입니다. Organization을 한 번 정의해 https://bpxg.io/#organization이라는 @id를 부여해 두면, 이후 모든 글의 publisher와 저자의 worksFor는 그 주소를 참조만 하면 됩니다. 값을 매번 복사해 넣을 필요가 없습니다.

왜 이렇게 해야 하는지는 반대 상황을 떠올리면 명확합니다. 페이지 A에서는 publisher 이름이 ‘BPXG’, 페이지 B에서는 ‘주식회사 비피엑스지’, 페이지 C에서는 ‘BPXG – 비피엑스지’라면 기계 입장에서는 세 개의 다른 기관일 가능성을 배제할 수 없습니다. 엔티티가 흩어지면 ‘이 회사에 대해 알려진 것’이 세 덩어리로 쪼개지고, 어느 덩어리도 충분히 두텁지 않게 됩니다. GEO에서 기관 엔티티를 하나로 모으는 일은 개별 글의 품질만큼 중요합니다.

@id는 반드시 실재하는 URL일 필요는 없지만, 사이트 내에서 절대 변하지 않는 문자열이어야 합니다. 관행적으로 도메인/#organization, 페이지URL/#article, 도메인/#/schema/person/1 같은 프래그먼트 형태를 씁니다. 도메인을 바꾸면 @id도 전부 바뀌므로, 도메인 변경은 구조화 데이터 관점에서도 가벼운 작업이 아닙니다.

페이지 하나에 스크립트는 몇 개까지?

구글은 한 페이지에 여러 개의 ld+json 블록이 있어도 모두 읽습니다. 다만 노드 간 참조를 쓰려면 같은 @graph 안에 두는 편이 안전합니다. 워드프레스에서 Yoast나 Rank Math를 쓰면 이미 플러그인이 하나의 @graph를 만들고 있으므로, 별도 스크립트를 추가하기보다 그 그래프에 노드를 보태는 필터를 쓰는 쪽을 권합니다. 두 개의 그래프가 각자 Organization을 정의하면 앞서 말한 엔티티 분산이 자기 사이트 안에서 일어납니다.

실제로 쓰는 JSON-LD 예시 코드는 어떻게 생겼나요?

아래 세 블록이 B2B 사이트에서 가장 자주 쓰이는 조합입니다. (a) 전역 Organization, (b) 글마다 붙는 BlogPosting + Person 저자, (c) 글 하단 FAQ. 값은 BPXG의 실제 정보를 넣었으니 자기 회사 정보로 바꿔 쓰면 됩니다.

(a) Organization — 사이트 전역에 한 번

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://bpxg.io/#organization",
  "name": "BPXG - 비피엑스지",
  "url": "https://bpxg.io/",
  "logo": {
    "@type": "ImageObject",
    "url": "https://bpxg.io/logo.png"
  },
  "email": "business@bpxg.io",
  "telephone": "+82-10-5689-1235",
  "sameAs": [
    "https://www.linkedin.com/company/bpxg/"
  ],
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "중화산로 68, 2층 201호",
    "addressLocality": "전주시 완산구",
    "addressRegion": "전북특별자치도",
    "addressCountry": "KR"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "sales",
    "email": "business@bpxg.io",
    "telephone": "+82-10-5689-1235",
    "availableLanguage": ["ko", "en"]
  },
  "knowsAbout": [
    "GEO 마케팅",
    "AEO 마케팅",
    "SEO",
    "Generative Engine Optimization",
    "Answer Engine Optimization"
  ]
}
</script>

knowsAbout은 리치 결과와 직접 연결되는 속성은 아니지만, 기관이 어떤 주제에 대해 아는지를 명시하는 몇 안 되는 속성입니다. 5~10개 수준으로 실제 사업 영역만 넣습니다. 욕심내서 20개를 넣으면 신호가 희석됩니다.

(b) BlogPosting + Person 저자

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "BlogPosting",
      "@id": "https://bpxg.io/aeo-marketing-agency-cost-deliverables-guide/#article",
      "headline": "AEO 마케팅 대행사는 뭘 해 주나요? 비용·산출물·성과 측정 판단 가이드",
      "url": "https://bpxg.io/aeo-marketing-agency-cost-deliverables-guide/",
      "datePublished": "2026-09-13",
      "dateModified": "2026-09-13",
      "inLanguage": "ko-KR",
      "image": ["https://bpxg.io/images/aeo-agency-guide.jpg"],
      "publisher": { "@id": "https://bpxg.io/#organization" },
      "author": { "@id": "https://bpxg.io/#/schema/person/content-team" },
      "mainEntityOfPage": {
        "@type": "WebPage",
        "@id": "https://bpxg.io/aeo-marketing-agency-cost-deliverables-guide/"
      }
    },
    {
      "@type": "Person",
      "@id": "https://bpxg.io/#/schema/person/content-team",
      "name": "BPXG 콘텐츠팀",
      "jobTitle": "GEO·AEO 컨설턴트",
      "worksFor": { "@id": "https://bpxg.io/#organization" },
      "url": "https://bpxg.io/"
    }
  ]
}
</script>

여기서 핵심은 publisher와 worksFor가 값을 복사하지 않고 @id로 참조만 한다는 점입니다. 회사 주소나 연락처가 바뀌어도 Organization 노드 한 곳만 고치면 전체 글에 반영됩니다. 저자가 실명 개인이라면 sameAs에 링크드인 프로필을, 자격이 있다면 hasCredential에 EducationalOccupationalCredential 객체를 붙입니다.

(c) FAQPage

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "@id": "https://bpxg.io/schema-org-json-ld-geo-aeo-guide/#faq",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "구조화 데이터를 넣으면 순위가 오르나요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "아닙니다. 구글은 구조화 데이터를 순위 요소가 아니라 콘텐츠 이해를 돕고 일부 검색 기능의 자격을 얻기 위한 수단으로 안내합니다. 넣었다고 상위 노출이 보장되지는 않으며, 잘못 읽힐 여지를 줄이는 장치로 이해하는 편이 정확합니다."
      }
    },
    {
      "@type": "Question",
      "name": "JSON-LD는 head와 body 중 어디에 넣나요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "둘 다 가능합니다. 구글은 head와 body 어느 쪽에 있든 JSON-LD를 읽습니다. 다만 템플릿 관리 편의를 위해 head에 두는 경우가 많고, 자바스크립트로 주입하는 경우에는 렌더링 시점에 실제로 삽입되는지 리치 결과 테스트로 확인해야 합니다."
      }
    }
  ]
}
</script>

FAQPage를 쓸 때 지켜야 할 규칙 하나는 화면에 보이는 FAQ 섹션이 실제로 있어야 한다는 것입니다. 마크업에만 존재하는 질문-답은 구글 스팸 정책 위반이고, 수동 조치 대상입니다. 이 원칙은 모든 타입에 공통으로 적용됩니다.

JSON-LD는 어디에 넣고 어떻게 검증하나요?

<script type="application/ld+json"> 블록을 head 또는 body에 넣으면 되고, 구글은 둘 다 읽습니다. 위치보다 중요한 것은 ‘최종 렌더링된 HTML에 실제로 존재하는가’입니다. 서버에서 출력하면 문제가 없지만, 클라이언트 자바스크립트로 주입하는 구조라면 크롤러가 렌더링 단계까지 도달했을 때만 인식됩니다. 이 경우 반드시 렌더링 결과 기준으로 확인해야 합니다.

CMS별 구현 방식

• 워드프레스 — Yoast SEO나 Rank Math가 이미 Organization·WebSite·Article을 포함한 @graph를 생성합니다. 플러그인 그래프를 끄고 직접 짜기보다, 제공되는 필터로 노드를 보태거나 값을 덮어쓰는 방식이 안전합니다. 중복 정의가 가장 흔한 사고 원인입니다.
• Ghost·헤드리스 CMS — 테마 템플릿에서 직접 출력합니다. 자유도가 높은 대신 글 타입별 분기를 직접 관리해야 합니다.
• 사내 개발 사이트 — 공통 레이아웃에 Organization을, 글 템플릿에 Article을 넣는 2층 구조로 설계하면 유지보수가 쉽습니다.

검증은 두 가지 도구로

두 검증 도구의 역할이 다르다는 점을 놓치면 혼란이 생깁니다. 리치 결과 테스트에서 ‘감지된 항목 없음’이 떠도 schema.org 문법상으로는 완벽히 유효한 마크업일 수 있습니다. 구글이 리치 결과로 쓰지 않는 타입일 뿐입니다. GEO 목적의 마크업은 애초에 리치 결과가 목표가 아니므로, 이 경우 validator.schema.org 결과를 기준으로 삼습니다.

구조화 데이터에서 흔히 저지르는 실수 6가지는?

대부분의 실수는 기술 문제가 아니라 운영 문제입니다. 처음 세팅은 잘해 놓고 6개월 뒤에 무너지는 패턴이 가장 많습니다.

1. 화면에 없는 내용을 마크업 — 가장 위험합니다. 구글 스팸 정책의 명시적 위반 항목이고, 리치 결과 자격 상실이나 수동 조치로 이어질 수 있습니다. FAQ를 늘리려고 페이지에 없는 질문을 마크업에만 넣는 사례가 대표적입니다.
2. 페이지마다 Organization을 다르게 정의 — 플러그인이 만든 그래프와 개발자가 추가한 스크립트가 각각 회사를 정의하면, 같은 페이지 안에서 엔티티가 둘로 갈립니다. @id 통일로 해결합니다.
3. dateModified를 안 올림 — 본문은 고쳤는데 날짜는 2년 전 그대로인 경우입니다. 최신성이 중요한 주제에서 이 값은 인용 판단 재료가 됩니다. 반대로 내용을 안 고치고 날짜만 올리는 것도 하지 말아야 합니다.
4. author를 문자열로만 — "author": "홍길동"은 유효하지만 아무 연결도 만들지 않습니다. Person 노드로 만들고 @id·worksFor·sameAs를 붙여야 저자 엔티티가 축적됩니다.
5. 이미지 없는 Article — image는 권장 속성이지만 누락 시 경고가 뜨고, 일부 기능 자격에서 제외됩니다. 대표 이미지 URL은 절대경로로 넣습니다.
6. FAQ를 광고 문구로 채움 — ‘왜 우리 회사를 선택해야 하나요?’ 같은 항목은 질문이 아니라 홍보입니다. 실제 검색 질의에 대응하는 질문만 넣습니다. 답변 엔진이 인용할 만한 형태인지가 기준입니다.

네이버에서도 JSON-LD가 통하나요?

통합니다. 네이버도 JSON-LD를 읽습니다. 네이버 서치어드바이저 웹마스터 가이드는 구조화 데이터 마크업을 권장 항목으로 다루고, 수집 과정에서 파싱한 정보를 검색결과 표시에 활용합니다. 물론 노출 형태는 구글과 같지 않고, 가이드가 강조하는 정확한 title·description, Open Graph 태그, 사이트 정보의 일관성이 여전히 기본이라는 점도 함께 기억해야 합니다.

그래서 한국 시장을 대상으로 하는 사이트의 현실적인 결론은 하나의 구조화 데이터를 제대로 갖추면 구글·AI 답변 엔진과 네이버에 동시에 통한다는 것입니다. 스키마를 검색엔진별로 나눠 만들 이유는 없습니다. 여기에 OG·메타 태그를 같이 관리하면 되는데, OG 태그는 카카오톡·슬랙 공유 미리보기에도 그대로 쓰이므로 투자 대비 회수가 빠른 쪽입니다.

다만 네이버 AI 브리핑이 구조화 데이터를 어떤 방식으로 참조하는지는 공개된 자료가 없습니다. 추정으로 예산을 배분하지 마시고, 네이버 대응은 서치어드바이저 가이드에 명시된 항목(수집·색인 허용, 사이트맵, RSS, 메타 태그 정확성)을 채운 뒤 같은 JSON-LD를 그대로 쓰는 순서가 안전합니다. 국내 검색 생태계와 글로벌 답변 엔진을 동시에 다루는 전체 그림은 온사이트 SEO vs 오프사이트 SEO 글에서 정리한 구분과 함께 보면 이해가 빠릅니다.

측정은 어떻게 하나요?

구조화 데이터의 효과를 단독 지표로 분리하기는 어렵습니다. 현실적으로는 Search Console ‘개선사항’ 보고서의 유효 항목 수를 위생 지표로 보고, 실제 성과는 AI 답변에서의 인용 여부로 봅니다. 인용 추적 방법은 AI SoV 측정 프레임워크에서 다뤘습니다. ‘스키마를 넣었더니 인용이 늘었다’는 인과를 단정할 수 없다는 점은 보고서에도 그대로 적는 편이 낫습니다.

대행사에게 무엇을 확인해야 하나요?

세 가지만 물어보면 구조화 데이터를 실제로 다루는 팀인지 아닌지가 갈립니다. 제안서에 ‘schema.org 마크업 적용’이라고 한 줄 적혀 있는 것만으로는 아무것도 확인되지 않습니다.

1. 발행하는 글마다 Article·FAQ 스키마가 실제로 들어가는가 — 확인 방법은 간단합니다. 그 대행사가 운영하는 사이트나 기존 고객사 페이지에서 소스 보기를 열고 ld+json을 검색하세요. 한 건도 안 나오면 답은 끝난 것입니다.
2. Organization @id가 하나로 통일돼 있는가 — 같은 사이트의 서로 다른 페이지 두 곳을 열어 Organization 노드의 @id와 name 값을 비교합니다. 다르면 엔티티가 분산돼 있는 상태입니다.
3. 검증 결과를 산출물로 주는가 — 리치 결과 테스트와 validator.schema.org 결과 화면을 월간 보고에 포함하는지 물어보세요. 오류 0건을 자랑하라는 게 아니라, 점검 절차가 운영에 들어 있는지를 보는 질문입니다.

대행사 계약 전 비용 구간과 산출물 목록을 어떻게 비교할지는 AEO 마케팅 대행사는 뭘 해 주나요?에서 항목별로 정리해 뒀습니다. 금융업처럼 표기 규제가 따르는 업종이라면 금융회사 SEO·GEO 전략 쪽 기준을 함께 보셔야 합니다.

BPXG는 발행하는 모든 글에 BlogPosting·FAQPage·Organization 스키마를 자동으로 싣고, @id 기준으로 기관 엔티티를 하나로 유지합니다. 구조화 데이터 현황 점검이나 GEO·AEO 전략 상담이 필요하시면 business@bpxg.io로 문의 주세요.

자주 묻는 질문

참고 자료

아래는 본문 서술의 바탕이 된 공개 자료입니다.

• Google — Intro to how structured data markup works (Google Search Central)
• Google — Structured data markup that Google Search supports
• schema.org — Schema Markup Validator
• 네이버 — 네이버 서치어드바이저 웹마스터 가이드