첫 단계는 실제 출력의 파싱입니다
소스 객체가 아니라 운영 HTML의 application/ld+json 내용을 읽습니다. 여러 스크립트가 있으면 각각 파싱하고 합쳐진 그래프의 ID를 확인합니다. 쉼표·따옴표 오류나 빈 값을 찾되 파싱이 된다는 사실만으로 다음 단계까지 통과한 것으로 표시하지 않습니다. 직접 삽입한 문자열에 사용자 입력이 섞이는지도 검토합니다.
두 번째는 표현할 대상과 어휘입니다
선택한 타입과 속성이 무엇을 의미하는지 공식 자료로 확인합니다. 조직, 브랜드, 서비스와 글을 같은 대상으로 합치지 않습니다. 도구가 경고하는 항목은 무조건 채우기보다 실제 사실로 제공할 수 있는지 확인합니다. 지원하지 않는 속성을 많이 붙이는 것과 정확한 관계를 표현하는 것을 구분합니다.
세 번째는 화면과 관계의 대조입니다
- 이름·주소·가격·제공 범위가 화면과 같은지 확인합니다.
- 작성자·게시자·운영 주체의 관계가 실제 공개 설명과 맞는지 봅니다.
- 문서 URL과 ID가 대표 주소 정책을 사용하는지 확인합니다.
- 같은 ID의 충돌과 잘못된 참조가 없는지 검사합니다.
가정한 예로 문법상 유효한 Service 객체에 더 이상 제공하지 않는 상품 가격이 남아 있다면 문법 검사가 문제를 대신 찾아주지 않을 수 있습니다. 반대로 실제 사업 정보가 정확해도 JSON이 깨지면 구조화된 형태로 읽기 어렵습니다. 두 결과를 모두 확인해야 운영 검수가 완성됩니다.
검사 도구의 범위를 기록합니다
Schema.org 어휘 검사, 특정 검색 기능 검사와 자사 정적 검사를 나눕니다. 사용한 URL·시각·배포와 오류·경고 수를 저장합니다. 경고가 없다고 모든 검색 기능에 적합하다고 확대하지 않고 해당 도구가 검사한 범위를 설명합니다. 화면에서 실제로 보이는 내용도 표본 검수합니다.
완료 기준과 회귀
파싱·어휘·사실·연결이 일치하고 변경될 때 다시 검사할 경로가 있어야 합니다. 공통 레이아웃에서 노드를 추가하면 기존 페이지의 중복 여부도 확인합니다. 구조화 데이터 적용 완료, 크롤러 접근 확인과 검색·AI 서비스 표시 결과는 각각 별도 단계로 유지합니다.
자주 묻는 질문
- Schema.org 검사에서 오류가 없으면 구글 표시도 보장되나요?
- 데이터의 문법·어휘 검사와 특정 검색 기능의 자격·표시 결정은 다릅니다. 실제 지원 유형과 정책을 확인하고 외부 표시 여부는 별도 결과로 기록합니다.
- 별점이나 가격을 넣으면 더 풍부한 데이터가 되나요?
- 실제로 확인할 수 있는 사실이 있어야 합니다. 존재하지 않는 리뷰·평점·가격·재고를 채워 넣는 방식은 데이터의 풍부함이 아니라 내용의 불일치를 만듭니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.