구조화 데이터 오류와 경고의 차이

오류와 경고의 수정 우선순위

구글의 리치 결과 테스트 도움말은 유효한 항목에도 경고가 있는 상태를 제시하며, 잘못된 항목이 있는 상태를 따로 설명합니다. 따라서 경고가 있다는 이유만으로 항목 전체가 무효라고 결론 내릴 수 없습니다. 반대로 오류를 단순한 정보 보완 요청으로 처리하면 표시 요건을 충족하지 못하는 원인을 남길 수 있습니다.

이 표는 상태 이름만으로 수정 내용을 확정하지 않기 위한 판단 기준입니다. 마케팅 담당자는 문제가 표시된 항목과 설명을 개발 담당자에게 전달하고, 개발 담당자는 그 설명이 실제 데이터의 어떤 결함을 가리키는지 정리합니다. 아직 원인을 가리지 못한 항목은 수정 완료 대상과 섞지 않고 판단 대기 항목으로 관리합니다.

필수 요건과 정보 보완의 목적

구글 검색 센터의 일반 가이드라인은 해당 리치 결과 유형의 필수 속성이 빠지면 그 항목을 리치 결과로 표시하지 않는다고 설명합니다. 필수 속성 누락이 밝혀졌다면 운영자는 권장 정보의 추가보다 해당 결함의 수정을 먼저 요청합니다. 이때 다른 유형에서 필수인 속성을 현재 항목에도 그대로 적용하지 않도록 대상 유형과 속성 설명을 함께 기재합니다.

권장 속성은 필수 요건을 대신하는 수단이 아닙니다. 구글 검색 센터는 부정확하거나 불완전한 권장 정보를 많이 채우는 것보다 적더라도 완전하고 정확한 정보를 적용하는 것이 중요하다고 설명합니다. 콘텐츠 담당자는 추가할 정보가 실제 페이지 내용과 일치하는지, 현재 자료로 정확하게 작성할 수 있는지 판단합니다.

필수·권장이라는 이름은 속성의 역할을 설명하고, 오류·경고라는 표시는 발견된 문제의 상태를 전달합니다. 두 이름을 일대일로 연결하면 값의 문제를 누락으로 오해하거나, 설명을 읽기 전에 담당 업무를 잘못 정할 수 있습니다. 수정 순서는 표시 색상이나 경고 개수보다 해당 문제 때문에 충족하지 못하는 요건을 근거로 결정합니다.

문제 설명에서 수정 판단까지의 순서

실무에서는 상태를 먼저 나누고, 속성의 요건을 찾은 뒤, 표시 요건을 막는 문제부터 수정 여부를 결정합니다. 이 순서를 유지하면 자료 추가로 해결할 일과 기존 값의 결함을 고칠 일을 같은 요청으로 처리하지 않게 됩니다. 문제 설명이 모호하다면 담당자는 추정한 수정안을 확정하지 말고 판단에 필요한 근거를 먼저 보완합니다.

1. 마케팅 담당자는 오류와 경고를 따로 정리하고, 각 문제가 속한 구조화 데이터 항목의 유형과 이름을 기재합니다.
2. 개발 담당자는 문제 설명이 누락, 잘못된 값, 해석 불가 등 무엇을 지적하는지 문장으로 정리합니다.
3. 담당자는 해당 리치 결과 유형의 문서에서 관련 속성의 필수·권장 여부와 문제에 연결되는 조건을 찾습니다.
4. 운영자는 표시 요건을 막는 수정과 정보 보완 요청을 나누고, 각 작업을 진행할 담당자와 필요한 자료를 정합니다.

표의 판단은 문제 설명과 문서의 조건이 연결된 경우에만 확정합니다. 설명에 없는 누락 원인을 임의로 추가하거나, 권장이라는 이유만으로 지적된 문제를 모두 미뤄서는 안 됩니다. 담당자는 판단 근거가 부족한 항목에 필요한 질문을 남기고, 근거가 확보된 작업부터 요청합니다.

담당자가 준비할 근거와 자료

개발 요청에는 문제 이름뿐 아니라 대상 항목, 관련 속성, 문제 설명, 적용 요건을 함께 기재합니다. 개발 담당자는 현재 값과 지적된 조건의 관계를 설명하고, 콘텐츠 담당자는 올바른 값으로 사용할 실제 정보를 준비합니다. 운영자는 이 자료를 바탕으로 기술 수정이 필요한지, 콘텐츠 보완이 필요한지 업무를 배정합니다.

