리치 스니펫 표시 기준 · 무엇이 검색 결과에 뜨나

리치 스니펫은 검색 결과에 제목, URL, 설명만 나오는 기본 형태 대신 별점, 이미지, 가격, 이동 경로, 질문 목록 같은 추가 정보가 함께 표시되는 결과를 말한다. 이 결과를 얻으려면 페이지에 구조화 데이터, 즉 페이지의 내용이 무엇인지를 검색엔진이 기계적으로 읽을 수 있는 형식으로 적어 둔 코드가 필요하다. 다만 순서를 정확히 알아야 한다. 구조화 데이터는 리치 스니펫의 필요조건이지 충분조건이 아니다. 마크업이 문법적으로 완벽하고 검증 도구가 오류 0을 띄워도 실제 표시 여부는 구글이 결정하며, 구글은 어떤 페이지에도 리치 결과 표시를 보장하지 않는다. 그래서 이 작업의 목표는 "리치 스니펫을 켠다"가 아니라 "리치 스니펫 후보 자격을 갖춘다"로 잡아야 한다.

구조화 데이터, 리치 결과, 리치 스니펫은 같은 말이 아니다

세 단어가 섞여 쓰이면서 대화가 어긋나는 경우가 많다. 정리하면 이렇다.

구조화 데이터는 내가 페이지에 넣는 입력이다. Schema.org 어휘를 써서 "이 페이지는 기사다", "이 항목은 가격이 얼마인 제품이다"를 선언한다.

리치 결과는 구글이 검색 결과 페이지에 그리는 출력이다. 별점이 붙거나, 이미지가 붙거나, 이동 경로가 붙는다.

리치 스니펫은 그 출력 중에서 기존 파란 링크 결과에 정보가 덧붙은 형태를 부르는 일상 용어다.

입력과 출력 사이에 구글의 판단이 한 겹 들어간다는 점이 핵심이다. 이 한 겹 때문에 "코드를 넣었는데 왜 안 나오냐"는 질문이 끝없이 반복된다.

마크업을 넣으면 무엇이 보장되나

마크업을 넣어서 확실해지는 것은 하나뿐이다. 페이지의 내용을 검색엔진이 기계적으로 읽을 수 있는 형태로 명시해 뒀다는 것. 그 이상은 보장되지 않는다.

마지막 줄을 특히 오해하기 쉽다. 결과에 정보가 더 붙으면 클릭이 늘 것 같지만, 붙은 정보만 보고 사용자가 만족해서 클릭하지 않는 경우도 있다. 그래서 "리치 스니펫을 받았다"는 성과가 아니라 관찰 대상이다.

작은 사이트가 실제로 쓸 만한 유형은 많지 않다

구글이 지원하는 리치 결과 유형은 갤러리 문서에 길게 나열돼 있지만, 작은 팀이 운영하는 회사 사이트에서 값을 하는 유형은 몇 개로 좁혀진다. 나머지는 레시피 사이트, 채용 플랫폼, 이벤트 티켓 사업처럼 그 유형이 사업 자체인 곳의 것이다. 아래 다섯 개는 그 기준으로 고른 것이고, 구글이 정한 우선순위가 아니라 구현 비용과 유지 비용을 놓고 판단한 결과다.

순서에 의미가 있다. BreadcrumbList가 첫 번째인 이유는 구현 비용이 가장 낮고, 사이트 구조를 명확히 하는 부수 효과가 있기 때문이다. Product가 뒤에 있는 이유는 반대다. 가격과 재고가 페이지 표시와 어긋나면 문제가 되는 유형이라 유지 비용이 붙는다.

여기서 예외를 하나 말해 둔다. 사업이 지역 기반이라면 LocalBusiness가 목록의 맨 위로 올라온다. 지역 검색에서는 사업체 정보의 일관성이 다른 어떤 마크업보다 먼저 작동한다.

