스키마 마크업 점검 체크리스트 | 연결 구조부터 페이지별 적용까지
연결되지 않은 스키마는 흩어진 정보일 뿐입니다
스키마 마크업은 검색 결과에 별점이나 추가 정보를 표시하기 위한 기술로만 생각하기 쉽습니다. 하지만 더 중요한 목적은 사이트의 정보를 기계가 이해할 수 있는 관계로 설명하는 것입니다.
예를 들면 다음과 같습니다.
이 회사가 어떤 조직인지
어떤 사람이 이 회사에 소속되어 있는지
누가 이 글을 작성했는지
어떤 조직이 이 상품이나 서비스를 제공하는지
여러 콘텐츠가 어떤 주제로 연결되어 있는지
이러한 관계를 구조적으로 보여 주는 것이 스키마 마크업의 핵심입니다.
그런데 실제 작업은 대부분 페이지별로 진행됩니다. 블로그 글에는 글 스키마를 넣고, 상품 페이지에는 상품 스키마를 따로 넣습니다. 각각의 문법은 맞지만 서로 연결되지 않는 경우가 많습니다.
이렇게 되면 페이지마다 같은 회사가 별개의 조직처럼 만들어집니다. 같은 저자가 쓴 글 50편도 서로 다른 50명의 글처럼 인식될 수 있습니다.
문제는 일반적인 검사 도구만으로는 이러한 오류를 찾기 어렵다는 점입니다. 대부분의 도구는 페이지 한 장씩 검사합니다. 각 페이지를 따로 검사하면 모두 정상으로 나올 수 있습니다. 사이트 전체를 하나로 놓고 봐야 정보 사이의 연결이 끊겨 있다는 사실을 발견할 수 있습니다.
해결 방법은 고유 식별자를 사용하는 것입니다.
고유 식별자는 조직이나 사람에게 부여하는 전용 주소와 같습니다. 조직 정보를 페이지마다 새로 입력하지 않고, 한 곳에서 정확하게 정의한 뒤 다른 페이지에서는 그 주소를 불러오는 방식입니다.
쉽게 말하면 조직을 200번 따로 설명하는 대신 한 번만 제대로 설명하고, 나머지 199곳에서는 “이 조직과 같은 곳”이라고 연결하는 것입니다.
이렇게 구성하면 회사 정보가 바뀌었을 때도 한 곳만 수정하면 됩니다. 페이지마다 회사명, 주소, 연락처를 따로 입력하면서 생기는 정보 불일치도 줄일 수 있습니다.
연결 구조가 중요한 또 다른 이유는 전문성의 축적입니다.
한 저자가 특정 분야의 글 50편을 썼고, 그 글들이 하나의 저자 정보로 연결되어 있다면 해당 저자가 어떤 분야를 꾸준히 다뤘는지 알 수 있습니다. 반면 글마다 이름만 적혀 있다면 같은 사람이 쓴 글인지 확실하게 구분하기 어렵습니다.
결국 스키마 연결은 저자의 경력, 소속, 전문 분야와 실제 콘텐츠를 하나의 증거로 이어 주는 작업입니다.
고유 식별자로 정보를 연결하는 방법
기본 원칙은 간단합니다.
정보는 한 번만 정의하고, 다른 페이지에서는 그 정보를 참조합니다.
다음 순서로 구성하면 됩니다.
조직을 대표할 기준 페이지를 정합니다. 일반적으로 회사 소개 페이지를 사용합니다. 이곳에 회사명, 주소, 연락처, 설립 정보 등 조직 정보를 자세히 작성합니다.
조직에 고유 식별자를 부여합니다. 회사 소개 페이지 주소 뒤에 구분 값을 붙이는 방식이 일반적입니다.
저자별 소개 페이지를 만들고 각각 고유 식별자를 부여합니다. 저자가 해당 조직에 소속되어 있다는 관계도 함께 표시합니다.
개별 글에서는 저자 이름과 회사 정보를 다시 입력하지 않고 각각의 식별자를 불러옵니다.
상품과 서비스 페이지에서도 제조사, 판매사 또는 서비스 제공자를 같은 조직 식별자로 연결합니다.
사이트 자체를 나타내는 웹사이트 정보를 별도로 만들고, 이 사이트를 운영하거나 발행하는 주체를 조직 식별자로 연결합니다.
조직 정보에는 동일한 조직임을 확인할 수 있는 외부 페이지 주소도 함께 넣습니다.
마지막 항목은 특히 자주 빠지는 부분입니다. 회사의 공식 등록 정보, 공공기관에 등록된 기업 정보, 공식 소셜미디어 계정처럼 외부에서 확인할 수 있는 주소를 함께 연결하면 실제 조직임을 확인하는 데 도움이 됩니다.
자사 사이트에서 스스로 회사 정보를 설명하는 것과 외부의 공식 정보까지 연결하는 것은 신뢰도 면에서 차이가 있습니다. 다만 관련이 없는 페이지나 단순한 언론 기사까지 무리하게 연결해서는 안 됩니다. 실제로 같은 조직임을 확인할 수 있는 주소만 사용해야 합니다.
식별자는 가급적 오래 유지할 수 있어야 합니다. 사이트를 개편하면서 주소가 바뀌면 기존 식별자 연결도 함께 끊길 수 있기 때문입니다.
소규모 사이트라면 회사 소개나 저자 소개 페이지 주소를 기반으로 식별자를 만들고, 개편할 때 기존 주소의 리디렉션과 식별자를 함께 유지하는 방법이 현실적입니다.
사이트와 조직도 구분해야 합니다. 회사는 하나지만 여러 브랜드 사이트를 운영할 수 있기 때문입니다. 조직 정보와 사이트 정보를 따로 만들고 서로 연결해야 각 사이트의 역할과 성격을 분명하게 설명할 수 있습니다.
▶ 핵심 정리: 회사와 저자 정보는 각각 한 곳에서 정의하고, 다른 페이지에서는 고유 식별자로 불러옵니다. 실제 조직임을 확인할 수 있는 외부 공식 주소도 함께 연결하는 것이 좋습니다.
저자 소개 페이지를 만드는 일을 부담스럽게 생각할 필요는 없습니다. 긴 자기소개가 필요한 것은 아닙니다.
다음 정보만 있어도 기본 역할을 할 수 있습니다.
실명
소속
담당 분야
관련 경력
보유 자격
작성한 글 목록
공식적으로 확인할 수 있는 외부 프로필
중요한 것은 글의 분량이 아니라 저자에게 고유한 페이지 주소가 있다는 점입니다. 본문에 이름만 적혀 있는 것보다 저자 소개 페이지로 연결되어 있을 때 해당 인물과 콘텐츠의 관계를 훨씬 분명하게 보여 줄 수 있습니다.
페이지 유형별로 어떤 스키마가 필요할까?
모든 페이지에 같은 스키마를 넣어서는 안 됩니다. 페이지의 목적에 맞는 유형을 선택해야 합니다.
페이지 유형 | 기본 구성 | 추가로 넣을 수 있는 정보 |
회사 소개 | 조직, 웹사이트, 연락처 | 수상 내역, 창립일, 직원 수 |
저자 소개 | 사람, 소속 조직 연결 | 자격, 저술 목록, 외부 공식 프로필 |
칼럼·블로그 | 글, 저자, 발행 주체, 발행일, 수정일 | 질문과 답변, 페이지 경로 |
질의응답 | 질문과 답변, 발행 주체 | 저자 정보 |
서비스 소개 | 서비스, 제공 조직, 제공 지역 | 가격 범위, 서비스 유형 |
상품 소개 | 상품, 제조사 또는 판매사, 재고, 가격 | 후기, 평점 |
사례·실적 | 글 또는 사례, 관련 조직 | 성과 지표, 사업 기간 |
채용 공고 | 채용 정보, 고용 주체, 근무지 | 고용 형태, 지원 마감일 |
칼럼과 블로그 글에서는 수정일이 자주 빠집니다. 내용을 실제로 보완하거나 주요 정보를 갱신했다면 수정일도 함께 바꿔야 합니다.
다만 오탈자 몇 개만 고친 뒤 수정일을 최신 날짜로 바꾸는 것은 바람직하지 않습니다. 독자가 체감할 수 있을 정도로 내용이 달라졌을 때 수정일을 갱신하는 것이 안전합니다.
후기와 평점은 실제 페이지에 표시된 정보만 넣어야 합니다. 화면에는 없는 평점을 스키마에만 입력하면 정책 위반이 될 수 있습니다. 잘못된 정보가 반복되면 해당 페이지나 사이트의 리치 결과 노출이 제한될 가능성도 있습니다.
사례와 실적 페이지도 중요한 자산입니다. 기업이 직접 수행한 프로젝트와 그 결과는 다른 사이트가 그대로 만들기 어려운 고유 정보입니다.
사례 페이지에 참여 조직, 수행 기간, 주요 결과를 정확하게 표시하면 해당 기업이 어떤 일을 했고 어떤 성과를 냈는지 기계가 이해하기 쉬워집니다. 다만 성과 수치는 실제 본문에 표시되어 있고 확인할 수 있는 값이어야 합니다.
▶ 핵심 정리: 페이지마다 목적에 맞는 스키마가 필요합니다. 수정일은 실제 내용을 갱신했을 때만 바꾸고, 후기·평점·성과 수치는 화면에 표시된 사실만 입력해야 합니다.
채용 공고에도 스키마를 적용할 수 있습니다. 직접적인 목적은 채용 관련 검색 노출이지만, 조직의 근무지와 채용 활동을 알리는 데도 도움이 됩니다. 실제 채용을 진행하고 있다면 적용할 가치가 있습니다.
서비스 소개 페이지에서는 제공 지역을 빠뜨리지 않는 것이 좋습니다. 특히 지역 기반 서비스나 공공기관 용역을 다루는 기업이라면 어느 지역에서 서비스를 제공하는지 분명하게 밝혀야 합니다.
전국을 대상으로 한다면 전국 단위로 제공한다는 사실을 표시할 수 있습니다. 다만 지역 정보를 입력했다고 해서 특정 지역 검색에서 자동으로 노출되는 것은 아닙니다. 실제 서비스 내용과 사업 정보가 함께 뒷받침되어야 합니다.
구현 후 확인해야 할 12가지
조직 정보가 사이트 전체에서 하나의 고유 식별자로 통일되어 있는가?
저자 정보가 페이지마다 반복 입력되지 않고 저자 고유 식별자로 연결되어 있는가?
조직과 저자의 식별자가 실제로 존재하는 소개 페이지를 가리키는가?
조직 정보에 실제 같은 조직임을 확인할 수 있는 외부 공식 주소가 연결되어 있는가?
저자 소개 페이지에 실제 인물의 소속, 경력, 담당 분야와 공식적인 확인 경로가 있는가?
한 페이지에 같은 종류의 스키마가 중복으로 들어가 있지 않은가? 사이트 테마와 플러그인이 각각 스키마를 넣으면 중복될 수 있습니다.
스키마를 넣는 방식이 사이트 전체에서 일관되어 있는가? 여러 방식을 섞어 쓰면 수정과 관리가 어려워집니다.
스키마가 자바스크립트 실행 이후에만 만들어지는 것은 아닌가? 가능하면 서버가 처음 보내는 문서 안에 포함되어 있는 편이 안전합니다.
다국어 사이트의 각 언어 페이지가 같은 조직 식별자를 참조하고 있는가?
페이지 경로를 표시하는 스키마가 실제 메뉴와 이동 경로에 맞게 구성되어 있는가?
스키마 정보가 본문의 회사명, 작성자, 날짜, 가격과 같은 원본 정보를 함께 사용하고 있는가? 별도로 수동 입력한다면 수정 담당자와 점검 주기가 정해져 있는가?
리치 결과 테스트와 일반 스키마 검증 도구에서 각각 확인했는가?
8번은 최근 특히 주의해야 할 항목입니다. 사용자의 브라우저에서는 스키마가 정상적으로 보이지만, 서버가 처음 보내는 문서에는 포함되지 않을 수 있습니다. 이 경우 브라우저 개발자 도구로만 확인하면 문제를 놓치기 쉽습니다. 자바스크립트가 실행된 뒤의 화면뿐 아니라 서버가 처음 보낸 원본 문서도 함께 확인해야 합니다.
리치 결과 테스트는 검색 결과에서 활용할 수 있는 특정 기능의 요건을 중심으로 검사합니다. 일반 스키마 검증 도구는 스키마 표준에 맞게 작성되었는지를 확인합니다. 가능하면 두 가지를 모두 확인하는 것이 좋습니다.
개발 조직이 있다면 검사 과정을 자동화할 수도 있습니다. 사이트를 배포하기 전에 스키마 오류를 자동으로 찾는 단계를 넣어두면 잘못된 정보가 실제 사이트에 올라가는 것을 줄일 수 있습니다.
수동 점검만으로 운영하면 담당자가 바쁘거나 바뀌었을 때 빠지는 항목이 생기기 쉽습니다. 회사명, 주소, 저자, 날짜처럼 자주 바뀌는 값은 콘텐츠 관리 시스템의 원본 정보와 자동으로 연결하는 것이 가장 안전합니다.
우선 다음 네 가지부터 정리하는 것이 좋습니다.
조직을 대표하는 기준 페이지와 식별자
저자별 소개 페이지와 식별자
콘텐츠와 저자의 연결
콘텐츠와 발행 조직의 연결
이 기본 구조를 먼저 만든 뒤 서비스, 상품, 사례, 채용 공고 등으로 범위를 넓혀가면 됩니다.
스키마 설계와 구현 문의
geoseonow.net은 스키마 작성 방법만 담은 사양서를 전달하는 데서 끝내지 않습니다.
조직, 저자, 콘텐츠, 상품과 서비스가 어떻게 연결되어야 하는지 먼저 설계하고, 실제 사이트 적용과 구현 후 검증까지 진행합니다. 운영 과정에서 회사명, 저자, 날짜 등의 정보가 바뀌었을 때 스키마 값도 함께 갱신되도록 콘텐츠 관리 시스템의 연결 방식도 설계합니다.
리퍼블릭미디어는 서울 종로구 새문안로에 있습니다. 소프트웨어사업자 확인과 직접생산확인증명서를 보유하고 있어 공공 부문에서 실제 구현이 포함된 용역을 진행할 때 관련 자격을 확인하기 수월합니다.
GEO와 SEO 진단부터 콘텐츠 전략 수립, 스키마 설계, 실제 적용과 운영까지 한곳에서 진행합니다.
출처 및 참고 자료
Schema.org, 공식 스키마 정의 문서
Google Search Central, 구조화된 데이터 일반 가이드라인
Google Search Central, 구조화된 데이터 관련 스팸 정책
Google Search Central, 리치 결과 테스트 및 검증 도구 안내
W3C, JSON-LD 1.1 명세
리퍼블릭미디어(Republik Media)는 기업이 쌓아 온 경험과 사업 성과를 체계적으로 정리해 오래 활용할 수 있는 지식 자산으로 만드는 기록 설계(Record Design) 콘텐츠 기업입니다.
댓글