구조화 데이터 작업을 개발자에게 요청하는 문서

개발 요청서의 구성 기준

구조화 데이터는 페이지 내용을 검색엔진이 읽을 수 있도록 설명하는 표시 정보입니다. 구글은 이 정보를 페이지 콘텐츠와 그 안에 등장하는 대상의 정보를 이해하는 데 사용한다고 설명합니다. 요청서에는 화면을 어떻게 꾸밀지보다 어떤 페이지 정보를 어떤 속성으로 전달할지 기재합니다.

요청서의 완성도는 개발자가 빈칸을 추측하지 않고 작업할 수 있는지로 판단합니다. 운영자는 확정된 사실과 아직 결정하지 않은 항목을 따로 표시하고, 미정 항목에는 결정에 필요한 자료를 기재합니다. 개발자가 질문해야 할 내용까지 모두 확정할 필요는 없지만, 내용 결정과 기술 판단을 같은 빈칸으로 남기지 않습니다.

요청 항목과 입력 근거의 연결

요청서 첫머리에는 적용할 페이지의 이름과 식별 정보, 구현하려는 검색 기능을 기재합니다. 구글 검색 센터는 구조화된 데이터 기능 목록에서 구현할 기능을 선택하고 해당 기능의 안내를 따르도록 설명합니다. 운영자는 기능 이름만 전달하지 말고 그 기능이 설명할 페이지 내용도 함께 지정합니다.

표의 빈칸은 개발자가 임의로 채우는 공간으로 사용하지 않습니다. 운영자는 값이 없는 이유를 자료 미확정, 공개 내용 부재, 적용 여부 미결정처럼 기재합니다. 서로 다른 이유를 표시해야 개발자가 정보 요청과 구현 검토를 각각 진행할 수 있습니다.

참고 문서와 요청 근거의 역할

참고 문서는 속성을 요청한 이유를 추적할 수 있는 형태로 정리합니다. 문서 이름과 관련 항목, 운영자가 읽은 날짜를 기재하고 필수 속성과 권장 속성을 따로 표시합니다. 구글은 특정 리치 결과 유형에서 요구하는 필수 속성이 빠지면 해당 항목이 리치 결과로 표시되지 않는다고 설명합니다.

필수·권장 여부는 담당자의 선호로 정하지 않고 선택한 기능의 문서에서 가져옵니다. 회사에서 추가로 원하는 정보는 별도의 요청 사유를 기재합니다. 문서상 요구와 회사의 선택을 나누면 개발자는 의무적으로 구현할 항목과 추가 협의할 항목을 가릴 수 있습니다.

자료 준비와 요청서 작성 순서

운영자는 적용 대상부터 정한 뒤 입력 자료를 모으고 마지막에 완료 조건을 작성합니다. 기능과 입력값을 먼저 뒤섞어 기재하면 어느 페이지에 어느 값을 사용할지 불분명해질 수 있습니다. 다음 순서로 문서를 작성하고, 각 단계에서 결정되지 않은 내용은 질문 항목으로 남깁니다.

1. 적용 페이지와 구현할 기능을 지정합니다. 사이트 운영자는 대상 목록과 페이지별 주요 콘텐츠를 준비하고, 제외 대상도 함께 기재합니다.
2. 속성별 입력값과 공개 근거를 정리합니다. 콘텐츠 담당자는 값의 표기와 공개 위치를 연결하고, 개발자는 값을 가져올 관리 항목을 검토합니다.
3. 구현 범위와 완료 확인 자료를 명시합니다. 운영자는 승인 조건을 작성하고, 개발자는 구현 결과를 어떤 자료로 전달할지 답합니다.

입력값은 설명문과 분리해 그대로 전달할 수 있는 형태로 정리합니다. 같은 정보의 표기가 여러 곳에서 다르면 콘텐츠 담당자가 사용할 값을 결정한 뒤 전달합니다. 개발 요청서에 상충하는 값을 모두 남기고 개발자에게 선택을 맡기지 않습니다.

구현 범위와 개발자 답변 항목

구현 범위에는 개별 페이지를 수정하는지, 공통 양식에 적용하는지, 페이지별 값을 관리 정보에서 가져오는지를 기재합니다. 운영자가 현재 시스템의 동작을 모르면 원하는 결과와 제한 조건을 먼저 쓰고 구현 가능 여부를 개발자에게 묻습니다. 특정 구현 형식을 지정하지 않더라도 대상과 제외 범위는 확정할 수 있습니다.

개발자는 기존 표시 정보와 이번 요청이 함께 존재할 수 있는지, 콘텐츠 편집 기능의 변경이 필요한지, 작업 대상 밖에도 영향이 있는지를 답하도록 요청합니다. 운영자는 그 답변을 받은 뒤 범위 변경 사항을 명세에 반영합니다. 추가 작업을 완료 보고에서 처음 접하지 않도록 착수 전에 합의할 항목을 별도로 표시합니다.

