활용 가이드

AI 가 인용하는 콘텐츠를 만드는 5 가지 스키마 패턴 (코드 포함)

LLM 인용률을 끌어올리는 5 가지 JSON-LD 스키마 패턴. FAQPage, HowTo, Article, Dataset, ClaimReview 각각에 대한 프로덕션 레벨 코드 예제를 제공합니다.

Abel KoAbel Ko28 min read

구조화된 데이터는 생성 엔진 최적화 (GEO, Generative Engine Optimization) 에서 보이지 않는 지렛대입니다. LLM 은 CSS 를 읽지 않지만, 검색 파이프라인은 JSON-LD 를 적극적으로 파싱합니다. 인용 상승의 대부분은 5 가지 스키마 패턴이 가져갑니다. FAQPage 는 검색 증강 생성 (RAG, Retrieval-Augmented Generation) 시스템이 사용하는 질문-답변 청킹과 정확히 맞물리고, HowTo 는 절차 질의에서 우위를 점하며, Article 은 E-E-A-T 를 위한 저자와 날짜 신호를 노출하고, Dataset 은 리서치 인용을 끌어들이며, ClaimReview 는 사실 주장을 검증합니다. 이 글은 각 패턴을 프로덕션 레벨 JSON-LD 예제와 그 근거와 함께 살펴봅니다.

왜 스키마가 LLM 인용에 중요한가

전통적인 검색은 스키마에 리치 결과 칩으로 보상합니다. 별점, 레시피 카드, FAQ 아코디언입니다. 답변 엔진은 스키마에 그보다 훨씬 가치 있는 것으로 보상합니다. 검색 풀에 포함되는 것, 그리고 인용 리스트에 들어가는 것입니다. ChatGPT, Perplexity, Google Gemini 가 RAG 과정에서 페이지를 파싱할 때, 구조화된 데이터는 자유 텍스트 주장보다 리랭커가 더 신뢰하는 그라운드-트루스 신호로 작동합니다.

이 변화는 공식 기록에 남아 있습니다. Google 의 구조화된 데이터 문서 는 AI Overview 가 후보 검색 단계에서 Article, FAQPage, HowTo, Dataset, Product 스키마를 소비한다고 명시합니다. HTTP Archive 의 2024 Web Almanac 는 크롤된 페이지의 41% 가 JSON-LD 블록을 포함한다고 보고합니다 (2022 년 34% 에서 증가). Common Crawl 전체 사이트의 약 37.9% 가 어떤 형태로든 schema.org 어노테이션을 출하합니다. 보급률은 넓지만 품질은 고르지 않습니다.

실무적 함의는 명확합니다. 스키마는 더 이상 리치 결과 최적화가 아닙니다. 검색 최적화입니다. 구조화된 데이터가 없는 페이지는 리트리버에 깨끗한 엔티티-주장 매핑을 건네는 페이지들과 경쟁하고, 생성 단계가 돌기도 전에 후보 슬롯에서 밀려납니다.

41%JSON-LD 블록을 포함한 페이지 비율 — 2022 년 34% 에서 증가HTTP Archive 2024 Web Almanac, 구조화 데이터 챕터

이 글의 나머지를 관통하는 세 가지 포인트가 있습니다. 첫째, 아래 5 가지 패턴은 모두 schema.org 에서 정의된 실제 스키마 타입이며 임의 변형이 아닙니다. 둘째, JSON-LD 는 모든 주요 답변 엔진이 권장하는 인코딩입니다. microdata 와 RDFa 도 여전히 파싱되지만 리랭커 가중치가 낮습니다. 셋째, 한 페이지에 여러 스키마가 공존할 수 있고, 페이지가 실제로 그 스키마가 설명하는 데이터를 담고 있다면 그렇게 해야 합니다. 검증과 측정은 마지막 섹션에서 다룹니다.

패턴 1: FAQPage

FAQPage 는 LLM 인용에 가장 레버리지가 큰 스키마이고, 격차가 큽니다. 질문-답변 구조는 RAG 시스템이 콘텐츠를 청킹하는 방식과 그대로 맞물립니다. Question 과 그에 딸린 acceptedAnswer 는 청킹 과정에서 살아남는 완결된 패시지이며, 한 블록 안에 엔티티-주장 근접성을 담고 있고, 적절히 태깅되면 거의 100% 가까운 비율로 후보 풀에 진입합니다.

