리치 결과 테스트로 구조화 데이터 오류 잡는 법

리치 결과 테스트(Rich Results Test)는 구글이 무료로 제공하는 검사 도구로, 페이지의 구조화 데이터(스키마 마크업)를 읽어 어떤 리치 결과 자격을 얻는지, 어디에 오류가 있는지를 즉시 보여준다. URL을 넣거나 코드를 직접 붙여넣기만 하면 되고, 결과는 "유효한 항목", "경고", "오류" 세 갈래로 나뉘어 나온다.

문제는 오류 문구가 대체로 영어로, 그것도 개발자 용어로 나온다는 점이다. Missing field "priceCurrency" 같은 문구만 보고 어디를 고쳐야 할지 막막해하는 경우가 실무에서 흔하다.

이 글은 리치 결과 테스트를 처음 써보는 사업가부터, 마크업을 직접 다루는 실무자까지 바로 따라 할 수 있도록 사용법, 자주 나오는 오류 유형과 해결법, 서치 콘솔 향상 기능 보고서와 연계해 점검하는 방법까지 예시 중심으로 정리한다.

이 글의 핵심만 먼저 추리면 이렇다.

• 리치 결과 테스트는 URL 검사와 코드 스니펫 검사 두 방식을 지원하며, 결과는 유효 항목·경고·오류로 나뉜다.
• 실무에서 가장 자주 나오는 오류는 필수 속성 누락과 잘못된 타입 중첩(문자열 자리에 객체를 넣거나 반대인 경우) 두 가지다.
• 테스트를 통과해도 실제로 리치 결과가 뜨는지는 별개 문제다. 구글이 최종적으로 노출 여부를 판단한다.
• 실제 배포된 페이지의 상태는 서치 콘솔의 향상 기능 보고서에서, 특정 URL 하나의 색인 상태는 URL 검사 도구에서 확인한다.
• 테스트 도구 하나만으로 끝내지 말고, 배포 전 테스트 → 배포 후 향상 기능 보고서 확인까지가 한 세트다.

조금 더 풀어 말하면, 구조화 데이터는 코드가 문법적으로 맞다고 끝나는 일이 아니다. 문법은 맞는데 실제 페이지 내용과 어긋나거나, 필수 속성 하나가 빠져 있어도 구글은 그 항목 전체를 리치 결과 후보에서 제외한다.

그래서 마크업을 심는 것과 마크업이 제대로 작동하는지 확인하는 것은 완전히 다른 작업이다. 발행 전 확인 없이 넘어가면, 몇 달째 오류가 난 채로 방치된 구조화 데이터를 그제서야 발견하는 일이 벌어진다.

특히 카페24·아임웹·식스샵 같은 빌더나 워드프레스 플러그인이 자동으로 마크업을 심어주는 경우, 사이트 운영자는 그 존재조차 모른 채 몇 년이 지나기도 한다. 플러그인이 알아서 해줄 거라 믿고 방치했다가, 정작 필수 속성 하나가 계속 빠진 채 발행되고 있었다는 사실을 뒤늦게 발견하는 사례도 드물지 않다.

리치 결과 테스트는 정확히 무엇을 확인해 주나?

리치 결과 테스트는 페이지 안의 JSON-LD, 마이크로데이터, RDFa 마크업을 읽어, 구글이 지원하는 리치 결과 타입 중 무엇에 해당하는지와 그 마크업이 문법적으로 유효한지를 알려주는 도구다. 주소는 search.google.com/test/rich-results다.

리치 결과란 검색 결과에서 일반적인 파란 링크 한 줄이 아니라, 별점·조리 시간·자주 묻는 질문·상품 가격처럼 추가 정보가 함께 표시되는 확장된 형태를 말한다. 이런 확장 표시는 클릭률을 눈에 띄게 끌어올리는 경우가 많다.

도구가 하는 일은 세 단계로 나뉜다.

1. 인식: 페이지(또는 붙여넣은 코드)에서 구조화 데이터를 찾아낸다.
2. 분류: 찾아낸 데이터가 어떤 리치 결과 타입(Article, FAQPage, Product, LocalBusiness 등)에 해당하는지 판단한다.
3. 검증: 각 타입이 요구하는 필수·권장 속성이 갖춰졌는지 확인하고, 미리보기 화면까지 보여준다.

