브레드크럼은 페이지 위쪽에 홈 > 블로그 > URL·사이트 구조처럼 놓이는 줄입니다. 지금 보고 있는 쪽이 사이트 안에서 어느 칸에 들어 있는지를 한 줄로 알려 주고, 각 칸을 누르면 그 윗 단계로 갑니다. 우리말 이름은 이동 경로이고, 네이버 문서도 이 이름을 씁니다.1[1]네이버 서치어드바이저의 구조화 데이터 문서에는 사이트 이동 경로 (BreadcrumbList)라는 이름으로 따로 한 쪽이 있습니다. 설명은 “검색결과에 사이트 이동 경로를 나타 냅니다. 검색 사용자가 웹페이지의 위치를 이해하는데 도움이 될수있습니다”입니다. 다만 같은 쪽에 “해당 내용이나 형식으로 노출되는 것을 보장하지 않습니다”라는 단서가 붙어 있어서, 넣으면 반드시 보여 준다는 뜻은 아닙니다. 인용문의 띄어쓰기는 네이버 페이지 그대로입니다.출처[5] 네이버 서치어드바이저 - 사이트 이동 경로 (BreadcrumbList)
이름이 비슷해서 애자일의 스크럼과 헷갈리는 분들이 있는데, 둘은 아무 관계가 없습니다. 브레드크럼은 화면에 놓이는 길 안내 줄이고, 스크럼은 일하는 방식입니다.
검색 결과에 주소가 나올 때, 예전에는 도메인 뒤에 이 경로가 함께 붙었습니다. 2025년 1월 23일부터는 휴대폰 검색 결과에서 이 경로가 나오지 않습니다. 구글이 그날 발표하고 바로 적용했습니다.2[2]구글 검색 센터 블로그 “Simplifying the visible URL element on mobile search results”(2025년 1월 23일)의 문장입니다. “Starting today, we’re rolling out a change to no longer show breadcrumbs on mobile search results in all languages and regions where Google Search is available (they continue to appear on desktop search results).” 모든 언어와 지역에 적용했다고 적었으므로 한국어 검색도 포함됩니다. 글쓴이는 구글 검색의 제품 관리자 Caitlin Dorsey입니다.출처[2] Google 검색 센터 블로그 - Simplifying the visible URL element on mobile search results (영어 원문) · 한국어판(기계 번역)
이유도 같이 적혀 있습니다. 작은 화면에서는 경로가 잘려서 쓸모가 떨어지기 때문입니다.3[3]같은 변경이 구글 문서 변경 이력에는 하루 앞선 1월 22일 자로 올라 있습니다. “Because of how breadcrumbs get truncated on smaller screens, we’ve found this feature isn’t as useful to people who are searching on mobile.” 블로그 쪽에는 “it gets cut off on smaller screens”로 적혀 있어 표현만 다르고 이유는 같습니다.출처[3] Google 검색 센터 - 문서 변경 이력 2025년 1월 (영어 원문) 지금 휴대폰으로 아무 검색이나 해 보시면 제목 위에 도메인만 있고 뒤쪽 경로는 없습니다.