자료가 없는 항목에는 빈칸을 채우기 위한 추정값 대신 확보해야 할 정보와 담당자를 기재합니다. 요청서의 완료 조건도 경고 전체 삭제처럼 포괄적으로 쓰지 않고, 지적된 결함을 어떻게 처리할지 명시합니다. 판단이 끝나지 않은 문제는 보류 사유를 남겨 다음 담당자가 미처리와 의도적인 보류를 혼동하지 않게 합니다.

문제의 적용 범위가 달라지는 경우

한 페이지에 여러 구조화 데이터 항목이 있다면 문제의 적용 범위를 항목 단위로 기록해야 합니다. 구글의 리치 결과 테스트 도움말은 감지된 항목 중 일부가 잘못된 상태도 제시합니다. 운영자는 페이지에 오류가 있다는 요약만 전달하지 않고, 어느 항목에 어떤 문제가 연결되는지 요청서에 남깁니다.

같은 이름의 속성에 문제가 생겼더라도 서로 다른 항목의 수정 사유까지 같다고 단정할 수는 없습니다. 담당자는 각 항목에 적용되는 요건과 실제 값을 연결한 뒤 공통 작업으로 처리할 수 있는지를 결정합니다. 항목별 판단이 끝나기 전에 일괄 수정으로 묶으면 정상 정보까지 불필요하게 변경할 수 있습니다.

문제가 있는 항목을 삭제하는 요청도 목적을 명확히 해야 합니다. 경고 목록을 줄이기 위해 필요한 정보를 제거하는지, 페이지 내용과 관계없는 항목을 정리하는지에 따라 판단이 달라집니다. 운영자는 삭제할 항목이 페이지의 어떤 내용을 설명했는지 기재하고, 유지해야 할 정보까지 함께 제거되지 않도록 요청 범위를 제한합니다.

보류와 완료를 가르는 기록

수정 기록에는 작업 결과와 아직 해결하지 않은 판단을 따로 기재합니다. 필수 속성을 채우는 작업을 완료했더라도 권장 정보의 자료 확보가 남아 있다면, 두 작업을 하나의 완료 표시로 묶지 않습니다. 담당자는 완료한 문제의 이름과 남은 작업의 사유를 연결해 후속 업무가 사라지지 않도록 관리합니다.

보류 사유는 자료 미확보, 적용 조건 불명확, 담당자 판단 대기처럼 다음 행동을 정할 수 있는 표현으로 작성합니다. 단순히 경고라서 보류했다고 쓰면 어떤 근거로 다시 처리해야 하는지 알기 어렵습니다. 운영자는 보류를 해제하는 데 필요한 자료나 결정 사항을 함께 기재하고, 이를 확보할 담당자에게 요청합니다.

완료 기록에서는 데이터 수정과 추가 자료 확보를 서로 다른 작업 결과로 남깁니다. 현재 값을 고친 담당자와 정보의 사실관계를 결정한 담당자가 다르다면 각자 처리한 내용을 기재합니다. 수정 사유를 읽을 수 있는 기록을 남기면 이후 같은 항목에 문제가 생겼을 때 이전 결정을 무조건 재사용하지 않고 현재 조건과 대조할 수 있습니다.

미사용 항목의 처리 판단

현재 운영 목적에 사용하지 않는 구조화 데이터 항목에서도 오류나 경고가 발견될 수 있습니다. 이 경우 운영자는 해당 항목을 계속 유지할 필요가 있는지 먼저 결정하고, 유지하기로 한 항목에 필요한 수정 자료를 요청합니다. 사용 여부가 불명확한 상태에서 속성부터 채우면 관리할 정보만 늘어날 수 있습니다.

미사용 판단은 오류를 피하기 위한 삭제 사유와 다릅니다. 담당자는 항목이 설명하는 콘텐츠가 현재 페이지에 존재하는지, 앞으로도 정보를 관리할 담당자가 있는지 기재합니다. 제거를 결정했다면 문제를 해결했다고 기록하기보다 해당 항목의 사용을 종료한 결정과 사유를 남깁니다.

이어서 읽을 주제

병원 답변 구조화 데이터는 답변 콘텐츠에 어떤 정보를 구조화할지 판단하는 후속 주제입니다. 오류와 경고의 수정 순서를 정한 뒤에는 답변 자체를 데이터로 표현할 때 필요한 내용과 관리 범위를 이어 검토할 수 있습니다.