리치 결과 테스트는 "문법과 자격 조건"을 확인해 주는 도구다. "이 페이지가 실제로 검색 결과에서 어떻게 뜰지"를 100% 보장하는 도구는 아니다.

여러 스키마 타입을 이미 다뤄본 사이트라면 Article·BlogPosting 스키마 가이드나 지역 사업체(LocalBusiness) 스키마 가이드에서 타입별 필수 속성을 먼저 확인하고, 이 도구로 실제 검증하는 순서가 효율적이다. 구조화 데이터 자체가 처음이라면 JSON-LD가 무엇인지부터 짚어보는 것을 권한다.

어떤 리치 결과 타입까지 검사할 수 있나?

구글이 공식 지원 목록에 올린 타입이라면 모두 검사 대상이다. 대표적으로 자주 쓰이는 타입만 꼽아도 다음과 같이 다양하다.

• Article / BlogPosting: 블로그·뉴스 글의 제목·작성일·작성자
• FAQPage: 질문과 답변 목록
• Review / AggregateRating: 개별 후기와 평균 별점
• LocalBusiness: 지역 사업체의 영업시간·주소·전화번호
• Product: 상품명·가격·재고 상태
• BreadcrumbList: 탐색경로(브레드크럼)
• HowTo: 단계별 방법 안내
• VideoObject: 영상의 제목·썸네일·재생 시간

이 중 어느 것을 검사하든 화면에 뜨는 절차와 판정 기준(유효·경고·오류)은 완전히 동일하다. 타입별로 도구가 따로 있는 것이 아니라, 하나의 도구가 모든 타입을 알아서 구분해 보여주는 방식이다.

다만 구글이 공식 지원하지 않는 타입(예: 일부 스키마닷오알지 확장 타입)은 문법상 오류가 없어도 "리치 결과" 후보로는 뜨지 않는다. 이 경우 리치 결과 테스트 화면에 아무 항목도 나타나지 않거나, "감지된 항목 없음"으로 표시될 수 있다.

여기서 한 가지 더 챙길 부분이 있다. 구조화 데이터는 구글 검색의 리치 결과뿐 아니라, AI 검색·챗봇형 답변이 페이지 내용을 파악하는 데도 도움이 된다는 점이다. 질문과 답변, 작성자, 발행일처럼 명확하게 구조화된 정보는 AI가 답을 인용할 때 근거로 삼기에도 유리하다. 다만 이 도구 자체는 구글 리치 결과 자격만 판정하므로, AI 검색 노출까지 보장하는 것은 아니라는 점은 구분해서 이해해야 한다.

URL 검사와 코드 스니펫 검사, 어떤 방식을 써야 하나?

이미 배포된 페이지를 점검할 때는 URL 검사, 아직 배포하지 않은 코드나 수정 중인 마크업을 미리 확인할 때는 코드 스니펫 검사를 쓴다. 두 방식은 검사 대상만 다를 뿐, 결과 화면과 판정 기준은 동일하다.

URL 검사는 실제 주소를 입력하면 구글봇이 그 페이지에 접근해 렌더링한 결과를 그대로 읽는다. 다만 조건이 있다. 페이지가 로그인 없이 누구나 접근 가능해야 하고, robots.txt로 차단돼 있지 않아야 한다. 내부망이나 스테이징(운영 전 임시) 서버처럼 외부에서 접근할 수 없는 주소는 이 방식으로 검사할 수 없다.

코드 스니펫 검사는 HTML 코드 전체를 텍스트 상자에 직접 붙여넣는 방식이다. 아직 서버에 올리지 않은 코드, 혹은 오류를 하나씩 고쳐가며 반복 테스트할 때 특히 유용하다. URL 검사와 달리 실제 페이지 접근이 필요 없으니 배포 전 단계에서 여러 번 돌려보기에 부담이 없다.

실무 흐름으로 정리하면 다음과 같다.

