구조화 데이터

탐색경로 표시와 BreadcrumbList 구조화 데이터, 어떻게 넣나요

탐색경로(브레드크럼)가 무엇인지 설명하고, BreadcrumbList 구조화 데이터의 필수 속성과 경로를 짜는 기준, 넣은 뒤 확인하는 순서를 작은 사업장 예시로 정리했어요.

2026년 10월 29일 작성 · 읽는 시간 약 8분 · 다올라 SEO 가이드

원본Google 검색 센터 「구조화된 탐색경로(BreadcrumbList) 데이터」 · 원문 최종 업데이트 2026-09-14 기준

핵심 정리

탐색경로 마크업은 Google이 검색어 맥락에 맞춰 페이지의 위치를 분류하는 데 쓰는 정보이고, 데스크톱 검색에서 제공돼요.
경로 이름은 주소 모양보다 손님이 실제로 찾아오는 길을 기준으로 정하는 것이 Google의 권장이에요.
BreadcrumbList에는 ListItem이 두 개 이상 필요해요. 각 칸에 name·position·item을 채우되, 마지막 칸의 주소는 생략할 수 있어요.
한 페이지로 오는 길이 여러 개라면 탐색경로를 여러 개 지정해도 돼요.
배포한 뒤에는 리치 결과 테스트, URL 검사 도구, Search Console 보고서로 오류를 차례대로 확인하면 돼요.

탐색경로(브레드크럼)는 '수업 › 그룹 수업 › 리포머 기초반'처럼, 지금 보는 페이지가 사이트 안에서 어디쯤 있는지 알려 주는 길 안내예요. 이 경로를 BreadcrumbList라는 구조화 데이터로 표시해 두면 Google이 검색 결과에서 페이지 정보를 분류할 때 활용할 수 있어요.

탐색경로는 손님과 Google에게 어떤 도움이 되나요

탐색경로는 페이지의 위치를 한 줄로 보여 줘요. 그래서 손님은 사이트 구조를 금방 이해하고, 한 단계씩 위로 올라가며 둘러볼 수 있어요. 꽃집 홈페이지에서 '꽃다발 › 생일 꽃다발 › 핑크 장미 꽃다발' 페이지를 보던 손님이라면, '생일 꽃다발'을 눌러 다른 상품으로 바로 넘어갈 수 있어요.

Google의 구조화된 탐색경로(BreadcrumbList) 데이터 안내를 보면, Google 검색은 페이지 본문에 있는 탐색경로 마크업으로 검색 결과 속 페이지 정보를 분류해요. 같은 페이지라도 손님이 어떤 검색어로 찾았는지에 따라 그 맥락에 맞게 분류해 보여 줄 수 있다는 뜻이에요. 이 기능은 데스크톱에서 제공되고, Google 검색이 서비스되는 모든 지역과 언어에서 쓸 수 있어요.

구조화 데이터가 처음이라면 구조화 데이터란? 작은 홈페이지는 무엇부터 넣으면 될까를 먼저 읽어 보세요. 기본 개념과 형식 고르는 법을 거기에 정리해 두었어요.

경로는 주소(URL)가 아니라 손님이 다니는 길로 짜요

탐색경로는 URL 구조를 그대로 옮기기보다, 손님이 그 페이지까지 오는 일반적인 길을 보여 주는 편이 좋다는 게 Google의 권장이에요. 주소가 /p/1024처럼 숫자로 되어 있어도, 경로는 '수업 › 그룹 수업 › 리포머 기초반'처럼 사람이 알아듣는 말로 지으면 돼요. 주소 자체를 짓는 법은 검색에 좋은 페이지 주소 짓는 법에서 따로 다뤘어요.

경로를 짤 때는 아래 기준을 함께 기억해 두세요.

맨 위 단계(도메인이나 '홈')는 탐색경로 항목에 꼭 넣지 않아도 돼요.
지금 보고 있는 페이지도 꼭 항목으로 넣을 필요는 없어요. 넣는다면 Google 예시처럼 마지막 칸에 이름만 적고 주소는 빼도 돼요.
한 페이지로 오는 길이 여러 개라면 탐색경로를 여러 개 지정할 수 있어요.

