Organization 스키마의 필수 항목

Organization의 필수 속성 판단

구글 검색 센터는 Organization에서 조직에 해당하는 권장 속성을 충분히 제공하도록 안내합니다. 이는 조직과 무관한 항목까지 채우라는 뜻으로 해석하지 않습니다. 마케팅 담당자는 항목의 수보다 해당 조직에 적용할 근거가 있는지를 판단하고, 개발 담당자는 그 판단에 따라 구현할 범위를 정합니다.

필수 속성이 없다는 설명은 Organization의 속성 요구에 관한 답입니다. 구조화된 데이터의 일반 가이드라인까지 적용하지 않아도 된다는 뜻은 아닙니다. 구글 검색 센터는 구조화된 데이터가 페이지의 실제 내용을 표현하고 사용자를 오해하게 만들지 않도록 요구합니다. 속성의 필수 여부와 콘텐츠가 지켜야 할 조건은 별도로 관리합니다.

예시와 속성 정의의 읽는 순서

공식 예시는 구성 방식을 이해하는 데 사용하고, 의무 여부는 해당 유형의 속성 정의에서 판단합니다. 예시를 먼저 복사하면 설명을 위해 들어간 항목과 실제 조직에 필요한 항목을 같은 수준으로 취급하기 쉽습니다. 담당자는 예시에서 추출한 목록에 곧바로 필수 표시를 하지 않고, 각 항목이 문서에서 어떤 표현으로 설명되는지 대조합니다.

일반 가이드라인에 모든 필수 속성을 지정하라는 문장이 있어도 적용 대상은 특정 리치 결과 유형 문서의 필수 속성입니다. 구글 검색 센터는 해당 필수 속성이 빠진 항목은 리치 결과로 표시되지 않는다고 설명합니다. 이 설명을 Organization의 예시 전체가 필수라는 근거로 옮겨 쓰지 않습니다. 같은 검색 센터 문서라도 문장이 가리키는 유형과 범위를 함께 읽어야 합니다.

구글 검색 센터는 구글 검색의 동작을 판단할 때 검색 센터 문서를 최종 기준으로 삼도록 안내합니다. 더 넓은 구조화된 데이터 어휘에 속성이 정의되어 있다는 사실만으로 구글 검색의 필수 항목이라고 결론 내리지 않습니다. 다른 서비스에서 사용할 목적이 있다면 그 목적을 별도로 기록하고, 구글 검색 대응 항목과 섞이지 않게 관리합니다.

유형에서 요청서까지의 실행 순서

작업은 적용 유형을 정하는 일부터 시작합니다. 마케팅 담당자는 대상 페이지가 무엇을 설명하는지 정리하고, 개발 담당자는 적용하려는 유형 이름을 전달합니다. 조직이라는 넓은 설명만으로 모든 페이지에 같은 속성 요구를 배정하지 않도록 두 자료를 함께 사용합니다.

1. 적용하려는 유형과 해당 유형의 구글 검색 센터 문서를 연결합니다. 더 구체적인 하위유형을 사용할 계획이라면 그 문서도 별도로 확보합니다.
2. Organization 안내에서 필수 속성 유무와 권장 속성의 적용 범위를 읽습니다. 다른 유형의 조건은 해당 유형 이름과 함께 기록합니다.
3. 현재 요청서의 의무 항목이 어디서 나온 것인지 대조합니다. 예시를 복사하면서 의무로 표시한 항목은 근거 문구를 다시 찾습니다.
4. 분류 결과를 개발 요청서에 반영합니다. 판단이 끝난 항목과 자료가 더 필요한 항목을 나누어 전달하고, 미결 사항의 결정 담당자를 정합니다.

구글 검색 센터는 조직에 적절한 구체적인 하위유형을 사용하도록 권합니다. 지역 비즈니스에 해당한다면 Organization의 권장 항목 외에 해당 유형의 필수·권장 항목도 따르도록 안내합니다. 하위유형을 선택한 경우에는 Organization만 읽고 요청서를 확정하지 않습니다.

개발 요청서의 항목 분류

요청서는 검색 문서의 요구와 회사가 정한 작업 조건을 따로 표현합니다. 회사가 내부 운영상 반드시 전달받기로 한 항목도 있을 수 있지만, 이를 구글의 필수 속성이라고 기재하지 않습니다. 개발 담당자가 요청의 이유를 알 수 있도록 분류 근거와 처리 방향을 함께 전달합니다.

