FAQPage·Product·Organization 스키마는 어떻게 작성하나요?

FAQPage는 mainEntity 배열에 Question을 넣고 각 Question에 acceptedAnswer(Answer)를 연결한다. Product는 sku·brand·offers·aggregateRating까지 채워야 가격·평점 인용 자격이 생긴다. Organization은 name·url·logo·description·sameAs·founder·foundingDate를 채우되, sameAs로 LinkedIn·Crunchbase·언론 보도 같은 외부 기준점을 걸어 회사 개체의 동일성을 확인시킨다.

schema markup을 JSON-LD로만 작성해야 하나요?

2026년 신규 사이트는 JSON-LD 하나만 쓴다. Microdata·RDFa는 schema.org 표준에 남아 있지만 Google이 JSON-LD를 권장 포맷으로 못 박았고 실무에서는 사실상 끝났다. JSON-LD는 HTML 본문과 분리된 script 블록이라, 콘텐츠를 수정해도 schema가 깨질 위험이 가장 낮다는 장점도 있다.

schema markup을 적용하면 AI 답변에 바로 노출되나요?

바로 뜨지 않는다. schema는 인용 자격을 여는 게이트일 뿐, 실제 노출은 콘텐츠의 답변 적합성·회사 개체의 신뢰도·사이트 권위가 결정한다. AI 엔진의 색인 갱신 주기가 24주이므로, schema 배포 후 한 달쯤 시점에 재측정해야 변화가 잡힌다.

schema markup 검증은 어디서 하나요?

Google Rich Results Test와 Schema.org Markup Validator 두 도구를 다 쓴다. 전자는 Google의 표시 정책 기준, 후자는 schema.org 표준 어휘의 문법 기준이라 성격이 다르다. 두 도구의 오류·경고를 모두 해소한 뒤 배포하고, schema 안 텍스트와 화면 본문 텍스트가 정확히 일치하는지 다시 확인한다.

AEO schema markup 완전 가이드 — FAQPage·Product·Organization (2026)

AI 검색은 페이지를 통째로 읽고 요약하지 않는다. 답변에 쓸 사실 조각만 골라 뽑는다. 그 발췌가 정확하려면 페이지가 "이건 발행 기관, 이건 질문, 이건 답, 이건 가격"이라고 기계가 읽을 수 있게 스스로 선언해야 한다. schema markup이 바로 그 선언서다.

짧은 답: 페이지 HEAD에 schema.org 어휘로 짠 JSON-LD 블록을 넣는다. 콘텐츠 글에는 BlogPosting·FAQPage·BreadcrumbList 세 개를 한 세트로, 회사 사이트에는 Organization·WebSite·Service(또는 Product)를 전역에 둔다. 구현 포맷은 JSON-LD 하나로 정리됐다. Microdata·RDFa는 표준 문서에만 남았을 뿐 실무에서는 끝났으니, 새로 만드는 사이트에서는 쳐다볼 필요가 없다.

왜 schema가 AEO의 최소 자격 조건인가

schema는 노출을 밀어올리는 장치가 아니다. 인용 후보군에 이름을 올리는 입장권이다. ChatGPT나 Perplexity가 답을 지을 때 이 페이지에서 어떤 문장을 인용할지 정하는데, 평문 HTML만 있으면 판단할 근거가 흐릿하다. 이 Q&A가 무슨 질문의 답인지, 발행 주체가 누구인지, 제품 가격이 얼마인지가 태그로 못 박혀 있지 않기 때문이다.

Search Engine Land가 2025년 9월 돌린 통제 실험에서, 내용이 똑같은 두 페이지 중 잘 짜인 JSON-LD가 붙은 쪽만 Google AI Overviews에 등장한 사례가 보고됐다. 실무 감각도 이와 어긋나지 않는다. 카테고리 핵심 프롬프트에서 인용률이 0인 페이지를 뜯어보면 schema가 아예 없거나, 있어도 회사 정보가 페이지마다 어긋나 있는 경우가 대부분이다.

