AEO를 위한 schema markup 작성법과 검증 순서

페이지 HEAD에 schema.org 어휘로 작성한 JSON-LD 블록을 넣습니다. 콘텐츠 글에는 BlogPosting·FAQPage·BreadcrumbList 세 타입을 함께, 회사 사이트에는 Organization·WebSite·Service(또는 Product)를 전역에 둡니다. 구현 포맷은 JSON-LD 하나면 됩니다. Microdata·RDFa도 표준 문서에 있지만, 새로 만드는 사이트에서는 쓸 이유가 없습니다.

AI 검색은 페이지 전체를 요약하는 대신 답변에 쓸 사실 조각만 골라 가져갑니다. 그 발췌가 정확하려면 페이지가 "이건 발행 기관, 이건 질문, 이건 답, 이건 가격"이라고 기계가 읽을 수 있게 표시해야 합니다. schema markup이 그 표시입니다.

AEO에 schema가 왜 필요한가요?

schema는 인용 후보에 오르기 위한 최소 조건입니다. ChatGPT나 Perplexity는 답을 만들 때 페이지에서 어떤 문장을 인용할지 고릅니다. 평문 HTML만 있으면 이 Q&A가 어떤 질문의 답인지, 발행 주체가 누구인지, 제품 가격이 얼마인지가 태그로 표시되지 않아 고를 근거가 흐릿합니다.

Search Engine Land가 2025년 9월 진행한 통제 실험에서는 내용이 같은 두 페이지 중 JSON-LD를 제대로 작성한 페이지만 Google AI Overviews(AI 개요)에 나왔다는 사례가 보고됐습니다. 카테고리 주요 프롬프트에서 인용 비율이 0인 페이지를 열어 보면, 대부분 schema가 없거나 있어도 회사 정보가 페이지마다 어긋나 있습니다.

schema를 넣었다고 답변에 저절로 노출되지는 않습니다. schema가 없으면 후보에서 빠지고, 있어야 후보에 듭니다. 후보 가운데 어떤 페이지가 노출될지는 콘텐츠의 답변 적합성과 회사의 신뢰도가 정합니다.

콘텐츠 글에 넣는 BlogPosting·FAQPage·BreadcrumbList

블로그나 가이드 글 한 페이지에는 세 타입을 함께 넣습니다. 세 타입이 맡는 신호가 겹치지 않아서, 하나만 넣으면 나머지 신호가 빠집니다.

dateModified는 비워 두지 않습니다. AI 답변은 최신 글에 인용 우선순위를 두는 경향이 있어서, 몇 년 전 글로 보이면 그만큼 불리합니다. 문장을 크게 고치지 않았어도 내용을 다시 점검했다면 점검한 날로 날짜를 올립니다.

FAQPage는 세 타입 중 AEO 효과가 가장 직접적입니다. schema.org의 FAQPage 정의대로 mainEntity 배열에 Question을 넣고 각 Question에 acceptedAnswer를 연결하면, 질문과 답 한 쌍이 AI가 그대로 가져다 쓸 수 있는 답변 형태가 됩니다. Google Search Central의 FAQPage 문서는 본문에 실제로 보이는 Q&A만 마크업하도록 정해 두었습니다. 화면에 없는 질문을 schema에만 넣으면 정책 위반입니다.

BreadcrumbList는 AI 엔진이 사이트 구성을 파악하고, Google 데스크톱 검색 결과가 페이지의 사이트 내 위치를 표시할 때 쓰는 값입니다. position·name·item을 순서대로 적기만 하면 되므로 들이는 품에 비해 효과가 좋습니다.

PION 자사 블로그는 글을 발행하면 세 타입이 자동으로 들어갑니다. 본문 FAQ를 className="faq-section" 컨테이너로 감싸면 빌더가 질문과 답을 추출해 FAQPage JSON-LD를 페이지에 넣습니다.

회사 사이트에 넣는 Organization·WebSite·Service/Product

