검색 결과를 보면 어떤 페이지는 제목 아래 별점, 가격, 자주 묻는 질문 같은 정보가 함께 붙어 눈에 확 띕니다. 반면 내 페이지는 제목과 설명 두 줄만 나옵니다. 이 차이를 만드는 게 구조화된 데이터, 흔히 스키마 마크업이라 부르는 것입니다. 그런데 실무에서는 "마크업을 넣었는데 왜 안 뜨느냐"는 질문이 가장 많습니다. 마크업은 리치 결과의 자격 요건일 뿐 표시 스위치가 아니기 때문입니다. 이 글은 구조화된 데이터의 원리와 자주 쓰는 유형, 가장 흔한 실수, 점검 도구, 그리고 정확히 넣어도 안 뜰 수 있는 현실을 정리합니다.
리치 결과가 뭐고 왜 중요한가
리치 결과(리치 스니펫)는 일반 검색 결과에 별점·가격·재고·FAQ·이미지 같은 추가 정보가 함께 표시되는 형태입니다. 같은 순위라도 이런 요소가 붙으면 눈에 더 띄고, 클릭으로 이어질 가능성이 높아집니다. 순위를 올리지 않고도 검색 결과에서 존재감을 키우는 방법인 셈입니다.
다만 처음부터 분명히 해둘 게 있습니다. 리치 결과를 띄울지는 구글이 정합니다. 마크업은 "이 페이지에 이런 정보가 있다"고 알려주는 자격 신청이고, 실제 표시 여부는 구글의 판단에 달렸습니다. 이 전제를 놓치면 "넣었는데 왜 안 되지"에서 계속 헤매게 됩니다.
구조화된 데이터의 원리
사람은 페이지를 보고 "아, 이건 별점 4.5짜리 제품 리뷰구나"를 바로 압니다. 하지만 검색엔진에는 그게 그냥 텍스트 덩어리입니다. 구조화된 데이터는 페이지 내용에 "이건 상품명, 이건 가격, 이건 평점"이라는 꼬리표를 붙여, 기계가 의미를 정확히 읽게 하는 표준입니다. 어휘 표준으로는 Schema.org를 씁니다.
넣는 방식은 여러 가지지만, 구글은 JSON-LD 형식을 권장합니다. 페이지 화면에는 보이지 않는 스크립트 형태로 머리말이나 본문에 넣는 방식이라, 디자인을 건드리지 않고 정보만 따로 전달할 수 있어 관리가 편합니다. 이 사이트의 글에도 BlogPosting 구조화 데이터가 이 방식으로 들어가 있습니다.
자주 쓰는 유형
업종·페이지 성격에 맞는 유형을 씁니다. 실무에서 자주 쓰는 것들입니다.
- 리뷰·평점 — 상품·서비스의 별점. 단, 뒤에 설명할 제약이 있습니다.
- FAQ — 자주 묻는 질문과 답. 검색 결과에 질문이 펼쳐지기도 합니다.
- 제품(Product) — 가격·재고·평점 등 쇼핑 관련 정보.
- 이동경로(Breadcrumb) — 검색 결과에 사이트 구조 경로 표시.
- 지역 비즈니스·문의처 — 매장 정보, 영업시간 등.
고를 때 기준은 하나입니다. 그 페이지에 실제로 존재하는 정보만 마크업합니다. 유형이 많다고 다 넣는 게 아니라, 페이지가 실제로 담은 것에 맞춰 고르는 게 원칙입니다.
가장 흔한 실수 ① 페이지에 없는 내용을 마크업
가장 많이 저지르는 실수입니다. 화면에는 없는 별점이나 FAQ를 구조화된 데이터에만 몰래 넣는 경우입니다. 구글 정책은 마크업이 페이지에서 사용자가 실제로 볼 수 있는 내용과 일치할 것을 요구합니다.
보이지 않는 정보를 마크업하면 리치 결과가 안 뜨는 정도로 끝나지 않습니다. 구조화된 데이터 관련 수동 조치를 받을 수 있습니다. FAQ를 리치 결과로 띄우고 싶다면, 페이지에 실제 FAQ 섹션이 사용자에게 보이게 있어야 합니다. 마크업은 있는 것을 설명하는 도구지, 없는 것을 지어내는 도구가 아닙니다.
가장 흔한 실수 ② 별점을 스스로 매기기
자기 사이트에서 자기 상품·서비스에 스스로 별점을 매겨 마크업하는 경우도 자주 봅니다. 이런 자체 평점은 구글이 리뷰 리치 결과로 잘 띄우지 않습니다. 이해 상충이 명확하기 때문입니다.
덧붙여 구글은 최근 몇 년간 리뷰 리치 결과를 적용하는 항목 자체를 좁혀 왔습니다. 예전엔 온갖 페이지에 별점이 붙었지만, 지금은 특정 유형에만 제한적으로 나타납니다. 별점이 안 뜬다고 마크업이 틀린 게 아니라, 애초에 그 유형이 대상이 아닐 수 있습니다. 이 점을 알면 불필요한 삽질을 줄입니다.
점검 도구
넣은 마크업이 제대로 됐는지 확인하는 무료 도구가 있습니다.
- 리치 결과 테스트 — 주소나 코드를 넣으면 어떤 리치 결과 자격이 있는지, 오류·경고가 무엇인지 보여줍니다.
- 스키마 마크업 검사 도구 — 구조 자체의 문법 오류를 잡는 데 씁니다.
- 서치콘솔 개선사항 리포트 — 사이트 전체에서 유형별로 유효·오류·경고를 모아 보여줍니다. 실제 색인 기준의 상태라 가장 현실적입니다.
순서는 이렇습니다. 개별 페이지는 리치 결과 테스트로 확인하고, 사이트 전반은 서치콘솔 개선사항에서 오류부터 잡습니다. 오류는 표시를 막고, 경고는 표시는 되지만 권장 항목이 빠진 상태를 뜻하는 경우가 많습니다.
정확해도 안 뜰 수 있다 — 현실적 기대
마지막으로 기대치를 맞춥니다. 마크업이 문법상 완벽하고 정책도 지켰는데 리치 결과가 안 뜨는 일은 흔합니다. 앞서 말한 대로 표시는 구글 재량이고, 사이트 신뢰도·검색어 맥락·유형 대상 여부 등이 함께 작용합니다.
그래서 구조화된 데이터를 "별점 붙이는 기능"으로만 보면 실망하기 쉽습니다. 리치 결과는 못 떠도, 정확한 구조화 데이터는 검색엔진이 페이지 내용을 더 정확히 이해하도록 돕습니다. 표시는 보너스로 두고, 페이지 내용과 일치하는 정직한 마크업을 기본으로 삼는 게 오래 가는 접근입니다.