브레드크럼(탐색경로) 완벽 가이드 — UX부터 스키마까지

브레드크럼(탐색경로)은 "홈 › 카테고리 › 상세" 처럼 지금 보고 있는 페이지가 사이트 안 어디에 있는지 보여주는 작은 링크 줄이다. 화면 상단에 놓인 몇 개의 링크지만, 사용자에게는 길을 잃지 않게 해주는 지도이고, 검색엔진에게는 페이지 사이의 관계를 알려주는 가장 명확한 신호다.

많은 홈페이지가 브레드크럼을 디자인 요소로만 취급한다. 링크 몇 개를 회색 글씨로 얹어두면 끝이라고 생각한다. 하지만 브레드크럼은 UI(화면에 보이는 경로)와 BreadcrumbList 구조화 데이터(검색엔진에게 전달하는 경로) 두 가지를 함께 갖춰야 제 역할을 한다. 둘 중 하나만 있으면 절반짜리다.

이 글은 브레드크럼을 왜 만들어야 하는지부터, 어떤 종류를 골라야 하는지, 화면에는 어떻게 디자인해야 하는지, 그리고 BreadcrumbList JSON-LD 스키마는 정확히 어떻게 작성해야 하는지까지 순서대로 정리한다. 사이트 구조 전체를 다루는 글이 아니라 브레드크럼이라는 한 요소에 집중했으므로, 끝까지 읽으면 오늘 바로 적용할 수 있다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• 브레드크럼은 위치형·경로형·속성형 세 종류가 있고, 대부분의 사이트에는 위치형이 맞다
• BreadcrumbList 스키마는 position·name·item 세 값만 있으면 되는 간단한 구조다
• 검색결과에서는 브레드크럼 경로가 URL 대신 회색 글씨로 노출돼 클릭률에 영향을 준다
• 마지막(현재) 페이지는 item(링크 URL)을 생략하는 편이 안전하다
• 같은 페이지에 진입 경로가 여러 개면 BreadcrumbList도 여러 개 넣을 수 있다
• 작성 후에는 반드시 리치 결과 테스트로 오류를 확인해야 한다

브레드크럼은 왜 만들어야 할까

브레드크럼은 사용자의 이탈을 막고, 검색엔진에게는 사이트 구조를 요약해서 알려주는 두 가지 역할을 동시에 한다. 상세페이지 하나에 검색을 통해 처음 들어온 사용자는 이 사이트에 어떤 카테고리가 있는지, 지금 보는 페이지가 전체에서 어떤 위치인지 전혀 모른다. 브레드크럼은 그 맥락을 한 줄로 채워준다.

UX 관점에서 브레드크럼의 가장 큰 효과는 뒤로 가기 버튼을 대체한다는 점이다. 브라우저의 뒤로 가기는 사용자가 거쳐온 페이지를 그대로 되짚어 가지만, 브레드크럼은 사이트의 논리적 상위 단계로 곧장 이동시켜 준다. 검색을 통해 상세페이지로 들어온 사용자가 "이 카테고리의 다른 상품도 보고 싶다"고 생각했을 때, 브레드크럼의 상위 카테고리 링크 하나로 그 목적을 바로 이룰 수 있다.

브레드크럼이 없는 페이지는 검색을 통해 들어온 방문자에게 "막다른 골목"과 같다. 관심이 있어도 다른 페이지로 이어질 방법이 화면 어디에도 없으면 그대로 이탈한다.

SEO 관점에서는 두 가지 효과가 있다. 첫째, 브레드크럼 링크 자체가 내부 링크이므로 상위 카테고리 페이지로 링크 가치가 흘러가고, 검색엔진이 사이트 구조를 파악하는 데 도움을 준다. 둘째, BreadcrumbList 스키마를 함께 넣으면 검색결과 화면에 경로가 노출돼 클릭률(CTR)에 긍정적인 영향을 줄 수 있다. 이 두 효과는 뒤에서 각각 더 자세히 다룬다.