완료 보고에 받을 자료

완료 보고는 작업했다는 문장보다 요청과 결과를 연결하는 자료로 받습니다. 구글은 리치 결과 테스트로 구조화된 데이터의 유효성을 검사하고 발견된 유형과 오류, 제안사항을 확인할 수 있다고 설명합니다. 운영자는 테스트 결과와 내용 대조 자료를 함께 요청하되 각각 다른 승인 항목에 사용합니다.

코드 검사 결과와 공개 페이지 검사 결과는 무엇을 대상으로 했는지 제목에 표시하도록 요청합니다. 작업 완료는 합의한 범위를 구현하고 증빙을 제출했는지로 판단하며, 이를 검색 노출이나 순위, AI 답변 인용의 보장으로 처리하지 않습니다.

입력 근거와 코드 값의 차이

요청서에서 자주 생기는 문제는 공개 근거를 개발자가 사용할 입력값과 동일하게 취급하는 일입니다. 공개 근거는 사용자가 그 정보를 읽을 수 있는 위치이고, 입력값은 구현에 사용할 확정 내용입니다. 본문 위치만 전달하면 개발자가 긴 설명에서 값을 추출해야 하므로 운영자는 두 항목을 별도로 작성합니다.

구글은 사용자에게 표시되지 않는 정보를 구조화된 데이터에 추가하지 말고 페이지 콘텐츠를 실제로 표현하도록 안내합니다. 콘텐츠 담당자는 공개된 문장에 없는 의미가 입력값에 추가되었는지 대조합니다. 내부 자료에 정확한 정보가 있더라도 공개 내용에 없는 정보라면 요청값으로 확정하기 전에 공개 여부를 결정합니다.

완료 자료에서는 속성 이름 옆에 요청값, 구현값, 공개 위치를 연결해 기록합니다. 문자열이 같은지만 판단하지 말고 같은 대상을 설명하는지도 대조합니다. 문장 전체를 복사하지 않는 값이라면 개발자가 값을 추출하거나 변환한 규칙을 설명하도록 요청합니다.

조건부 완료와 보류 항목의 기록

요청한 항목을 일부 구현하지 못했다면 그 사실을 완료 표시 안에 숨기지 않습니다. 개발자는 미반영 항목과 이유를 제출하고 운영자는 해당 항목을 이번 승인에서 제외할지 결정합니다. 보류 사유와 승인 범위를 함께 기록해야 완료라는 표현이 어디까지 적용되는지 명확해집니다.

테스트 자료가 제출되었어도 승인된 입력값과 다른 내용이 구현되었다면 내용 승인까지 끝난 것으로 처리하지 않습니다. 반대로 내용이 일치하더라도 약속한 검사 자료가 빠졌다면 증빙 제출은 남은 작업으로 기록합니다. 운영자는 구현 상태, 내용 승인, 자료 제출을 각각 기록해 서로 다른 미완료 사항이 섞이지 않도록 합니다.

작업 중 추가된 페이지나 속성은 최초 요청과 별도로 변경 이력을 남깁니다. 변경 이유와 승인한 내용을 기재하고, 그 변경을 반영한 완료 자료를 받습니다. 최초 요청서만 기준으로 승인하면 합의 후 추가된 작업이 결과 대조에서 빠질 수 있습니다.

예외 페이지를 선택하는 기준

공통 양식에 적용하는 작업에서는 내용이 충실한 대표 페이지만 완료 대상으로 선택하지 않습니다. 운영자는 선택 입력란이 비어 있는 페이지, 본문 구성에 차이가 있는 페이지, 공개 상태가 다른 페이지를 대상 목록에서 가려 개발자에게 전달합니다. 이는 플랫폼의 별도 요구가 아닌 공통 구현의 적용 범위를 판단하기 위한 운영 절차입니다.

예외 페이지에는 정상 페이지의 값을 복사해 채우도록 요청하지 않습니다. 실제 콘텐츠에 값이 없는 경우에는 해당 페이지의 처리 방침을 개발자가 설명하도록 합니다. 운영자는 예외 처리가 다른 페이지의 정보 사용으로 이어지지 않았는지 결과 자료에서 대조하고, 미결정 사항은 승인 범위에서 제외합니다.

이어서 읽을 주제

병원 답변 구조화 데이터는 업종별 답변 콘텐츠에 적용할 때 어떤 공개 자료와 요청 항목이 필요한지 이어 읽을 주제입니다. 공통 작업 명세를 특정 콘텐츠에 적용하는 판단을 이해하려는 독자에게 연결되는 내용입니다.