학원을 예로 들어 볼게요. '중등 과정 › 수학 › 내신 대비반'과 '시험 대비 › 내신 대비반', 두 길로 같은 페이지에 올 수 있다면 두 경로를 모두 표시해도 돼요. JSON-LD(스크립트 태그 안에 따로 적는 구조화 데이터 형식)에서는 BreadcrumbList 두 개를 대괄호 [ ]로 묶어 배열로 넣으면 돼요.

BreadcrumbList에 꼭 들어가야 하는 항목

탐색경로를 지정하려면 BreadcrumbList 안에 ListItem을 두 개 이상 넣고, 각 칸에 필수 속성을 채워야 해요. BreadcrumbList는 경로 전체를 담는 상자이고, ListItem은 그 안의 한 단계예요.

속성	들어가는 곳	적는 내용
itemListElement	BreadcrumbList	순서대로 늘어놓은 ListItem 목록
item	ListItem	그 단계 페이지의 주소. 마지막 칸에서는 빼도 되고, 빼면 Google이 현재 페이지 주소를 씀
name	ListItem	손님에게 보일 단계 이름
position	ListItem	경로 안에서의 순서. 1이 시작

공방 홈페이지의 원데이 클래스 페이지라면 아래처럼 쓸 수 있어요. 이 내용을 페이지 HTML의 script 태그(type 값은 application/ld+json) 안에 넣으면 돼요.

{
  "@type": "BreadcrumbList", "@context": "https://schema.org",
  "itemListElement": [
    { "position": 1, "@type": "ListItem", "name": "클래스", "item": "https://example.com/classes" },
    { "position": 2, "@type": "ListItem", "name": "가죽 공예", "item": "https://example.com/classes/leather" },
    { "position": 3, "@type": "ListItem", "name": "카드지갑 원데이 클래스" }
  ]
}

예전에 쓰던 data-vocabulary.org 방식 마크업은 이제 Google 리치 결과(검색 결과에 제목·설명 말고 덧붙는 추가 정보 표시)에 쓸 수 없어요. 오래된 테마가 아직 이 방식을 쓰고 있다면 data-vocabulary 지원 종료 안내를 확인하고 schema.org 방식으로 바꾸세요.

가이드라인과 화면 표시도 함께 챙겨요

탐색경로가 검색에 표시될 수 있으려면 마크업이 검색 Essentials와 구조화된 데이터 일반 가이드라인을 따라야 해요. 규칙에 어긋나는 방식으로 마크업을 꾸미면, 그 사이트는 직접 조치(Google이 문제를 확인하고 사이트에 내리는 제재) 대상이 될 수 있어요.

Google 문서에는 JSON-LD 말고도 RDFa·마이크로데이터 예시가 있어요. 둘 다 화면에 보이는 HTML 태그에 속성을 덧붙여 의미를 표시하는 방식이에요. 화면 디자인의 일부로 보이는 일반 HTML 탐색경로 블록 예시도 함께 실려 있어요. 손님이 화면에서도 같은 경로를 볼 수 있게 만들어 두면, 마크업과 실제 화면을 나란히 놓고 점검하기가 한결 편해요.

넣은 뒤에는 이렇게 확인해요

마크업을 넣은 뒤에는 테스트, 일부 배포, 모니터링 순서로 확인하면 돼요.

리치 결과 테스트로 코드를 검사하고 심각한 오류부터 고쳐요. 심각하지 않은 경고는 고치지 않아도 리치 결과에 쓰일 수 있지만, 고치면 데이터 품질이 좋아질 수 있어요.
몇 페이지만 먼저 올리고 URL 검사 도구로 Google이 페이지를 어떻게 보는지 확인해요. robots.txt, noindex 태그, 로그인 요구 때문에 막혀 있지 않은지도 함께 봐요. 막힘 문제는 noindex로 막는 방법에서 자세히 다뤘어요.
페이지가 제대로 보이면 Google에 URL 재크롤링을 요청할 수 있어요. 다시 크롤링하고 반영하는 데 며칠이 걸릴 수 있어요.
앞으로의 변경 사항을 알리려면 사이트맵을 제출해 두는 게 좋아요. 방법은 사이트맵 만들고 제출하는 방법에 있어요.
색인된 뒤에는 Search Console의 리치 결과 상태 보고서에서 유효 항목은 늘고 잘못된 항목은 늘지 않는지 봐요. 오류를 고쳤다면 실제 URL을 다시 검사한 다음, 보고서에서 유효성 검사를 요청해요.