브레드크럼이 특히 효과적인 사이트는 계층 구조가 3단계 이상인 곳이다. 쇼핑몰의 "여성의류 › 원피스 › 린넨 원피스", 블로그의 "블로그 › 검색엔진최적화 › 개별 글"처럼 카테고리가 여러 겹으로 쌓인 사이트일수록 브레드크럼의 체감 효과가 크다. 반대로 페이지가 10개 안팎인 단순한 홈페이지라면 상단 메뉴만으로 충분해서 브레드크럼의 효과가 크지 않을 수 있다.

체류시간에도 간접적인 영향이 있다. 브레드크럼을 눌러 상위 카테고리로 이동한 방문자는 그 자리에서 이탈하지 않고 사이트 안에서 다른 페이지를 한 번 더 둘러볼 확률이 높아진다. 상세페이지 하나만 보고 나가는 방문과, 카테고리를 오가며 두세 페이지를 더 보는 방문은 전환율에서도 차이가 난다. 브레드크럼은 그 다음 클릭을 만들어주는 가장 저렴한 장치인 셈이다.

브레드크럼 종류는 몇 가지이고 무엇을 골라야 할까

대부분의 홈페이지에는 위치형(location-based) 브레드크럼이 맞다. 브레드크럼은 크게 위치형, 경로형(path-based), 속성형(attribute-based) 세 종류로 나뉘는데, 성격이 서로 다르므로 사이트 구조에 맞게 골라야 한다.

종류	보여주는 것	적합한 사이트
위치형	고정된 카테고리 계층(홈 › 카테고리 › 상세)	대부분의 홈페이지·쇼핑몰·블로그
경로형	사용자가 실제로 클릭해 온 이동 경로	검색 결과 목록을 거쳐 들어온 경우가 많은 사이트
속성형	선택한 필터·옵션 조합(색상·가격대 등)	필터가 많은 쇼핑몰 카테고리 페이지

위치형은 사용자가 어떻게 들어왔든 상관없이 그 페이지의 고정된 자리를 보여준다. "린넨 원피스" 상세페이지는 검색으로 들어오든, 홈에서 클릭해서 들어오든 항상 "홈 › 여성의류 › 원피스 › 린넨 원피스"로 동일하게 표시된다. 일관성이 가장 높아 대부분의 상황에 무난하다.

경로형은 사용자가 실제로 지나온 페이지를 순서대로 보여준다. 검색 결과 목록에서 상품 A, B, C를 차례로 열어봤다면 "검색결과 › 상품A › 상품B"처럼 방문 이력 자체가 경로가 된다. 구현이 상대적으로 복잡하고, 같은 페이지라도 사용자마다 표시되는 경로가 달라 검색엔진에 전달할 고정된 구조가 없다는 단점이 있다.

속성형은 필터·정렬 옵션을 경로처럼 보여준다. "원피스 › 색상: 블랙 › 사이즈: L"처럼 선택한 조건을 나열하는 방식으로, 필터가 많은 쇼핑몰 카테고리 페이지에서 자주 쓰인다. 다만 속성형은 BreadcrumbList 스키마와 궁합이 좋지 않다. 필터 조합이 무한히 늘어나는 페이지에 매번 새 BreadcrumbList를 넣으면 관리가 번거롭고, 애초에 그런 필터 페이지는 검색 색인에서 빼는 경우가 많기 때문이다.

실무에서는 세 종류를 섞어 쓰기도 한다. 쇼핑몰이라면 상품 상세페이지에는 위치형(고정된 카테고리 경로)을 쓰고, 필터를 적용한 목록 페이지에서는 화면 UI로만 속성형을 보여주되 그 페이지는 스키마 대상에서 제외하는 방식이 흔하다. 이렇게 하면 사용자에게는 지금 선택한 필터가 보이면서도, 검색엔진에는 깔끔한 위치형 경로만 전달된다.

브레드크럼 UI는 어떻게 디자인해야 할까

위치는 페이지 상단, 헤더 바로 아래가 기본이다. 홈에서 시작해 현재 페이지까지 순서대로, 각 단계는 구분 기호로 나누고, 마지막 현재 페이지만 링크 없이 강조한다. 이 네 가지만 지켜도 브레드크럼 UI의 절반은 완성된다.