상황	추천 방식	이유
신규 마크업을 처음 작성 중	코드 스니펫 검사	배포 전에 여러 번 반복 테스트 가능
이미 배포된 페이지 점검	URL 검사	실제 렌더링 결과를 그대로 반영
오류 수정 후 재확인	코드 스니펫 검사 → 배포 → URL 검사	배포 전 확정, 배포 후 최종 확인
여러 페이지 유형(상품·글·지역업체)을 한 번에 점검	URL 검사를 유형별로 대표 페이지 하나씩	전체를 일일이 볼 필요 없이 유형당 하나로 충분

코드 스니펫 검사로 오류를 다 잡았다고 끝난 게 아니다. 실제 서버에 올린 뒤 URL 검사로 한 번 더 확인해야 한다. 배포 과정에서 인코딩이 깨지거나, 서버가 다른 버전의 페이지를 캐시해 보여주는 경우가 실무에서 종종 있다.

"유효한 항목", "경고", "오류"는 각각 무엇을 뜻하나?

결과 화면에 뜨는 세 표시는 심각도가 다르다. 유효한 항목은 문제없이 인식된 상태, 경고는 인식은 됐지만 권장 속성이 빠진 상태, 오류는 필수 속성이 빠지거나 문법이 깨져 해당 항목 전체가 인식되지 않은 상태를 말한다.

• 유효한 항목(Valid item): 필수 속성이 모두 있고 문법도 정상이다. 리치 결과 후보 자격을 얻은 상태다.
• 경고(Warning): 필수 속성은 채워졌지만 권장 속성 일부가 빠졌다. 리치 결과 후보 자격은 유지되지만, 표시되는 정보의 풍부함이 줄어들 수 있다.
• 오류(Error): 필수 속성이 아예 없거나, 값의 형식(타입) 자체가 잘못됐다. 이 경우 해당 항목은 리치 결과 후보에서 완전히 제외된다.

여기서 헷갈리기 쉬운 지점이 하나 있다. 경고는 무시해도 당장 큰 문제가 생기지 않지만, 오류는 방치하면 그 마크업 전체가 무용지물이 된다는 점이다. 우선순위를 정할 때는 오류부터 처리하고, 여유가 있을 때 경고를 채우는 순서가 맞다.

경고가 100개 남아 있어도 오류가 0개면 리치 결과 후보 자격은 있다. 반대로 경고가 0개라도 오류가 1개면 그 항목은 후보에서 빠진다. 오류와 경고를 같은 무게로 취급하지 말 것.

자주 나오는 오류는 무엇이고 어떻게 고치나?

실무에서 반복되는 오류는 크게 두 가지 패턴으로 나뉜다. 필수 속성이 아예 빠진 경우와, 속성은 있는데 값의 타입을 잘못 넣은 경우다.

첫째, 필수 속성 누락. 타입마다 반드시 있어야 하는 속성이 정해져 있는데, 이를 빠뜨리는 경우다.

나쁜 예 — 상품(Product) 마크업에서 가격 정보 없이 상품명만 채운 경우:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "무선 이어폰 프로"
}

이 코드는 상품 리치 결과가 요구하는 offers(가격·재고 정보) 속성이 통째로 빠져 있다. 구글은 상품명만으로는 가격 리치 결과를 만들 수 없어 오류로 처리한다.

좋은 예 — 필수 속성을 갖춘 경우:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "무선 이어폰 프로",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "KRW",
    "price": "89000",
    "availability": "https://schema.org/InStock"
  }
}

offers 안에 가격(price)과 화폐 단위(priceCurrency)를 함께 넣은 것이 차이다. 화폐 단위를 빠뜨리는 것도 실무에서 흔한 실수이니 함께 챙겨야 한다.

둘째, 잘못된 타입 중첩. 속성 자체는 있지만, 문자열이 들어가야 할 자리에 객체를 넣거나 반대로 객체가 들어가야 할 자리에 단순 문자열만 넣는 경우다.

나쁜 예 — 작성자(author)를 그냥 문자열로 넣은 경우:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "홈페이지 제작 비용 총정리",
  "author": "홍길동"
}