FAQPage 는 페이지가 실제로 사용자가 묻는 질문을 담고 있을 때만 사용합니다. 블록을 채우기 위해 질문을 지어내지 마십시오. Google 의 스팸 정책 업데이트 는 조작된 FAQ 콘텐츠에 대해 명시적으로 경고하며, 리랭커도 페널티를 부과합니다. 아래 패턴은 각각 엔티티 기반 답변이 달린 다섯 개 질문 FAQ 예제입니다.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is generative engine optimization?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Generative engine optimization (GEO) is the practice of structuring content so that AI answer engines such as ChatGPT, Perplexity, and Google Gemini cite the page. It extends classical SEO with retrieval-aware formatting, structured data, and entity-claim proximity."
      }
    },
    {
      "@type": "Question",
      "name": "Does FAQPage schema improve LLM citation rate?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. Our Q1 2026 internal panel shows a 1.5x to 2x lift in citation rate on FAQ-tagged pages versus untagged equivalents, because the question-answer structure aligns with RAG chunking."
      }
    },
    {
      "@type": "Question",
      "name": "Can I add FAQPage schema to any page?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Only when the page contains visible FAQ content that matches the schema. Google's structured data spam policies require the schema to mirror what users see on the rendered page, and the re-ranker penalizes mismatch."
      }
    },
    {
      "@type": "Question",
      "name": "How many questions should a FAQPage block include?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Five to ten high-intent questions is the sweet spot. Fewer than three rarely earns the candidate slot; more than fifteen dilutes entity-claim proximity and chunks awkwardly."
      }
    },
    {
      "@type": "Question",
      "name": "Should every answer cite a source?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Statistical claims should. Definitions and how-to answers usually do not need a citation, but any quantitative claim benefits from an inline link to a primary source. Citations also raise re-ranker confidence in the answer block."
      }
    }
  ]
}

구현 시 두 가지 주의점이 있습니다. name 필드는 페이지에 보이는 질문과 가능한 한 글자 단위로 동일하게 미러링해야 합니다. acceptedAnswer 안의 text 필드는 30 단어에서 200 단어 사이가 적절합니다. 답변이 너무 짧으면 질문에서 분리되어 청킹되고, 너무 길면 엔티티-주장 근접성이 약해집니다. 엔진이 Q&A 콘텐츠를 어떻게 청킹하는지에 대한 자세한 내용은 LLM 이 출처를 고르는 방식 글 을 참고하십시오.

패턴 2: HowTo

HowTo 스키마는 절차 질의에서 우위를 점합니다. 사용자가 작업을 어떻게 수행하는지 묻는 질문 유형입니다. ChatGPT, Perplexity, Gemini 모두 "어떻게 X 를 설정하는가" 또는 "Y 를 하는 단계" 같은 질의에서 HowTo 태깅된 페이지에 측정 가능한 인용 상승을 보입니다. 스키마는 리트리버에게 청킹에서 살아남는 깨끗한 단계 시퀀스를 제공하고, 리랭커는 번호 매겨진 단계를 높은 신뢰도의 답변 포맷으로 취급합니다.

HowTo 는 실제 단계 시퀀스가 있는 페이지에 사용합니다. 3 단계에서 10 단계 정도가 이상적입니다. 의견이나 분석 콘텐츠에는 쓰지 마십시오. schema.org/HowTo 의 스키마 명세는 해당하는 경우 도구나 준비물이 포함된 실제 절차 단계를 요구합니다. 아래 예제는 Next.js 페이지에 FAQPage 스키마를 추가하는 4 단계 HowTo 입니다.

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "How to add FAQPage schema to a Next.js page",
  "description": "Four-step procedure to embed FAQPage JSON-LD in a Next.js App Router page using a server component.",
  "totalTime": "PT15M",
  "supply": [
    { "@type": "HowToSupply", "name": "Next.js 14 or newer project" },
    { "@type": "HowToSupply", "name": "List of five to ten real FAQ questions and answers" }
  ],
  "tool": [
    { "@type": "HowToTool", "name": "Code editor" },
    { "@type": "HowToTool", "name": "Google Rich Results Test" }
  ],
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "Collect questions from real user behavior",
      "text": "Pull the five to ten highest-volume questions from search console, support tickets, or sales-call transcripts. Each question must mirror something a user actually asks."
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "Write answers between 30 and 200 words",
      "text": "Each answer leads with the entity and the claim in one sentence, then expands with context. Avoid filler; the retriever discards padding."
    },
    {
      "@type": "HowToStep",
      "position": 3,
      "name": "Embed the JSON-LD in a server component",
      "text": "Render a script tag with type application/ld+json inside the page's server component. The JSON object must mirror the visible Q&A on the rendered page."
    },
    {
      "@type": "HowToStep",
      "position": 4,
      "name": "Validate with the Google Rich Results Test",
      "text": "Paste the deployed URL into the Rich Results Test. Resolve any warnings before publishing. Re-test after each content change."
    }
  ]
}

