크롤러가 사이트 계층에 대해 아는 것 대부분은 추론입니다. URL 세그먼트, 페이지 간 링크 관계, 메뉴 위치에서 유추합니다. 브레드크럼은 사이트가 자신의 계층을 직접 선언하는 유일한 지점입니다. 이 페이지는 여기에 있고, 그 위는 여기이며, 그 위는 여기다. 그리고 이 선언은 사용자, 검색엔진, 그리고 사이트로부터 IA 문서를 만드는 모든 도구가 함께 읽습니다.
투입 대비 회수로 보면 IA 영역에서 이만한 것이 없습니다.
세 명의 독자, 하나의 컴포넌트
사용자는 방향 감각을 얻습니다. 검색을 통해 깊은 상품 페이지로 바로 진입한 사람은 자신이 어디에 있는지 전혀 모릅니다. 브레드크럼은 이를 한 줄로 알려주고 상위로 올라갈 경로를 즉시 제공합니다. 검색 유입 사용자는 GNB보다 브레드크럼을 먼저 씁니다.
검색엔진은 명시적인 계층 신호를 얻습니다. BreadcrumbList 마크업이 있으면 검색 결과의 URL 자리에 브레드크럼 경로가 노출되는 경우가 많습니다. example.com › 원피스 › 실크가 example.com/collections/dresses/silk-2024-ss보다 읽기 좋습니다.
크롤러와 분석 도구는 정답지를 얻습니다. DeepAnalyzer가 IA 시트를 만들 때, 브레드크럼이 있는 페이지는 사이트가 직접 쓴 라벨로 높은 신뢰도로 분류됩니다. 없는 페이지는 URL 형태와 내비게이션 위치로 추론해야 합니다. 동작은 하지만, 읽는 것이 아니라 재구성하는 것입니다.
좋은 브레드크럼의 조건
홈 › 솔루션 › 열관리 시스템 › 히트펌프 모듈
실무에서 중요한 규칙들입니다.
- 루트부터 전체 경로를 보여줍니다. 현재 섹션부터 시작하는 잘린 브레드크럼은 효용이 크게 떨어집니다.
- 상위는 모두 링크, 현재 페이지는 링크가 아닙니다. 마지막 항목은 일반 텍스트입니다.
- 라벨은 도착 페이지와 일치해야 합니다. 브레드크럼에는 '솔루션', 해당 페이지 H1에는 '기술 소개'라고 쓰여 있다면 하나의 노드에 이름이 둘인 셈이고, 사용자도 분석 도구도 혼란스러워집니다.
- 이동 이력이 아니라 계층을 반영합니다. 브레드크럼은 뒤로가기가 아닙니다. 사용자가 지나온 경로를 보여주면 같은 페이지가 방문마다 다른 브레드크럼을 갖게 되어 신호가 무너집니다.
- H1 위, 좌측 정렬, GNB 아래에 배치합니다. 사람들이 실제로 보는 자리입니다.
- 모바일에서도 유지합니다. 공간이 부족하면 가운데를 말줄임하되 제거하지는 마세요. 방향 감각이 가장 필요한 환경이 모바일입니다.
마크업
먼저 시맨틱 HTML입니다.
<nav aria-label="Breadcrumb">
<ol>
<li><a href="/">홈</a></li>
<li><a href="/solutions">솔루션</a></li>
<li><a href="/solutions/thermal">열관리 시스템</a></li>
<li><span aria-current="page">히트펌프 모듈</span></li>
</ol>
</nav>
그다음 구조화 데이터입니다.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "홈", "item": "https://example.com/" },
{ "@type": "ListItem", "position": 2, "name": "솔루션", "item": "https://example.com/solutions" },
{ "@type": "ListItem", "position": 3, "name": "열관리 시스템", "item": "https://example.com/solutions/thermal" },
{ "@type": "ListItem", "position": 4, "name": "히트펌프 모듈", "item": "https://example.com/solutions/thermal/heat-pump-modules" }
]
}
</script>
두 가지만 지키면 됩니다. position은 1부터 시작해 빠짐없이 증가해야 하고, 화면에 보이는 브레드크럼과 마크업이 일치해야 합니다. 페이지에 표시되지 않는 계층을 구조화 데이터로 선언하는 것은 불일치이며, 리치 결과가 차단되는 대표적인 사유입니다.
마지막 항목의 item은 넣어도 되고 생략해도 되지만, 현재 URL을 포함하는 쪽이 더 안전하고 일관적입니다. 전체 스키마 그래프와의 관계는 구조화 데이터 가이드에서 다룹니다.
까다로운 케이스
부모가 여러 개인 페이지. 하나의 상품이 세 카테고리에 속하는 전형적인 문제입니다. 선택지는 두 가지입니다.
- 상품마다 대표 카테고리를 하나 지정하고 항상 그 경로를 노출합니다. 가장 단순하고 일관적이며, 기본값으로 권장합니다.
- 유입 카테고리에 맞춰 경로를 바꿔 보여줍니다. UX는 낫지만 브레드크럼이 가변적이 되어 구조 신호로서의 힘이 약해집니다. 이 방식을 택하더라도 구조화 데이터는 대표 경로를 유지하세요.
필터 결과. 원피스 › 블랙 › 10만원 이하는 계층 노드가 아니라 필터 상태입니다. 브레드크럼은 카테고리 수준에서 멈추고, 적용된 필터는 별도 UI로 표시하세요.
얕은 사이트. 2단계 구조에서는 효용이 거의 없습니다. 3단계 이상이거나 검색 유입이 깊은 콘텐츠로 들어올 때 도입하세요.
로케일 세그먼트. /ko/solutions/thermal은 홈 › 솔루션 › 열관리 시스템이어야 하며 'KO' 노드를 만들면 안 됩니다. 로케일은 계층의 한 단계가 아니라 사이트의 차원입니다.
브레드크럼을 IA 점검 도구로 쓰기
브레드크럼은 선언된 계층이므로, 사이트 전체를 크롤링해 수집하면 사이트 스스로 이해하는 구조를 그대로 얻게 됩니다. 두 가지로 활용할 수 있습니다.
첫째, 정합성 점검입니다. 전 페이지를 크롤링해 브레드크럼 경로, URL 경로, 내비게이션 위치 세 가지를 비교합니다. 이 셋이 어긋나는 지점이 IA 결함입니다. 한 곳에 분류되고, 다른 곳에 주소가 있고, 또 다른 곳에서 링크되는 페이지 말입니다. 사용자는 이걸 "한 번 찾은 페이지를 다시 못 찾겠다"로 경험합니다.
둘째, IA 문서의 출발점입니다. IA 시트의 Depth 1 / Depth 2 / Depth 3 열은 브레드크럼 레벨과 그대로 대응하고, Screen ID는 그 뎁스 그룹에서 파생됩니다(Screen ID 네이밍 체계 참고). 브레드크럼이 완비된 사이트는 IA 시트 초안을 자동으로 뽑을 수 있고, 없는 사이트는 행마다 해석이 필요합니다.
도입 전에 확인할 것
브레드크럼은 계층을 드러냅니다. 계층이 엉망이면 브레드크럼은 그것을 고쳐주는 게 아니라 보이게 만듭니다. 홈 › 제품 › 제품2 › 새 폴더 같은 경로는 구조 문제의 정직한 반영입니다. 구조를 먼저 정리하고 나서 선언하세요. 정보 아키텍처 분석이 이 작업의 앞 단계입니다.
자주 묻는 질문
브레드크럼이 순위에 영향을 주나요?
직접적인 순위 요소는 아닙니다. 다만 내부 링크와 크롤 경로를 개선하고, 검색 결과에서 URL을 읽기 쉬운 경로로 대체하며, 깊은 페이지 유입의 이탈을 줄입니다. 효과는 간접적이지만 실재합니다.
현재 페이지도 브레드크럼에 포함해야 하나요?
네, 링크 없는 마지막 항목으로 포함합니다. 사용자에게 현재 위치를 확인시켜 줍니다. 구조화 데이터에도 포함하세요.
URL과 브레드크럼이 일치하지 않으면요?
덮어둘 문제가 아니라 들여다볼 신호입니다. URL 구조와 브레드크럼은 보통 같은 계층을 설명해야 합니다. 불가피한 경우(예: 카테고리 브레드크럼 아래의 플랫한 상품 URL)에는 브레드크럼이 개념적 구조를 반영하도록 하세요. 사용자와 검색 결과가 보는 것이 그쪽입니다.
사이트맵 대신 브레드크럼을 써도 되나요?
안 됩니다. 목적이 다릅니다. 브레드크럼은 한 페이지의 계층을 선언하고, 사이트맵은 발견을 위해 URL을 열거합니다. 둘 다 필요합니다.
몇 단계까지가 적당한가요?
4~5단계를 넘어가면 대개 계층이 너무 깊다는 뜻입니다. 경로가 깊으면 홈에서의 클릭 수가 늘고 크롤 우선순위가 떨어집니다(크롤 예산 최적화).