테스트를 통과했어도 Google이 표시를 보장하지는 않아요. 스팸성 마크업처럼 문법 문제가 아닌 경우는 리치 결과 테스트로 잡히지 않을 수 있으니, 가이드라인도 다시 한번 읽어 보세요.

정리

손님이 많이 보는 페이지 몇 개를 골라, 실제로 그 페이지까지 오는 길을 종이에 적어 보세요. 길이 둘이면 둘 다 적어요.
적은 경로를 JSON-LD로 옮기고 itemListElement, name, position, item이 빠짐없이 들어갔는지 표와 대조해요.
리치 결과 테스트와 URL 검사 도구로 확인한 뒤 일부 페이지에 먼저 배포해요.
템플릿을 바꾸거나 사이트를 고친 뒤에는 Search Console 보고서에서 잘못된 항목이 늘지 않았는지 살펴요.

자주 묻는 질문

홈페이지 제작 도구(CMS)를 쓰는데, 코드를 직접 넣어야 하나요?

꼭 그렇지는 않아요. Google은 CMS를 쓴다면 그 CMS에 통합된 플러그인을 쓰는 편이 더 쉬울 수 있다고 안내해요. 다른 사람이 사이트를 관리해 주고 있다면, Search Console에서 받은 문제 메시지를 그대로 관리자에게 전달해 도움을 받으세요.

자바스크립트로 화면을 그리는 사이트에도 탐색경로 구조화 데이터를 넣을 수 있나요?

넣을 수 있어요. Google 검색 센터에 자바스크립트로 구조화 데이터를 생성하는 방법을 따로 안내한 문서가 있어요. 넣은 뒤에는 URL 검사 도구로 Google이 실제로 그 데이터를 읽는지 꼭 확인하세요.

item에는 꼭 주소 문자열만 적어야 하나요?

아니요. 주소를 바로 적어도 되고, ID로 페이지를 가리키는 방식도 쓸 수 있어요. JSON-LD는 @id를 쓰고, 마이크로데이터는 href나 itemid, RDFa는 about·href·resource 가운데 하나를 써요. 이렇게 name이 들어 있는 대상으로 item을 지정했다면 name을 따로 적지 않아도 돼요.

사이트를 개편한 뒤 Search Console에서 유효한 탐색경로 항목이 줄었어요. 왜 그런가요?

잘못된 항목은 늘지 않았는데 유효한 항목만 줄었다면, 새 페이지에 구조화 데이터가 더 이상 들어가지 않는 것일 수 있어요. 반대로 잘못된 항목이 늘었다면 새 템플릿이 제대로 작동하지 않는 경우일 수 있어요. 어느 쪽이든 URL 검사 도구로 원인을 확인해 보세요.

구조화 데이터 때문에 직접 조치를 받으면 페이지가 검색에서 사라지나요?

그렇지는 않아요. 직접 조치를 받으면 그 페이지의 구조화 데이터는 무시되지만, 페이지 자체는 계속 검색 결과에 나올 수 있어요. 문제를 해결하려면 Search Console의 직접 조치 보고서를 확인하세요.

출처

구조화된 탐색경로(BreadcrumbList) 데이터 — Google 검색 센터 · 최종 업데이트 2026-09-14

이 글은 위 Google 검색 센터 문서(CC BY 4.0)를 바탕으로 다올라가 한국어로 풀어 쓴 가이드입니다. 원문은 바뀔 수 있으니 중요한 결정 전에는 원문을 함께 확인해 주세요.