나쁜 예와 좋은 예를 비교하면 차이가 분명하다.

나쁜 예: "Home / cat / sub2 / item48213" 처럼 내부 URL 슬러그를 그대로 노출하거나, 구분 기호 없이 링크를 붙여써서 어디서 끊어지는지 알 수 없게 만드는 경우다.

좋은 예: "홈 › 여성의류 › 원피스 › 린넨 A라인 원피스" 처럼 사람이 읽는 실제 이름을 쓰고, "›" 나 "/" 같은 구분 기호로 각 단계를 명확히 나눈 경우다.

세부 규칙을 항목별로 정리하면 다음과 같다.

• 현재 페이지는 링크로 만들지 않는다. 이미 있는 페이지를 다시 클릭하게 하는 것은 불필요한 동작이다. 대신 텍스트 색을 진하게 하거나 굵게 표시해 "여기가 지금 위치"라는 것만 알려준다
• 구분 기호는 화살표(›)나 슬래시(/)처럼 방향성이 느껴지는 기호를 쓴다. 점(·)이나 쉼표는 계층 관계가 잘 드러나지 않는다
• 글자 크기는 본문보다 작게, 색은 본문보다 연하게 해서 브레드크럼이 헤드라인보다 시선을 뺏지 않도록 한다
• 터치 영역은 손가락으로 누르기 충분한 크기로 확보한다. 모바일에서 브레드크럼 링크 간격이 너무 좁으면 오터치가 잦아진다
• 홈 아이콘을 첫 단계에 쓰는 것은 선택이다. 텍스트 "홈"과 아이콘을 함께 쓰면 더 명확하다

모바일 화면에서는 별도의 규칙이 필요하다. 계층이 4단계, 5단계로 깊어지면 좁은 화면에서 브레드크럼 한 줄이 다 들어가지 않는다. 이럴 때 흔히 쓰는 방법은 중간 단계를 "…"으로 줄이고 처음(홈)과 마지막 두 단계만 보여주는 방식이다. 또는 가로 스크롤을 허용해 전체 경로를 유지하되 화면 밖으로 자연스럽게 흐르게 하는 방법도 있다. 모바일에서 가장 나쁜 선택은 브레드크럼을 통째로 숨기는 것이다 — 좁은 화면일수록 사용자는 지금 위치를 잃기 쉽다.

색상은 사이트 전체 디자인 톤에 맞추되, 브랜드 포인트 컬러를 브레드크럼 전체에 쓰지 않는 편이 좋다. 링크 색과 현재 페이지 색만 최소한으로 구분하고, 나머지는 무채색 계열로 차분하게 처리해야 브레드크럼이 화면에서 과하게 두드러지지 않는다.

브레드크럼과 웹 접근성은 어떻게 연결될까

브레드크럼은 마크업 하나로 시각 디자인과 스크린리더 접근성을 동시에 챙길 수 있는 요소다. <nav> 태그에 aria-label="브레드크럼" 을 붙이고, 그 안에 순서가 있는 목록(<ol>)으로 항목을 나열하는 것이 표준적인 방식이다.

<nav aria-label="브레드크럼">
  <ol>
    <li><a href="/">홈</a></li>
    <li><a href="/women">여성의류</a></li>
    <li><a href="/women/dress">원피스</a></li>
    <li aria-current="page">린넨 A라인 원피스</li>
  </ol>
</nav>

이렇게 마크업하면 스크린리더 사용자는 "브레드크럼, 목록 4개 항목" 처럼 이 구역이 무엇인지 먼저 안내받고, 각 항목을 순서대로 읽어나갈 수 있다. 현재 페이지 항목에는 aria-current="page"를 붙여 링크가 아니라 지금 위치라는 것을 명확히 구분해야 한다. 나쁜 예는 <div>와 <span>만으로 브레드크럼을 구성해 스크린리더가 이 영역을 그냥 일반 텍스트로 읽어버리는 경우다. 좋은 예는 nav·ol·aria-current를 갖춰 브레드크럼이라는 의미 자체를 코드로 전달하는 경우다.