FAQPage는 성격이 조금 다르다. 질문과 답변이 검색 결과에 그대로 펼쳐지는 표현은 표시 조건이 좁은 쪽이라, 표시를 기대하고 넣을 유형이 아니라 페이지 구조를 명확히 하는 용도로 보는 편이 안전하다. 지금 어떤 사이트에 어떤 조건으로 표시되는지는 갤러리 문서에서 직접 확인해야 한다.

유형별로 빠지면 문제가 되는 항목

정확한 필수 속성 목록은 유형마다 다르고 시간이 지나면 바뀐다. 배포 전에 해당 유형의 공식 문서를 직접 열어 확인하는 것이 원칙이다. 그래도 현장에서 빠뜨려서 문제가 되는 항목은 대체로 정해져 있다.

이 표는 체크리스트지 명세서가 아니다. 명세는 공식 문서에 있다.

페이지에 보이지 않는 내용은 마크업하면 안 된다

이것이 구조화 데이터에서 가장 자주 어겨지고, 가장 크게 손해 보는 규칙이다.

마크업한 내용은 사용자가 페이지에서 실제로 볼 수 있어야 한다. 페이지에 없는 별점을 코드에만 넣거나, 화면에는 접혀서 안 보이는 내용을 질문 목록으로 마크업하거나, 실제 가격과 다른 가격을 선언하는 것은 최적화가 아니라 정책 위반으로 다뤄질 수 있는 영역이다.

위반의 대가가 그 페이지의 리치 결과 하나로 끝난다는 보장은 없다. 구글이 사이트 단위로 조치를 취하면 정상적으로 만들어 둔 다른 페이지의 자격까지 함께 사라질 수 있다. 한 페이지에서 아낀 시간을 사이트 전체로 갚는 구조라서, 걸릴 확률을 따지기 전에 넣지 않는 편이 계산이 맞는다.

판단 기준은 단순하다. 마크업을 지우고 페이지를 새로고침했을 때, 그 정보가 화면에 그대로 남아 있어야 한다. 남아 있지 않다면 그 마크업은 넣으면 안 된다.

JSON-LD를 쓰는 이유

구조화 데이터를 적는 형식은 여러 가지가 있지만, 지금 새로 만드는 페이지라면 JSON-LD 하나만 고려하면 된다.

JSON-LD는 HTML 태그 사이에 속성을 흩뿌리지 않고, 스크립트 블록 하나에 데이터를 모아서 넣는다. 이 차이가 실무에서 크게 작동한다.

첫째, 디자인을 바꿔도 구조화 데이터가 깨지지 않는다. HTML 태그에 속성을 박아 넣는 방식은 퍼블리싱을 한 번 고치면 같이 무너진다.

둘째, 템플릿에서 생성하기 쉽다. 블로그 글 목록이나 상품 목록처럼 같은 형태가 반복되는 페이지에서, 데이터만 갈아 끼우면 된다.

셋째, 검토가 쉽다. 문제가 생겼을 때 봐야 할 곳이 한 군데다.

예외는 있다. 이미 마이크로데이터로 넓게 구현된 오래된 사이트라면, 전면 교체보다 그대로 두는 편이 나을 수 있다. 두 형식을 같은 페이지에서 섞어 같은 대상을 중복 선언하는 것이 가장 나쁘다.

검증 도구는 서로 다른 질문에 답한다

세 가지를 구분해서 써야 혼란이 줄어든다.

리치 결과 테스트는 "구글이 이 페이지에서 리치 결과 자격을 인식하는가"에 답한다. 배포 직후 확인용이다.

스키마 마크업 검증 도구는 "이 코드가 Schema.org 문법에 맞는가"에 답한다. 구글이 리치 결과로 쓰지 않는 유형까지 검사한다.

서치 콘솔의 리치 결과 보고서는 "실제 색인된 페이지들에서 무슨 일이 벌어지고 있는가"에 답한다. 셋 중 유일하게 사이트 전체를 시간축으로 보여준다.

앞의 두 도구는 통과했는데 세 번째에서 오류가 잡히는 경우가 흔하다. 테스트 도구는 지금 이 URL 하나를 즉석에서 가져와 보고, 보고서는 구글이 실제로 크롤링해 저장한 버전을 본다. 둘이 다르면 대개 렌더링이나 배포 시점의 문제다.

