AI 답변을 위한 Schema.org: 2026년에 중요한 것

구조화 데이터는 조용히 독자층을 바꿔놓았다. 10년 동안 그것은 검색 페이지에서 리치 결과를 얻기 위해 존재했지만, 이제는 언어 모델에게 제품에 대한 사실을 진술하는 가장 신뢰할 수 있는 방법이기도 하다. 어시스턴트는 자신 있게 파싱할 수 있는 페이지를 인용하며, JSON-LD는 "이 문자열은 제품 이름이고, 이 숫자는 가격이며, 이 날짜는 마지막 업데이트다"라고 산문이 그것을 명확히 해주기를 바라지 않고도 말할 수 있는 유일한 곳이다.

이것은 완전한 schema.org 강좌가 아니다. 창업자를 위한 우선순위다: 해볼 가치가 있는 네 가지 유형, 건너뛸 하나, 그리고 나머지를 조용히 무효화하는 실수들.

우선순위

1. Organization — 정체성의 닻

AI 답변에서 단일 최고 가치 블록이다. 어시스턴트가 누가 주장을 하는지를 해석하는 방식이 바로 이것이다: 이름, 법적 정체성, 로고, same-as 프로필, 연락처. 당신이 게시하는 다른 모든 사실은 이 닻을 기준으로 귀속된다.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "aat.ee",
  "url": "https://www.aat.ee",
  "logo": "https://www.aat.ee/logo.svg",
  "sameAs": ["https://github.com/yeagoo/Open-Launch"]
}

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "aat.ee",
  "url": "https://www.aat.ee",
  "logo": "https://www.aat.ee/logo.svg",
  "sameAs": ["https://github.com/yeagoo/Open-Launch"]
}

sameAs 배열은 보기보다 더 중요하다: 그것은 당신의 정체성을 모델이 이미 알고 있을 수 있는 프로필에 연결하며, 이것이 "aat.ee"가 단순한 문자열이기를 그치는 방식이다.

2. Article — 게시하는 모든 것에 대해

어시스턴트는 페이지가 인용 가능한 출처인지 마케팅 잔여물인지 판단할 때 datePublished, dateModified, author, headline에 의존한다. 오래된 dateModified는 최신성이 중요한 질문에서 인용이 중단되는 가장 빠른 방법 중 하나다.

{
  "@type": "Article",
  "headline": "Schema.org for AI Answers",
  "datePublished": "2026-09-24",
  "dateModified": "2026-09-24",
  "author": { "@type": "Organization", "name": "aat.ee Team" }
}

{
  "@type": "Article",
  "headline": "Schema.org for AI Answers",
  "datePublished": "2026-09-24",
  "dateModified": "2026-09-24",
  "author": { "@type": "Organization", "name": "aat.ee Team" }
}

dateModified를 정직하게 유지하라. 2년 된 날짜로 당신의 페이지를 인용하는 어시스턴트는 2년 된 답변에 대해서도 계속 그렇게 할 것이다.

3. Product + Offer — 무언가를 판다면

제품 페이지의 경우, 내장된 Offer가 있는 Product는 어시스턴트가 "얼마예요"에 답하기 위해 필요한 사실을 진술한다: 가격, 통화, 구매 가능 여부. 어시스턴트는 검증할 수 없는 가격을 인용하는 것을 눈에 띄게 꺼리므로, 이 마크업이 없는 페이지는 가격 없이 설명되거나 경쟁사의 가격으로 설명되는 경향이 있다.

4. FAQPage — 인용 가능한 질문 형태의 사실

FAQ 블록은 어시스턴트가 가장 쉽게 들어올릴 수 있는 것이다: 질문은 이미 사용자의 형태이고 답변은 이미 한 문단이다. 지원 문의함에 실제로 들어오는 진짜 질문에 사용하라. 두 가지 규칙: 보이는 페이지가 마크업과 동일한 텍스트를 포함해야 하며, 모든 답변은 "위 참조" 없이 단독으로 성립해야 한다.

건너뛸 것

스키마에 Keyword를 채워 넣기, 숨겨진 텍스트를 위한 중복 블록, 물리적 위치가 없는 비즈니스에 대한 LocalBusiness 마크업은 모두 어시스턴트 이득 없이 유지 비용만 더한다. 그 유형에 대해 리치 결과가 결코 나타나지 않는다면, 그 유형은 아마 당신에게 필요 없는 검색 기능을 위해 만들어진 것이다.

나머지를 무효화하는 세 가지 실수

보이는 페이지와 불일치하는 마크업. JSON-LD가 제품 가격이 $29라고 하는데 페이지가 $49를 렌더링한다면, 어시스턴트(그리고 그들을 먹여 살리는 검색 시스템)는 당신의 구조화 데이터가 신뢰할 수 없다고 학습한다. 그 낙인은 남는다.
오래된 날짜. 아무도 건드리지 않은 페이지에 dateModified: <today>를 자동 생성하는 것은 구조화 데이터판 늑대 소리치기다.
유효하지 않은 JSON-LD. 후행 쉼표나 누락된 @context는 블록 전체를 무효화한다. 모든 템플릿 변경을 리치 결과 테스트로 검증하라 — 템플릿이 바로 이런 오류가 숨는 곳이다. 오류는 소스 파일이 아니라 렌더링된 페이지에서만 나타나기 때문이다.

돈 내지 않고 검증하는 방법

Google의 리치 결과 테스트는 구문과 자격을 검증한다. AI 답변 쪽에는 검증기가 없다 — 확인은 행동적이다: 답이 당신의 마크업에 있는 사실 질문("제품 X는 얼마예요?")을 어시스턴트에게 물어보고, 답변이 그 숫자를 말하는지, 얼버무리는지, 아니면 대신 경쟁사를 언급하는지 보라. 우리의 크롤러 로그 워크플로는 이것과 잘 어울린다: 가져오기 패턴은 페이지가 읽히긴 했는지 알려준다.

솔직한 요약

구조화 데이터가 자격 없는 제품을 어시스턴트가 추천하게 만들지는 않는다. 그것이 하는 일은 모호함을 제거하는 것이다: 이름, 가격, 날짜, 카테고리가 추측이 아닌 _사실_이 된다. 어시스턴트가 끊임없이 얼버무리는 환경에서, 사실을 진술하기 쉬운 존재라는 것은 진짜 우위다 — 그리고 그것은 분기가 아니라 하루의 작업이다.

AI 답변을 위한 Schema.org: 실제로 효과를 내는 것은 무엇인가