🧩 JSON-LD 생성기
schema.org 구조화 데이터 (JSON-LD) 를 9 타입 실시간 생성. Organization / WebSite / Article / Product / FAQPage / HowTo / Event / LocalBusiness / Recipe 지원, Google Rich Results 호환 코드 복사 · 다운로드.
🔒 개인정보 보호
- ・입력은 브라우저 내에서만 처리됩니다
- ・서버 전송 · 저장 · 로그 없음
- ・가입 · 로그인 · 결제 불필요
📋 생성된 JSON-LD
💡 한 페이지에 여러 schema 를 포함하려면 @graph 배열로 묶어 중복을 피하세요. Rich Results Test 에 붙여 검증하세요.
📖 자주 걸리는 지점
Organization / WebSite / Article / Product / FAQPage / HowTo / Event / LocalBusiness / Recipe 아홉 타입에 대해 schema.org 의 구조화 데이터 (JSON-LD) 를 폼 입력에서 생성합니다. 처리는 브라우저 안에서 끝납니다. 다만 「구문으로서 올바른 JSON-LD」와 「리치 결과가 나온다」는 다른 이야기입니다 — 전자는 검증 도구로 확인할 수 있지만 후자를 보증하는 방법은 없습니다. 그리고 구조화 데이터에서 가장 흔한 실패는 서식이 아니라 내용에 있습니다: 페이지에 쓰여 있지 않은 것을 마크업에 쓰면 그것은 고쳐야 할 미비가 아니라 가이드라인 위반입니다.
| 사례 | 무슨 일이 일어나는가 | 어떻게 하면 되는가 |
|---|---|---|
| 마크업과 보이는 페이지의 내용이 어긋난다 | 검색 엔진은 구조화 데이터가 페이지에 실제로 존재하는 내용을 나타낼 것을 요구합니다. 페이지 어디에도 쓰여 있지 않은 평점·가격·재고·리뷰 수를 마크업에만 쓰면 가이드라인 위반이 되고 수동 조치 (해당 페이지의 구조화 데이터가 무시되거나 사이트 전체의 평가가 떨어지는) 의 대상이 됩니다. 악의가 없어도 일어납니다 — 가장 흔한 원인은 템플릿입니다. JSON-LD 를 템플릿에 직접 써서 모든 페이지에서 공유하면 페이지마다 달라야 할 값이 고정되어 본문과 벌어져 갑니다. 「한 페이지만 손으로 써서 동작을 확인한 것을 그대로 옆으로 펼쳤다」는 경위가 대부분입니다. 그리고 괴리는 조용히 진행됩니다 — 본문만 갱신하고 JSON-LD 를 고치는 것을 잊으면 그날부터 불일치입니다. | 마크업과 본문을 같은 하나의 데이터에서 생성하세요. 템플릿 안의 상품 가격 같은 변수를 JSON-LD 쪽에도 넘기면 본문을 고쳤을 때 구조화 데이터도 자동으로 따라옵니다 — 「양쪽을 손으로 고치는」 운용은 반드시 한쪽이 남겨집니다. 이 사이트 자신이 블로그 28 편에서 같은 문제를 밟았고 같은 대책으로 해결했습니다. 손으로 쓰는 경우의 원칙도 하나뿐입니다: 페이지에 표시하지 않은 값은 쓰지 않는다. 평점이나 리뷰를 넣고 싶다면 먼저 페이지에 리뷰를 표시하세요 — 순서가 반대가 되면 반드시 위반이 됩니다. 기존 페이지 점검에는 Search Console 의 「개선사항」 리포트를 쓸 수 있습니다 — 오류뿐 아니라 경고도 읽으세요. |
| FAQ 와 HowTo 의 리치 결과는 이제 나오지 않는다 | 2023 년의 변경으로 FAQ 의 리치 결과는 정부 기관이나 의료 기관 등 「신뢰할 수 있는 공적 사이트」로 한정되었고 HowTo 는 데스크톱·모바일 양쪽에서 표시가 종료되었습니다. 즉 일반적인 기업 사이트나 블로그가 이 둘의 마크업을 추가해도 검색 결과의 겉모습은 달라지지 않습니다. 마크업 자체가 무효가 된 것은 아니고 올바르게 해석도 됩니다 — 바뀐 것은 「표시되는가」뿐입니다. 여기서 문제가 되는 것은 기대값의 어긋남으로, 「검색 결과의 면적을 늘린다」를 목적으로 FAQ 블록을 페이지에 더하면 목적은 달성되지 않고 본론과 관계가 옅은 Q&A 가 페이지에 남습니다 — 읽는 사람에게는 답을 찾는 데 방해가 될 뿐입니다. | 마크업을 더하는 목적을 「표시」에서 「이해」로 바꾸세요. FAQPage 도 HowTo 도 검색 엔진이나 언어 모델이 페이지의 구조를 파악하는 데는 도움이 됩니다 — 다만 그것이 순위나 표시를 약속하지는 않으므로 비용 대비 효과로 판단하세요. 리치 결과를 실제로 노릴 수 있는 타입은 한정되어 있습니다: Article·Product·Recipe·Event·LocalBusiness·Breadcrumb 정도가 현실적입니다. 그리고 가장 확실히 듣는 것은 Breadcrumb — 구현이 단순하고 검색 결과의 URL 표시가 이동 경로로 바뀌는 알기 쉬운 변화가 있습니다. FAQ 를 쓰는 것 자체는 좋은 일입니다 — 다만 「사용자가 그것을 읽으니까」 쓰세요. SERP 를 위해서가 아니라. |
| 검증은 통과하는데 리치 결과의 요건을 만족하지 않는다 | schema.org 는 대부분의 프로퍼티를 필수로 두지 않습니다 — 타입만 맞으면 「타당한 JSON-LD」가 됩니다. 한편 검색 엔진의 리치 결과에는 타입마다 별도의 필수 항목 목록이 있습니다. 이 둘을 혼동하면 「검증 도구에서 오류가 0 인데 아무것도 표시되지 않는」 상태가 됩니다. 흔한 누락은 Article 의 image 와 datePublished, Product 의 offers (가격과 통화와 재고 상태), Event 의 location 과 startDate, LocalBusiness 의 address. 또 하나 놓치는 것이 엔티티의 중복입니다 — 각 페이지에 Organization 을 통째로 쓰면 같은 조직의 정보가 수십 개 존재하게 되어 어느 것이 정본인지 애매해집니다. |
두 검증 도구를 나눠 쓰세요. Schema Markup Validator 는 구문과 타입을 보는 것이고 리치 결과 테스트는 「검색 결과에 나올 자격이 있는가」를 보는 것입니다 — 후자만이 필수 항목의 누락을 알려 줍니다. 그리고 권장 항목도 넣으세요 — 필수가 아니므로 경고에 그치지만 실제 표시는 권장 항목의 충실도에 영향을 받습니다. 중복 해소에는 @id 를 씁니다: Organization 을 사이트에 한 곳만 (첫 페이지 등) 완전한 형태로 쓰고 다른 페이지에서는 {"@id": "https://example.com/#organization"} 이라고 참조만 하면 정보의 정본이 하나로 정해지고 갱신도 한 곳으로 끝납니다. |
구조화 데이터는 순위를 올리는 요인이 아닙니다. Google 은 랭킹 요인이 아니라고 명언했습니다 — 효과가 있는 것은 「클릭률」 쪽으로 리치 결과가 표시되면 눈에 띄기 쉬워진다는 것뿐입니다. 따라서 얇은 페이지에 구조화 데이터를 더해도 아무 일도 일어나지 않습니다. 순서로는 먼저 내용을 두껍게 한 다음입니다. 구현 면의 주의를 둘. JSON-LD 는 JavaScript 로 나중에 삽입해도 읽히지만 확실한 것은 서버 쪽에서 HTML 에 포함하는 것입니다 — 렌더링을 기다리는 만큼 인식이 늦어지거나 되지 않는 경우가 있습니다. 또 하나, 한 페이지에 여러 타입을 두는 것은 문제없습니다 — Article 과 Breadcrumb 과 Organization 이 함께 있는 것은 정상이며 @graph 로 묶어도 별개의 <script> 로 나눠도 상관없습니다. 마지막으로 반영에는 시간이 걸립니다 — 다시 크롤될 때까지 Search Console 의 리포트는 변하지 않으므로 변경한 다음 날에 「안 듣는다」고 판단하지 마세요.
📖 사용법
-
1
스키마 타입 선택드롭다운에서 9 가지 타입 중 선택.
-
2
필수 입력* 표시 필드 입력 시 출력이 실시간 갱신.
-
3
복사 또는 다운로드wrap 체크 시 <script> 태그 형식. <head> 에 삽입.
-
4
Rich Results Test 검증Google Rich Results Test 에 붙여 확인.
❓ 자주 묻는 질문
JSON-LD 란?
어떤 타입을 써야 하나요?
한 페이지에 여러 schema 가능?
<script> 태그 또는 하나의 @graph 배열로 묶기 가능. @graph 가 권장됨.Rich Results 에 표시되려면?
AI 크롤러도 JSON-LD 를 읽나요?
🔗 관련 도구
🐛 이 도구에서 문제가 발생했나요?
무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.
보고 감사합니다!
운영자에게 전달되었습니다. 개선에 사용됩니다.