문법적으로는 오류가 안 뜨는 경우도 있지만, 구글 문서는 author를 Person 또는 Organization 타입의 객체로 넣도록 권장한다. 문자열만 넣으면 이름 외의 정보(프로필 URL 등)를 구글이 함께 파악할 방법이 없다.

좋은 예 — 객체 형태로 명확히 감싼 경우:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "홈페이지 제작 비용 총정리",
  "author": {
    "@type": "Person",
    "name": "홍길동"
  }
}

이 밖에도 실무에서 반복되는 오류 유형을 정리하면 다음과 같다.

오류 유형	흔한 원인	해결 방법
필수 속성 누락	타입별 필수 속성을 확인하지 않고 복사한 예제 코드 사용	구글 공식 문서에서 해당 타입의 필수 속성 목록 재확인
날짜 형식 오류	"2026년 9월 27일"처럼 자연어로 입력	ISO 8601 형식(2026-09-27)으로 통일
이미지 URL 접근 불가	상대경로만 적거나 로그인 뒤에 있는 이미지	절대경로(https://로 시작)이면서 누구나 접근 가능한 URL로 교체
페이지 내용과 마크업 불일치	마크업에는 별점 4.8인데 본문에는 리뷰 내용이 없음	마크업이 설명하는 내용이 실제 페이지에도 보이도록 수정
JSON 문법 오류(쉼표·중괄호)	수동 편집 중 오타	JSON 유효성 검사기로 문법부터 확인 후 재검사

오류 문구에 나오는 속성 이름을 그대로 검색창에 넣고 "schema.org [속성명]"으로 검색하면, 그 속성이 정확히 어떤 타입의 값을 요구하는지 공식 정의를 바로 확인할 수 있다.

FAQ·후기 마크업에서는 어떤 오류가 흔한가?

FAQPage와 Review는 겉보기엔 단순해 보이지만, 실제로는 "내용 일치" 문제로 걸리는 경우가 상품·글보다 더 많다. 문법은 맞는데 페이지 내용과 마크업이 어긋나 오류 취급을 받는 사례가 유독 많다는 뜻이다.

나쁜 예 — FAQPage 마크업에 답변 내용을 빈 문자열로 남긴 경우:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "환불이 가능한가요?",
    "acceptedAnswer": { "@type": "Answer", "text": "" }
  }]
}

질문은 있는데 답변(text)이 비어 있다. 필수 속성 자체는 존재하지만 값이 비어 있어 오류로 처리되는, 실무에서 자주 놓치는 패턴이다.

좋은 예 — 답변 내용을 실제로 채운 경우:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "환불이 가능한가요?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "제품 수령 후 7일 이내, 미사용 상태라면 전액 환불이 가능합니다."
    }
  }]
}

Review·AggregateRating도 비슷한 함정이 있다. 나쁜 예는 별점만 있고 실제 후기 텍스트가 페이지 어디에도 보이지 않는 경우다.

{
  "@context": "https://schema.org",
  "@type": "AggregateRating",
  "ratingValue": "4.9",
  "reviewCount": "128"
}

이 코드만 보면 문법은 멀쩡하다. 하지만 페이지 본문에 실제 후기가 단 한 건도 보이지 않는다면, 구글은 마크업과 실제 콘텐츠가 어긋난다고 판단해 경고를 띄우거나 정책 위반으로 볼 수 있다. bestRating, worstRating처럼 평가 기준을 함께 밝혀주는 것도 신뢰도를 높이는 좋은 습관이다.

좋은 예의 공통점은 "마크업이 설명하는 내용이 실제 화면에도 그대로 보인다"는 점이다. 코드만 그럴듯하게 채우고 화면에는 안 보이게 숨기는 방식은 오래가지 못한다.

테스트를 통과하면 리치 결과가 반드시 뜨나?

아니다. 리치 결과 테스트에서 오류가 0개여도, 그 페이지가 실제 검색 결과에서 리치 결과로 뜰지는 구글이 별도로 최종 판단한다. 마크업 검증은 "자격을 얻었다"는 뜻이지, "노출이 확정됐다"는 뜻이 아니다.