홈·소개·서비스·제품 같은 주요 페이지에는 회사를 하나의 개체로 등록하는 schema를 따로 넣습니다. 개별 글의 schema와 별개로 사이트 전역에 두는 층입니다.

Organization에서 가장 신경 쓸 필드는 sameAs입니다. name·url·logo·description은 대부분 채웁니다. sameAs 배열이 비어 있으면 AI가 "getpion.com의 그 회사"와 "LinkedIn·언론 보도에 나온 그 회사"가 같은 곳인지 대조할 근거가 없어, 인용할 때 회사명 표기가 흔들립니다. LinkedIn·Crunchbase·기사 링크를 걸어도 링크한 페이지들의 사명·도메인·로고가 제각각이면 효과가 없습니다. sameAs는 외부에 같은 이름으로 일관되게 노출돼 있을 때 작동합니다.

WebSite는 도메인 자체의 메타데이터이고, publisher 연결로 개별 글의 BlogPosting과 묶입니다. SearchAction으로 띄우던 검색 결과의 사이트링크 검색창은 Google이 2024년 11월부터 없앴고, 사이트 이름 표시에는 WebSite 구조화 데이터가 계속 쓰입니다.

Service와 Product 중 어느 타입을 쓸지는 사업 모델로 정합니다. PION 같은 마케팅 대행사는 Service, 물건을 파는 이커머스 브랜드는 Product입니다. Product를 쓰는 브랜드가 "크림 가격 얼마" 같은 프롬프트에 인용되려면 sku·brand·offers·aggregateRating까지 모두 채워야 합니다. Service라면 provider(Organization 참조)·areaServed·serviceType·hasOfferCatalog를 둡니다.

JSON-LD는 페이지 어디에 넣나요?

JSON-LD는 보통 페이지 HEAD에 둡니다. BODY 끝에 두어도 작동하지만, HEAD에 있으면 크롤러가 문서 앞부분에서 메타데이터를 먼저 잡습니다. 한 페이지에 schema가 여럿이면 그래프로 묶거나, 타입마다 <script type="application/ld+json"> 블록을 따로 넣습니다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "AEO를 위한 schema markup 어떻게 적용하나요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "페이지 HEAD에 JSON-LD 블록을 삽입하고 ..."
      }
    }
  ]
}
</script>

운영할 때는 아래 규칙을 지킵니다.

• schema 안 텍스트 = 화면 본문 텍스트. 본문에 없는 문장을 schema에만 넣으면 Google 정책 위반이 되고 페널티를 받습니다.
• @id로 개체를 서로 연결합니다. Organization·WebSite·BlogPosting·Person이 @id로 서로를 참조하면 AI 엔진이 사이트 전체를 연결된 개체 묶음으로 인식합니다. 참조가 없으면 같은 사이트의 페이지들을 따로 떨어진 페이지로 인식합니다.

배포 전 검증 순서

schema를 작성했으면 배포 전에 두 도구를 모두 통과시킵니다. 두 도구가 검사하는 대상이 겹치지 않아서 하나로는 부족합니다.

• Google Rich Results Test는 URL이나 코드 스니펫을 넣으면 Google이 인식하는 rich result 타입과 오류·경고를 보여 줍니다. Google의 표시 정책에 맞는지 검사합니다.
• Schema.org Markup Validator는 표준 어휘 자체의 문법을 검사합니다. Rich Results Test가 잡지 못하는 어휘 오류를 여기서 잡습니다.

두 도구를 통과했다는 것은 문법이 맞다는 뜻이고, 실제로 인용되는지는 따로 측정합니다. PION은 클라이언트 사이트를 수정하면 두 도구로 점검한 뒤, AI 엔진(ChatGPT·Perplexity·Gemini(제미나이))에 카테고리 주요 프롬프트를 입력해 인용 비율이 어떻게 움직이는지 측정합니다. schema는 바로 반영되지 않고 다음 색인 주기에 들어가므로, 2~4주 간격으로 다시 측정하는 것을 표준 절차로 둡니다.