접근성을 챙긴 마크업은 부수적인 이점도 있다. 검색엔진 역시 nav처럼 의미가 분명한 시맨틱 태그를 div보다 더 신뢰도 있게 해석하는 경향이 있어서, 접근성 개선이 곧 검색엔진의 페이지 이해도 개선으로도 이어진다.

브레드크럼과 URL·사이트 구조는 어떻게 연결될까

브레드크럼은 홈페이지 URL 구조를 그대로 화면에 옮겨놓은 결과물이어야 한다. 브레드크럼만 따로 설계할 수는 없다. URL 경로("/여성의류/원피스/린넨원피스")와 브레드크럼("홈 › 여성의류 › 원피스 › 린넨원피스")이 서로 어긋나면 사용자도, 검색엔진도 혼란스럽다.

이 말은 순서가 중요하다는 뜻이다. 사이트 구조(카테고리 depth, URL 규칙)를 먼저 정하고, 브레드크럼은 그 구조를 화면에 표시하는 역할만 맡아야 한다. 반대로 브레드크럼부터 임의로 만들고 나중에 URL 구조를 짜 맞추면 둘 사이에 불일치가 생기기 쉽다.

카테고리 depth(단계 수)는 보통 3단계에서 4단계 안이 적당하다. "홈 › 대분류 › 중분류 › 상세"처럼 짧으면 브레드크럼도 한눈에 들어오고, 각 카테고리 페이지도 검색엔진의 크롤링 우선순위에서 밀리지 않는다. 5단계를 넘어가는 깊은 구조는 브레드크럼 자체가 길어져 UI로도 부담스럽고, 최하위 페이지까지 크롤링이 도달하는 데도 불리하다.

내부 링크 전체 전략에서 브레드크럼이 차지하는 역할과, 사이트 전체 구조를 처음부터 설계하는 방법은 검색과 AI에 잘 잡히는 홈페이지 구조 설계법에서 더 자세히 다뤘다. 링크가 페이지 사이를 어떻게 연결해야 하는지 원리부터 알고 싶다면 내부 링크 전략 가이드도 함께 참고하면 좋다.

브레드크럼과 사이트맵, 내비게이션 메뉴는 어떻게 다를까

셋 다 사이트 구조를 알려주는 요소지만 역할이 다르다. 상단 메뉴는 "어디로 갈 수 있는가", 브레드크럼은 "지금 어디에 있는가", 사이트맵은 "전체가 어떻게 이뤄져 있는가"를 각각 담당한다. 이 차이를 헷갈리면 셋 중 하나로 나머지를 대신하려는 실수를 하기 쉽다.

요소	답하는 질문	대상	노출 위치
상단 메뉴(내비게이션)	어디로 이동할 수 있는가	주로 상위 카테고리까지	헤더, 항상 고정 노출
브레드크럼	지금 페이지가 어디에 있는가	홈부터 현재 페이지까지 전체 경로	본문 상단, 해당 페이지에서만
사이트맵(sitemap.xml)	사이트 전체 페이지 목록이 무엇인가	사이트의 모든 색인 대상 URL	검색엔진 전용, 사용자에게는 비노출

상단 메뉴는 보통 대분류 몇 개만 보여주기 때문에 세부 카테고리나 현재 위치까지는 알려주지 못한다. 사이트맵은 사람이 읽는 화면 요소가 아니라 검색엔진에게 URL 목록을 통째로 전달하는 파일이라 사용자 경험과는 직접 관련이 없다. 이 둘 사이의 빈틈, 즉 "지금 이 페이지가 전체 구조에서 어디쯤인지"를 사용자 화면에서 채워주는 것이 바로 브레드크럼의 역할이다. 사이트맵 자체를 만드는 방법이 궁금하다면 사이트맵(sitemap.xml)이란? 만드는 법 총정리에서 확인할 수 있다.

BreadcrumbList 스키마는 어떻게 작성해야 할까

BreadcrumbList는 itemListElement 배열 안에 ListItem 객체를 순서대로 나열하는 구조다. 각 ListItem은 position(순서)·name(이름)·item(URL) 세 값만 있으면 된다. 구글 서치 센트럴 공식 문서 기준으로 이보다 복잡한 필수 항목은 없다.