구글이 실제 노출 여부를 정할 때 고려하는 요소는 마크업 문법 외에도 여러 가지다. 페이지의 전반적인 콘텐츠 품질, 검색어와의 관련성, 그리고 무엇보다 Search Essentials(검색 필수 요건) 충족 여부가 함께 작용한다.

• 페이지가 robots.txt로 차단돼 있으면 마크업이 완벽해도 소용없다.
• 페이지에 noindex가 걸려 있으면 색인 자체가 안 되니 리치 결과도 뜨지 않는다.
• 같은 검색어라도 사용자의 기기, 위치, 검색 이력에 따라 리치 결과가 뜨는 경우와 안 뜨는 경우가 나뉠 수 있다.

리치 결과 테스트는 미리보기 화면을 보여주지만, 이 화면이 곧 실제 검색 결과 화면이라는 뜻은 아니다. 구글은 검색 맥락에 따라 다른 레이아웃을 보여줄 수 있다고 명시하고 있다.

그래서 마크업 하나를 완벽하게 고쳤다고 끝내지 말고, 몇 주 뒤 실제로 검색 결과에 반영됐는지까지 지켜보는 습관이 필요하다. 이 단계에서 필요한 도구가 바로 서치 콘솔이다.

이 구분을 처음부터 알아두면 불필요한 오해를 줄일 수 있다. "테스트에서 유효하다고 나왔는데 왜 검색에는 안 뜨나요"라는 질문을 실무에서 자주 받는데, 답은 대부분 "자격을 얻은 것과 실제 노출은 별개"라는 이 원칙으로 설명된다. 특정 리치 결과 타입은 구글이 아예 노출 물량 자체를 제한적으로 운영하는 경우도 있어서, 마크업이 완벽해도 검색어에 따라 노출이 안 될 수 있다.

서치 콘솔 향상 기능 보고서와는 어떻게 연계해서 봐야 하나?

리치 결과 테스트는 지금 이 순간의 마크업 상태를, 서치 콘솔의 향상 기능 보고서는 구글이 실제로 크롤링하고 색인한 여러 페이지의 누적 상태를 보여준다. 둘은 서로 대체하는 도구가 아니라, 순서대로 함께 쓰는 도구다.

서치 콘솔 왼쪽 메뉴의 "향상 기능" 항목에는 사이트에서 발견된 구조화 데이터 타입별로(글, 상품 스니펫, FAQ 등) 별도 보고서가 생긴다. 각 보고서는 유효한 페이지 수, 경고가 있는 페이지 수, 오류가 있는 페이지 수를 그래프와 목록으로 보여준다.

리치 결과 테스트와 향상 기능 보고서를 함께 쓰는 흐름은 이렇다.

1. 배포 전: 코드 스니펫 검사로 오류를 미리 잡는다.
2. 배포 직후: URL 검사로 실제 배포된 페이지에서도 문제없는지 재확인한다.
3. 배포 후 며칠–몇 주: 서치 콘솔 향상 기능 보고서에서 해당 타입의 오류 페이지 수가 늘었는지 주기적으로 확인한다.
4. 오류 페이지가 발견되면: 그 목록에 있는 URL을 다시 리치 결과 테스트에 넣어 원인을 구체적으로 확인하고 수정한다.

향상 기능 보고서에 뜨는 데이터는 실시간이 아니다. 구글이 그 페이지를 다시 크롤링해야 반영되므로, 마크업을 고친 직후에는 보고서 수치가 며칠 동안 그대로일 수 있다. 급하게 재검사하려면 리치 결과 테스트나 URL 검사를 직접 쓰는 것이 빠르다.

사이트 전체의 검색 성과를 정기적으로 점검하는 습관이 아직 없다면, 서치 콘솔 실적 보고서 완벽 가이드도 함께 참고하면 향상 기능 보고서를 볼 때 놓치기 쉬운 부분까지 챙길 수 있다.

URL 검사 도구와는 또 어떻게 다른가?

