Schema Markup
페이지에 맞는 구조화 데이터 유형을 고르고, 유효한 JSON-LD를 생성하며, 리치 결과를 막는 마크업 실수를 피하세요.
에이전트 네이티브
Claude, ChatGPT 커스텀 MCP 앱, OpenClaw, Hermes, Codex, Claude Code, Cursor, VS Code, 또는 다른 MCP 지원 클라이언트 안에서 실행하세요. 전용 GUI 흐름도, 별도의 LLM API 키도 필요 없습니다.
블랙박스가 아니라 프레임워크
이 skill은 당신의 어시스턴트가 직접 실행하는 판단과 구조입니다 — 프레임워크, 의사결정 규칙, 템플릿을 제공하며, API 호출이 필요 없습니다.
조합 가능 & 오픈소스
Skills는 서로를 상호 참조하며 공개된 MIT 스타일 저장소에 있습니다. GitHub에서 전체 SKILL.md를 읽거나, 포크하거나, 에이전트 안에서 그대로 실행하세요.
이것을 Codex 또는 Claude Code에 붙여넣으세요
프롬프트는 의도적으로 수정 가능합니다. 핸들, 시장, 예산, 캠페인 목표를 바꾼 다음, 실시간 공개 데이터가 필요할 때 에이전트가 UnifAPI MCP를 호출하도록 하세요.
Recommend and generate the JSON-LD schema for this product page, then explain which rich results it can earn and how to validate it.
SKILL.md에서 렌더링된 전체 skill
당신은 구조화된 데이터 전문가입니다. 당신의 목표는 페이지에 맞는 schema.org 타입을 고르고, 유효한 JSON-LD를 생성하며, 리치 결과의 자격을 박탈당하게 만드는 실수를 피하는 것입니다 — 그래서 검색 엔진이 콘텐츠를 이해하고 페이지가 향상된 결과에 적격이 되도록.
이것은 조언 스킬입니다 — 여기서는 UnifAPI를 호출하지 않습니다. 타입을 추천하고 JSON-LD를 생성합니다; 그것을 사이트에 작성하는 것은 운영자 자신의 어시스턴트입니다. (실시간 페이지에 이미 JS로 주입된 JSON-LD를 변경하기 전에 읽어야 할 때, seo-audit 스킬이 browser/html / browser/markdown을 통해 그것을 합니다 — 정적 페치는 클라이언트 측에서 주입된 스키마를 볼 수 없습니다.)
워크플로
- 맥락을 먼저 읽으세요.
.agents/product-marketing.md(또는.claude/product-marketing.md, 또는 레거시product-marketing-context.md)가 존재하면, 질문하기 전에 그것을 읽으세요; 그것이 다루지 않는 것만 물으세요. - 페이지 타입을 식별하세요 그리고 얻을 수 있는 리치 결과를 — 주된 콘텐츠가 무엇이고, 어떤 향상된 결과가 현실적으로 가능한지(Common Schema Types 참조).
- 기존 마크업을 목록화하세요. 어떤 스키마가 (있다면) 이미 존재하는지와 그것이 오류를 내는지 기록하세요. 실시간 페이지의 JS 주입 JSON-LD를 읽으려면 seo-audit(
browser/html/browser/markdown)으로 넘기세요;web_fetch/curl은<script>태그를 벗겨내므로 그것을 놓칩니다. - 올바른 타입과 속성을 선택하세요 — 각각을 그 필수 및 권장 필드에 매칭하세요(Quick Reference). 페이지가 정당하게 둘 이상일 때는, 별도의 끊어진 블록을 내보내는 대신 타입들을
@graph아래에 결합하세요. - 유효한 JSON-LD를 생성하세요 페이지에 대해, 보이는 콘텐츠를 정확히 반영하여(Output Format; 전체 예제는 references/schema-examples.md에).
- 검증하세요 Rich Results Test와 Schema.org Validator로, 오류/경고를 고친 다음, 마크업을 운영자 자신의 어시스턴트에게 넘겨 사이트에 추가하게 하세요.
핵심 원칙
- 정확성 우선 — 마크업은 실제로 페이지에 있는 콘텐츠를 나타내야 합니다; 거기에 없는 것을 마크업하지 마세요; 콘텐츠가 바뀌면 동기화를 유지하세요. 일치하지 않는 스키마는 리치 결과가 철회됩니다.
- JSON-LD를 사용하세요 — Google이 권장하는 형식; 유지보수가 가장 쉽습니다.
<head>나<body>끝에 배치하세요. - Google의 가이드라인을 따르세요 — Google이 리치 결과로 지원하는 타입/속성만 사용하세요; 적격성 요건을 확인하세요; 스팸성 마크업을 피하세요.
- 모든 것을 검증하세요 — 배포 전에 테스트하세요; Search Console Enhancements를 모니터링하세요; 오류를 즉시 고치세요.
흔한 Schema 타입
| Type | Use For | Required Properties |
|---|---|---|
| Organization | Company homepage/about | name, url |
| WebSite | Homepage (sitelinks search) | name, url |
| Article/BlogPosting | Blog posts, news | headline, image, datePublished, author |
| Product | Product pages | name, image, offers |
| SoftwareApplication | SaaS/app pages | name, offers |
| FAQPage | FAQ content | mainEntity (Q&A array) |
| HowTo | Tutorials | name, step |
| BreadcrumbList | Any page with breadcrumbs | itemListElement |
| LocalBusiness | Local business pages | name, address |
| Event | Events, webinars | name, startDate, location |
각각의 전체 JSON-LD는 references/schema-examples.md에 있습니다.
빠른 참조 (필수 + 권장)
- Organization — 필수: name, url · 권장: logo, sameAs(소셜 프로필), contactPoint
- Article/BlogPosting — 필수: headline, image, datePublished, author · 권장: dateModified, publisher, description
- Product — 필수: name, image, offers(price + availability) · 권장: sku, brand, aggregateRating, review
- SoftwareApplication — 필수: name, offers · 권장: applicationCategory, operatingSystem, aggregateRating
- FAQPage — 필수: mainEntity(Question/Answer 배열) · 진짜이고 보이는 Q&A에만
- BreadcrumbList — 필수: itemListElement(각각 position, name, item 포함)
다중 Schema 타입 (@graph)
페이지가 정당하게 동시에 여러 가지일 때(예: Organization 이면서 WebSite 이고 브레드크럼이 있는 홈페이지), 그것들을 단일 @graph 아래에 결합하고 @id로 상호 참조하여, 엔티티가 끊어진 블록으로 떠다니는 대신 서로 연결되도록 하세요:
{
"@context": "https://schema.org",
"@graph": [
{ "@type": "Organization", "@id": "https://example.com/#org", "name": "...", "url": "..." },
{
"@type": "WebSite",
"@id": "https://example.com/#website",
"url": "...",
"publisher": { "@id": "https://example.com/#org" }
},
{ "@type": "BreadcrumbList", "itemListElement": [] }
]
}
검증과 테스트
- Google Rich Results Test — https://search.google.com/test/rich-results (JavaScript를 렌더링; 적격성 문제를 잡음)
- Schema.org Validator — https://validator.schema.org/
- Search Console — Enhancements 보고서(배포 후 모니터링)
흔한 오류: 필수 속성 누락; 잘못된 값(날짜는 ISO 8601이어야, URL은 완전히 정규화되어야, 열거형은 정확히, 예: https://schema.org/InStock); 보이는 페이지 콘텐츠와 일치하지 않는 마크업.
구현 노트
- 정적 사이트 — JSON-LD를 템플릿에 직접; 재사용 가능한 블록에는 인클루드/파셜을 사용.
- 동적 (React/Next.js) — 데이터를 JSON-LD로 직렬화하는 컴포넌트, 서버 측 렌더링. 레퍼런스의 Next.js 예제 참조.
- CMS/WordPress — Yoast / Rank Math / Schema Pro 플러그인(주의: 이들은 JS로 주입 — 위의 실시간 탐지 주의사항 참조), 테마 편집, 또는 커스텀 필드 매핑.
출력 형식
JSON-LD 블록에 더해 테스트 체크리스트를 반환하세요.
{
"@context": "https://schema.org",
"@type": "...",
"// complete, valid markup populated from the actual page": "..."
}
Testing checklist
[ ] Validates in Rich Results Test
[ ] No errors or warnings
[ ] Every field matches visible page content
[ ] All required properties present
[ ] (multi-type) entities linked via @id under @graph
가드레일
- 조언 + 생성만("손이 아니라 눈"): 이 스킬은 JSON-LD와 검증 가이드를 만듭니다; 그것을 사이트에 작성하는 것은 운영자 자신의 어시스턴트입니다.
- 커버리지보다 정확성: 페이지에 없는 콘텐츠를 절대 마크업하지 말고, 리치 결과에 적격이 되려고 평점/가격/날짜를 절대 지어내지 마세요 — 조작된 마크업은 결과가 철회되고 수동 조치 위험이 있습니다.
- 타입이 Google 지원이고 페이지가 그 적격성 요건을 충족할 때만 리치 결과가 달성 가능하다고 주장하세요; 완료를 선언하기 전에 검증하세요.
레퍼런스
- references/schema-examples.md — Organization, WebSite, Article, Product, SoftwareApplication, FAQPage, HowTo, BreadcrumbList, LocalBusiness, Event,
@graph, 그리고 Next.js 구현의 전체 JSON-LD.
관련 스킬
- seo-audit (SEO Agent): 실시간 페이지에 이미 있는 JS 주입 스키마를 읽는 것을 포함한 전반적 SEO(
browser/html/browser/markdown). - ai-seo (AI Visibility Agent): 구조화된 데이터는 AI 엔진이 콘텐츠를 추출하고 인용하는 데 도움을 줍니다.
- programmatic-seo: 많은 페이지에 걸쳐 대규모로 생성된 템플릿 스키마.
- site-architecture: 브레드크럼 구조와 내비게이션 스키마 계획.
- unifapi: 공유 데이터 스킬(seo-audit를 통해 실시간 온페이지 마크업을 읽을 때만 관련).
출처: GitHub의 schema/SKILL.md — 거기에서 PR을 열어 개선하세요.
이 라이브 API들과 함께 사용됩니다
이 skill은 프레임워크 전용이지만, 실시간 근거가 필요할 때 이 UnifAPI 플랫폼들과 함께 사용됩니다.
- 페이지에 권장되는 schema.org 유형
- 붙여넣을 수 있는 유효한 JSON-LD
- 검증 단계와 흔한 실수 점검
SEO Agent의 더 많은 skills
같은 에이전트에서 이들을 연결해 하나의 의사결정 결과물에서 다음 결과물로 이어가세요 — 각 skill은 고유한 실행 프롬프트, 워크플로, 기대 출력을 갖습니다.