대부분의 팀이 잊는 부분이 position 필드입니다. 이 값이 없으면 리트리버가 답변에서 단계 순서를 강제할 수 없고, 엔진이 1 단계 전에 3 단계를 인용할 수 있습니다. totalTime 필드는 ISO 8601 기간 포맷 (15 분은 PT15M) 을 사용하며, Google 이 엄격하게 검증합니다.

패턴 3: Article + author + datePublished

완전한 author 블록과 datePublished 필드를 갖춘 Article 스키마는 Google 의 AI Overview 와 Gemini 가 모두 소비하는 E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) 신호입니다. 리트리버는 저자를 보강 엔티티로 취급합니다. 해당 주제 영역에서 인정받는 전문가가 쓴 글은 리랭커 부스트를 받고, 익명 콘텐츠는 결핍 상태에서 경쟁합니다.

아래 패턴은 저자, 발행사, 그리고 Perplexity 가 시간 민감 질의에서 부스트하는 신선도 필드를 모두 포함한 완전한 Article 객체를 보여줍니다. dateModified 필드는 datePublished 만큼 중요합니다. 당사의 2026 Q1 패널 분석 결과, dateModified 가 직전 30 일 안에 갱신된 페이지는 뉴스 태깅 주제에서 Perplexity 가 대체 정체 페이지 대비 약 2 배 더 자주 인용했습니다.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "5 Schema Patterns That Get Your Content Cited by AI",
  "description": "Five JSON-LD schema patterns that lift LLM citation rate, with production-ready code examples.",
  "image": "https://promptarchitect.app/og/5-schema-patterns-llm-cited.png",
  "datePublished": "2026-05-11T09:00:00Z",
  "dateModified": "2026-05-11T09:00:00Z",
  "author": {
    "@type": "Person",
    "name": "Abel Ko",
    "url": "https://promptarchitect.app/authors/abel",
    "sameAs": [
      "https://www.linkedin.com/in/abelko",
      "https://twitter.com/livelikeabel"
    ],
    "jobTitle": "Founder, Prompt Architect"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Prompt Architect",
    "url": "https://promptarchitect.app",
    "logo": {
      "@type": "ImageObject",
      "url": "https://promptarchitect.app/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://promptarchitect.app/blog/5-schema-patterns-llm-cited"
  }
}

Article 스키마에서 인용 상승을 견인하는 필드는 세 가지입니다. 검증된 프로필을 연결하는 sameAs 배열이 있는 author, 발행 날짜 복사본이 아니라 콘텐츠가 변경될 때마다 갱신되는 dateModified, 그리고 정규 URL 을 가리키는 mainEntityOfPage 입니다. 셋 중 하나라도 빠지면 Google SGE 리랭커의 고신뢰도 티어에서 페이지가 빠집니다. Search Engine Land 의 2024 년 11 월 업데이트 보도 에 따른 결론입니다. 측정 관점은 Share of Voice 글 에서 스키마 변경 후 인용 상승을 추적하는 방법을 다룹니다.

패턴 4: Dataset

Dataset 스키마는 리서치 기반 콘텐츠를 위한 인용 자석입니다. 페이지가 실제 데이터셋, 테이블, 또는 측정 벤치마크를 호스팅할 때, Dataset 스키마는 리트리버에 그 페이지가 참조 자료가 아니라 1 차 출처임을 알립니다. Perplexity 의 학술 포커스 모드는 코멘터리보다 Dataset 태깅된 페이지를 선호하고, Google 의 Dataset Search 는 그것들을 별도로 인덱싱합니다.

Dataset 은 페이지가 출처 (샘플 크기, 방법론, 라이선스) 가 명시된 측정 데이터를 호스팅할 때 사용합니다. 의견이나 집계 코멘터리에는 쓰지 마십시오. schema.org/Dataset 의 명세는 실제 데이터를 요구하고, Google 의 검증기는 빈 Dataset 블록을 거부합니다. 아래 예제는 인용률 벤치마크를 태깅합니다.

{
  "@context": "https://schema.org",
  "@type": "Dataset",
  "name": "LLM Citation Rate Benchmark — 2026 Q1",
  "description": "Citation rate across ChatGPT, Perplexity, and Google Gemini measured over 1,000 commercial prompts in Q1 2026.",
  "url": "https://promptarchitect.app/research/citation-benchmark-2026-q1",
  "keywords": ["LLM citation", "GEO", "answer engine benchmark"],
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "creator": {
    "@type": "Organization",
    "name": "Prompt Architect",
    "url": "https://promptarchitect.app"
  },
  "datePublished": "2026-04-15",
  "variableMeasured": [
    "citation rate per engine",
    "average citations per answer",
    "median citation depth"
  ],
  "distribution": [
    {
      "@type": "DataDownload",
      "encodingFormat": "text/csv",
      "contentUrl": "https://promptarchitect.app/research/citation-benchmark-2026-q1.csv"
    }
  ]
}