기본 예시 코드는 다음과 같다.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "홈",
      "item": "https://iruweb.com"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "여성의류",
      "item": "https://iruweb.com/women"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "원피스",
      "item": "https://iruweb.com/women/dress"
    },
    {
      "@type": "ListItem",
      "position": 4,
      "name": "린넨 A라인 원피스"
    }
  ]
}

여기서 눈여겨봐야 할 점은 마지막 항목(4번, 현재 페이지)에는 item(URL)이 빠져 있다는 것이다. 구글 공식 가이드는 현재 페이지의 URL은 생략해도 된다고 안내한다. 어차피 그 페이지 자체의 주소는 검색엔진이 이미 알고 있기 때문이다. item을 넣어도 오류는 아니지만, 굳이 넣지 않는 편이 더 명확하다.

각 값의 의미를 짚어보면 이렇다.

• position: 1부터 시작하는 정수. 배열에 나열한 순서와 실제 값이 일치해야 한다
• name: 사용자에게 보이는 텍스트와 같은 이름을 쓴다. 화면의 브레드크럼과 스키마의 name이 다르면 신뢰도가 떨어진다
• item: 해당 단계 페이지의 절대 URL(https:// 로 시작하는 전체 주소). 상대 경로만 쓰면 인식이 안 될 수 있다

작성 방식으로는 페이지 하단이나 head 영역에 <script type="application/ld+json"> 태그로 위 코드를 그대로 삽입하면 된다. 화면에 보이는 브레드크럼 HTML과 이 JSON-LD는 서로 다른 코드지만 내용은 반드시 일치해야 한다. 화면에는 "홈 › 원피스 › 린넨원피스"인데 스키마에는 중간 단계가 빠져 있으면 구글이 둘 중 무엇을 믿어야 할지 알 수 없다.

구조화 데이터라는 개념 자체가 낯설다면 JSON-LD 스키마 마크업 쉽게 이해하기를 먼저 읽으면 이해가 훨씬 빠르다.

브레드크럼 스키마 작성 시 흔한 실수는 무엇일까

position 번호가 실제 순서와 어긋나거나, name이 화면 텍스트와 다르거나, 중간 단계를 건너뛰는 세 가지가 가장 흔한 실수다. 하나씩 나쁜 예와 좋은 예로 비교해보면 원인이 분명해진다.

실수 유형	나쁜 예	좋은 예
position 오류	4개 항목인데 position이 1, 2, 2, 4로 중복·누락	position이 1, 2, 3, 4로 빠짐없이 순차 배정
name 불일치	화면은 "원피스", 스키마는 "여성원피스카테고리"	화면과 스키마의 name을 완전히 동일하게
단계 누락	홈 › 상세(중간 카테고리 생략)	홈 › 대분류 › 중분류 › 상세 모두 포함
item 형식 오류	item에 /women/dress처럼 상대 경로만 입력	item에 https://iruweb.com/women/dress 전체 URL
페이지마다 다른 구조	같은 카테고리인데 페이지별로 순서가 뒤바뀜	같은 카테고리 트리는 항상 같은 순서로 고정

가장 많이 발생하는 실수는 화면 브레드크럼을 나중에 손봤는데 스키마 코드는 그대로 방치해서 두 가지가 서로 달라지는 경우다. 브레드크럼 UI를 리뉴얼하거나 카테고리명을 바꿀 때는 반드시 JSON-LD 코드도 함께 수정해야 한다.

또 하나 자주 보이는 실수는 위치형 브레드크럼에 검색 결과 페이지나 필터 조건을 섞어 넣는 것이다. "홈 › 검색결과 › 원피스"처럼 사용자마다 달라지는 임시 경로를 고정된 스키마에 넣으면, 같은 원피스 페이지인데도 진입 경로에 따라 스키마 내용이 계속 바뀌는 문제가 생긴다. 위치형 스키마에는 항상 변하지 않는 고정된 카테고리 경로만 담아야 한다.

진입 경로가 여러 개인 페이지는 어떻게 처리해야 할까

하나의 페이지에 여러 경로로 들어올 수 있다면, BreadcrumbList도 경로 수만큼 여러 개를 한 페이지에 넣을 수 있다. 구글 공식 문서도 이 방식을 지원한다고 안내한다.

예를 들어 "린넨 A라인 원피스"라는 상품이 "여성의류 › 원피스" 카테고리에도 속하고, 동시에 "여름 신상품" 기획전 카테고리에도 속한다고 하자. 이 경우 아래처럼 BreadcrumbList 두 개를 각각의 @type: "BreadcrumbList" 객체로 나란히 넣으면 된다.

[
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
      { "@type": "ListItem", "position": 1, "name": "홈", "item": "https://iruweb.com" },
      { "@type": "ListItem", "position": 2, "name": "여성의류", "item": "https://iruweb.com/women" },
      { "@type": "ListItem", "position": 3, "name": "원피스", "item": "https://iruweb.com/women/dress" },
      { "@type": "ListItem", "position": 4, "name": "린넨 A라인 원피스" }
    ]
  },
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
      { "@type": "ListItem", "position": 1, "name": "홈", "item": "https://iruweb.com" },
      { "@type": "ListItem", "position": 2, "name": "여름 신상품", "item": "https://iruweb.com/summer-new" },
      { "@type": "ListItem", "position": 3, "name": "린넨 A라인 원피스" }
    ]
  }
]