리치 스니펫이 안 나올 때 무엇을 먼저 보나

"코드는 넣었는데 안 나온다"는 상황은 원인이 몇 가지로 좁혀진다. 위에서부터 순서대로 확인하면 대부분 걸린다.

세 번째 줄에서 막히는 경우가 생각보다 많다. 색인 여부는 URL 검사에서 lastCrawlTime을 봐야 하는데, 구글이 URL을 알기만 하고 가져간 적이 없으면 마크업을 아무리 고쳐도 평가받을 기회 자체가 없다. 그때는 마크업이 아니라 블로그 방문자 줄었을 때 원인 찾는 순서 쪽을 봐야 한다.

마지막 줄이 가장 중요하다. 구글은 지원 유형과 표시 조건을 계속 조정한다. 어제까지 나오던 표현이 오늘 사라지는 일은 사이트의 잘못 없이도 일어난다. 그래서 리치 스니펫을 전제로 한 사업 계획은 세우지 않는 편이 안전하다.

스니펫 자체를 통제하는 방법은 따로 있다

구조화 데이터로는 리치 결과의 표시를 요구할 수 없지만, 일반 스니펫이 어떻게 보이는지는 어느 정도 통제할 수 있다. 이쪽은 별도의 메타 태그 영역이다.

여기서도 원칙은 같다. 제공은 내가 하고, 선택은 구글이 한다. meta description을 잘 쓰는 것은 여전히 가치 있는 일이지만, 그대로 나온다는 보장은 없다.

처음 넣을 때는 어떤 순서로 하나

작은 팀이라면 다음 순서로 하면 낭비가 없다.

1. 사이트에 이미 들어 있는 구조화 데이터를 먼저 확인한다. 워드프레스나 쇼핑몰 솔루션은 플러그인이 이미 넣어 둔 경우가 많다. 모르고 하나 더 넣으면 중복 선언이 된다.

2. BreadcrumbList부터 넣는다. 구현이 가장 단순하고 실패할 여지가 적다.

3. 사이트 성격에 맞는 주 유형을 하나만 고른다. 블로그면 Article, 매장이면 LocalBusiness, 판매면 Product.

4. 대표 페이지 한 장에만 먼저 적용하고 검증 도구를 돌린다. 전체 배포는 그다음이다.

5. 서치 콘솔의 리치 결과 보고서는 시간을 두고 본다. 구글이 다시 크롤링하고 색인해야 잡히는 데이터라, 배포 다음 날 비어 있다고 실패로 판단하지 않는다.

한 번에 다섯 유형을 다 넣는 것이 가장 흔한 실수다. 오류가 나도 어디서 났는지 알 수 없게 된다.

구조화 데이터를 쓰지 않아야 할 때

넣지 않는 것이 정답인 경우도 분명히 있다.

페이지 내용이 자주 바뀌는데 마크업을 손으로 관리해야 한다면 넣지 않는 편이 낫다. 값이 어긋난 마크업은 없느니만 못하다.

리뷰가 아직 없는데 별점을 붙이고 싶어서 마크업을 검토 중이라면 멈춰야 한다. 이것이 앞서 말한 위반의 전형이다.

색인 자체가 안 되고 있는 사이트라면 순서가 틀렸다. 크롤링과 색인 문제를 먼저 해결해야 한다. 구조화 데이터는 이미 검색에 나오는 페이지의 표현을 다듬는 일이지, 안 나오는 페이지를 나오게 하는 일이 아니다.

경쟁사가 별점을 달고 있어서 따라가야 한다는 판단이라면, 그 별점이 어디서 왔는지부터 확인해야 한다. 실제 리뷰가 쌓여서 나온 별점이라면, 해야 할 일은 마크업이 아니라 리뷰 수집이다.

정리하면 무엇을 해야 하나

구조화 데이터는 넣을 가치가 있다. 다만 이유가 리치 스니펫 하나여서는 안 된다.