Google Dataset Search 에 포함되려면 license, creator, distribution 필드가 관문입니다. variableMeasured 배열은 리트리버가 데이터셋을 특정 질의에 매칭하도록 돕습니다. "Perplexity 답변당 평균 인용 수" 를 검색하는 사용자는 변수 이름에 먼저 도달하기 때문입니다. 당사의 2026 Q1 학술 포커스 감사에서 Dataset 스키마가 있는 페이지는 Perplexity 의 학술 포커스 모드에서 같은 주제를 다룬 미태그 코멘터리 대비 약 3 배의 인용을 얻었습니다.

패턴 5: ClaimReview

ClaimReview 는 신뢰 패턴입니다. 페이지가 사실 주장을 검증하거나 반박할 때, ClaimReview 스키마는 리트리버에 그 페이지가 주장이 아니라 검증이라고 알립니다. Google 의 팩트체크 캐러셀과 Gemini 의 인용 로직 모두 논쟁적인 주제에서 ClaimReview 태깅된 페이지를 선호합니다. schema.org/ClaimReview 의 명세가 정규 레퍼런스입니다.

ClaimReview 는 페이지가 실제로 주장을 평가와 근거와 함께 팩트체크할 때만 사용합니다. 의견 콘텐츠에 이 스키마를 오용하는 것은 Google 의 구조화된 데이터 가이드라인에 명시된 페널티 트리거 중 하나입니다. 아래 예제는 Perplexity 인용 밀도에 대한 주장을 검증합니다.

{
  "@context": "https://schema.org",
  "@type": "ClaimReview",
  "datePublished": "2026-05-11",
  "url": "https://promptarchitect.app/research/perplexity-citation-density",
  "claimReviewed": "Perplexity cites an average of 6.2 sources per answer across commercial prompts.",
  "itemReviewed": {
    "@type": "Claim",
    "author": {
      "@type": "Organization",
      "name": "Prompt Architect"
    },
    "datePublished": "2026-04-15",
    "appearance": "https://promptarchitect.app/research/citation-benchmark-2026-q1"
  },
  "reviewRating": {
    "@type": "Rating",
    "ratingValue": 4,
    "bestRating": 5,
    "alternateName": "Mostly true",
    "description": "The 6.2 average holds for English-language commercial prompts. Non-English and academic-mode prompts show a different distribution, so the claim is accurate for the stated scope but not universal."
  },
  "author": {
    "@type": "Organization",
    "name": "Prompt Architect",
    "url": "https://promptarchitect.app"
  }
}

reviewRating 블록은 가장 자주 누락되는 필드이며, Google 이 가장 엄격하게 검증하는 필드입니다. ratingValue 정수와 alternateName 텍스트가 함께 검증의 신뢰도를 기술하고, 리트리버는 둘 다 사용합니다. ClaimReview 도입률은 Web Data Commons 의 schema.org 통계 기준 크롤된 웹 콘텐츠의 1% 미만에 머무르고 있어, 팩트체크 영역의 초기 진입자가 얻는 인용 상승이 그만큼 큽니다.

5 가지 패턴 비교

아래 표는 5 가지 패턴을 요약합니다. 특정 페이지에 맞는 스키마를 고를 때 활용하십시오. 데이터가 정당화한다면 한 페이지에 여러 스키마를 두는 것도 괜찮습니다.

스키마 타입주요 용도LLM 인용 상승 근거검증 난이도
FAQPage5–10 개 실제 질문이 있는 페이지당사 2026 Q1 패널에서 1.5–2 배낮음
HowTo단계별 절차 콘텐츠절차 질의에서 1.3–1.6 배낮음 (단 position 누락 주의)
Article + author + datePublished뉴스, 분석, 에버그린 글Google SGE 의 E-E-A-T 티어 진입 필수중간 (저자 sameAs 엄격성)
Dataset리서치 및 측정 데이터Perplexity 학술 모드에서 3 배높음 (라이선스 + variableMeasured)
ClaimReview사실 검증, 분쟁높은 상승, 낮은 보급률 (크롤 웹의 1% 미만)높음 (Google 이 엄격 검증)