화면 UI에서는 보통 둘 중 사용자가 실제로 들어온 경로 하나만 보여주면 충분하다. 두 경로를 화면에 동시에 표시하면 오히려 혼란스럽다. 반면 스키마(JSON-LD)에는 존재하는 경로를 전부 넣어도 무방하다. 검색엔진은 이 여러 경로를 통해 그 페이지가 사이트 안에서 어떤 카테고리들과 연결돼 있는지 더 폭넓게 이해할 수 있다.

주의할 점은 실제로 존재하지 않는 가짜 경로를 만들어 넣지 않는 것이다. 사용자가 실제로 그 경로를 통해 페이지에 도달할 수 있어야 하며, 접근할 수 없는 경로를 스키마에만 표시하면 구조화 데이터 정책 위반으로 볼 수 있다.

브레드크럼이 검색결과에 어떻게 노출될까

BreadcrumbList 스키마를 정확히 넣으면, 검색결과 화면에서 회색 URL 대신 브레드크럼 경로가 표시된다. 예를 들어 원래는 "iruweb.com › women › dress"처럼 URL 경로 그대로 나올 자리가, "이루웹 › 여성의류 › 원피스"처럼 사람이 읽기 쉬운 이름으로 바뀐다.

이 변화는 클릭률에 직접 영향을 준다. 검색 결과에서 사용자가 클릭 전에 보는 정보는 제목·설명·그리고 이 경로 표시뿐이다. URL 슬러그(예: /cat2/sub19/id48213)보다 실제 카테고리 이름이 노출되면, 사용자는 클릭 전에 이 페이지가 어떤 내용인지 더 정확히 예측할 수 있고, 그만큼 클릭 의사결정이 쉬워진다.

다만 이 노출은 구글이 자동으로 판단해서 보여주는 것이라 100퍼센트 보장되지는 않는다. 스키마를 정확히 넣어도 특정 검색 상황에서는 여전히 일반 URL이 표시될 수 있다. 그래도 BreadcrumbList를 갖춰두는 것 자체는 위험이 없고 노출 확률을 높이는 방향이므로, 안 할 이유가 없다.

모바일 검색결과에서는 이 브레드크럼 표시가 데스크톱보다 더 자주 나타나는 편이다. 모바일 화면은 좁아서 전체 URL을 표시할 공간이 부족한데, 짧은 브레드크럼 경로는 이 제약에 잘 맞기 때문이다. 모바일 트래픽 비중이 큰 사이트일수록 브레드크럼 스키마의 체감 효과가 크다.

