페이지와 지원되는 기능부터 시작하세요
비즈니스와 관련 있어 보인다고 해서 schema.org의 모든 타입을 무작정 추가하지 마세요. schema.org는 광범위한 공통 어휘이고, Google의 Search Gallery는 지원하는 풍부결과 기능과 해당 기능에 필요한 속성을 문서화합니다. 제품, 이벤트, 기사 페이지는 마크업 없이도 먼저 유용해야 합니다.
템플릿마다 주요 주제와 가시적 보조 사실을 명명하세요. 그런 다음 일치하는 기능에 대해 Google의 최신 가이드를 읽으세요. Product, Recipe, Article, Breadcrumb, Event, Organization, LocalBusiness, Video 등이 예입니다. 어휘 타입만으로 Google 기능이 생성되는 것은 아니며, 해당 기능의 필수 속성이 적격성을 결정합니다.
가시적으로 가장 중요한 항목을 주요 마크업으로 만드세요.
기능 동작에는 Google 가이드를, 어휘에는 schema.org를 참조하세요.
가시적 페이지를 기준 소스로 삼으세요
마크업은 페이지의 주요 콘텐츠를 나타내야 하며 숨겨진, 관련 없는, 오해를 일으키는 자료를 포함해서는 안 됩니다. 공연자가 출연한다고 마크업에 적으면 페이지에 그 공연자가 설명되어 있어야 합니다. 집계 평점을 마크업한다면 방문자도 그 평점을 볼 수 있어야 합니다. 이는 템플릿이 오해를 낳는 요약으로 변질되는 것을 방지합니다.
페이지 카피와 마크업을 동일한 승인된 레코드에서 작성하세요. 제품 피드, 이벤트 시스템, CMS가 둘 다 제공할 수 있지만 값은 게시 전에 검토되어야 합니다. 가격, 재고 상태, 날짜, 리뷰 총합을 마크업 전용 필드에 복사해 두고 잊지 마세요. 가시적 정보가 변경되면 마크업을 업데이트하거나 제거하세요.
이름, 날짜, 가격, 가용성, 평점을 페이지와 정렬해 유지하세요.
출처 데이터가 없을 때 속성을 추측하거나 오래된 값으로 채우지 마세요.
유지 관리 가능한 데이터 레이어로 JSON-LD를 사용하세요
JSON-LD는 HTML 문서에 배치하는 JSON 기반의 링크드 데이터 형식입니다. Google은 JSON-LD, Microdata, RDFa를 지원하며 일반적으로 JSON-LD가 대규모로 구현하고 유지 관리하기에 가장 쉽다고 말합니다. 가시적 마크업과 분리되어 중첩 정보 모델링이 쉬워질 수 있습니다.
실제 항목마다 하나의 명확한 데이터 객체를 사용하고 적절한 schema.org 타입과 정확한 지원 속성을 포함하세요. 각 템플릿에 대해 기능 가이드, 출처 필드, 필수 필드 동작, 책임자를 문서화하세요. 렌더링된 출력도 검사하세요: 플러그인이나 컴포넌트가 중복되거나 상충하는 마크업을 추가할 수 있습니다.
팀이 일관되게 유지할 수 있는 형식을 선택하세요.
출처 데이터가 없을 때 필수 값을 임의로 생성하지 마세요.
코드와 접근 가능한 페이지를 검증하세요
검증은 두 가지 질문에 답합니다. 첫째, 마크업이 지원되는 기능에 충분히 완전한가? Rich Results Test는 붙여넣은 코드나 공개 URL을 받아 구조화된 데이터로부터 생성할 수 있는 풍부결과를 보고합니다. 템플릿별로 대표적인 예제를 테스트하세요—특히 유난히 모든 값이 채워진 하나의 페이지만 테스트하지 마세요.
둘째, Google이 공개된 페이지와 자원에 접근할 수 있는가? 마크업된 페이지를 robots.txt, noindex, 또는 접근 제어로 차단하지 마세요. 관련 이미지 URL도 확인하세요. 테스트는 품질 보장의 도구가 아니며, 가시적 콘텐츠나 정책 문제로 인해 실제 노출이 차단될 수 있습니다.
먼저 코드(또는 코드 샘플)를 테스트한 다음 공개 가능한 URL로 테스트하세요.
툴링이 마크업을 추가할 때 렌더된 페이지, 소스, 테스트 결과를 비교하세요.
잠재적 노출은 최종 노출 보장이 아닙니다.
사용자 대상 템플릿 변경처럼 배포하세요
구조화된 데이터는 종종 템플릿, 피드, 게시 규칙에 의존합니다. 리디자인, 재고 통합 변경, 현지화 업데이트, 또는 컴포넌트 제거가 많은 항목을 깨뜨릴 수 있습니다. 표준 태그, 타이틀, 이미지에 사용하는 사전 출시 검토에 대표적인 마크업 검사를 추가하세요. 템플릿, 페이지 예제, 출처 필드, 배포일을 기록하세요.
템플릿이 잘못된 마크업을 발행하면 공유 출처나 템플릿을 수정하고, 소규모 샘플로 검증한 뒤 가장 좁은 범위의 안전한 변경을 배포하고 영향을 받는 URL을 재테스트하세요. 수정이 예기치 않게 동작하면 일반 롤백 프로세스를 사용하세요. 목표는 열화된 웹 역량의 근거 기반 복구이지 장애 알림이 아닙니다.
단일 URL이 아니라 대표적인 페이지 집합을 확인하세요.
후속 수정 전에 변경 사항과 마크업 구성 요소를 기록하세요.
유지, 측정, 노출 한계 수용하기
배포 후에는 관련 Search Console 리치 결과 보고서를 사용해 문제를 조사하고 수정 사항을 확인하세요. 보고서는 전체 인벤토리가 아니라 샘플이며, 수치는 페이지가 아니라 항목(items)을 가리킵니다. 필요한 경우 특정 URL을 검사하세요.
측정은 신중히 하세요. Google은 Search Console에서 충분히 안정적인 읽기량이 있는 페이지를 대상으로 출시 전후 비교를 수개월에 걸쳐 수행할 것을 권장합니다. 배포일과 다른 페이지 변경 사항을 기록하세요. 올바른 마크업은 적격성만 활성화하며 실제 검색 노출 방식은 Google이 결정합니다.
CMS, 템플릿, 피드, 정책, 콘텐츠 모델 변경 후 다시 확인하세요.
다른 주요 페이지 변경이 다른 집단과 섞이지 않도록 하세요.