없어진 것은 휴대폰 쪽뿐입니다. 컴퓨터 검색 결과에는 지금도 도메인과 경로가 함께 나옵니다. 구글은 발표와 함께 브레드크럼 문서에 이 기능은 데스크톱에서 제공됩니다라는 칸을 새로 만들어 두었습니다.4[4]구글은 같은 날 문서에도 “Feature availability”라는 칸을 새로 만들었습니다. 내용은 이렇습니다. “This feature is available on desktop in all regions and languages where Google Search is available.” 구글 문서에서 이 칸은 기능이 어디까지 나오는지를 적는 자리이고, 여기에 데스크톱만 적힌 것은 2025년 1월 변경 때문입니다.출처[1] Google 검색 센터 - Breadcrumb (BreadcrumbList) structured data (영어 원문) · 한국어판(기계 번역)
그래서 “브레드크럼이 검색 결과에 보인다”는 말은 지금 절반만 맞습니다. 한국어로 브레드크럼을 검색해서 나오는 윗자리 글들을 직접 받아 읽어 봤는데, 이 변경을 적어 둔 곳은 한 곳도 없었습니다.5[5]한국어 “브레드크럼” 검색 결과에서 윗자리에 있던 지면 아홉 곳을 직접 받아 글자를 검사했습니다. 일곱 곳이 읽혔고(두 곳은 접속이 막혔습니다), 2025년 모바일 변경을 적은 곳은 없었습니다. BreadcrumbList라는 낱말이 나온 곳도 MDN 한 곳뿐이었고, 첫 쪽에 하나뿐인 SEO 글에도 없었습니다. 잰 날은 2026년 10월 4일입니다.
화면에 보여 주는 것 말고 다른 쓰임이 하나 더 있습니다. 구글은 본문에 들어 있는 브레드크럼 표시를 검색 결과에서 그 페이지의 정보를 분류하는 데 쓴다고 적습니다.6[6]구글 브레드크럼 구조화 데이터 문서의 문장입니다. “Google Search uses breadcrumb markup in the body of a web page to categorize the information from the page in search results.” 같은 쪽에서 구글은 그 뒤에 예를 들어 설명하는데, 사람들이 아주 다른 검색어로 같은 페이지에 닿더라도 브레드크럼이 그 내용을 검색 맥락 안에 놓아 준다는 취지입니다. 분류에 쓴다는 말과 화면에 보여 준다는 말이 같은 쪽에 나란히 적혀 있어서 섞어 읽기 쉽습니다.출처[1] Google 검색 센터 - Breadcrumb (BreadcrumbList) structured data (영어 원문) · 한국어판(기계 번역) 같은 페이지라도 사람마다 아주 다른 검색어로 들어오는데, 브레드크럼이 그 페이지를 어느 갈래에 놓을지 알려 주기 때문입니다.
브레드크럼 표시를 넣지 않아도 검색 결과에 경로가 나올 수 있습니다. 구글은 주소에 들어 있는 낱말을 보고 브레드크럼을 스스로 익힌다고 적어 두었습니다.7[7]이 문장은 브레드크럼 문서가 아니라 구글 SEO 시작 가이드에 있습니다. “Google learns breadcrumbs automatically based on the words in the URL, but you can also influence them with structured data if you like a technical challenge.” 구조화 데이터를 “기술적 도전”이라고 부른 데서 알 수 있듯, 구글은 이것을 모든 사이트의 필수 과제로 적지 않았습니다. 같은 가이드는 주소에 사람에게 쓸모 있는 낱말을 넣으라고 권하면서, 도메인이나 주소 경로의 키워드 자체는 브레드크럼에 나오는 것 말고는 순위에 거의 영향이 없다고도 적습니다.출처[4] Google 검색 센터 - SEO 시작 가이드 (영어 원문) · 한국어판(기계 번역) 주소가 /blog/url-structure/라면 blog와 url-structure를 경로로 읽는 식입니다.
구조화 데이터는 그 짐작을 바로잡는 수단입니다. 반드시 넣어야 나오는 것이 아니라, 넣으면 내가 정한 이름과 순서로 바꿀 수 있습니다. 주소에 쓴 낱말이 사람이 읽기에 어색한 사이트일수록 넣을 이유가 커집니다.
모바일에서 안 보이게 됐으니 표시를 걷어내야 하는지 궁금할 수 있습니다. 구글은 발표 글에서 쓰고 있다면 할 일이 없다고 못 박았습니다.8[8]2025년 1월 23일 발표 글의 문장입니다. “If you’re using breadcrumb markup, there’s nothing you need to do, as we continue to support breadcrumb markup for use in desktop search results.” 같은 글에서 구글은 서치 콘솔의 브레드크럼 리치 결과 보고서도 그대로 유지되고, 리치 결과 테스트로 계속 검사할 수 있다고 덧붙였습니다.출처[2] Google 검색 센터 블로그 - Simplifying the visible URL element on mobile search results (영어 원문) · 한국어판(기계 번역) 데스크톱 검색 결과에서는 계속 지원하기 때문입니다.
브레드크럼이 순위를 올린다는 말은 업계에 흔한데, 구글이 순위 요소라고 말한 적은 없습니다. 구글 직원이 공개적으로 한 말은 브레드크럼 링크를 보통 링크와 같이 센다는 것까지입니다.9[9]Gary Illyes가 2017년에 “We treat them as normal links in e.g. PageRank computation”이라고 적었고, John Mueller는 2021년에 브레드크럼을 화면 어디에 두는지는 SEO와 무관하다고 답했습니다. 둘 다 업계 기사가 옮긴 것이고 저희는 원래 글을 직접 보지 못했습니다. Mueller는 2022년에 구조화 데이터가 일반 내부 링크를 대신하지 못한다고도 말했는데, 브레드크럼을 구조화 데이터로만 넣고 화면에는 링크를 두지 않는 경우를 생각하면 새겨들을 만합니다. 분리 테스트 쪽은 SearchPilot이 브레드크럼 마크업을 고친 뒤 트래픽이 6~12% 줄었다고 보고했고, Semrush SplitSignal은 마지막 항목을 없앴더니 8.7% 늘었다고 보고했습니다. 둘 다 고객 한 곳짜리 테스트이고 바꾼 것도 달라서, 서로 견줄 수 있는 숫자가 아닙니다. [9] [10]출처[9] Search Engine Roundtable - Google: We Like Breadcrumb Navigation Links On Your Site (Gary Illyes 발언 전달, 2017-06-22)[10] SearchPilot - SEO test: How important is breadcrumb markup for SEO? (2021-05-23)[11] Semrush SplitSignal - Removing the Last Breadcrumb on Product Page (2021-08-20) 업계가 돌린 분리 테스트 결과도 서로 반대라서, 한쪽은 순위가 내려갔다고 하고 다른 쪽은 올라갔다고 합니다.
브레드크럼이 있는 쪽과 없는 쪽에 사람을 무작위로 나눠 견준 실험은 찾아보니 둘뿐이었습니다. 2003년에 45명, 2024년에 37명을 대상으로 했습니다. 둘 다 과제를 끝내는 시간에서 차이를 찾지 못했습니다.10[10]2003년 연구는 Rogers와 Chaparro가 위치타주립대 소프트웨어 사용성 연구소에서 한 것으로 45명이 참여했고, 2024년 연구는 미국 인구조사국이 스마트폰 설문을 대상으로 한 것으로 37명이 참여했습니다. 2003년 쪽은 방문한 페이지 수, 메뉴 클릭, 본문 링크 클릭, 과제 완료 시간 어디에서도 차이를 찾지 못했다고 적었습니다. 2024년 쪽은 과제 하나에서 브레드크럼 없는 집단이 더 빨랐다는 수치를 냈지만, 브레드크럼을 실제로 쓴 사람이 거의 없어 “쓴 사람과 안 쓴 사람”의 비교가 아니었고 통계적으로도 경계에 걸쳐 있어서 저희는 그 숫자를 쓰지 않습니다. 참고로 2001년 메릴랜드대 수업 과제로 진행된 18명짜리 실험에서는 홈 링크만 있는 쪽이 브레드크럼이 있는 쪽보다 오히려 빨랐는데, 동료 심사를 거친 논문이 아니라 한 학기 과제입니다. [6] [7]출처[6] Rogers & Chaparro (2003) Breadcrumb Navigation: Further Investigation of Usage, Usability News 5.2[7] Falcone, Feuer & Wang (2024) Mobile Survey Design Research Experiment 27: Breadcrumb Trail, 미 인구조사국[8] Bowler, Ng & Schwartz (2001) Navigation Bars for Hierarchical Web Sites, SHORE 2001
2003년 연구는 그냥 못 찾은 것이 아닙니다. 연구진이 브레드크럼을 쓰면 유리해지도록 과제를 일부러 짜 놓고도 차이가 없었습니다.
같은 2003년 실험에서 전체 페이지 클릭 가운데 브레드크럼이 차지한 몫은 6%였습니다. 주 메뉴와 뒤로 가기, 본문 링크가 훨씬 많이 쓰였습니다. 2024년 실험은 더 심했습니다. 브레드크럼이 있는 쪽에 배정된 19명 가운데 실제로 누른 사람이 2명이었습니다. 효과를 재는 것 자체가 불가능했습니다.11[11]2003년 논문의 논의 첫 문단에 이렇게 적혀 있습니다. “In this study, we designed the tasks such that navigational efficiency would be optimized through the use of a breadcrumb trail. Despite this, only 6% of the page clicks were accounted for by the breadcrumb.” 참가자의 40%가 한 번이라도 브레드크럼을 썼지만, 쓰는 빈도 자체가 다른 길찾기 수단보다 낮았다는 뜻입니다. 2024년 보고서 쪽은 “Since only two of 19 participants in the Breadcrumb group actually used the breadcrumb trail, navigation performance of using a breadcrumb trail could not be meaningfully assessed.”라고 적고 분석 방법을 바꿨습니다. 다만 이 보고서가 다룬 것은 웹사이트가 아니라 한 줄씩 넘어가는 설문 화면이어서, 결과를 사이트에 그대로 옮기면 안 됩니다. [6]출처[6] Rogers & Chaparro (2003) Breadcrumb Navigation: Further Investigation of Usage, Usability News 5.2[7] Falcone, Feuer & Wang (2024) Mobile Survey Design Research Experiment 27: Breadcrumb Trail, 미 인구조사국
그렇다고 쓸모가 없다고 나온 것은 아닙니다. 2003년 실험에서 브레드크럼이 있는 사이트를 쓴 사람은 그 사이트를 계단처럼 층이 진 구조로 알아본 비율이 유의하게 높았습니다. 뒤로 가기도 덜 썼습니다.12[12]2003년 실험은 과제를 마친 참가자에게 방금 쓴 사이트의 구조로 어떤 그림이 맞는지 고르게 했습니다. 계층형 두 가지와 비계층형 두 가지를 놓고 고르게 했더니 브레드크럼이 있던 쪽 사람들이 계층형을 고른 비율이 높았습니다(χ²(2, N = 45) = 8.08, p = .02). 브레드크럼을 쓴 사람은 뒤로 가기 버튼을 덜 썼다는 결과도 같이 나왔습니다. 모두 20년이 넘은 데스크톱 환경의 실험이라는 점은 감안해야 합니다.출처[6] Rogers & Chaparro (2003) Breadcrumb Navigation: Further Investigation of Usage, Usability News 5.2
정리하면 브레드크럼이 주는 것은 속도가 아니라 위치 감각입니다. 일을 빨리 끝내 주지는 않지만, 자기가 어디쯤 와 있는지를 알게 해 줍니다.
한국어로 브레드크럼을 검색하면 브레드크럼은 죽었다는 글이 첫 쪽에 나옵니다. 근거로 든 것은 웹이 비선형이 됐다, 추천이 앞서 간다, 모바일에서 자리를 차지한다 같은 것입니다. 읽어 보니 숫자는 한 건도 없었습니다.13[13]2025년 3월 Web Designer Depot에 실린 글이고 국내에는 긱뉴스 요약으로 퍼졌습니다. 본문에 바깥 링크가 하나도 없고 퍼센트 수치도 없습니다. “대부분의 사용자는 검색창에서 여정을 시작한다는 연구가 있다”고 적으면서 어떤 연구인지 밝히지 않았습니다. 검색 결과나 구조화 데이터 이야기는 나오지 않아서, 구글이 두 달 전에 모바일 표시를 뺀 일도 언급되지 않습니다. 달린 댓글 세 개 가운데 둘은 그 주장에 되묻는 내용이었습니다.출처[12] Web Designer Depot - Breadcrumbs Are Dead in Web Design (Noah Davis, 2025-03-17)
덜 쓰인다는 말 자체는 맞습니다. 다만 그건 2003년에 이미 측정된 사실이고, 새로 생긴 일이 아닙니다.
가장 흔한 실수입니다. 구글은 주소 구조를 그대로 옮기지 말고, 사람이 지나올 법한 길을 담으라고 적습니다.14[14]구글 브레드크럼 문서의 일반 지침에 있는 문장입니다. “We recommend providing breadcrumbs that represent a typical user path to a page, instead of mirroring the URL structure. It is not required to include a breadcrumb ListItem for the top level path (your site’s domain or host name), nor for the page itself.” 뒷문장은 맨 위 칸과 페이지 자신을 넣지 않아도 된다는 뜻인데, 넣어서 틀리는 것은 아니고 필수가 아니라는 말입니다. 쇼핑몰처럼 한 상품이 여러 분류에 걸쳐 있는 사이트에서 이 지침이 특히 걸립니다. 주소는 분류 하나만 담고 있지만 사람은 다른 분류를 거쳐 들어오기도 하기 때문입니다.출처[1] Google 검색 센터 - Breadcrumb (BreadcrumbList) structured data (영어 원문) · 한국어판(기계 번역) 주소는 파일을 정리하려고 만든 순서여서, 사람이 실제로 거쳐 온 길과 다를 때가 많기 때문입니다.
맨 앞의 도메인과 지금 보고 있는 페이지 자신은 넣지 않아도 됩니다.
구글은 BreadcrumbList 안에 칸이 둘 이상 있어야 한다고 적습니다. 칸마다 item과 name과 position을 모두 넣으라고 합니다. 네이버는 name만 필수이고 position은 필수가 아닙니다.15[15]구글은 “define a BreadcrumbList that contains at least two ListItems”라고 적고, ListItem의 필수 속성으로 item·name·position 셋을 듭니다. 네이버 문서는 name만 필수로 적고 position은 “필수아님”으로 표시하며, item은 필수 목록에 올리지 않습니다. 네이버는 이름을 지을 때 “top”, “홈” 같은 일반적인 낱말 대신 페이지를 잘 설명하는 말을 쓰라고 덧붙이고, 넓은 범위에서 좁은 범위 순서로 적으라고 안내합니다. 다만 네이버는 넣는다고 해서 검색 결과에 그 모습으로 나오는 것을 보장하지 않는다고 같은 쪽에 적어 두었습니다. [1]출처[1] Google 검색 센터 - Breadcrumb (BreadcrumbList) structured data (영어 원문) · 한국어판(기계 번역)[5] 네이버 서치어드바이저 - 사이트 이동 경로 (BreadcrumbList)
둘 다 맞추려면 구글 쪽에 맞춰 셋을 다 넣으면 됩니다.
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[
{"@type":"ListItem","position":1,"name":"블로그","item":"https://example.com/blog"},
{"@type":"ListItem","position":2,"name":"URL·사이트 구조"}]}
마지막 칸은 item을 빼도 됩니다. 비워 두면 구글이 그 페이지 주소를 쓰기 때문입니다.16[16]구글 문서의 문장입니다. “If the breadcrumb is the last item in the breadcrumb trail, item is not required. If item isn’t included for the last item, Google uses the URL of the containing page.” 위 예시에서 두 번째 칸에 item이 없는 것이 그 때문입니다. 구조화 데이터를 넣는 방식은 JSON-LD 말고도 마이크로데이터와 RDFa가 있고, 구글은 셋을 모두 읽습니다. 저희가 검색 상위 지면을 세어 보니 브레드크럼을 넣은 149곳 가운데 140곳이 JSON-LD를 썼고, 마이크로데이터가 12곳, RDFa가 1곳이었습니다.출처[1] Google 검색 센터 - Breadcrumb (BreadcrumbList) structured data (영어 원문) · 한국어판(기계 번역)
2003년 실험은 같은 브레드크럼을 페이지 맨 위와 제목 바로 아래에 각각 놓고 견줬습니다. 눌린 199번 가운데 82%가 제목 아래에 있는 쪽이었습니다.17[17]2003년 연구는 같은 사이트를 브레드크럼 위치만 바꿔 두 벌 만들고 참가자를 나눠 배정했습니다. 제목 아래에 둔 쪽에서 더 많은 사람이 눌렀고(10명 대 4명), 차이는 통계적으로 유의했습니다(χ²(1, N = 30) = 4.82, p = .03). 연구진은 제목 아래가 눈높이에 가깝고 다른 링크와 가까워서라고 설명했습니다. 참고로 구글 쪽에서는 브레드크럼을 화면 어디에 두는지가 검색 순위와 무관하다고 밝힌 적이 있으므로, 이 자리 선택은 검색이 아니라 사람을 위한 것입니다.출처[6] Rogers & Chaparro (2003) Breadcrumb Navigation: Further Investigation of Usage, Usability News 5.2
한국어 검색 결과에 올라온 지면을 도메인마다 한 쪽씩 받아 세어 봤습니다. 읽힌 653곳 가운데 브레드크럼 표시가 있는 곳은 149곳, 22.8%였습니다. 구조화 데이터 자체를 쓰는 곳만 따로 보면 이야기가 달라집니다. 389곳이 무언가를 넣고 있었고, 그 가운데 브레드크럼까지 넣은 곳은 149곳, 38.3%였습니다. 나머지 240곳은 다른 것은 넣으면서 브레드크럼만 빼 두었습니다.18[18]재는 방법은 이렇습니다. 저희가 다른 글을 쓰려고 모아 둔 한국어 검색 결과 지면에서 도메인마다 한 쪽씩 600개를 골라 받았고(2026년 10월 4일), 차단과 시간 초과를 뺀 653곳이 읽혔습니다. 받은 HTML에서 BreadcrumbList를 JSON-LD·마이크로데이터·RDFa 세 방식으로 찾았습니다. 숫자를 쓰기 전에 무작위 18곳을 다시 받아 손으로 세어 맞춰 봤고 열여덟 곳 다 맞았습니다. 한계가 있습니다. 표본이 검색 상위에 뜬 지면이라 웹 전체가 아니고, 받은 HTML만 보았으므로 자바스크립트로 그려 넣는 브레드크럼은 세지 못합니다. 사이트마다 한 쪽만 보았으므로 다른 쪽은 다를 수 있습니다. 화면에 브레드크럼이 보이는지도 함께 재 보려 했지만 HTML만으로는 믿을 만하게 가릴 수 없어 그 숫자는 버렸습니다.
몰라서 안 넣은 쪽보다 알면서 이것만 건너뛴 쪽이 많다는 뜻입니다.
페이지 위쪽에 홈 > 블로그 > 글처럼 놓여 지금 보는 쪽이 사이트 어디에 있는지 알려 주는 줄입니다. 우리말로는 이동 경로라고 합니다. 각 칸을 누르면 윗 단계로 갑니다.
브레드크럼을 잘못 적은 말로 보입니다. 애자일의 스크럼과는 관계가 없습니다. 찾으시는 것이 화면의 길 안내 줄이라면 브레드크럼이 맞습니다.
브레드크럼이 따라가는 층을 어떻게 짤지는 홈페이지 구조에서, 주소를 어떤 모양으로 만들지는 URL 구조에서 다룹니다.
출처