공통 틀과 페이지별 값의 판단 기준
구조화 데이터 템플릿은 공통 틀과 페이지마다 채워야 할 값을 구분하고, 필수 속성 누락과 배포용 코드의 댓글을 점검해야 합니다. 이후 실제 배포 페이지에서도 유효성을 확인해야 합니다. 같은 템플릿을 사용해도 각 페이지에서 가져오는 자료와 최종 출력값은 다를 수 있으므로, 틀의 완성도만으로 전체 적용 상태를 판단하지 않습니다.
공통 틀은 속성을 어떤 순서와 관계로 출력할지 정하는 부분이며, 공통값은 적용 대상 페이지에서 실제로 같은 의미를 갖는 정보입니다. 페이지별 값은 해당 페이지의 제목이나 설명처럼 콘텐츠에 따라 달라지는 정보입니다. 사이트 운영자는 여러 페이지에 같은 값이 들어간다는 이유만으로 이를 공통값으로 승인하지 않고, 그 값이 각 페이지에서도 정확한지 판단합니다.
구글의 구조화된 데이터 일반 가이드라인은 마크업이 해당 페이지의 콘텐츠를 실제로 표현해야 한다고 설명합니다. 마케팅 담당자는 페이지에 표시한 정보와 템플릿이 출력할 정보가 같은 대상을 설명하는지 대조합니다. 입력 편의를 위해 만든 기본값이 개별 페이지의 내용을 대신하고 있다면 공통값 목록에서 제외합니다.
| 템플릿 항목 | 공통값 또는 페이지별 값 | 값을 가져올 위치 | 누락 시 확인할 사항 |
|---|---|---|---|
| 유형과 속성 구성 | 같은 용도의 페이지에 적용할 공통 틀 | 적용하려는 기능의 문서와 템플릿 설계 자료 | 해당 페이지도 같은 틀의 적용 대상인지 |
| 여러 페이지에서 쓰는 조직 정보 | 실제로 같은 대상을 설명할 때만 공통값 | 사이트의 공식 조직 정보 | 공통 자료 연결이 빠졌는지 |
| 페이지 제목과 설명 | 페이지별 값 | 해당 페이지의 콘텐츠 입력 항목 | 자료가 없는지 또는 잘못된 항목을 연결했는지 |
| 선택한 기능의 필수 속성 | 속성의 의미에 따라 각각 판단 | 해당 속성에 대응하는 실제 자료 | 값이 없거나 출력 조건에서 제외됐는지 |
이 표는 운영자가 만들 수 있는 값 관리표이며, 모든 구조화 데이터에 동일하게 적용되는 속성 목록은 아닙니다. 담당자는 사용 중인 템플릿의 항목으로 표를 채우고, 값의 출처를 입력 화면이나 콘텐츠 항목 이름으로 구체화합니다. 공통값과 페이지별 값이 섞인 항목은 하나로 묶지 않고 각각의 출처를 기재합니다.
필수 속성과 빈 값의 처리 기준
구글은 특정 리치 결과 유형에서 요구하는 필수 속성이 빠진 항목은 리치 결과로 표시되지 않는다고 설명합니다. 따라서 필수 여부는 템플릿의 기본 설정에 맡기지 않고, 적용하려는 기능의 문서에 따라 정합니다. 기술 담당자는 속성 이름이 코드에 존재하는지에 더해 실제 페이지 자료가 그 값으로 출력되는지 점검합니다.
값이 비어 있다는 상황과 값이 존재하지만 잘못 연결됐다는 상황은 따로 처리합니다. 전자는 콘텐츠 자료의 부재나 입력 누락을 추적하고, 후자는 템플릿이 참조하는 항목과 출력 조건을 조사합니다. 구글은 부정확한 권장 속성을 많이 제공하는 것보다 완전하고 정확한 정보를 제공하는 편이 중요하다고 설명합니다. 담당자는 빈칸을 채우기 위해 임의의 기본 문구를 사용하지 않습니다.
적용 전 준비 자료와 실행 순서
템플릿 적용은 값의 출처를 정리한 뒤 코드와 실제 페이지를 차례로 검사하는 순서로 진행합니다. 사이트 운영자는 적용 대상 페이지 목록, 콘텐츠 입력 항목, 현재 템플릿, 선택한 기능의 필수 속성 목록을 준비합니다. 마케팅 담당자는 내용의 정확성을 판단할 자료를 전달하고, 기술 담당자는 그 자료가 코드로 출력되는 경로를 기재합니다.
- 앞에서 정한 기준으로 템플릿 항목별 값의 출처를 정리하고, 공통 자료와 페이지별 자료를 연결합니다.
- 필수 속성을 채운 코드와 자료가 비어 있는 페이지의 코드를 각각 생성해 누락 여부를 점검합니다.
- 배포할 코드에서 예시용 댓글을 제거하고, 수정한 코드로 개발 중 테스트를 진행합니다.
- 배포 페이지의 실제 출력을 검사하고, 배포 후 보고되는 오류를 추적합니다.
구글의 리치 결과 테스트 도움말은 코드 스니펫을 입력해 테스트하고 수정 후 다시 실행할 수 있다고 안내합니다. 개발 중에는 정상 자료만 넣은 예시 코드에 그치지 않고, 실제 입력 상태에 따라 생성한 코드도 테스트합니다. 콘텐츠가 없는 항목을 템플릿이 생략하는지, 빈 문자열로 남기는지, 다른 값으로 대체하는지를 기록합니다.
| 적용 단계 | 점검 대상 | 확인할 문제 | 수정 후 재확인 |
|---|---|---|---|
| 값 연결 | 입력 항목과 출력값 | 공통값 오용과 페이지 자료 연결 오류 | 해당 페이지의 콘텐츠와 출력값 대조 |
| 코드 생성 | 필수 속성과 출력 조건 | 값이 비었을 때 발생하는 누락 | 같은 입력 조건으로 코드 재생성 |
| 배포 준비 | 최종 JSON-LD 코드 | 예시용 댓글 잔존 | 댓글을 제거한 코드 재검사 |
| 배포 이후 | 실제 페이지와 상태 보고서 | 템플릿 또는 게재 과정의 오류 | 수정한 페이지의 출력과 유효성 검사 |
배포 페이지의 유효성 기록
구글은 개발 중에는 리치 결과 테스트를 사용하고, 배포 후에는 리치 결과 상태 보고서로 페이지 유효성을 모니터링하도록 안내합니다. 템플릿이나 게재 문제 때문에 배포 뒤 오류가 생길 수 있다는 설명도 포함합니다. 기술 담당자는 배포 전에 저장한 코드만 제출하지 않고, 실제 페이지에서 생성된 결과를 대상으로 검사합니다.
리치 결과 테스트에서는 오류나 경고의 세부정보를 펼쳐 해당 위치의 렌더링된 소스 코드를 확인할 수 있습니다. 담당자는 보고된 항목과 실제 출력 위치를 연결해 수정 대상을 특정합니다. 점검 기록에는 페이지 식별 정보, 사용한 템플릿 버전, 문제 항목, 수정 내용, 재검사 결과를 남깁니다. 동일한 출력 조건을 사용하는 페이지도 수정 대상에 포함되는지 목록에서 가립니다.
예시용 댓글이 남는 실수
JSON-LD 예시의 댓글은 설명 자료에만 남기고 배포 코드에서는 제거합니다. 구글의 리치 결과 테스트 도움말은 도구가 JSON-LD 블록의 댓글을 무시하지만, JSON-LD 표준은 이를 지원하지 않아 실제 사용 시 오류가 발생할 수 있다고 설명합니다. 테스트에서 오류가 없었다는 결과만으로 댓글이 포함된 코드를 배포용으로 승인하지 않습니다.
기술 담당자는 예시를 복사한 원본과 최종 출력 코드를 따로 관리합니다. 설명을 위해 삽입한 댓글이 템플릿 파일에 남았는지, 코드 생성 과정에서 다시 출력되는지를 조사합니다. 댓글을 제거한 파일이 실제 배포에 사용되는지도 작업 기록에 기재합니다. 코드에 설명이 필요하면 JSON-LD 블록 밖의 별도 문서로 관리합니다.
댓글 제거 작업에서 콘텐츠의 일반 문장을 함께 삭제하지 않도록 처리 대상을 명확히 정합니다. 설명값에 들어간 텍스트와 코드 해설용 댓글은 역할이 다르므로, 문자열 내용까지 일괄 삭제하는 방식은 피합니다. 수정한 뒤에는 코드가 정상적으로 생성되는지 검사하고, 콘텐츠 값이 유지됐는지 대조합니다.
자료가 비어 있는 페이지의 적용 판단
자료가 모두 채워진 페이지만 테스트 대상으로 선택하면 템플릿의 조건부 출력 문제를 놓칠 수 있습니다. 운영자는 필수 자료가 없는 페이지와 일부 선택 자료가 없는 페이지를 적용 목록에서 따로 표시합니다. 기술 담당자는 각각의 입력 상태로 생성된 코드를 검사해, 누락이 자료 부족에서 발생했는지 출력 로직에서 발생했는지 가립니다.
필수 자료를 확보하지 못한 페이지는 해당 구조화 데이터 항목의 배포를 보류하는 운영 절차를 정할 수 있습니다. 이 절차는 사이트 운영상의 판단이며, 자료가 없다는 이유로 페이지 콘텐츠 자체를 삭제하라는 뜻은 아닙니다. 담당자는 자료 보완이 필요한 항목과 코드 수정이 필요한 항목을 서로 다른 작업으로 기록합니다.
한 페이지의 입력값을 수정했다고 해서 템플릿 문제도 해결됐다고 처리하지 않습니다. 입력값 수정은 그 페이지의 자료를 보완한 것이고, 출력 조건 수정은 같은 조건의 여러 페이지에 영향을 줄 수 있습니다. 수정 요청에는 변경한 대상과 영향을 받는 페이지 범위를 함께 기재해 재검사 대상을 정합니다.
자주 묻는 질문
검사용 페이지에 비밀번호가 있어도 테스트할 수 있습니까?
구글의 리치 결과 테스트 도움말은 익명 사용자가 페이지의 모든 리소스에 접근할 수 있어야 하며, 비밀번호나 네트워크 접근 제한으로 보호된 리소스는 테스트할 수 없다고 안내합니다. 운영자는 테스트에 필요한 접근 조건을 준비하되, 공개하면 안 되는 자료를 검사 편의만으로 공개하지 않습니다. 개발 단계에서는 접근 제한을 유지하면서 코드 스니펫 테스트를 활용할 수 있습니다.
일부 페이지의 검사 결과를 전체 적용 결과로 보고해도 됩니까?
일부 페이지를 검사했다면 보고 범위도 실제 검사한 대상으로 제한합니다. 담당자는 서로 다른 입력 조건과 템플릿 변형을 적용 목록에 표시하고, 아직 검사하지 않은 조건을 별도로 기재합니다. 모든 페이지를 직접 검사하지 못한 상황에서 전체 적용이 완료됐다고 표현하지 않습니다.
운영자가 입력 항목 이름을 변경하면 어떤 작업이 필요합니까?
콘텐츠 입력 항목을 변경할 때는 템플릿이 참조하는 항목도 변경 대상인지 조사합니다. 관리 화면의 표시 이름만 달라진 경우와 실제 자료 연결이 달라진 경우는 작업 범위가 다릅니다. 담당자는 변경 요청서에 입력 항목의 이전 이름과 새 이름, 연결 변경 여부를 기재해 기술 담당에게 전달합니다.
이미지 자료를 공통값으로 사용할 때 어떤 조건이 필요합니까?
구글의 일반 가이드라인은 구조화된 데이터에 지정한 이미지가 해당 페이지와 관련이 있어야 한다고 설명합니다. 같은 이미지를 반복 사용하려면 적용 대상 페이지에서도 그 관련성이 성립하는지 판단합니다. 파일을 공통으로 관리한다는 운영상의 편의만으로 모든 페이지에 동일한 이미지를 지정하지 않습니다.
중복된 콘텐츠 페이지에도 템플릿을 적용해야 합니까?
구글의 일반 가이드라인은 동일한 콘텐츠의 중복 페이지가 있다면 표준 페이지뿐 아니라 중복 페이지에도 동일한 구조화된 데이터를 배치하는 것을 권장합니다. 운영자는 콘텐츠가 실제로 같은 페이지인지 먼저 판단하고 적용 목록을 정리합니다. 제목이 비슷하다는 이유만으로 서로 다른 콘텐츠에 같은 값을 복사하지 않습니다.