검색엔진과 AI 검색 도구가 페이지 내용을 정확히 파악하게 만드는 것 자체가 목적이고, 리치 스니펫은 그 결과로 따라올 수도 있는 부수 효과로 보는 편이 맞다. 이렇게 기대치를 잡아야 표시가 안 될 때 엉뚱한 곳을 고치지 않는다.

그리고 사이트마다 상황이 다르다. 어떤 유형이 우리 사이트에 값을 하는지는 지금 어떤 검색어로 어떤 페이지가 노출되고 있는지를 봐야 답할 수 있다. 그 데이터 없이 유형을 고르는 것은 추측이다.

자주 묻는 질문

구조화 데이터를 넣으면 검색 순위가 올라갑니까?

구조화 데이터는 순위를 올리려고 넣는 장치가 아닙니다. 검색엔진이 페이지 내용을 더 정확히 이해하게 만드는 장치이고, 리치 결과 표시 자격의 조건입니다. 구글은 리치 결과 표시조차 보장하지 않는다고 밝히고 있고, 순위 상승을 약속한 적은 없습니다. 순위가 오르는 것처럼 보이는 경우가 있다면, 대개 리치 결과로 클릭률이 달라지면서 생긴 간접 효과이거나 다른 변화가 겹친 결과입니다.

리치 스니펫이 나오기까지 얼마나 걸립니까?

정해진 기간은 없습니다. 구글이 해당 페이지를 다시 크롤링하고 색인해야 반영되기 때문에, 사이트의 크롤링 빈도에 따라 달라집니다. 서치 콘솔 리치 결과 보고서에 유형이 잡히기 시작하는지를 지켜보시고, 그사이 해당 URL이 다시 크롤링된 정황이 있는데도 보고서가 계속 비어 있다면 색인 문제부터 확인하시기를 권합니다. 기다리는 기간 자체를 구글이 공개한 적은 없습니다.

질문과 답변 마크업을 아무 페이지에나 붙여도 됩니까?

붙이면 안 됩니다. 페이지에 실제로 질문과 답변이 표시되고 있어야 하며, 사용자가 화면에서 그 내용을 읽을 수 있어야 합니다. 또한 어떤 유형이 현재 리치 결과로 지원되는지와 그 조건은 구글이 계속 조정하므로, 구조화 데이터 갤러리에서 해당 유형의 현재 문서를 직접 확인한 뒤 넣으시는 것이 안전합니다.

플러그인이 자동으로 넣어주는 구조화 데이터를 믿어도 됩니까?

기본적으로는 쓸 만하지만 그대로 두기 전에 한 번은 검증해야 합니다. 흔한 문제는 두 가지입니다. 테마와 SEO 플러그인이 같은 유형을 각각 넣어 중복 선언이 되는 경우, 그리고 페이지에 없는 정보가 템플릿 기본값으로 들어가는 경우입니다. 대표 페이지 한 장을 검증 도구로 확인하면 둘 다 바로 드러납니다.

잘 나오던 리치 스니펫이 갑자기 사라졌으면 무엇을 해야 합니까?

먼저 사이트 쪽 변화를 확인하십시오. 페이지 내용 변경, 템플릿 배포, 플러그인 업데이트로 마크업이 깨졌는지 검증 도구로 봅니다. 마크업에 문제가 없다면 구글의 표시 정책이나 판단이 바뀐 경우일 수 있고, 이때는 복구를 강제할 방법이 없습니다. 해당 유형의 공식 문서에서 조건이 달라졌는지 확인한 뒤, 스니펫 노출을 전제로 잡아 둔 계획이 있다면 그 계획을 조정하시는 편이 현실적입니다.

참고 자료

• 구조화 데이터 갤러리 — 구글이 지원하는 리치 결과 유형과 각 유형의 조건을 확인하는 공식 목록
• 검색 결과 스니펫 관리 — 스니펫이 만들어지는 방식과 nosnippet, max-snippet 등 표시 통제 수단에 대한 공식 문서