속성 정의와 검색 기능 요건의 차이
구글 검색 동작을 위한 구조화 데이터는 스키마닷오알지의 정의만으로 결정하지 않고, 구글 검색 센터의 해당 기능 문서를 최종 기준으로 삼습니다. 구글에 필요하지 않은 속성이라는 이유만으로 다른 서비스에서도 쓸모없다고 판단하지 않습니다. 사이트 운영자는 속성이 뜻하는 내용과 구현하려는 검색 기능의 요구사항을 서로 다른 질문으로 나누어 개발 담당에게 전달해야 합니다.
유형과 속성의 정의를 읽는 목적은 페이지의 정보를 어떤 개념으로 표현할지 결정하는 데 있습니다. 검색 기능 문서를 읽는 목적은 그 표현을 구글 검색에 적용할 때 무엇을 갖춰야 하는지 결정하는 데 있습니다. 속성 이름이 정의되어 있다는 사실만으로 특정 검색 기능의 요구사항을 충족했다고 결론 내리면 두 문서가 답하는 범위를 혼동하게 됩니다.
| 판단할 질문 | 참고할 문서 | 그 문서로 결정할 범위 |
|---|---|---|
| 페이지 정보를 어떤 유형과 속성으로 표현할까 | 스키마닷오알지의 유형·속성 정의 | 표현할 대상과 속성의 의미 |
| 선택한 구글 검색 기능에 무엇이 필요할까 | 구글 검색 센터의 해당 기능 문서 | 필수·권장 속성과 기능별 적용 요건 |
| 내용과 배치에 어떤 조건을 적용할까 | 구글의 일반 가이드라인과 해당 유형의 추가 지침 | 페이지 내용과의 관련성 및 구현 조건 |
| 다른 서비스에도 속성을 사용할까 | 사용하려는 서비스의 문서와 내부 사용 자료 | 그 서비스에서의 사용 목적과 유지 필요성 |
문서 간 차이는 곧바로 어느 한쪽의 오류를 뜻하지 않습니다. 같은 속성을 설명하더라도 용어의 의미와 특정 기능의 적용 조건은 다를 수 있습니다. 운영자는 차이가 발생한 문장을 기록하고, 그 문장이 정의를 설명하는지 기능의 조건을 설명하는지부터 가립니다.
해당 기능 문서까지 읽는 판단 범위
구글 검색 센터는 검색 동작을 판단할 때 자사 문서를 최종 참고 기준으로 설명합니다. 또한 일반 가이드라인과 사용하는 구조화된 데이터 유형의 지침을 함께 따르도록 안내합니다. 운영자는 일반 소개 문서만 읽고 구현 요청을 끝내지 말고, 선택한 기능의 속성 목록과 추가 지침까지 요청 범위에 포함합니다.
구글은 특정 리치 결과 유형에 필요한 필수 속성을 모두 지정해야 한다고 설명합니다. 권장 속성은 가능한 한 많이 채우는 것보다 완전하고 정확하게 제공하는 것이 중요하다고 안내합니다. 따라서 필수 속성의 누락과 권장 속성에 넣을 자료의 부족을 같은 사유로 처리하지 않습니다. 필수 자료가 없으면 적용 요건을 충족할 수 있는지 판단하고, 권장 자료가 불명확하면 임의의 값을 만들지 않고 제외 사유를 남깁니다.
추가 지침은 속성 목록과 별도로 읽어야 합니다. 구글의 일반 가이드라인은 구조화된 데이터가 페이지의 실제 내용을 표현해야 한다고 설명하며, 해당 유형 문서의 추가 조건도 따르도록 안내합니다. 운영자는 속성을 채웠다는 기록과 페이지 내용이 그 값을 뒷받침한다는 기록을 각각 작성합니다.
적용 목적에서 시작하는 실행 순서
운영자는 구현 목적을 정한 뒤 정의와 기능 요건을 순서대로 연결합니다. 처음부터 속성 목록을 개발 담당에게 넘기면 어떤 검색 기능을 위한 요청인지 빠질 수 있습니다. 요청서에는 대상 페이지, 표현하려는 정보, 구현하려는 구글 검색 기능을 먼저 기재합니다.
- 운영자는 대상 페이지에서 어떤 정보를 검색 기능에 연결하려는지 설명하고, 구글 검색의 구조화된 데이터 기능 목록에서 구현할 기능을 선택합니다.
- 개발 담당은 스키마닷오알지의 유형·속성 정의를 읽고, 페이지 정보에 맞는 의미인지 대조합니다. 운영자는 각 값의 근거가 되는 콘텐츠와 관리 자료를 전달합니다.
- 개발 담당은 구글 검색 센터의 해당 기능 문서에서 필수·권장 속성과 추가 지침을 정리합니다. 운영자는 자료의 유무와 정확성을 기준으로 적용할 항목을 결정합니다.
- 양측은 문서 사이에 차이가 있는 항목의 처리 사유를 요청서에 기록합니다. 구글 검색용 적용 결정과 다른 서비스의 사용 여부는 별도 항목으로 남깁니다.
준비할 자료에는 페이지에 표시되는 설명, 속성 값의 출처, 해당 정보를 관리하는 부서가 포함됩니다. 개발 담당에게는 문서 이름뿐 아니라 판단에 사용한 항목명과 요건의 내용을 전달합니다. 설명을 읽고도 적용 이유를 알 수 없다면 속성 이름만 추가로 나열하지 말고, 목적이나 자료의 누락을 먼저 보완합니다.
문서 간 차이를 전달하는 요청서
개발 요청서는 차이가 난 항목과 처리 결정을 연결해야 합니다. 아래처럼 기록하면 운영자가 의미를 정한 이유와 개발 담당이 적용 요건을 처리한 이유를 함께 남길 수 있습니다. 이 표는 특정 기능의 속성 목록을 대신하는 양식이므로, 실제 항목은 선택한 기능 문서에서 가져옵니다.
| 문서 간 차이 항목 | 구글 검색용 적용 판단 | 개발 담당에게 전달할 근거 |
|---|---|---|
| 정의에는 있으나 기능 문서에 없는 속성 | 해당 기능의 필수 항목으로 임의 지정하지 않음 | 속성의 의미, 사용 목적, 다른 서비스의 사용 여부 |
| 해당 기능에서 필수로 지정한 속성 | 필수 요건에 맞게 제공할 수 있는지 결정 | 기능 문서의 요구사항과 실제 값의 출처 |
| 권장 속성이지만 정확한 자료가 없는 항목 | 추정값으로 채우지 않고 제외 사유 기록 | 부족한 자료와 자료를 관리하는 부서 |
| 속성 외에 추가 지침이 있는 항목 | 추가 조건을 구현 범위에 포함 | 적용할 지침과 대상 페이지의 내용 |
요청서의 완료 조건은 코드에 속성 이름이 들어갔는지만으로 정하지 않습니다. 값의 출처를 연결했는지, 선택한 기능의 요건을 반영했는지, 남은 자료 요청이 무엇인지까지 기록합니다. 아직 결정하지 못한 항목은 완료 항목과 따로 표시하고, 운영 판단이 필요한지 개발 작업이 필요한지 담당을 지정합니다.
문서에 없는 속성을 삭제하는 오류
구글 기능 문서에 속성이 없다는 이유만으로 삭제하면 다른 사용 목적까지 영향을 받을 수 있습니다. 구글 검색 센터는 스키마닷오알지에 구글 검색에 필요하지 않은 속성과 객체가 더 있으며, 이들이 다른 검색 엔진이나 서비스·도구·플랫폼에서 유용할 수 있다고 설명합니다. 삭제를 요청하기 전에는 그 속성을 누가 어떤 목적으로 사용하는지 관리 자료에서 찾아야 합니다.
반대로 다른 서비스에 유용할 수 있다는 설명을 모든 속성을 유지해야 한다는 뜻으로 확대하지 않습니다. 운영자는 실제 사용 목적, 값을 관리하는 담당자, 정확한 자료를 계속 확보할 수 있는지를 근거로 유지 여부를 결정합니다. 사용처가 불명확한 항목은 유용성을 단정하지 말고 결정에 필요한 자료를 요청합니다.
구글은 문서에 설명한 항목 외에도 sameAs와 다른 스키마닷오알지 데이터를 일반적으로 사용한다고 설명합니다. 이 사실만으로 문서에 없는 개별 속성의 처리 방식이나 검색 기능을 추정할 수는 없습니다. 따라서 요청서에는 '기능 문서에 기재되지 않음'과 '구글이 사용하지 않음'을 같은 표현으로 적지 않습니다.
다른 검색 엔진으로 확대하지 않는 결론
구글 검색용 적용 결정은 다른 검색 엔진의 문서 우선순위까지 결정하지 않습니다. 다른 서비스에도 같은 데이터를 전달하려면 그 서비스의 문서와 사용 목적을 별도로 확보해야 합니다. 구글 기준으로 완료한 작업에 다른 서비스까지 대응했다는 설명을 추가하지 않습니다.
여러 사용 목적이 있는 속성은 요청서에 목적별 판단을 남깁니다. 구글 검색 기능을 위해 필요한 항목과 내부 관리 또는 다른 서비스 때문에 유지하는 항목의 근거를 각각 기재합니다. 공통으로 사용하는 값의 의미가 서로 어긋나면 어느 목적에서 나온 요청인지 가린 뒤, 개발 담당에게 데이터 처리 방식을 논의하도록 요청합니다.
속성 목록과 예시 코드의 역할
문서의 예시 코드에 있는 항목을 그대로 회사의 입력 목록으로 삼는 방식은 피합니다. 예시를 참고하더라도 적용 결정을 내릴 때는 필수·권장 설명과 추가 지침을 근거로 기록합니다. 코드에 값이 들어 있다는 이유만으로 그 값을 회사도 반드시 제공해야 한다고 요청하지 않습니다.
운영자는 개발 담당에게 완성된 코드만 전달하기보다 값의 출처와 자료 부족 여부를 함께 전달합니다. 회사가 관리하지 않는 정보를 예시 형태에 맞추기 위해 새로 만들지 않습니다. 예시와 실제 자료가 다르면 형식을 흉내 내는 작업보다 어떤 정보를 정확하게 표현할 수 있는지 결정하는 작업을 먼저 진행합니다.
자주 묻는 질문
구조화된 데이터 형식도 기능 문서만으로 결정해야 하나요?
구글은 사이트 설정이 허용하면 JSON-LD를 사용하도록 권장하며, 구현과 유지보수가 쉽다는 이유를 설명합니다. 개발 담당은 사이트의 출력 방식과 수정 가능한 범위를 정리한 뒤 사용할 형식을 제안합니다. 속성의 의미를 정하는 작업과 코드 형식을 선택하는 작업은 별도 결정으로 기록합니다.
마케팅 담당자가 코드 전체를 읽을 수 있어야 하나요?
코드 전체를 해석하는 능력을 요청서 작성의 전제로 삼을 필요는 없습니다. 마케팅 담당자는 목적, 실제 값, 값의 출처를 설명하고 개발 담당에게 기술적 표현을 맡길 수 있습니다. 전달 내용을 이해하기 어렵다면 속성명과 그 뜻을 함께 기재한 목록을 요청합니다.
문서를 읽어도 페이지에 맞는 유형이 모호하면 어떻게 하나요?
먼저 페이지가 실제로 설명하는 대상과 내용을 문장으로 정리합니다. 구글은 스키마닷오알지에서 가장 구체적이고 적절한 유형과 속성 이름을 사용하도록 안내합니다. 운영자는 후보 유형을 개발 담당에게 전달하고, 각 후보가 페이지 내용에 맞는 이유를 요청합니다.
같은 페이지의 정보를 여러 항목으로 표현할 수 있나요?
구글은 한 페이지의 여러 항목을 중첩하거나 개별적으로 지정해도 파악할 수 있다고 설명합니다. 운영자는 페이지에 실제로 존재하는 정보와 항목 사이의 관계를 정리해 개발 담당에게 전달합니다. 항목을 여러 개 사용한다는 이유만으로 관계까지 자동으로 설명된다고 생각하지 않습니다.
여러 부서가 서로 다른 속성 값을 전달하면 어떻게 처리하나요?
코드에 먼저 입력된 값을 최종값으로 채택하지 않습니다. 운영자는 각 부서가 사용한 자료와 적용 대상을 대조하고, 해당 정보를 관리하는 책임 부서에 최종값을 요청합니다. 결정한 값의 출처를 요청서에 남겨 후속 작업에서 서로 다른 값이 재사용되지 않도록 합니다.