JSON-LD와 마이크로데이터 가운데 정하는 기준

검색상 우열보다 사이트 구현 조건

구글 검색 센터는 별도로 명시한 경우를 제외하면 두 형식을 모두 지원하며, 유효한 마크업을 기능 문서에 맞게 구현했을 때 검색에서 사용할 수 있다고 설명합니다. 따라서 운영자는 권장 형식이라는 이유만으로 JSON-LD에 검색상 우위를 부여하지 않습니다. 형식 이름을 정하기 전에 적용하려는 검색 기능의 문서에서 별도 조건이 있는지 읽어야 합니다.

이 표는 지원되는 형식 중 어느 쪽을 실제 사이트에 적용할지 판단하는 기준입니다. 개발 담당이 사이트 제약을 조사하기 전에는 형식을 최종 확정하지 않는 편이 적절합니다. 운영자는 검색 기능의 요구 조건과 사이트에서 가능한 작업을 함께 기록해 결정 근거로 사용합니다.

구현 방식에 따른 수정 범위

구글 검색 센터는 사이트 설정이 허용할 때 JSON-LD를 권장하며, 그 이유를 구현과 유지보수의 편의성으로 설명합니다. JSON-LD는 HTML 페이지 안의 스크립트 태그에 구조화된 데이터를 넣는 방식입니다. 개발 담당에게는 해당 위치에 데이터를 입력하고 이후 값을 수정할 수 있는지 구체적으로 묻습니다.

마이크로데이터는 HTML 콘텐츠의 태그 속성으로 구조화된 정보의 이름을 지정하는 방식입니다. 이 형식을 선택하려면 데이터가 연결될 HTML 속성을 사이트에서 편집할 수 있어야 합니다. 운영자는 페이지 내용의 변경과 관련 속성의 수정을 함께 처리할 수 있는지를 개발 담당에게 요청합니다.

두 방식의 차이는 데이터 수정이 사이트의 어느 부분에 영향을 주는지 판단하는 데 사용합니다. JSON-LD를 넣을 수 있다는 답변만으로 값의 수정까지 가능하다고 해석해서는 안 됩니다. 마이크로데이터 역시 HTML 편집이 가능하다는 답변에서 그치지 않고, 필요한 속성을 실제로 수정할 수 있는지 답변을 받아야 합니다.

기능 문서부터 테스트까지의 순서

운영자는 적용하려는 검색 기능을 정한 뒤 해당 기능 문서의 형식 조건부터 읽습니다. 구글 검색 센터는 구글 검색 동작에 관한 판단에서 스키마닷오알지 문서보다 검색 센터 문서를 최종 참고 대상으로 삼도록 안내합니다. 일반적인 형식 설명만으로 개별 기능의 구현 조건을 확정하지 않습니다.

1. 운영자가 해당 검색 기능 문서에서 허용 형식과 구현 조건을 정리합니다.
2. 개발 담당이 사이트 설정을 조사하고, 형식별 입력과 수정 가능성을 답변합니다.
3. 운영자가 앞에서 정한 기준에 따라 형식을 선택하고 결정 이유를 기재합니다.
4. 개발 담당이 선택한 형식으로 작성한 데이터를 리치 결과 테스트에서 시험합니다.

개발 담당에게 전달할 자료에는 적용하려는 기능명, 대상 페이지, 구조화할 정보의 항목을 포함합니다. 현재 사이트에서 사용하는 형식을 알고 있다면 그 내용도 함께 전달합니다. 페이지 정보가 변경될 때 수정해야 하는 항목을 표시하면, 처음 입력할 수 있는지와 이후 수정할 수 있는지를 별도로 답변받기 쉽습니다.

개발 담당에게 요청할 조건과 답변

개발 담당에게는 선호하는 형식보다 실제로 허용되는 작업을 묻습니다. 답변에는 가능한 작업과 제한되는 작업을 나누어 기재하도록 요청합니다. 아직 조사하지 못한 조건은 불가능으로 처리하지 않고 미확정 항목으로 남깁니다.

답변이 모이면 운영자는 허용되는 형식과 추가 조사가 필요한 형식을 따로 기록합니다. 두 형식 모두 가능하다면 개발 담당이 설명한 수정 범위와 제약을 근거로 선택 이유를 작성합니다. 특정 페이지에만 적용할 수 있다는 답변을 사이트 전체에서 사용할 수 있다는 뜻으로 확대하지 않습니다.