마케팅 담당자가 준비할 자료는 대상 페이지의 설명, 적용 유형 목록, 요구를 뒷받침하는 문서명과 관련 문구입니다. 여기에 현재 요청서와 항목별 판단 상태를 추가하면 개발 담당자가 변경 범위를 정할 수 있습니다. 자료가 없는 칸을 채우기 위해 임의의 값을 만들지 않고, 누가 어떤 자료를 전달해야 하는지 기재합니다.

전달 전에 요청서의 필수 표시마다 근거가 연결되어 있는지 점검합니다. 근거가 회사 내부 방침이면 그 사실을 명시하고, 문서 해석이 끝나지 않았으면 미결 상태로 남깁니다. 승인 담당자는 작업 완료 여부와 항목 분류의 승인 여부를 따로 처리합니다.

필수 표시가 늘어나는 오해

속성을 포함할 수 있다는 설명과 반드시 포함해야 한다는 요구는 다르게 처리합니다. 사용할 수 있는 항목을 모은 목록에 빈칸이 있다는 이유만으로 구현 누락이라고 판단하면 적용 범위가 불필요하게 넓어집니다. 현재 요청서에서 누락으로 표시된 항목은 앞에서 정한 기준에 따라 다시 분류합니다.

권장 속성을 최대한 포함하라는 안내도 모든 항목을 채우라는 작업 지시로 변경하지 않습니다. 구글 검색 센터는 불완전하거나 부정확한 권장 정보를 많이 넣기보다 정확하고 완전한 정보를 적용하는 편이 중요하다고 설명합니다. 자료가 충분하지 않은 항목은 값 입력을 서두르지 않고 적용 여부를 결정할 수 있는 자료부터 확보합니다.

다른 유형의 요구를 가져왔을 때는 속성 이름이 같다는 이유만으로 의무 수준까지 같다고 판단하지 않습니다. 특정 유형을 적용하려는 것인지, 참고 자료에서 항목 이름만 가져온 것인지 먼저 가립니다. 개발 요청서에 유형 이름이 빠져 있다면 마케팅 담당자가 사용 목적을 보완한 뒤 필수 표시를 승인합니다.

누락 지적을 처리하는 기록

누락 지적을 받으면 바로 값을 추가하기보다 지적의 출처와 대상부터 기록합니다. 지적한 사람이 사용한 문서, 적용 유형, 빠졌다고 주장하는 항목을 같은 기록에 기재합니다. 이 기록으로 실제 요구를 충족하지 못한 경우와 회사의 작업 조건을 충족하지 못한 경우를 따로 처리할 수 있습니다.

수정 기록에는 문제 표현과 결정 이유를 함께 남깁니다. 예시 항목을 필수로 오해했다면 값 추가가 아니라 요청서의 분류 수정이 필요한 작업일 수 있습니다. 반대로 적용 유형 자체가 달라졌다면 항목 하나의 상태만 변경하지 않고 해당 유형의 요구를 다시 반영합니다.

마케팅 담당자는 수정 후에도 남아 있는 질문을 결정 담당자에게 전달합니다. 개발 담당자는 기술적으로 입력 가능한지를 답하고, 조직 정보 담당자는 실제 자료를 사용할 수 있는지를 답합니다. 입력 가능하다는 답만으로 내용까지 승인된 것으로 처리하지 않습니다.

필수 없음의 적용 범위

필수 속성이 없다는 설명은 구현 문법이나 문서 전체의 작성 규칙까지 없다는 뜻으로 확대하지 않습니다. Organization 속성 목록의 분류와 데이터 형식의 성립 여부는 서로 다른 질문입니다. 개발 담당자에게는 속성 요구에 관한 판단과 형식에 관한 질문을 별도 항목으로 전달합니다.

요청서에서 필수 속성을 삭제했다는 표현도 무엇을 수정했는지 불명확할 수 있습니다. 실제 데이터를 제거했는지, 의무 표시만 해제했는지, 적용 보류로 변경했는지를 구체적으로 기재합니다. 운영자는 승인 전에 변경 내역이 자료 삭제로 잘못 전달되지 않았는지 대조하고, 유지할 항목에는 처리 상태를 명시합니다.

이어서 읽을 주제

병원 정보 점검은 업종별 공개 정보의 관리 항목을 따로 정리하려는 독자가 이어 읽을 주제입니다. 병원 플레이스 등록은 구조화된 데이터 작업과 별개로 등록 서비스에 전달할 자료와 절차를 정리할 때 이어 읽을 주제입니다.