Structured Data
JSON-LD 그래프 및 중복 스키마 검사기
대부분의 검증 도구는 하나의 JSON-LD 블록을 하나의 스키마 타입에 대해서만 검사합니다. 실제 페이지는 보통 Organization, WebSite, WebPage, Article, 플러그인 출력 등 여러 블록을 동시에 내보내며, 이들은 @id로 서로 참조합니다. 전체 페이지 HTML을 붙여넣으면 이 도구는 그 참조 그래프를 구성하고, 타입별 검증 도구가 찾을 수 없는 문제를 찾아냅니다: 중복되거나 충돌하는 @id 값, 아무것도 가리키지 않는 끊어진 참조, 비정상적인 순환 참조 체인, 철자가 틀린 @type 이름, 그리고 같은 페이지를 두고 경쟁하는 두 개의 주요 엔티티까지.
모든 처리는 브라우저 안에서만 이루어집니다. 여기에 붙여넣은 내용은 익명화된 사용 횟수를 제외하고 어디로도 전송되지 않습니다.
페이지 소스 전체를 붙여넣으세요(<script type="application/ld+json"> 블록은 모두 자동으로 추출됩니다). 원시 JSON-LD를 바로 붙여넣어도 됩니다.
무엇을 검사하고, 어떻게 고치는가
중복/충돌하는 @id. 두 노드가 같은 @id를 공유하지만 데이터(이름, 로고, URL 등)가 다르면, 검색엔진은 어느 것이 정확한지 판단할 수 없습니다 — 어떤 값이 우선하는지가 불확실합니다. 각 엔티티에 고유한 @id를 부여하거나, 중복된 항목이 정말로 완전히 동일한 복사본인지 확인하세요.
끊어진 참조. mainEntityOfPage, isPartOf, author, publisher 같은 속성은 데이터를 반복하는 대신 {"@id":"..."} 만으로 다른 노드를 가리킬 수 있습니다. 그 @id가 페이지 어디에도 선언되어 있지 않다면 참조는 아무 곳도 가리키지 않게 됩니다 — id를 수정하거나 누락된 노드를 추가하세요.
순환 참조 체인. WebPage 노드가 mainEntity로 자신의 Article을 가리키고, Article이 mainEntityOfPage/isPartOf로 다시 WebPage를 가리키는 것은 완전히 정상적인 2노드 패턴입니다(여기서는 정보성으로만 표시됩니다). 하지만 더 길고 이례적인 루프는 다시 확인해볼 가치가 있습니다 — 보통 플러그인이 생성한 블록 간의 복사-붙여넣기 실수를 의미합니다.
철자가 틀린 @type. schema.org 타입 이름은 대소문자를 구분하는 PascalCase 문자열입니다. "Article" 대신 "Aricle"이라고 써도 유효한 JSON으로 파싱되지만 실제 존재하는 타입이 아닙니다 — 검색엔진은 조용히 무시해버립니다. 이 도구는 실제 schema.org 어휘와 비교해 비슷한 철자를 표시합니다.
중복되거나 서로 경쟁하는 주요 엔티티. 페이지는 일반적으로 하나의 주요 콘텐츠 엔티티만 가져야 합니다 — Article 하나, Product 하나, Recipe 하나. Article 노드가 두 개이거나, 서로 연결되지 않은 Article과 Product가 있으면 검색엔진은 이 페이지가 실제로 무엇에 관한 것인지 추측해야 합니다.
이것은 구조적/블록 간 감사이며, 타입별 필드 검증기가 아닙니다 — 각 엔티티 자체의 필수 속성도 검사하려면 전용 Article, Product, Recipe, Event, FAQ, Local Business 스키마 검증기와 함께 사용하세요.