선택 결과에는 형식 이름뿐 아니라 적용 대상과 판단에 사용한 사이트 조건을 함께 기재합니다. 조건이 달라질 때 어느 결정을 다시 검토해야 하는지 알 수 있도록 하기 위한 실무 기록입니다. 작업 방법의 세부 설계는 이 선택 기록과 별도로 작성합니다.

권장 형식과 필수 조건의 차이

자주 틀리는 판단은 JSON-LD 권장을 모든 사이트의 필수 형식으로 받아들이는 것입니다. 구글 검색 센터의 권장은 사이트 설정이 허용한다는 조건을 포함합니다. 개발 담당의 조사에서 제한이 드러났다면, 운영자는 그 제한을 기록하고 마이크로데이터가 해당 기능에 맞게 구현 가능한지 판단합니다.

반대로 현재 사이트에서 마이크로데이터를 사용한다는 이유만으로 앞으로도 같은 형식을 선택할 필요는 없습니다. 기존 형식이 있다는 사실과 새 적용 대상에서 적합하다는 판단은 별개의 문제입니다. 변경을 검토할 때는 익숙함이나 선호보다 이번 대상의 입력·수정 조건을 근거로 삼습니다.

두 형식을 모두 사용할 수 있다는 답변을 받았을 때는 작업 범위의 차이를 더 구체적으로 요청합니다. 처음 입력할 때 필요한 변경과 정보가 갱신될 때 필요한 변경을 나누어 설명하도록 합니다. 개발 담당이 제약을 특정하지 못했다면 운영자는 선택 이유를 확정하지 않고 조사할 조건을 명시합니다.

형식 결정 이후의 테스트 자료

선택한 형식은 리치 결과 테스트에서 시험할 수 있습니다. 구글의 리치 결과 테스트 도움말은 JSON-LD와 마이크로데이터를 지원 형식으로 안내합니다. 따라서 마이크로데이터를 선택했다고 해서 별도의 형식으로 변환한 뒤 시험해야 한다고 판단하지 않습니다.

운영자는 개발 담당에게 선택한 형식이 적용된 페이지 또는 구현 코드를 테스트 자료로 요청합니다. 제출한 자료에 사용한 형식과 적용 대상을 함께 기재하면 선택 기록과 시험 자료를 연결할 수 있습니다. 테스트를 위해 다른 형식으로 다시 작성한 자료를 받았다면, 실제 선택한 형식의 시험 자료도 별도로 요청합니다.

형식을 결정한 기록과 테스트를 실행한 기록은 각각 남깁니다. 전자는 사이트 조건에 따른 선택을 설명하고, 후자는 선택 이후 시험을 진행했는지 나타냅니다. 형식 이름을 결정한 것만으로 구현과 테스트까지 완료했다고 보고하지 않습니다.

사이트 제약에 대한 답변의 유효 범위

사이트 설정에 대한 답변은 어떤 운영 상태를 전제로 했는지 함께 기록하는 편이 좋습니다. 현재 설정에서 가능한 작업인지, 설정 변경이 있어야 가능한 작업인지에 따라 선택 시 필요한 준비가 달라집니다. 개발 담당에게 답변의 전제와 미확정 사항을 분리해 기재하도록 요청합니다.

또한 조사 대상에서 제외된 페이지나 편집 영역이 있다면 기록에 명시합니다. 제한된 범위의 답변을 전체 사이트의 조건으로 받아들이면 적용 대상을 추가할 때 판단 근거가 부족해집니다. 새 대상이 기존 조사 범위를 벗어나면 필요한 조건만 추가로 질문합니다.

이어서 읽을 주제

진료 페이지 SEO는 페이지의 검색 목적과 콘텐츠 요건을 다루므로, 구조화 데이터 형식을 선택한 뒤 해당 주제의 페이지 설계 기준을 이어 읽을 때 참고할 수 있습니다. 형식 선택 기록과 콘텐츠 설계 자료를 별도로 정리하면 기술 조건과 페이지 요건에 관한 질문을 나누어 전달할 수 있습니다.