다만 오해는 말자. schema를 붙였다고 답변에 저절로 뜨는 게 아니다. 없으면 아예 심사 대상에서 빠지고, 있어야 비로소 후보에 낀다. 거기서부터 노출을 가르는 건 콘텐츠의 답변 적합성과 회사의 신뢰도라는, 다음 단계의 문제다.

콘텐츠 글: BlogPosting + FAQPage + BreadcrumbList 세 개를 한 세트로

블로그나 가이드 글 한 페이지에는 세 타입을 묶어서 넣는다. 셋이 각각 다른 신호를 담당하기 때문에 하나만 붙이면 반쪽짜리가 된다.

타입	담당 신호	꼭 채우는 필드
BlogPosting	누가·언제·무슨 주제의 글인가	headline, datePublished, dateModified, author, publisher, mainEntityOfPage
FAQPage	이 페이지의 질문–답 쌍	mainEntity[] 안의 Question → acceptedAnswer(Answer)
BreadcrumbList	사이트 안에서 이 글의 위치	itemListElement의 position, name, item

dateModified를 비워두지 마라. AI 답변은 최신 글에 인용 우선순위를 준다. 몇 년 전 글로 보이면 그만큼 손해다. 문장을 크게 뜯어고치지 않았더라도 내용을 한 번 훑어 점검했다면, 그 시점으로 날짜를 올려두는 게 맞다.

FAQPage는 세 개 중 AEO 효과가 가장 직접적이다. schema.org의 FAQPage 정의대로 mainEntity 배열에 Question을 넣고 각 Question에 acceptedAnswer를 연결하면, 질문–답 한 쌍이 AI가 그대로 가져다 쓸 수 있는 완성된 답변 형태가 된다. 단, Google Search Central의 FAQPage 문서가 못 박은 원칙이 있다. 본문에 실제로 보이는 Q&A만 마크업할 것. 화면에 없는 질문을 schema에만 몰래 넣으면 정책 위반이다.

BreadcrumbList는 눈에 안 띄지만 빼면 아깝다. AI 엔진이 사이트 구조를 파악하고, Knowledge Panel이 출처 경로를 표기할 때 이 값을 쓴다. 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·기사 링크만 걸어두면 되는 것도 아니다. 정작 그쪽에서 사명·도메인·로고가 제각각이면 효력이 죽는다. 외부에 같은 이름으로 일관되게 노출돼 있을 때만 이 필드가 산다.

WebSite는 도메인 자체의 메타데이터다. SearchAction을 같이 두면 Knowledge Panel에 사이트 내 검색창이 뜰 수 있고, publisher 연결로 개별 글의 BlogPosting과 묶인다.

Service냐 Product냐는 사업 모델이 정한다. PION 같은 마케팅 대행사는 Service, 물건을 파는 이커머스 브랜드는 Product다. 이 선택을 대충 하면 손해가 크다. 예를 들어 "○○ 크림 가격 얼마" 같은 프롬프트에 인용되려면 Product의 sku·brand·offers·aggregateRating까지 다 채워야 한다. Service라면 provider(Organization 참조)·areaServed·serviceType·hasOfferCatalog를 둔다.

어디에, 어떤 모양으로 넣는가

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가 잡지 못하는 어휘 오류를 여기서 잡는다.

여기서 실무의 현실을 하나 짚어야겠다. 두 도구를 통과했다고 AI 답변에 뜨는 게 아니다. 검증 통과는 문법이 맞다는 뜻일 뿐, 실제 인용은 그다음 문제다. 그래서 대행사 PION이 클라이언트 사이트를 손볼 때는, 두 도구로 한 번 걸러낸 뒤 실제 AI 엔진(ChatGPT·Perplexity·Gemini)에 카테고리 핵심 프롬프트를 던져 인용률이 어떻게 움직이는지 후속 측정으로 확인한다. schema는 결과가 즉시 잡히지 않고 다음 색인 사이클에 반영되므로, 2~4주 간격 재측정을 표준 절차로 둔다.

AEO를 위한 schema markup 완전 가이드 — FAQPage·Product·Organization