URL 검사 도구는 구글이 마지막으로 크롤링한 버전을 기준으로 리치 결과 자격을 보여주고, 리치 결과 테스트는 지금 이 순간 접속해서 가져온 최신 버전을 기준으로 보여준다. 둘 다 서치 콘솔과 무관한 독립 페이지처럼 보이지만, 실제로는 검사 시점이 다르다는 차이가 핵심이다.

예를 들어 방금 마크업을 수정하고 배포했다면, 구글이 아직 그 페이지를 다시 크롤링하지 않았을 수 있다. 이 경우 URL 검사 도구에는 여전히 수정 전 상태가 나온다. 반면 리치 결과 테스트로 같은 주소를 검사하면 방금 수정한 최신 상태가 바로 반영된다.

• 당장 수정 결과를 확인하고 싶다 → 리치 결과 테스트
• 구글이 실제로 어떤 버전을 인식하고 있는지 확인하고 싶다 → URL 검사 도구(필요하면 색인 생성 요청도 함께)

두 도구를 혼동해 "리치 결과 테스트에서는 유효한데 왜 실제로는 안 뜨지"라고 오해하는 경우가 많다. 답은 대개 구글이 아직 최신 버전을 다시 크롤링하지 않았기 때문이다. 이럴 때는 URL 검사 도구에서 색인 생성을 요청해 재크롤링 속도를 높일 수 있다.

잘 뜨던 리치 결과가 갑자기 사라졌다면 무엇을 확인해야 하나?

몇 달째 잘 떠 있던 리치 결과가 어느 날 갑자기 사라지는 경우, 원인은 대개 마크업이 아니라 페이지 자체의 변화에 있다. 코드를 건드리지 않았다면 마크업을 의심하기보다 먼저 페이지 주변 상황을 점검하는 것이 순서다.

확인할 순서는 다음과 같다.

1. 리치 결과 테스트로 현재 상태 재확인. 최근 사이트 개편이나 템플릿 교체 과정에서 마크업이 실수로 삭제된 경우가 실무에서 의외로 잦다.
2. 페이지 내용이 바뀌지 않았는지 확인. 예를 들어 후기 섹션 위치를 옮기면서 실제 리뷰 텍스트가 사라졌는데 마크업만 남아 있다면, 앞서 다룬 "내용 불일치"로 걸릴 수 있다.
3. robots.txt와 noindex 여부 재확인. 사이트 이전이나 보안 설정 변경 과정에서 의도치 않게 크롤링이 막힌 경우가 있다.
4. 서치 콘솔 향상 기능 보고서에서 오류 추세 확인. 특정 시점부터 오류 페이지 수가 급증했다면, 그 시점에 있었던 사이트 변경 이력과 대조해본다.
5. 경쟁 상황 변화도 배제하지 않는다. 구글은 검색 결과 화면의 리치 결과 노출을 지속적으로 실험한다. 마크업과 페이지 모두 문제가 없는데도 노출이 줄었다면, 구글 쪽의 화면 구성 변화일 가능성도 열어두어야 한다.

원인을 못 찾겠다고 마크업을 통째로 지웠다가 다시 심는 것은 최후의 수단으로 남겨두는 것이 좋다. 대부분의 경우 위 다섯 단계 중 하나에서 원인이 잡힌다.

FAQ 마크업이나 브레드크럼도 같은 방식으로 확인하나?

그렇다. 타입이 무엇이든 리치 결과 테스트에 넣는 절차는 동일하다. FAQPage, BreadcrumbList, HowTo, Review 등 구글이 지원하는 타입이라면 모두 같은 화면에서 유효 항목·경고·오류를 확인할 수 있다.

다만 타입마다 요구하는 필수 속성이 다르므로, 타입별 문서를 먼저 확인해두는 것이 오류를 줄이는 지름길이다. 예를 들어 브레드크럼 스키마 가이드에서 다룬 것처럼 BreadcrumbList는 position과 name, item(마지막 단계는 생략 가능) 순서가 정확히 맞아야 한다. 순서가 하나라도 어긋나면 오류로 처리된다.

여러 타입을 한 페이지에 동시에 넣는 경우(예: Article과 FAQPage를 같은 페이지에 함께), 리치 결과 테스트는 각 타입을 따로따로 인식해 결과를 보여준다. 한 타입에서 오류가 나도 다른 타입의 유효성에는 영향을 주지 않는다.

