郊山步道的岔路口，常常會看到一條顏色鮮明的路條綁在樹枝上，每隔一段距離就出現一次；它的作用不是裝飾，而是讓走這條路的人隨時知道自己在哪一段、要往哪裡去，萬一迷路了，也能沿著路條一路退回登山口。百貨公司或大型展場的樓層指標也是同一種邏輯，搭電梯到了三樓，牆上那排「一樓服飾、二樓生活雜貨、三樓家具」的字樣，讓人不用回頭確認，一眼就知道自己站在整棟樓的哪個位置。
網站的麵包屑導覽設計，做的正是同一件事。它是頁面上一小串連結，標出使用者目前所在頁面在整個網站階層中的位置，通常擺在頁首主導覽下方、頁面標題上方。少了它，訪客從搜尋結果直接落在一篇很深的文章或某個商品頁時，常常搞不清楚自己在網站的哪個分類底下、往上一層是什麼，只能被迫用瀏覽器的上一頁鍵慢慢試。麵包屑要處理的問題並不只是好不好看，而是格式該長怎樣、該放在頁面的哪個位置，以及手機版該怎麼精簡顯示、又該怎麼寫進 BreadcrumbList 結構化資料讓搜尋引擎看得懂。這幾件事，決定了一個網站的導覽做得紮不紮實。
先從麵包屑本身的基本構成講起，再一路往下拆。
麵包屑導覽是什麼？先看懂三個基本元素
麵包屑導覽（Breadcrumb Navigation）是一串顯示目前頁面在網站階層中位置的連結，一般跟主導覽分開，獨立擺在頁首主導覽的下方、頁面標題的上方。這串連結由三個基本元素組成，第一是起點，通常就是網站首頁；第二是中間層級，也就是從首頁到目前頁面之間，一層一層的分類或子分類；第三是目前頁面本身，也就是路徑最後一節。
三個元素之間習慣用「>」這個符號隔開，例如「首頁 > 部落格分類 > 這篇文章」，清楚標出從首頁走到這一頁，中間經過了哪些層級。要特別注意的是目前頁面這一節，它不應該做成可以點擊的連結，使用者已經站在這一頁，再點一次沒有意義，視覺上也要跟前面的連結明顯區分開來，常見做法是拿掉底線、換成不同顏色或加粗，讓使用者一眼就分得出哪裡是連結、哪裡是自己現在的位置。
這一串連結看起來簡單，背後其實對應著整個網站的資訊架構，網站的分類怎麼分、子分類怎麼掛，直接決定了麵包屑會長成什麼樣子。這也是為什麼麵包屑不是隨便排列組合就好，接下來先看常見的三種類型，分別適合什麼樣的網站。
麵包屑常見的三種類型：階層式、屬性式、路徑式
麵包屑常見的做法可以分成三種類型。階層式（Location-based）跟著網站原本的分類架構走，一層一層對應到分類與子分類，這是多數網站的預設選擇，也最容易維護。屬性式（Attribute-based）則常見於電商網站，依照使用者篩選的條件層層疊加，例如「首頁 > 女鞋 > 高跟鞋 > 紅色」，每一層代表一個篩選維度，而不是分類階層。路徑式（Path-based）跟著使用者實際點擊的先後順序走，問題是它容易跟瀏覽器內建的上一頁功能重複做同一件事，而且如果訪客是從搜尋結果或社群連結直接跳進某個頁面，不是從首頁一路點進來，路徑式麵包屑就會顯示出一條跟他實際經驗完全對不上、甚至互相矛盾的路徑。
判斷該用哪一種其實不難，頁面層級多、分類架構清楚的網站，優先用階層式；只有電商的篩選結果頁，才需要考慮屬性式；路徑式在多數情境下風險偏高，不建議當成主要的麵包屑邏輯來用。
還有一種情況值得特別留意，同一個頁面如果同時掛在好幾個分類底下（例如一篇文章分別歸在「SEO優化」和「網路行銷」兩個分類），對應到的麵包屑路徑理論上就不只一條。這時候的做法是挑一條多數使用者最典型的路徑固定下來當唯一麵包屑，不要同時顯示好幾條路徑，也不要依照使用者這次是怎麼點進來的去客製化，麵包屑呈現的應該是網站固定的階層，不是一次性的瀏覽紀錄。
麵包屑導覽和主要導覽，有什麼不同？
上一節提到麵包屑該固定成一條路徑，不隨使用者這次怎麼點進來改變，這跟網站主導覽列是不同的兩件事，分工也很明確。麵包屑的角色是輔助、次要的導覽，幫使用者確認自己現在在哪裡，它不能拿來取代主導覽列或側邊選單這種讓使用者主動決定要去哪裡的核心導覽元件。換句話說，拿掉麵包屑，使用者理論上還是能靠主導覽或搜尋功能找到想去的地方；但拿掉主導覽，整個網站的動線就斷了。
另一個常被搞錯的地方是，麵包屑常被誤認成瀏覽紀錄，以為它記錄的是「我剛剛怎麼一路點進來」。實際上麵包屑反映的是網站固定的階層結構，不管使用者是從首頁點進來，還是從搜尋結果直接落在這一頁，同一個頁面顯示出來的麵包屑路徑都應該一模一樣。
也因為這樣，像是回首頁這種連結，通常主導覽列本身就會有（常見做法是點 LOGO），麵包屑的第一節也一定是首頁，兩邊功能重複時，擇一保留清楚呈現就好，沒必要在同一個畫面裡放兩次功能一樣的連結，徒增版面雜訊。
什麼樣的網站，不需要麵包屑？
釐清了麵包屑跟主導覽的分工之後，接下來要看的是，並不是每個網站都得裝一組麵包屑。如果一個網站的頁面層級很淺，例如整站只有一到兩層，或者內容本身就是線性排列，像是一篇分成好幾頁、本來就要照順序往下讀的教學文章，硬加一組麵包屑不會帶來額外的方向感，反而變成畫面上多餘的視覺雜訊，佔位置卻沒發揮作用。
另一個更容易被忽略的地雷，是結帳、註冊、表單填寫這類多步驟流程頁。這種頁面看起來也是一步一步往下走，很容易讓人聯想到麵包屑，但恰恰相反，在這種流程裡放麵包屑，等於在使用者填到一半的時候，遞給他一個方便的逃生出口。使用者只要看到「上一步」或「首頁」這種可以點的連結，半路點掉、放棄完成整個流程的機率就會提高。這種情境該用的是標出第幾步、共幾步的進度指示，而不是麵包屑。
麵包屑該放在頁面的哪個位置？
確定了該不該做之後，接下來要處理的是實際動手時最先碰到的問題。標準的位置是頁首主導覽的下方、頁面標題（也就是 H1）的上方。這個位置的好處是使用者需要的時候一眼就能看到，不需要的時候也不會擋到閱讀主要內容。它剛好卡在導覽跟內容中間，是最自然的過渡位置。
排版上有幾個細節值得注意。麵包屑的字級不必跟內文一樣大，它是次要資訊，通常會縮小處理，避免搶走頁面標題的視覺重量；連結與連結之間要留夠的空白，讓使用者能清楚辨識每一節都是各自獨立、可以點擊的項目，不會擠成一團看不出分界；目前頁面那一節，前面已經提過，要用不同顏色或拿掉底線做出區分。
位置也不是完全的鐵律。國際知名品牌像 Apple 官網，就把麵包屑放在頁尾靠上方的位置，而不是傳統的頁首，一樣運作得很順暢。這說明位置本身可以有彈性，重點反而是全站要保持一致，不管選在哪個位置，同一個網站裡的每個頁面都用同一個位置，使用者才不用每次都重新找。
麵包屑的分隔符號、字數與目前頁面，怎麼處理？
位置定案之後，接下來是幾個可以直接照做的細部規則。
分隔符號要全站統一，「>」是最常見的選擇，也有網站用斜線「/」，但不管選哪一種，整個網站都要用同一種符號，不要這頁用「>」、那頁又換成「/」，讓使用者以為換了一套系統。每一層的名稱要簡短，能代表這個分類的主題就好，不需要為了塞關鍵字硬把完整的分類名稱、修飾詞全部堆進去，那是寫給搜尋引擎看的思維，不是寫給使用者看的。
另一個常見的失誤，是把整篇文章又長又完整的標題原封不動塞進麵包屑的最後一層。這樣做在桌面版可能還看得過去，但換到手機這種小螢幕上，又長又完整的標題很容易換行，甚至被直接截斷，兩個問題都會讓使用者體驗變差。
這幾條規則多半只影響看得到畫面的使用者，但麵包屑要服務的對象，不只他們。
無障礙設計，讓螢幕閱讀器也讀得懂麵包屑
麵包屑不只是給看得到畫面的使用者用的視覺元素。要讓螢幕閱讀器使用者也能理解這串連結背後代表的階層，還有幾個具體的技術細節值得做好，而這些細節在多數網站上都做得不夠完整。
整組麵包屑應該包在一個具備語意的導覽容器裡，並且標上專屬標籤，讓輔助技術能明確辨識出這是麵包屑導覽，而不是隨便一串連結。階層順序建議用有序清單來呈現，讓螢幕閱讀器可以照順序一項一項唸出來，使用者也能掌握自己現在是第幾層。目前頁面那一節，除了視覺上要跟其他連結區分，也要在程式碼裡標出這是目前所在頁面的狀態，讓輔助技術能明確告訴使用者。至於「>」這種分隔符號，則要設成裝飾用途，確保螢幕閱讀器不會把它當成一段有意義的文字唸出來，打斷閱讀的節奏。
這幾項技術細節不複雜，卻是判斷一組麵包屑做得夠不夠完整的重要指標。
手機版麵包屑，該不該精簡顯示？
位置、留白、無障礙標記都顧到之後，還有一個變數會直接影響顯示效果，那就是螢幕大小。手機螢幕小，桌面版那種完整的長串路徑，搬到手機螢幕上很容易撐爆一行，不是被迫換成兩三行擠在一起，就是每個字被壓縮到小到很難點準。
不過答案並不是乾脆把麵包屑從手機版拿掉。就算畫面上看不到完整路徑，麵包屑背後代表的階層資訊，對訪客跟搜尋引擎來說仍然有價值，差別只在於呈現的方式要換一種做法，而不是整個拿掉。實務上常見的精簡做法有三種，第一種只顯示最近的一到兩層，適合使用者只是想回上一層的情境，不需要看到從首頁開始的完整路徑；第二種讓整條路徑保留完整，改用水平捲動呈現，搭配箭頭之類的視覺提示，讓使用者知道還可以往旁邊滑看到更多層級；第三種是把完整路徑收合成一顆按鈕或一個省略號，平常只佔一點點空間，點開才展開完整清單。
不管選哪一種做法，有一個地雷特別容易被忽略，連結的可點擊區域至少要有約一公分見方，太小的話，手指在小螢幕上很難點準，反而讓原本要幫忙導覽的功能，變成一個點不到的困擾。
BreadcrumbList 結構化資料，怎麼正確標記？
前面談的都是使用者眼睛看得到的麵包屑，但麵包屑還有另一個看不到的用途——寫進網頁原始碼裡的 BreadcrumbList 結構化資料，是搜尋引擎理解頁面位置的另一條線索。
這是 Google 官方支援的結構化資料類型，目的是讓搜尋引擎更清楚一個頁面在整個網站階層中的位置，標記得當，也有機會讓桌面版的搜尋結果多顯示一段複合式的導覽路徑。誠實說，符合格式不保證一定會顯示出來，它也不是直接的排名因子；但長期來看，對搜尋引擎理解整個網站的架構還是有幫助。
這裡有一個 2025 年的重要更新，不能不提。Google 從 2025 年 1 月 23 日起，已經不再於手機版的搜尋結果畫面上顯示導覽標記路徑，桌面版搜尋結果依然會顯示，理由是這段路徑在小螢幕上常常被截斷，對手機使用者的幫助其實有限。不過這只是搜尋結果畫面要不要顯示的改變，已經做好標記的網站不需要因此把 BreadcrumbList 拿掉，桌面版的顯示效果、底層結構化資料幫助搜尋引擎理解頁面的價值都還在。這也是網站自己手機版的麵包屑要做得更扎實的原因之一，使用者在手機上已經看不到搜尋結果裡的路徑提示，進站之後就更依賴網站本身的麵包屑導覽，才能搞清楚自己身在何處。
具體怎麼寫，Google 建議用 JSON-LD 格式，比起 Microdata、RDFa 這兩種舊格式更容易維護、也比較不容易寫錯。一個 BreadcrumbList 裡至少要放兩個 ListItem，最上層的網域跟頁面本身都不必特別另外列一項，只要把中間有意義的層級標記清楚就好。
JSON-LD 三個必填欄位：position、name、item
把 JSON-LD 攤開來看，其實只有三個欄位要填。position 標出這一層在整條路徑中的順序，從 1 開始算；name 是顯示給使用者看的名稱；item 則是這一層對應的網址，如果這一層是路徑中的最後一項，也就是目前頁面本身，item 這個欄位可以不填，因為使用者已經站在這個網址上，不需要再連一次。
以一條「首頁 > 部落格分類 > 這篇文章」的三層路徑為例（以下是去識別化的示範，不對應任何真實網站），寫出來大致長這樣：
{
"@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/blog/"
},
{
"@type": "ListItem",
"position": 3,
"name": "這篇文章"
}
]
}Code language: JSON / JSON with Comments (json)可以看到，最後一項只有 position 跟 name，沒有 item，因為它就是目前所在的這一頁。
前台顯示和結構化資料要一致，這是最常見的錯誤
寫好 JSON-LD 之後，最容易出狀況的地方，反而不是語法寫錯，而是兩邊對不起來。畫面上訪客實際看到的麵包屑路徑，跟原始碼裡 BreadcrumbList 標記的路徑，必須完全一致，item 欄位也要填完整的網址，不能只寫相對路徑。如果前台顯示跟結構化資料兜不起來，或者同一個頁面被好幾套不同的路徑重複標記，搜尋引擎對這個頁面階層的判斷就會變得混亂，也容易在 Search Console 觸發警告。
還有一個常被忽略的技術細節，如果麵包屑是靠前端 JavaScript 執行完才顯示出來，建議改成伺服器端直接輸出好整段內容，搜尋引擎爬取的時候才能穩定讀到，不必依賴額外的執行環境。
標記完成之後，可以先用 Google 的複合式搜尋結果測試工具驗證語法有沒有寫對；上線之後，則建議持續在 Search Console 觀察「有效」、「警告」、「錯誤」這三種項目數量的變化，一旦警告或錯誤數字往上升，通常就是哪裡的標記出了狀況，可以及早回頭修正。
AI 摘要與語意搜尋，也讀得懂這份結構化資料
結構化資料的價值，這幾年也延伸到傳統搜尋結果之外。當生成式搜尋、AI 摘要這類功能要判斷一個頁面在整個網站主題脈絡裡的定位時，一條清楚一致的麵包屑路徑，比一篇孤立存在、看不出上下文的文章，更容易讓系統判斷出這個頁面的主題深度跟專業範疇，例如「首頁 > 部落格分類 > 這篇文章」這樣的路徑，本身就在告訴系統這篇內容隸屬於哪個更大的主題分類。
不過這裡也要誠實交代現況，目前沒有證據顯示 AI 模型會把麵包屑路徑當成直接的排名因子。它的效益主要展現在幫助系統理解語意脈絡這件事上，不宜誇大成保證曝光或排名的萬靈丹。
一個多層頁面網站，麵包屑該怎麼規劃？
把前面幾節串起來，可以想像一個情境，一個經營好幾個內容分類、文章數量持續累積的部落格型網站，要重新規劃自己的麵包屑導覽，通常會照著這樣的順序走一遍。
第一步不是急著挑麵包屑的樣式，而是先確認網站本身的分類架構合不合邏輯，麵包屑只能忠實反映既有的階層，如果分類本身分得亂七八糟，麵包屑再怎麼設計都救不回來。確認架構清楚之後，才決定採用階層式麵包屑，並且把每個頁面對應的路徑固定下來，不會隨著使用者這次是怎麼點進來而改變。
接著分開規劃桌面版跟手機版的呈現方式，桌面版放在頁面標題正上方，字級縮小、留白足夠，目前頁面用不同顏色標示出來；手機版則精簡成回上一層分類，加一顆可以展開完整路徑的按鈕，避免長串路徑在小螢幕上換行或被截斷。同一時間，原始碼裡也要寫好 JSON-LD 版的 BreadcrumbList，並且反覆核對前台顯示的路徑跟標記的路徑是否完全一致。
上線之後，先用複合式搜尋結果測試驗證語法沒有寫錯，後續也要在 Search Console 定期檢查有效與警告的項目數量。照著這個順序走一次，大致就是一套完整的麵包屑導覽設計；而且這件事不是做完一次就能放著不管，網站改版、分類架構調整之後，都得回頭重新檢查一次麵包屑有沒有跟著更新。
麵包屑導覽做得好不好，往往要等訪客從搜尋結果直接落在很深的一篇文章或某個商品頁時，才會真正被用到。下次不妨找一篇網站裡層級最深的文章或商品頁，試著不靠瀏覽器的上一頁按鈕，只靠畫面上的麵包屑，看看能不能順利回到想去的地方，這個小測試，往往比對照理論更快抓出問題出在哪裡。