실제 화면을 예로 들면 이렇다. 나쁜 예는 검색결과에 iruweb.com › product-detail › item?id=48213 처럼 내부 URL 파라미터가 그대로 노출되는 경우다. 사용자는 이 페이지가 정확히 무엇을 파는 페이지인지 제목만 보고 짐작해야 한다. 좋은 예는 같은 페이지가 이루웹 › 여성의류 › 원피스로 표시되는 경우다. 제목을 읽기도 전에 이미 "원피스 카테고리의 상품이구나"라는 맥락이 전달되고, 원피스를 찾는 사용자라면 이 맥락만으로도 클릭 확률이 올라간다. 검색결과의 브레드크럼 표시는 제목·설명과 함께 클릭 여부를 결정하는 세 번째 요소로 봐야 한다.

플랫폼별로 브레드크럼 적용은 어떻게 다를까

카페24·아임웹 같은 플랫폼은 화면 UI 브레드크럼을 기본 제공하는 경우가 많지만, BreadcrumbList 스키마까지 자동으로 넣어주는지는 플랫폼과 테마마다 다르다. 직접 확인이 필요하다.

플랫폼별로 점검할 순서는 다음과 같다.

1. 관리자 화면에서 "SEO 설정" 또는 "구조화 데이터" 메뉴가 있는지 먼저 확인한다
2. 상품·게시글 상세페이지 소스보기(또는 개발자 도구)에서 BreadcrumbList라는 문자열이 있는지 검색한다
3. 없다면 테마 편집 기능으로 직접 JSON-LD 코드를 헤더나 본문에 삽입할 수 있는지 확인한다
4. 코드 삽입 기능조차 없는 폐쇄형 플랫폼이라면, 최소한 화면 UI 브레드크럼만이라도 정확히 설정해 UX 효과는 챙긴다

워드프레스처럼 직접 코드를 다룰 수 있는 자체 제작 홈페이지는 브레드크럼 플러그인이나 SEO 플러그인(Yoast, RankMath 등)이 화면 UI와 스키마를 함께 자동 생성해주는 경우가 많다. 이 경우에도 생성된 코드가 실제 화면과 정확히 일치하는지 한 번은 직접 검증하는 과정이 필요하다.

자체 제작 홈페이지에서 처음부터 브레드크럼과 사이트 구조를 함께 설계하고 싶다면 개발 단계에서 카테고리 트리를 먼저 정의하고, 그 트리를 기반으로 화면 컴포넌트와 스키마 생성 로직을 함께 만드는 방식이 가장 안정적이다. 이렇게 트리를 먼저 확정해 두면 앞서 다룬 사이트맵 제출이나 내부 링크 설계도 같은 기준으로 한 번에 정리된다.

브레드크럼 검증은 어떻게 해야 할까

작성한 BreadcrumbList는 반드시 리치 결과 테스트로 오류를 확인한 뒤 발행해야 한다. 코드 문법은 맞아 보여도 실제로는 인식되지 않는 경우가 흔하기 때문이다.

검증 절차는 크게 두 단계다.

• 1단계 (발행 전): 구글의 리치 결과 테스트 도구에 페이지 URL을 입력하거나 코드를 직접 붙여넣어 BreadcrumbList가 정상 인식되는지, 필수 항목 누락 경고가 없는지 확인한다
• 2단계 (발행 후, 주기적): 서치 콘솔의 "향상 기능" 메뉴에서 사이트 전체의 브레드크럼 관련 오류 수를 확인한다. 오류가 있는 페이지 목록이 여기 모여서 표시된다

체크리스트로 정리하면 다음과 같다.