빌더가 자동으로 만든 마크업도 직접 검사해야 하나?

그래야 한다. 카페24·아임웹·식스샵 같은 쇼핑몰 빌더나 워드프레스 SEO 플러그인은 상품·글 페이지에 구조화 데이터를 자동으로 심어주는 기능을 제공하는 경우가 많다. 하지만 자동 생성이라는 이유로 항상 오류가 없다고 보장되지는 않는다.

자동 생성 마크업에서 특히 자주 발견되는 문제는 다음과 같다.

• 상품 옵션(색상·사이즈)마다 가격이 다른데, 대표 가격 하나만 반영되는 경우
• 재고 상태가 실시간으로 바뀌는데 마크업은 "재고 있음"으로 고정되는 경우
• 템플릿이 기본으로 채워둔 예시 텍스트("샘플 상품명" 등)가 그대로 남아 있는 경우
• 여러 상품을 한 페이지에서 보여주는 목록형 페이지에 개별 상품 마크업이 중복으로 삽입되는 경우

빌더를 쓰더라도 대표 페이지 몇 개를 골라 리치 결과 테스트로 직접 확인해보는 절차는 건너뛰지 않는 것이 안전하다. 특히 상품을 대량으로 등록하는 쇼핑몰이라면, 상품 유형별로 하나씩만 검사해도 전체 패턴의 오류를 미리 걸러낼 수 있다.

페이지가 수백 개인 쇼핑몰은 하나씩 다 검사해야 하나?

그럴 필요는 없다. 리치 결과 테스트는 한 번에 URL 하나만 검사하는 도구라, 상품이 수백–수천 개인 쇼핑몰을 전부 손으로 검사하는 것은 현실적이지 않다. 대신 템플릿(레이아웃) 단위로 대표 페이지를 뽑아 검사하는 방식이 효율적이다.

같은 템플릿을 쓰는 상품 페이지는 마크업 구조도 대부분 동일하다. 그래서 다음과 같은 순서로 접근하면 전체를 검사한 것과 비슷한 효과를 얻을 수 있다.

1. 상품 카테고리별로 대표 페이지 1개씩 선정한다(옵션이 있는 상품, 옵션이 없는 상품, 품절 상품 등 유형별로).
2. 각 대표 페이지를 리치 결과 테스트로 검사해 템플릿 단위의 오류를 찾는다.
3. 템플릿에서 오류가 발견되면, 그 템플릿을 쓰는 모든 페이지에 동일한 오류가 있다고 가정하고 템플릿 자체를 수정한다.
4. 수정 후 서치 콘솔 향상 기능 보고서에서 해당 타입의 전체 오류 페이지 수가 줄었는지 대략적인 규모로 확인한다.

개별 페이지마다 일일이 들어가 검사할 필요 없이, 템플릿 몇 개만 확인하면 전체 사이트의 오류 패턴 대부분을 잡아낼 수 있다는 뜻이다. 상품이 새로 계속 추가되는 쇼핑몰이라면, 신상품을 대량으로 올린 직후 한 번씩 대표 페이지를 재검사하는 주기를 정해두는 것도 도움이 된다.

발행 전 체크리스트로 정리하면?

지금까지 다룬 내용을 실제로 쓸 수 있는 순서로 정리하면 다음과 같다. 검사는 한 번 하고 끝내는 일이 아니라 콘텐츠를 새로 발행하거나 템플릿을 바꿀 때마다 반복하는 루틴으로 자리 잡아야 오류를 조기에 잡을 수 있다.

• 1단계: 마크업 작성 중에는 코드 스니펫 검사로 반복 테스트한다.
• 2단계: 오류(빨간 표시)를 먼저 모두 없앤다. 경고는 시간이 있을 때 채운다.
• 3단계: 실제 서버에 배포한 뒤 URL 검사로 재확인한다.
• 4단계: 배포한 페이지가 색인되도록 서치 콘솔에서 색인 생성 요청을 넣는다.
• 5단계: 며칠 뒤 서치 콘솔 향상 기능 보고서에서 해당 타입의 오류 페이지 수를 확인한다.
• 6단계: 오류 페이지가 새로 발견되면 그 URL을 다시 리치 결과 테스트에 넣어 원인을 확인하고 고친다.