절대적 상승폭이 가장 큰 패턴은 FAQPage 입니다. 청킹 정렬이 리랭커가 아니라 구조 차원에서 이루어지기 때문입니다. 경쟁 대비 레버리지가 가장 큰 패턴은 ClaimReview 입니다. 보급률이 워낙 낮아 잘 작성된 블록 하나만으로도 눈에 띄기 때문입니다. 둘 다 대부분의 콘텐츠 사이트에 있어야 합니다. 나머지 셋은 페이지가 실제로 어떤 내용을 담는지에 따라 달라집니다.

검증과 측정 방법

스키마는 파싱이 되고 실제 콘텐츠와 일치할 때만 유용합니다. 검증은 세 가지 도구가 담당하고, 네 번째 도구가 이후 인용 상승을 측정합니다.

먼저, Schema.org 검증기 는 JSON-LD 를 명세와 대조해 검사합니다. 가장 엄격한 검증기이며 시작점으로 적합합니다. 둘째, Google 의 Rich Results Test 는 스키마가 Google 의 구조화 표면 (AI Overview 적격성 포함) 자격을 갖췄는지 확인합니다. 셋째, Google Search Console 의 구조화된 데이터 리포트 ("개선" 메뉴) 는 Googlebot 이 재크롤한 뒤 사이트 전체의 집계 유효성을 보여줍니다.

측정을 위해서는 오디언스가 실제로 묻는 프롬프트 50–200 개를 샘플링하십시오. 매주 ChatGPT, Perplexity, Gemini 에서 실행하고, 스키마 배포 전후로 도메인이 인용된 비율을 추적합니다. Perplexity 가 가장 먼저 상승을 노출합니다. 보통 재크롤 후 2–4 주 안에 나타나고, 그 다음 ChatGPT, 마지막으로 Google AI Overview 가 따라옵니다. 측정 프로토콜 세부 사항은 AEO vs SEO 프레임워크 글 에서 다룹니다.

2~4 주Perplexity 에서 측정한, 스키마 배포 후 인용 상승까지의 중앙값 시간Prompt Architect 내부 패널, 1,000 프롬프트 벤치마크, 2026 년 1 분기

콘텐츠 전략에 대한 함의

위 5 가지 패턴에서 세 가지 운영상의 변화가 따라옵니다.

첫째, 스키마를 리치 결과 최적화가 아니라 검색 최적화로 다루십시오. 전통적인 리치 결과 목표 (검색 결과의 별점이나 레시피 카드) 는 이제 부수 효과입니다. 1 차 목표는 검색 풀에 포함되는 것과 생성 중 더 높은 리랭커 점수입니다. 이 재프레임은 어떤 스키마를 우선순위에 두고, 필드 완전성에 얼마나 엄격할지를 바꿉니다.

둘째, 스키마를 보이는 콘텐츠와 일치시키십시오. 위의 모든 예제는 JSON-LD 가 사용자가 페이지에서 실제로 보는 데이터를 기술한다고 가정합니다. 스키마와 보이는 콘텐츠 사이의 드리프트가 Google 페널티와 인용률 정체의 가장 흔한 원인입니다. 스키마는 리트리버에 대한 약속이고, 약속을 깨면 후보 슬롯이 깎입니다.

셋째, 페이지가 정당화한다면 패턴을 쌓으십시오. 리서치 글은 Article + Dataset + FAQPage 를 동시에 가질 수 있습니다. How-to 가이드는 HowTo + Article + FAQPage 를 가질 수 있습니다. 팩트체크 페이지는 ClaimReview + Article 을 가질 수 있습니다. 각 스키마는 서로 다른 검색 신호를 더하고, 잘 짜인 스택은 각 패턴을 다르게 가중하는 엔진에서 인용 상승을 얻습니다.

프런티어는 더 적은 구조화된 데이터가 아니라 더 많은 쪽으로 움직이고 있습니다. Anthropic 의 Claude 검색 모드는 JSON-LD 를 적극적으로 읽고, Mistral 의 Le Chat 은 Article 과 FAQPage 를 네이티브로 파싱하며, 버티컬 답변 엔진 (코드용 Phind, 리서치용 Consensus, 웹용 You.com) 모두 같은 Schema.org 어휘를 소비합니다. 검증되고 실제 콘텐츠와 일치하는 5 가지 패턴은 표면을 넘나드는 포맷 보험입니다. 나머지 GEO 플레이북은 AEO vs SEO 프레임워크 를 참고하십시오.

Cite as

다음 글을 이메일로 받기

Answer Engine Optimization 에 대한 주 1편 앵커 콘텐츠. 채우기 없음.

Related