• position이 1부터 순서대로 빠짐없이 이어지는가
• name이 화면에 보이는 텍스트와 정확히 같은가
• item(URL)이 절대 경로(https://)로 작성됐는가
• 현재(마지막) 페이지의 item은 생략했는가(선택 사항이지만 권장)
• 리치 결과 테스트에서 오류·경고 없이 인식되는가

이 검증은 한 번으로 끝나는 일이 아니다. 카테고리 구조를 바꾸거나 사이트를 리뉴얼할 때마다 브레드크럼 UI와 스키마가 함께 바뀌었는지, 리치 결과 테스트에서 여전히 오류가 없는지 다시 확인하는 습관이 필요하다.

자주 묻는 질문

브레드크럼이 꼭 필요한가, 없어도 괜찮은 사이트가 있나

페이지 수가 아주 적고 계층이 1에서 2단계뿐인 단순한 사이트라면 없어도 크게 문제되지 않는다. 다만 카테고리가 3단계 이상이거나 페이지 수가 많다면 브레드크럼 없이 운영하는 것은 사용자와 검색엔진 양쪽에 손해다.

BreadcrumbList 스키마만 넣고 화면에는 브레드크럼 UI가 없어도 되나

권장하지 않는다. 화면에 보이는 브레드크럼과 스키마 코드는 일치해야 한다는 것이 구글의 기본 원칙이다. 화면에는 없는데 스키마에만 있으면 사용자 눈에 보이지 않는 콘텐츠를 검색엔진에만 알리는 것으로 오해받을 수 있다.

브레드크럼 링크가 너무 많아지면 어떻게 줄여야 하나

계층이 5단계를 넘어간다면 화면에서는 중간 단계를 "…"으로 생략하고 처음과 마지막 두세 단계만 보여주는 방식이 일반적이다. 다만 스키마(JSON-LD)에는 생략 없이 전체 경로를 다 넣는 것이 좋다. 화면 축약과 스키마 전체 표기는 서로 다른 문제다.

첫 페이지(홈)도 브레드크럼에 넣어야 하나

넣는 것이 일반적이다. "홈"을 position 1로 넣으면 사용자와 검색엔진 모두에게 경로의 출발점이 명확해진다. 구글 공식 가이드도 도메인 자체를 반드시 포함하라고 요구하지는 않지만, 실무에서는 "홈"을 첫 단계로 넣는 편이 UX상 자연스럽다.

태그 페이지나 검색 결과 페이지에도 브레드크럼을 넣어야 하나

태그 페이지처럼 콘텐츠가 유동적으로 모이는 페이지는 위치형보다는 화면 UI만 간단히 처리하고, BreadcrumbList 스키마는 생략하는 경우가 많다. 검색 결과 페이지처럼 사용자마다 결과가 달라지는 페이지도 마찬가지로 고정된 스키마를 넣기에 적합하지 않다.

브레드크럼 디자인이 사이트마다 달라도 괜찮은가

괜찮다. 구글은 화면 디자인(색상·구분 기호·폰트)에 대해서는 규정을 두지 않는다. 디자인 자유도는 전적으로 브랜드 톤에 맞추면 되고, 지켜야 할 것은 항목의 순서와 이름이 실제 사이트 구조와 일치하는지뿐이다.

브레드크럼 링크의 앵커 텍스트도 최적화해야 하나

그렇다. 브레드크럼 링크도 내부 링크이므로 일반 내부 링크와 같은 원칙이 적용된다. "카테고리1"처럼 의미 없는 이름 대신 실제 검색어와 가까운 카테고리명을 쓰면 그 링크를 통해 상위 페이지로 전달되는 맥락도 더 명확해진다. 앵커 텍스트를 포함한 내부 링크 전반의 최적화 원칙은 앞서 소개한 내부 링크 전략 가이드에 정리돼 있다.

브레드크럼은 작은 링크 줄처럼 보이지만, 화면 UI와 BreadcrumbList 스키마가 함께 맞아떨어져야 사용자의 이탈을 막고 검색결과 노출에도 도움을 주는 요소입니다. 지금 운영 중인 홈페이지의 브레드크럼이 카테고리 구조와 정확히 일치하는지, 스키마 코드가 빠짐없이 들어가 있는지 이번 기회에 점검해보시길 권해 드립니다. 브레드크럼을 포함한 사이트 구조 설계와 구조화 데이터 적용이 막막하시다면 이루웹의 홈페이지 제작 서비스에서 카테고리 설계부터 스키마 마크업까지 함께 도와드리고 있습니다. 이루웹의 다른 서비스도 함께 살펴보시고, 궁금한 점은 상담 신청으로 편하게 문의해 주시기 바랍니다.