자주 묻는 질문

리치 결과 테스트는 무료인가

그렇다. 구글이 제공하는 무료 도구이며 별도 로그인 없이 URL 하나만으로도 즉시 사용할 수 있다. 다만 검사 이력을 계속 남기고 싶다면 구글 계정으로 로그인해두는 것이 편리하다.

오류가 있는데도 지금 당장 리치 결과가 뜨고 있다면 그냥 둬도 되나

당장 문제가 없어 보여도 손보는 것이 안전하다. 구글이 다음 재크롤링 시점에 그 오류를 다시 판단하면서 리치 결과가 갑자기 사라질 수 있다. 오류는 발견 즉시 고치는 습관이 리치 결과를 안정적으로 유지하는 방법이다.

코드 스니펫 검사는 몇 번까지 반복해도 되나

제한은 없다. 배포 전 단계에서는 오히려 여러 번 반복해서 오류를 하나씩 줄여가는 방식이 권장된다. 다만 매번 마크업 전체를 다시 붙여넣어야 하므로, 수정한 코드를 따로 저장해두면서 진행하는 것이 편하다.

리치 결과 테스트 결과가 실제 검색 결과 화면과 다르게 보이는 이유는 무엇인가

구글은 검색 맥락(기기, 위치, 검색어)에 따라 실제 노출 레이아웃을 다르게 구성할 수 있다고 명시하고 있다. 테스트 도구의 미리보기는 참고용 예시이며, 실제 화면과 완전히 동일하다는 보장은 없다.

한 페이지에 마크업을 여러 개 겹쳐 넣으면 리치 결과 확률이 올라가나

아니다. 필요한 타입만 정확하게, 페이지 내용과 일치하게 넣는 것이 중요하다. 관련 없는 타입을 이것저것 끼워 넣는다고 노출 확률이 높아지지 않으며, 오히려 페이지 내용과 어긋나는 마크업이 늘어나 관리가 더 어려워질 수 있다.

빌더나 플러그인이 자동으로 넣은 마크업의 오류는 직접 못 고치는 것 아닌가

플랫폼에 따라 다르다. 코드를 직접 수정할 수 있는 자체 도메인 홈페이지라면 오류가 발견된 부분을 직접 고치면 된다. 반면 수정 권한이 제한된 빌더라면, 어떤 값(가격·재고 등)이 잘못 반영되고 있는지 구체적으로 파악한 뒤 빌더 지원팀이나 제작을 맡은 쪽에 정확히 전달하는 것이 빠르다. 오류 문구를 그대로 캡처해 전달하면 처리 속도가 빨라진다.

오류를 다 고쳤는데도 향상 기능 보고서 수치가 그대로다

향상 기능 보고서는 구글이 해당 페이지를 다시 크롤링해야 갱신된다. 수정 직후에는 며칠 동안 이전 수치가 남아 있을 수 있으므로, URL 검사 도구에서 색인 생성을 요청해 재크롤링을 앞당기는 것이 도움이 된다.

---

구조화 데이터는 한 번 제대로 세팅해두면 이후 발행하는 모든 콘텐츠에 그대로 재사용할 수 있는 자산입니다. 다만 마크업을 심어두는 것과 실제로 오류 없이 작동하는지 확인하는 것은 별개의 작업이므로, 발행 전후로 리치 결과 테스트와 서치 콘솔 점검을 함께 챙기는 습관을 권해 드립니다.

이루웹은 SEO 최적화 홈페이지 제작과 검색엔진최적화 컨설팅을 진행하면서 구조화 데이터 설계부터 오류 점검까지 함께 살펴보고 있습니다. 우리 사이트의 마크업이 제대로 작동하는지 확인이 필요하시다면 이루웹의 전체 서비스를 살펴보시고, 상담 문의를 통해 현재 상태부터 편하게 점검받아 보시기를 권해 드립니다.