구조화 데이터 심화: 「달았다」에서 「정확하다」로

기초와 심화의 경계는 어디인가?

기초 단계(구조화 데이터 기본)가 Organization·Article·FAQPage 같은 타입을 페이지에 다는 일이라면, 심화 단계의 주제는 세 가지입니다: 중첩, 참조, 정합. 중첩은 「Article 안에 author로 Organization을 넣는」 식의 관계 표현이고, 참조는 @id로 「여러 페이지의 마크업이 같은 존재를 가리키게」 하는 장치이며, 정합은 마크업이 본문·외부 소스와 한 글자까지 일치하는 상태입니다.

엔티티 앵커(@id)는 왜 중요한가?

@id는 마크업 안의 엔티티에 「항구적 주소」를 부여합니다. 예를 들어 Organization에 https://example.com/#org라는 @id를 부여해 두면, 사이트 전체의 Article·Product·FAQPage 마크업이 author·brand·publisher로 이 주소를 참조할 수 있습니다. 이렇게 하면 엔진은 「페이지마다 따로 등장하는 회사명」이 아니라 「하나의 고정된 엔티티를 가리키는 참조망」을 읽습니다——이것이 지식 그래프 진입의 기술적 고리입니다(지식 패널).

중첩 JSON-LD의 실전 패턴은?

• @graph 패턴: 한 페이지의 여러 타입을 하나의 JSON-LD 블록 안에 @graph로 묶고, 각 노드를 @id로 연결. 페이지 단위 그래프의 표준 형태입니다.
• 관계의 명시: Product → brand → Organization(@id 참조), Article → author/publisher → Organization, FAQPage → mainEntity → Question/Answer. 「타입의 나열」이 아니라 「관계의 선언」이 목표입니다.
• sameAs와 alternateName: 공식 SNS·외부 프로필을 양방향으로 고정하고, 다국어 표기를 병기——엔티티 정합의 연장선입니다(엔티티 설계).

심화 단계의 검증 절차는?

1. 리치 결과 테스트와 Schema.org 검증기로 파싱 오류 제거
2. @id 참조의 연결 상태 점검——참조는 있는데 대상 노드가 없는 「끊긴 참조」 제거
3. 마크업 값과 본문 표기의 전수 대조——가격·날짜·이름의 불일치는 그라운딩 감점으로 직결(그라운딩)
4. CMS·플러그인의 자동 마크업과 수동 마크업의 중복 점검——같은 엔티티가 두 벌로 선언되면 엔진은 둘을 다른 존재로 처리할 수 있습니다

흔한 함정은 무엇인가?

첫째, 「스키마에만 있는 사실」——본문에 없는 리뷰 평점·수상 경력을 마크업에 넣는 것은 신호가 아니라 잡음이며, 검증 실패 시 신뢰를 깎습니다. 둘째, 플러그인 중복——SEO 플러그인과 테마가 각각 Organization을 출력하는 사례가 흔합니다. 셋째, 「한 번 달고 방치」——조직 정보·가격이 바뀌면 마크업도 같은 주기로 갱신해야 합니다. 기술 감사는 GEO 서비스의 1~2주 차 표준 항목입니다.