什麼是 Breadcrumb 與麵包屑導覽
Breadcrumb，中文常譯為「麵包屑」，是一種網頁導覽輔助元件，顯示使用者於網站架構中的當前位置。它通常以「首頁 > 分類頁 > 目前頁」的路徑形式，呈現於頁面頂部、主內容區域之前。這項設計源自於童話故事中角色撒下麵包屑以標記路徑的概念，如今廣泛應用於網站與應用程式介面。
這條路徑之所以被稱為「麵包屑」，正是借用童話故事中「沿途撒下麵包屑，以便循原路返回」的意象。將此概念轉換到網頁介面時，網站管理者預先將內容歸類成不同層級，並讓使用者在頁面頂部看到自己從起點到目前頁面的逐步軌跡。這個軌跡同時具備兩個特性：它既是「目前位置的標示」，也是「可返回上層的捷徑」。換句話說，麵包屑並非取代主要的導覽選單，而是作為選單之外的一種補充性線索，特別適用於內容層級較深、或使用者需要頻繁往返於分類與內容頁之間的網站。
麵包屑的核心功能包含三項：告知使用者目前所處的網站位置、提供快速返回上層頁面的導覽捷徑，以及輔助搜尋引擎爬蟲理解網站的層級結構。從搜尋引擎優化（SEO）的角度來看，麵包屑可拆解為兩個獨立但可並存的層次。第一個是使用者看得見的「視覺導覽元件」，也就是以超連結組成的 HTML 路徑。第二個則是標記給搜尋引擎看的「結構化資料」，透過 BreadcrumbList Schema 告知 Google 這段路徑的層級關係。兩者在技術實作上各自獨立，但共同作用時能為使用者與搜尋引擎提供清晰的網站結構線索。
這兩個層次在實作上必須被清楚地區分。視覺導覽元件負責的是「人類可讀」的路徑，它影響使用者的操作感受與方向感；結構化資料負責的是「機器可讀」的層級描述，它協助搜尋引擎建立對網站的整體輪廓。兩者不必然同時存在，卻建議同時存在：一個頁面可以只有視覺麵包屑而沒有結構化資料，也可以只有結構化資料而沒有任何視覺路徑，但當兩者並行且內容一致時，才能讓不同類型的訪客、無論是真人還是爬蟲、都獲得一致的網站結構資訊。因此，在後續任何討論中，都應謹記這兩個層次的獨立性與互補性。
麵包屑的類型與 SEO 效益
根據網站架構與使用目的，麵包屑主要可分為三種類型：層級型、屬性型與路徑型。不同類型的麵包屑適用於不同情境，其中僅有特定類型適合用於 SEO 標記。正確選擇並實施麵包屑，有助於搜尋引擎理解網站內容的關聯性與深度，但並非直接影響排名的因素。
三種麵包屑類型怎麼選
選擇哪種麵包屑類型，取決於網站的內容組織方式與主要使用者導覽需求。層級型麵包屑反映的是網站預先設定的資訊架構，例如電子商務網站的「首頁 > 女性服飾 > 上衣 > 棉質T恤」。屬性型麵包屑則是根據內容的標籤或屬性動態生成，常見於商品篩選頁面，如「首頁 > 側邊欄篩選：顏色：紅色」。路徑型麵包屑又稱為歷史型，它完全依照使用者個人的點擊瀏覽順序呈現，例如「首頁 > 使用者點的頁面A > 使用者點的頁面C」。
從上述三種型態可以進一步區分它們的適用情境：層級型適合內容具有固定分類樹狀結構的網站，例如電子商務平臺的商品目錄、部落格的文章分類、或是企業官網的服務項目分層。屬性型適合內容本身沒有嚴格層級，但可透過多個面向篩選的網站，例如購物網站同時以顏色、尺寸、價格區間作為篩選維度，使用者在不同篩選組合之間切換時，麵包屑會隨之反映當下的篩選狀態。路徑型則較適合特殊應用流程，例如購物車結帳步驟、線上表單填寫流程，這類情境下的使用者行為偏向線性推進，路徑型麵包屑能讓使用者理解自己正處於流程中的哪一個階段。
判斷該採用何種類型時，可以先問兩個問題：第一，這個頁面在網站中是否具有唯一且固定的上層分類？若是，則層級型是自然選擇。第二，這個頁面的內容是否會因使用者的操作方式而改變其「位置」？例如透過篩選器組合出來的列表頁，其內容並非固定在單一分類之下，此時屬性型更能如實反映頁面的產生條件。至於路徑型，則需要謹慎評估、因為它與使用者的個人瀏覽紀錄綁定，無法提供一致性的網站結構線索，也就難以作為通用的導覽輔助工具。
層級型麵包屑為什麼最適合 SEO
在三種類型中，層級型麵包屑最適合用於 SEO 標記。原因在於它穩定地反映網站的分類架構，這正是搜尋引擎用以理解網站主題與內容深度的關鍵依據。屬性型麵包屑因內容動態變化，標記價值較低。路徑型麵包屑則不建議用於 SEO，因為 Google 官方結構化資料文件並未支援此類型，且每位使用者產生的路徑皆不同，可能導致大量重複或混亂的標記。Google 官方文件指出，正確標記的 BreadcrumbList 有助於搜尋結果顯示網站路徑，提升結果的可讀性，並可能讓使用者更清楚該連結與他們搜尋意圖的關聯程度。
「穩定」是層級型麵包屑的核心優勢。無論訪客透過哪一個入口進入，也無論他是否經過篩選器操作，層級型麵包屑顯示的內容都保持一致：同一件商品永遠顯示相同的分類路徑。這種一致性讓搜尋引擎在比對標記與頁面內容時，不會因使用者行為差異而產生矛盾。而屬性型麵包屑雖然能反映當下的篩選條件，但同一頁面可能因為不同篩選組合而有完全不同的路徑，搜尋引擎難以判斷哪一條路徑纔是該頁面的「正式位置」，因此標記價值較低。路徑型麵包屑則由於完全不可預測，Google 官方文件甚至未將其列為可支援的類型，不適合做任何形式的 SEO 標記。
選擇類型時應注意的綜合判斷原則
綜合上述比較，選擇麵包屑類型應該以「內容是否具有固定的分類歸屬」作為首要判斷條件。若內容被歸屬到明確且穩定的分類下，採用層級型是較好的策略。若內容本身就可能同時歸屬於多個分類，或必須仰賴多項屬性才能被完整描述，則可考慮屬性型，但必須接受它在 SEO 標記上的限制。路徑型則應限縮在少數流程型頁面，且在這些頁面中不應該加入 BreadcrumbList 結構化資料。這個判斷原則的核心在於：麵包屑的價值不只取決於它看起來像什麼，更取決於它在不同訪客與不同進入路徑下是否維持一致的語意。一致才能被理解，被理解纔有助於建立信賴，無論是對人類使用者還是對搜尋引擎爬蟲而言都是如此。
| 麵包屑類型 | 適用情境 | 是否建議用於 SEO |
|---|---|---|
| 層級型 | 網站有固定、清晰的分類樹狀結構（如電商、部落格分類） | 是，強烈建議 |
| 屬性型 | 內容具備多個可篩選標籤，路徑會根據篩選條件動態改變 | 否，因內容不固定 |
| 路徑型 | 強調使用者個人瀏覽歷程的特殊應用（如購物車流程） | 否，Google 官方不支援 |
BreadcrumbList Schema 結構化資料實作（JSON-LD）
BreadcrumbList Schema 是讓搜尋引擎理解麵包屑層級關係的結構化資料格式。Google 建議採用 JSON-LD 格式實作，因其易於撰寫與維護。實作時必須遵循特定的標籤結構，並確保標記內容與頁面實際顯示的可見麵包屑完全一致。
一個可直接複製的 JSON-LD 範例
以下是一個標準的三層級 BreadcrumbList JSON-LD 範例。每個層級對應一個 ListItem 物件，並依序設定 position、name 與 item 屬性。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "首頁",
"item": "https://www.example.com"
},
{
"@type": "ListItem",
"position": 2,
"name": "SEO 教學",
"item": "https://www.example.com/seo"
},
{
"@type": "ListItem",
"position": 3,
"name": "結構化資料指南",
"item": "https://www.example.com/seo/schema"
}
]
}
</script>
在此範例中，「@context」與「@type」是固定值。「itemListElement」是一個陣列，包含所有路徑層級。每個「ListItem」的「position」必須是從 1 開始的連續整數數字，「name」是該層級的顯示名稱，「item」則是該層級頁面的完整 URL。所有標記應放置於 HTML 文件的 <head> 或 <body> 區塊中，Google 可自行偵測。
這個範例展示了三層路徑的標記方式，但實際上 BreadcrumbList 的層級數不限制為三層。任何數量的 ListItem 都可以被放入 itemListElement 陣列中，只要從 1 開始依序編號、且每層都具備 name 與 item 即可。然而，實務上應遵循「每一層都必須是頁面上實際看得見的麵包屑其中之一」的原則，過度冗長的路徑或隱藏層級都不建議標記，因為這會讓搜尋引擎在比對標記與可見內容時產生疑慮。
position、name、item 屬性的判斷要點
在三種核心屬性中，「position」代表的是層級的順序，它必須是整數，而且必須從 1 開始連續遞增。第一個 ListItem 的 position 永遠是 1，通常對應首頁；第二個是 2，對應第一層分類；第三個是 3，對應第二層分類，依此類推。不可以跳號、不可以重複、也不可以反向排序。「name」是該層級顯示在頁面上的文字，它不必與頁面的 title 標籤完全相同，但必須與使用者實際看到的麵包屑文字一致。換句話說，如果頁面上顯示的是「SEO 教學」，標記中的 name 就應該寫「SEO 教學」，而不是寫成「SEO 教學指南」或其他變體。「item」則必須是該層級頁面的完整 URL，包含協議名稱（https://）與網域名稱，不可使用相對路徑。僅有最後一層（當前頁）的 item 可以省略，因為當前頁的 URL 可以由搜尋引擎自行判定；但若當前頁也有獨立的 URL，仍建議完整填寫。
外掛輸出與手動撰寫的選擇
若您的網站使用 WordPress，多數 SEO 外掛（如 Yoast SEO、Rank Math）在啟用麵包屑功能後，會自動為頁面生成 BreadcrumbList 結構化資料。對於不熟悉程式碼的管理者，這是較為便捷的選擇。然而，外掛的輸出品質可能因版本或設定而異。安裝並設定外掛後，務必使用驗證工具檢查輸出是否正確。若您使用自訂系統或追求完全控制，則可參照上述 JSON-LD 語法手動撰寫，並將程式碼嵌入各頁面模板中。選擇哪種方式取決於技術能力與維護需求，但無論如何，驗證步驟都不可或缺。
在抉擇外掛與手動撰寫時，可以從三個面向評估：一是「技術門檻」，外掛大幅降低撰寫與維護的難度，手動撰寫則要求熟悉 JSON-LD 語法與網站的模板結構。二是「控制彈性」，外掛的路徑生成邏輯通常與網站的分類設定綁定，較難針對特殊頁面逐一調整；手動撰寫則可以在每個模板中自由指定 path 的內容，特別適合需要高度客製化的網站。三是「更新風險」，外掛升級時可能改變輸出結構，若未即時檢查可能導致標記失效；手動撰寫的程式碼則完全掌握在自己手中，只要網站結構不變，標記就不會意外變動。綜合而言，外掛適合追求快速與便捷的站長，手動撰寫則適合對程式碼熟練且需要精準控制的高階使用者。
麵包屑 HTML 與無障礙最佳實踐
頁面上可見的麵包屑導覽元件，應使用具備語意性的 HTML 標籤與 WAI-ARIA 屬性來實作。這不僅是為了程式碼的整潔，更是為了確保使用螢幕閱讀器等輔助科技的使用者，也能清楚理解頁面結構與自身位置。BreadcrumbList 結構化資料服務於搜尋引擎，而正確的 HTML 結構則服務於人類使用者，兩者建議並行實作。
HTML 結構與無障礙屬性對照
正確的麵包屑 HTML 結構應包含以下關鍵元素：首先，使用 <nav> 標籤將整個導覽區域包裹起來，並加上 aria-label="breadcrumb" 屬性，向輔助科技明確宣告此區塊為麵包屑導覽。內部應使用 <ol>（有序清單）與 <li>（清單項目）標籤來組織路徑的每一個層級，因為路徑的順序具有意義。連結（<a>）用於指向上層頁面，而當前所在的頁面則不應包含連結。最重要的是，在當前頁面對應的 <li> 元素上，應標記 aria-current="page"，讓螢幕閱讀器使用者知道這是他們目前所在的頁面。
一個符合無障礙規範的範例結構如下：<nav aria-label="breadcrumb"> <ol> <li><a href="/">首頁</a></li> <li><a href="/seo">SEO 教學</a></li> <li aria-current="page">結構化資料指南</li> </ol> </nav>。根據 WAI-ARIA 實踐指南，麵包屑導覽通常不需要特別的鍵盤操作支援。這套 HTML 結構與 BreadcrumbList 結構化資料標記是兩套獨立的系統，但頁面上的可見路徑內容必須與結構化資料中標記的名稱及層級保持一致。
使用 <ol> 而非 <ul> 的理由在於：麵包屑的每一個項目之間的先後順序具有實質意義，首頁永遠在第一位，接著依序展開各層分類，最後纔是當前頁。有序清單能讓輔助科技的使用者知道這是一組有順序的項目，而不是可以任意排列的清單。相對地，無序清單僅表示「一羣相關項目」，無法傳達順序的概念，與麵包屑的語意不符。
無障礙屬性與當前頁面標示的實作細節
在實作無障礙屬性時，幾個細節值得特別注意。首先是 aria-label 的命名，它可以自由設定，但建議使用「breadcrumb」這個固定的英文名稱，因為這是最廣為輔助科技所認得的名稱；當然，若網站是繁體中文介面，也可以寫成「麵包屑導覽」，但一致性的考量下，多數無障礙規範仍建議保留「breadcrumb」作為標籤值。其次是 aria-current="page" 的位置，它必須放在代表當前頁面的 <li> 元素上，而不是放在該頁面的任何連結上；因為當前頁不應該有連結，所以這個屬性自然存在於該 <li> 本身。當螢幕閱讀器讀到這個項目時，會特別向使用者宣告「目前所在頁面」，使用者便能清楚知道自己正在讀取的內容位於網站路徑的最末端。
另一方面，並非所有麵包屑都需要為每個層級都加上連結。通常只有當前頁之前的上層頁面才需要加連結，當前頁本身不加連結是常見的做法，這樣可以避免使用者誤以為點擊當前頁會跳到其他位置。若網站有特殊需求，例如當前頁實際上也有另一個子頁面，則可以在視覺上保持無連結、同時在結構化資料中填入當前頁的 URL，讓搜尋引擎依然有所依據。整體而言，HTML 結構的目標是讓使用者「一看就知道自己在哪裡」，而結構化資料的目標則是讓搜尋引擎「一讀就知道這條路徑如何組成」，兩者各司其職，卻必須分享相同的路徑名稱與順序。
BreadcrumbList 常見設定錯誤與驗證方式
完成 BreadcrumbList 結構化資料的實作後，必須進行驗證以確保標記正確無誤，能被 Google 正確解讀。Google 提供了免費的 Rich Results Test 工具進行即時檢測，並可透過 Search Console 監控長期狀態。以下是驗證流程與最常見的錯誤類型。
Rich Results Test 驗證操作步驟
- 開啟 Google 的 Rich Results Test 工具頁面。
- 在「檢查網址」分頁貼上您要測試的頁面完整網址，點擊「執行測試」。或者，在「程式碼」分頁直接貼上您的 BreadcrumbList JSON-LD 程式碼進行測試。
- 等待數十秒後，工具會顯示偵測結果。在「結構化資料」區塊中，找到類型為「BreadcrumbList」的項目。
- 檢查是否有任何錯誤或警告。錯誤會阻止結構化資料被視為有效；警告則不影響有效性，但可能表示有改善空間。
- 若發現錯誤，根據錯誤訊息修正您的程式碼或外掛設定，然後重新執行測試，直到通過為止。
透過 Rich Results Test 的檢測結果，您可以確認三件事：第一，麵包屑結構化資料是否有被成功偵測到；第二，標記中是否有任何違反 Google 規範的欄位或數值；第三，標記的路徑順序是否如預期且與頁面一致。測試工具並不會替您判斷「這個麵包屑是否適合出現在這個頁面」這類主觀問題，它只負責比對結構化資料的格式是否符合 Schema.org 與 Google 的規範。因此，即使通過測試，仍應自行檢查所使用的麵包屑類型與路徑名稱是否合理。
通過 Rich Results Test 後，建議定期查閱 Google Search Console 的「增強功能」報告。若 BreadcrumbList 被正確實作且偵測到，這裡會出現對應的報表，並顯示頁面是否有任何長期問題。這有助於監控外掛更新或網站變更是否意外破壞了原有的結構化資料。
常見錯誤的逐一判斷方法
實務上最常見的錯誤包括：position 欄位填入了字串（例如 "1"）而非數字（1）；ListItem 缺少必填的 name 欄位；item 欄位使用了相對路徑（如 /seo）而非完整的 URL（https://www.example.com/seo）；以及標記的路徑與頁面上實際可見的麵包屑內容不一致。Google 會比對標記與頁面內容，不一致的標記可能被忽略。
在上述錯誤中，每一項都有明確的判斷與修正方法。position 欄位的錯誤，通常發生在撰寫者不熟悉 JSON-LD 的資料型別時、以雙引號包裹數字，例如 "1"，會被視為字串，正確的唯一寫法是不加引號的 1。ListItem 缺少 name，則多半是因為外掛設定不完整或手動撰寫時遺漏，修正方式是在每個 ListItem 物件中補上對應的 name 字串。關於 item 欄位，常見的疑惑在於「當前頁是否也需要 item」，根據原稿及 Google 慣例，僅最後一層可以省略 item，但其餘每一層都必須提供完整的 URL；若全部層級都填寫完整也沒有問題。最後，路徑不一致的問題最容易被忽略，卻也是最關鍵的，因為搜尋引擎的目標是提供與使用者所見相符的資訊，若標記路徑與視覺路徑不同，Google 可能判定標記為不可信而予以忽略。
透過 Search Console 進行長期維護
短期驗證可以依靠 Rich Results Test，而長期監控則必須依賴 Google Search Console。在 Search Console 的「增強功能」報表中，若網站上的 BreadcrumbList 被正確實作，系統會收集並呈現相關資料，包括何時被偵測、是否存在錯誤、以及有多少頁面受到影響。這對於追蹤外掛更新、模板修改或大規模內容變更後的影響尤其重要。若某次改版後，原本正常的麵包屑標記突然出現大量錯誤，您可以在 Search Console 中即時看到，並迅速針對問題頁面進行修正。
維護工作應建立在「持續檢查」的基礎上。即使網站當前沒有任何錯誤，也不代表永遠不會出錯；外掛升級、主題更新、甚至是文章分類調整，都可能讓原本的麵包屑路徑產生變化。若結構化資料與頁面內容不一致，Google 不會主動通知您，而是默默地忽略標記。因此，建議每隔一段時間就重新透過 Rich Results Test 抽測幾個代表性的頁面，並隨時留意 Search Console 上的狀態變化，以確保這項技術 SEO 的基礎設施始終保持在正確運作的狀態。
麪包屑和 BreadcrumbList 有什麼不同？
Breadcrumb（麵包屑）是頁面上可見的導覽路徑，例如「首頁 > SEO 教學 > 文章頁」，主要服務於使用者導覽。BreadcrumbList 則是一種結構化資料格式，用於讓搜尋引擎理解這段路徑的層級關係。兩者是獨立的技術，建議同時實施：一個用於改善使用者體驗，另一個用於協助搜尋引擎理解網站結構。
BreadcrumbList Schema 一定要用 JSON-LD 格式嗎？
並非強制，但 Google 明確建議使用 JSON-LD 格式實作 BreadcrumbList。JSON-LD 易於撰寫與維護，且不受頁面 HTML 結構影響，Google 官方文件將其列為推薦的標記方式。相較於其他格式，JSON-LD 能獨立於視覺元素之外，清楚定義路徑中每個層級的順序與 URL，是目前實務上最穩定且支援度最高的做法。
何謂層級型麵包屑，為何它最適合用於 SEO？
層級型麵包屑是依照網站預先設定的資訊架構，以固定分類樹狀結構顯示路徑，例如「首頁 > 女性服飾 > 上衣 > 棉質T恤」。它最適合用於 SEO 的原因在於：路徑穩定一致，不受使用者進入方式或篩選操作影響，能清楚反映網站的主題層級，讓搜尋引擎比對標記與頁面內容時不會產生矛盾，因而被 Google 強烈建議採用。
在 JSON-LD 標記中，position、name、item 各代表什麼？
position 代表層級順序，必須是從 1 開始的連續整數，依序對應首頁、第一層分類、第二層分類等。name 是該層級顯示在頁面上的文字，需與使用者實際看到的麵包屑文字一致。item 則是該層級頁面的完整 URL，包含 https:// 協議和網域名稱，不可使用相對路徑；僅最後一層（當前頁）的 item 可省略。
麵包屑的 HTML 結構應如何使用無障礙屬性？
應使用 <nav> 標籤包裹整個導覽區域，並加上 aria-label="breadcrumb" 屬性。內部以 <ol> 與 <li> 組織路徑的各層級，因為順序有其意義。連結用於指向上層頁面，當前頁不加連結。同時，在當前頁對應的 <li> 上標記 aria-current="page"，讓螢幕閱讀器使用者明確得知目前所在頁面。
如何驗證 BreadcrumbList 結構化資料是否正確？
可以使用 Google 提供的 Rich Results Test 工具進行即時檢測。操作方法為：貼上欲測試的頁面 URL 或直接貼上 BreadcrumbList 的 JSON-LD 程式碼，執行測試後，工具會顯示偵測結果，並列出任何錯誤或警告。錯誤會阻止結構化資料被視為有效，修正後需重新測試直到通過。通過後，建議定期透過 Google Search Console 的「增強功能」報告監控長期狀態。
BreadcrumbList 實作最常見的錯誤有哪些？
最常見的錯誤包括：position 欄位填入字串（如 "1"）而非數字（1）；ListItem 缺少必填的 name 欄位；item 使用了相對路徑（如 /seo）而非完整 URL（https://www.example.com/seo）；以及標記的路徑與頁面上實際可見的麵包屑內容不一致。這些錯誤都可能導致標記無效或遭 Google 忽略，需逐一檢查修正。