網站資訊架構怎麼規劃？導覽列層級、URL 結構與麵包屑的實作

資訊架構不只是選單怎麼排，它直接決定搜尋引擎能不能找到你的文章。這篇依 Google Search Central 與 schema.org 官方文件（查核日 2026 年 8 月 6 日）拆解導覽列層級與「三次點擊」迷思的真相、URL 結構與中文網址的取捨、分類與標籤何時該 noindex、麵包屑 BreadcrumbList 的必填欄位與實作、分頁與無限捲動的爬取限制，以及重整架構時不掉排名的遷移順序，最後附上內容站與接案作品集站的架構差異對照。

淺色亞麻布上以河石堆成三層、由大到小的石堆，比喻網站資訊架構由上而下的層級關係

我第一次真正意識到資訊架構不是設計師的事，是在一個已經寫了三百多篇文章的部落格上。那個站每篇文章都認真寫、每篇都配圖、每篇都填了 meta description，可是後台一看，超過一半的文章從來沒有從首頁以外的任何頁面被連到過。它們躺在資料庫裡，像倉庫深處沒貼標籤的箱子。

內容目錄

更難堪的是標籤頁。那個站累積了四百多個標籤，其中三百個以上只掛著一篇文章。每一個標籤都自動生成一個可以被索引的網址，每一個網址上面只有一則摘要、一張縮圖、一堆側邊欄。搜尋引擎爬進去、看一眼、判斷這頁沒東西，然後帶著這個印象離開。

那次之後我養成一個習慣：在動任何一篇文章之前，先把整個站的結構畫出來。哪些是樞紐、哪些是支線、哪些頁面該讓搜尋引擎看、哪些該擋掉、網址長什麼樣子、麵包屑指向哪裡。這篇文章就是把那套流程整理成可以照做的順序，所有規則都回到 Google Search Central 與 schema.org 的官方文件，查核日是 2026 年 8 月 6 日。

這篇會用比較多篇幅講「為什麼」，因為資訊架構最貴的錯誤不是做錯，是做了一半又改回來——每改一次網址就要建一次轉址，每建一次轉址就多一層債。與其快，不如一次想清楚。

📌 本文重點

  • Google 的官方說法是「主要透過已爬取頁面上的連結來找到新頁面」，所以資訊架構直接決定哪些內容會被發現——它是爬取問題，不只是版面問題。
  • 中文站最常見的架構災難是標籤浮濫：一個標籤一篇文，生出幾百個薄頁。判準是「這個分類頁本身值不值得被搜尋」，不值得就用 noindex，而且不能同時用 robots.txt 擋（擋了就看不到 noindex）。
  • Google 的 URL 文件對中文站最常用到的四條是：用可讀的字、用受眾語言、非 ASCII 字元要百分比編碼、用連字號而非底線；另外還提醒網址區分大小寫。但它從頭到尾沒有規定目錄要幾層。
  • 「三次點擊」是 2003 年就被實測推翻的迷思：44 位使用者、620 個任務、8,000 多次點擊的資料裡，找不到點擊數與成功率的關聯。
  • 麵包屑的 BreadcrumbList 最後一項可以省略 item；Google 會改用該頁本身的網址。改架構時的順序是先做網址對照表、再改內部連結、再上 301，而且 301 要「至少維持一年」。

一、資訊架構為什麼是 SEO 問題，不只是設計問題

舊橡木桌上以麻繩打結交織成的網，交叉處都打了結，比喻站內文章之間必須真的互相連結成網而非各自孤立

很多人把資訊架構理解成「選單怎麼排」。選單當然是它的一部分，但如果只從版面看，你會漏掉最關鍵的一段：搜尋引擎根本不是用眼睛看你的網站的。

Google 在《搜尋引擎最佳化 (SEO) 入門指南》裡寫得很直白：「Google primarily finds pages through links from other pages it already crawled.」（Google 主要透過它已經爬過的頁面上的連結來找到新頁面，查核日 2026-08-06，該頁標示最後更新 2025-12-10 UTC。）這句話翻成白話就是：一個頁面如果沒有任何被爬過的頁面連到它，它在搜尋引擎眼中幾乎不存在。

這就是為什麼架構問題會直接變成收錄問題。你可以把一篇文章寫成全站最好的一篇，但只要它掛在一個沒人連進去的標籤頁底下，它就只能靠 sitemap 被動被發現。

連結必須是搜尋引擎「跟得動」的形式

再往下一層，連結本身還有格式門檻。Google 的連結最佳做法文件（最後更新 2025-12-10 UTC）寫著：「Generally, Google can only crawl your link if it’s an <a> HTML element (also known as anchor element) with an href attribute.」——一般來說，只有帶 href 屬性的 <a> 元素才爬得到。原文開頭的「Generally」是官方留的餘地，別把它讀成一○○％的絕對規則，但更不該反過來拿它當「其他寫法也沒關係」的藉口。

同一份文件把三種寫法歸在「Not recommended (but Google may still attempt to parse this)」這一欄——缺 href 的 <a routerLink="...">、用錯元素的 <span href="...">、以及靠 JavaScript 觸發的 <a onclick="goto('...')">。注意括號裡那句：Google「可能還是會試著解析」，但這是碰運氣，不是保證。這幾種在現代前端框架和某些頁面編輯器裡都很常見，別因為抽查到一頁被收錄了就以為沒問題。

反過來也有一個常被誤會的點：官方明講「Links are also crawlable when you use JavaScript to insert them into a page dynamically as long as it uses the HTML markup shown above.」——用 JavaScript 動態插入連結本身沒問題，只要插進去的是標準的 <a href>。問題出在「用 JavaScript 取代 href」，不是「用了 JavaScript」。

我實際踩過的版本是：某個佈景主題的「漢堡選單」在手機版展開後是一堆綁了事件處理器的 <div>，桌機版才輸出真的 <a href>。在行動優先索引的前提下，那個選單就是不合格。土法檢查：把頁面原始碼下載下來，搜尋你期待的網址字串在不在裡面。找不到也先別下結論——依前一段的官方說法，JavaScript 插入的標準 <a href> 是算數的，所以原始碼裡沒有只代表「它是渲染後才出現的」。要確定 Google 到底看到什麼，得用 Search Console 的網址檢查工具看已算繪的 HTML，官方在同一份文件裡也是這樣建議的。

錨文字不只是給人看的

Google 同一份文件對錨文字的說法是：「The better your anchor text, the easier it is for people to navigate your site and for Google to understand what the page you’re linking to is about.」並且明確要避開「click here」「read more」這類泛用字眼，同時警告不要在錨文字裡塞關鍵字（那屬於垃圾內容政策的範圍）。

換成中文站的實務就是：不要寫「詳見這裡」，要寫「WordPress 的麵包屑設定」。錨文字是你唯一能主動告訴搜尋引擎「那一頁在講什麼」的欄位，浪費掉很可惜。這也是為什麼我在寫 SEO 的使用者意圖與內容基礎觀念那類入門文章時，會刻意把每一條站內連結的錨文字寫成完整的名詞片語。

爬取預算：多大的站才需要在意

「爬取預算」這個詞被濫用得很嚴重，小站被嚇得亂改 robots.txt。Google 這份文件現行的標題是《Optimize your crawl budget》（它已經從 Search Central 移到 Google 的爬取基礎架構文件區，舊網址會自動轉過去，最後更新 2026-07-22 UTC），開頭第一段就寫明適用對象。

站況 Google 文件的描述 是否需要主動管理爬取預算
大型網站 超過一百萬個獨特頁面，且內容每週變動 需要
中大型網站 超過一萬個獨特頁面，且內容每天快速變動 需要
Search Console 有大量「已找到 – 目前尚未建立索引」 文件把此列為需要檢視的訊號 需要檢視
一般個人部落格、接案作品集站 不在上述範圍 通常不需要

資料來源：Google《Optimize your crawl budget》（Google 爬取基礎架構文件），查核日 2026-08-06。要特別注意文件緊接在這兩條後面的但書：「The numbers given here are a rough estimate to help you classify your site. These are not exact thresholds.」——這些數字只是幫你分類的粗略估計，不是精確門檻，所以不要拿「我只有 9,999 頁」當免死金牌。

所以如果你的站只有兩百篇文章，「爬取預算不夠」幾乎不會是你排名不好的原因。但這不代表架構不重要——只是重點不在「省爬取次數」，而在「有沒有被發現」和「權重有沒有流到該去的地方」。

不過這份文件裡有一條對小站也成立的原則：把重複內容整併起來，讓爬取集中在獨特的內容上。以及避免長串的轉址鏈。這兩點跟站大小無關，只跟你有沒有亂改網址有關。

目錄結構的官方說法比你想的保守

Google 的入門指南對目錄只講了一件事：「using directories (or folders) to group similar topics can help Google learn how often the URLs in individual directories change.」——用目錄把相似主題分組，可以幫 Google 學會各個目錄的更新頻率。

而且這段話前面還掛著一個規模前提，抄的人幾乎都會漏掉：「If you have more than a few thousand URLs on your site, how you organize your content may have effects on how Google crawls and indexes your site.」——網址數超過幾千個，內容怎麼組織才「可能」影響 Google 的爬取與索引。換句話說，一個兩百篇文章的部落格為了目錄結構糾結，官方根本沒說那會有差。

注意它給的理由是「更新頻率」，不是「權重傳遞」。官方文件並沒有承諾「放在淺一層的目錄排名會比較好」。這是很多中文 SEO 教學會加油添醋的地方，我建議在自己的站上不要拿這個當決策依據。

二、動手之前，先把現況畫出來

資訊架構最容易失敗的原因不是不會設計，是在不知道現在長什麼樣子的狀態下就開始改。我固定用三個來源湊出一張現況表。

第一個來源是 sitemap。Google 的 sitemap 說明文件（最後更新 2025-12-10 UTC）是分成「可能需要」與「可能不需要」兩張清單來寫的。可能需要的是：網站很大、網站很新且外部連結很少、有大量影音圖片或出現在 Google 新聞。可能不需要的是：網站「小」——原文的定義是「about 500 pages or fewer on your site」、站內連結串得很完整、以及沒有想被搜尋到的影音與新聞內容。要注意它算的分母：「Only pages that you think need to be in search results count toward this total.」——只有你認為需要出現在搜尋結果裡的頁面才算數，不是資料庫裡所有網址。

同一份文件也把話講清楚：sitemap 幫助發現，但「it doesn’t guarantee that all the items in your sitemap will be crawled and indexed」——放進 sitemap 不保證會被爬取與索引。所以 sitemap 是盤點工具，不是索引開關。

第二個來源是 Search Console 的頁面索引報表。它會告訴你哪些網址被排除、排除的理由是什麼。如果你還沒把這個工具接起來，可以先看 Google Search Console 從驗證網站到讀懂報表的完整教學，把驗證跟資料來源先搞定，後面所有判斷才有依據。

第三個來源是自己爬一次前台。我用的做法是從首頁開始，只抓每頁主要內容區塊裡的 <a href>，記錄「誰連到誰」。重點是要抓前台實際輸出的 HTML，不是抓資料庫裡的文章內容欄位——因為側邊欄、頁尾、相關文章模組產生的連結不在文章內容裡，而版面外掛產生的內容也不一定在資料庫的原始欄位裡。

現況表要有的四個欄位

把資料湊起來之後，我會做一張表，每一列一個網址，欄位是：網址、頁面類型（文章／分類／標籤／固定頁）、被幾個站內頁面連到、以及這一頁想承接的搜尋意圖。

被連入次數是 0 的那些，就是孤兒頁；意圖欄位填不出來的那些，就是應該合併或刪掉的頁。這張表做完，你大概就知道要改什麼了，而且會比任何「架構最佳實務清單」更貼近你的站。

另外提醒一個實務細節：有些頁面編輯器（例如 Elementor 這類）的內容不會完整出現在標準的內容欄位裡，用資料庫欄位去算內部連結會漏掉一大半，導致你誤判某些頁面是孤兒頁。這個坑我踩過，解法就是回到前台實爬。

盤點會冒出來的四種頁面

表做完之後，所有網址通常會自動分成四堆，處置方式完全不同。

第一堆是「有意圖、有入鏈」的健康頁。這些不用動，它們是你的資產。你要做的只是確認它們有沒有被放進對的樞紐底下。

第二堆是「有意圖、沒入鏈」的孤兒頁。這是最划算的一堆，因為內容已經寫好了，你只要補幾條內部連結就可能有效果，成本幾乎是零。我每次接手一個站，都是先把這堆處理掉。

第三堆是「沒意圖、有入鏈」的頁面。典型是那些為了衝數量寫出來的湊數文，或是早年跟風的時事文。它們吃掉了內部連結的額度，卻接不到任何搜尋流量。處理方式是合併進相關的主題文，或直接讓它們退場。

第四堆是「沒意圖、沒入鏈」的頁面。這堆通常是系統自動產生的：日期封存、作者頁、只有一篇文的標籤頁、附件頁。這些是 noindex 的主要對象。

把四堆分完，你會發現「要新增內容」其實排在最後——先把既有的東西接好，往往比再寫十篇新的更有效。

三、分類與標籤：中文站最常見的薄頁災難

石台上左邊三支高蜂蠟蠟燭、右邊散落許多短燭頭，比喻少數有內容的分類頁與大量只掛一篇文章的薄標籤頁之間的落差

先把 WordPress 的定義講清楚，因為很多爭論其實是名詞沒對齊。WordPress 官方文件《Taxonomies》說：「By default, a standard post will have two taxonomy types called Categories and Tags which are a handy way of ensuring related content on your website is easy for visitors to find.」——分類與標籤都是 WordPress 內建的分類法（taxonomy），用途是讓相關內容容易被訪客找到。（兩者的差別在於分類有層級、標籤沒有；這一點那一頁沒有寫，是 WordPress 的既有行為，不要當成官方原文引用。）

關鍵是：這兩種分類法都會自動生成可以被索引的封存頁。你每建一個標籤，就等於在網站上多開一個網址。這件事本身沒有錯，錯在多數人建標籤的時候，腦袋想的是「幫我自己整理文章」，而不是「這一頁值不值得出現在搜尋結果裡」。

判準只有一條：這一頁本身值不值得被搜尋

我用的判準很簡單，而且刻意跟「內容管理方便不方便」脫鉤：如果有人真的會在 Google 搜尋這個詞、而且他要的是一份清單而不是單篇文章，這個分類法頁面就值得被索引；否則就不值得。

舉例來說，「WordPress 佈景主題」這種詞，使用者要的常常就是一份清單，所以以它為名的分類頁有存在價值。但「2024」「心得」「筆記」這種標籤，沒有人會搜、頁面上也只有一兩篇文章，它存在的唯一功能是幫你自己找檔案。

情境 用分類還是標籤 封存頁是否開放索引 理由
網站的主要主題支柱，預期會持續累積 10 篇以上 分類（可有子分類） 開放，並手動寫分類描述 清單型意圖存在，頁面有實質內容
跨分類的橫向主題，例如「新手入門」 標籤 視文章數而定，少於 5 篇建議 noindex 文章太少的封存頁接近空頁
年份、月份、心情、隨手備註 標籤或乾脆不建 noindex 沒有搜尋需求，只會稀釋爬取
作者頁（單人網站） 不適用 noindex 內容與首頁或部落格列表高度重複
日期封存（年／月） 不適用 noindex 或直接關閉 與分類列表重複，無獨立搜尋意圖

此表為依 Google 索引控制文件所做的實務判斷，不是 Google 的官方分級；索引控制方式的依據見下段。

noindex 要這樣下，而且千萬別跟 robots.txt 混用

Google 的《Block Search indexing with noindex》文件（最後更新 2025-12-10 UTC）給的兩種寫法是 meta 標籤與 HTTP 標頭：

<meta name="robots" content="noindex">

或只針對 Google：

<meta name="googlebot" content="noindex">

非 HTML 資源（例如 PDF）則用 HTTP 回應標頭 X-Robots-Tag: noindex。文件對效果的描述是：「When Googlebot crawls that page and extracts the tag or header, Google will drop that page entirely from Google Search results, regardless of whether other sites link to it.」

接下來這一句是全篇最容易被忽略、後果又最嚴重的一句：「For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler.」——要讓 noindex 生效，那個頁面不能被 robots.txt 擋住。

邏輯很直覺但很多人想反了：robots.txt 擋的是「爬取」，noindex 是寫在頁面裡的指示。你把頁面擋掉，爬蟲根本進不去，也就永遠讀不到那個 noindex。結果就是那頁繼續留在索引裡，只是沒有摘要。

Google 的 robots.txt 說明文件（最後更新 2025-12-10 UTC）也把這件事寫成一句警告：「it is not a mechanism for keeping a web page out of Google.」——robots.txt 不是把網頁排除在 Google 之外的手段。要真的排除，用密碼保護、noindex，或把頁面移除。

實務上我在 WordPress 站的做法是：分類與標籤封存頁的索引開關交給 SEO 外掛統一管理（Rank Math 與 Yoast 都有這一區的設定），robots.txt 保持極簡，只擋掉真的不想被爬的系統路徑。如果你正在盤點站上的外掛職責，我把網站精簡到 11 支外掛的取捨清單裡有寫我怎麼決定哪些功能該由誰負責，索引控制就是我堅持不重複裝第二套的功能之一。

薄頁不是罪，重複才是

還有一個常被誤解的點：標籤頁本身不會「被懲罰」。真正的傷害是它們大量存在時，會產生一堆彼此高度相似、又跟分類頁重複的網址。Google 的爬取預算文件在最佳做法的第一項「管理你的網址清單」（Manage your URL inventory）底下，第一條子項就是「整併重複內容」，原文的理由是「Eliminate duplicate content to focus crawling on unique content rather than unique URLs.」——讓爬取集中在獨特的內容，而不是獨特的網址。

換句話說，處理標籤浮濫的正確心態不是「怕被罰」，而是「不要讓自己的爬取和內部連結權重被稀釋」。這個差別會影響你的做法：不是全部刪光，而是留下有意圖的、關掉沒意圖的。

四、URL 結構：官方到底說了什麼、沒說什麼

網址是資訊架構裡最不可逆的部分——改了就要轉址，轉址就是債。所以我把 Google 的原文抄下來，只照它說的做，其他一律當作偏好而不是規則。

Google《URL structure best practices for Google Search》（最後更新 2025-12-10 UTC）的核心建議是這幾條：

  • 「When possible, use readable words rather than long ID numbers in your URLs.」——可以的話，用可讀的字，不要用長串 ID 數字。
  • 「Use words in your audience’s language in the URL (and, if applicable, transliterated words).」——用受眾的語言，必要時可用音譯。
  • 非 ASCII 範圍的字元應該做百分比編碼（percent encoding）。
  • 「Specifically, we recommend using hyphens (-) instead of underscores (_) to separate words in your URLs」——用連字號而不是底線分隔字詞。

先講一句誠實話：這四條是我認為對中文站最常用到的，不是這份文件的全部。同一節（Make it easy to understand your URL structure）其實列了七條，另外三條是「參數用得越少越好」、「網址是區分大小寫的」、以及多地區網站的網址安排；這一節前面還有一整節「Requirements for a crawlable URL structure」，要求遵循 IETF STD 66、不要用網址片段（#）改變頁面內容、參數編碼要統一。

其中「Be aware that URLs are case sensitive」在 WordPress 上最容易無聲出事——手動貼連結時大小寫寫錯，就等於幫同一篇文章多開一個網址。這條沒有列進上面四條，不代表它比較不重要。

值得注意的是它「沒說」的部分：這份文件沒有規定目錄要幾層、沒有規定網址要幾個字元、也沒有給「淺層比深層好」的結論。它只說要建立簡單的網址結構、把內容用對人類最好理解的方式組織起來。查核日 2026-08-06，這是現行版本的內容。

中文網址的取捨：可讀性 vs 分享時的樣子

這是繁中站最實際的難題。Google 說「用受眾的語言」，那就該用中文；但同一份文件又說非 ASCII 字元要百分比編碼。這兩件事同時成立的結果是：網址列裡是漂亮的中文，複製出去貼到別人的訊息框裡，就變成一長串 %e7%b6%b2%e7%ab%99。

我自己這個站就是活生生的例子。文章網址是中文 slug，編碼之後單一網址常常超過 200 個字元。好處是使用者在搜尋結果裡看到麵包屑路徑時，看到的是中文；壞處是在 Line、Threads 這類地方分享時，那串編碼會蓋掉整個訊息的視覺重心。

slug 寫法 優點 缺點 適合的站
中文 slug（如 /wordpress-備份策略/） 符合「用受眾語言」，搜尋結果的路徑顯示為中文 複製後變成百分比編碼長字串；部分舊系統處理會出錯 讀者幾乎都是中文使用者、且很少手動分享網址的內容站
英文／拼音 slug（如 /wordpress-backup-strategy/） 短、乾淨、任何地方貼上都可讀 對中文讀者沒有語意提示 接案作品集、對外提案要貼網址的站
中英混用（品牌詞用英文、概念詞用中文） 兼顧兩者 命名規則要自己維護，容易走鐘 已有命名規範、且只有一兩人在發文的站

編碼行為依 Google URL 結構文件與 RFC 3986 的百分比編碼規則，查核日 2026-08-06；優缺點欄為實務判斷。

我的建議是：如果這個網址的主要用途是被搜尋到，用中文；如果它的主要用途是被你貼給客戶看，用英文。接案者的作品集頁面幾乎都屬於後者，這一點我在 接案作品集網站的實作流程裡也提過：作品頁的網址是要貼進提案信裡的，可讀性的價值遠高於關鍵字。

要不要含分類前綴？先看 WordPress 的三個限制

「文章網址要不要帶分類目錄」是永遠吵不完的題目。與其吵，不如先認清 WordPress 官方文件《Customize permalinks》（最後更新 2025-06-28）寫明的三個技術限制：

限制一：結構標籤必須以 %post_id% 或 %postname% 結尾。官方原文是「End your structure with either %post_id% or %postname% so that WordPress can target an individual post for every permalink.」這是為了讓每篇文章都能被唯一定位。

限制二：一篇文章掛多個分類時，網址裡只會出現其中一個，而且是按字母順序決定的。官方原文：「When you assign multiple categories to a post, only one can show up in the permalink. Which category gets displayed in the permalink is determined alphabetically.」想自己指定就得靠外掛。

限制三：分類與標籤的前綴（category base／tag base）可以改名，但拿不掉。官方原文：「The default values for Category base and Tag base are category and tag. You can change them, but you can’t remove them from the URLs altogether.」

順帶一提，很多中文教學會引用一條「網址結構開頭放 %postname% 或 %category% 會有效能問題」的警告。我在 2026-08-06 查核現行版本的官方文件時，這段警告已經不在頁面上了。所以我不會把它寫成事實，也建議你不要拿舊 Codex 時代的說法當決策依據。

那到底要不要帶分類？

把限制看完之後，決策其實很單純。帶分類前綴的好處是網址本身表達了層級，搜尋結果裡的路徑顯示也比較有脈絡；壞處是文章一旦換分類，網址就變了，而且多分類的情況你控制不了顯示哪一個。

我的判準是：如果你的分類體系已經穩定超過半年、而且每篇文章只掛一個分類，就可以帶；只要有任何一個條件不成立，就用 /%postname%/ 這種扁平結構。因為分類調整的機率遠高於你想像，而每次調整都要建 301。

如果你的站還在起步階段、分類體系都還沒定，那更該用扁平結構。這一點和 網站架設新手該先設定好的幾件事裡講的思路一致：先把不可逆的部分固定下來，可逆的部分留給以後調。

網址一旦改了，Google 怎麼認

Google 的《Redirects and Google Search》文件（最後更新 2026-04-14 UTC）先把轉址分成「永久」與「暫時」兩大類，再按「Google 能正確解讀的機率」由高到低列出實作方式：伺服器端轉址最高，接著是 meta refresh 與其 HTTP 等價寫法，然後是 JavaScript 轉址（官方註明「Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.」），最後是 crypto redirect——其實就是在舊頁面放一條「我們搬家了」的連結加一句說明，官方自己形容它「like the Loch Ness monster, its existence may be disputed」，並要求「不到最後關頭不要用」。永久轉址是 HTTP 301 與 308，暫時轉址是 302、303、307。

兩者在正規化上的待遇完全不同。文件寫：永久轉址時「the indexing pipeline uses the redirect as a signal that the redirect target should be canonical」；暫時轉址時「Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal」。

白話：換網址一定要用 301（或 308），用 302 等於告訴 Google「舊網址才是本尊」。這個錯誤在 WordPress 上很常見，因為某些外掛的預設值是 302。

至於 rel="canonical"，Google 的《Consolidate duplicate URLs》文件（最後更新 2026-07-10 UTC）把訊號強度排成：轉址是「a strong signal」、rel="canonical" 是「a strong signal」、放進 sitemap 是「a weak signal」。而且它一律用「signal」這個詞，不是指令——意思是 Google 保留最終判斷權，你指定的 canonical 不一定被採納。

五、導覽列層級與「三次點擊」的真相

「任何頁面都要能在三次點擊內到達」這句話流傳了二十幾年，強到很多人以為它是 Google 的規定。它不是。Google 的官方文件裡沒有任何一處規定點擊深度上限，這一點我在查核入門指南與 URL 結構文件時都確認過。

更有意思的是，這條規則在 2003 年就被實測資料推翻了。使用者體驗研究者 Joshua Porter 在 2003 年 4 月 16 日發表的〈Testing the Three-Click Rule〉分析了 44 位使用者、620 個任務、超過 8,000 次點擊的資料。

結論相當直接：「Hardly anybody gave up after three clicks」（幾乎沒有人在三次點擊後放棄），有些人「甚至持續點到 25 次」。而且「there wasn’t any more likelihood of a user quitting after three clicks than after 12 clicks」——第三次點擊後放棄的機率，並沒有比第十二次點擊後更高。

滿意度資料也不支持這條規則。研究顯示不同任務長度下的不滿意比例落在 46% 到 61% 之間，變化很小。Porter 的結論是：「Fewer clicks do not make more satisfied users.」（更少的點擊不會讓使用者更滿意。）

那該在意什麼

把「三次點擊」丟掉之後，真正該檢查的是三件事，而且每一件都有官方依據。

第一，每一頁是不是至少有一條可爬取的路徑通到它。依據是入門指南那句「Google 主要透過連結找到頁面」。零入鏈的頁面就是問題，不管它在第二層還是第八層。

第二，導覽的連結是不是真的 <a href>。依據是連結最佳做法文件。用 div 加事件處理器模擬的按鈕、只有 onclick 沒有 href 的下拉選單，都不合格；但如果選單是用 JavaScript 把標準的 <a href> 插進去，官方說那是可以爬取的。

第三，使用者在任何一頁上，知不知道自己在哪裡、上一層是什麼。這一點沒有硬性 SEO 依據，但它是麵包屑存在的理由，下一節會講。

主選單該放幾項

這題沒有官方答案，我也查不到 Google 有任何關於選單項目數量的建議，所以我不會給你一個看起來精確的數字。

我實際的做法是反過來推：主選單只放「有能力接住搜尋流量、而且我打算長期經營」的樞紐頁，其他一律往下放。如果一個項目連續三個月沒有任何內容更新、也沒有任何自然流量，它就不該佔用主選單的位置。

這個判斷需要資料支撐，所以我會固定看 Search Console 的頁面層級數據，而不是憑感覺。搭配 關鍵字研究工具的免費與付費搭配方式看一下每個樞紐主題的實際需求量，會比純看流量更早發現某個分類其實根本沒有市場。

六、麵包屑與 BreadcrumbList：規格與實作

麵包屑是資訊架構唯一一個「同時給人看、給機器看、還會出現在搜尋結果裡」的元件，值得花時間做對。

Google 的麵包屑結構化資料文件（最後更新 2025-12-10 UTC）對用途的說明是：「Google Search uses breadcrumb markup in the body of a web page to categorize the information from the page in search results.」——Google 用頁面主體裡的麵包屑標記，來把該頁的資訊在搜尋結果中歸類。

而在 Google 支援的結構化資料清單（最後更新 2026-06-15 UTC）裡，Breadcrumb 的功能描述是「Navigation that indicates the page’s position in the site hierarchy」——顯示該頁在網站層級中的位置。

規格：必填欄位與那個常被漏掉的例外

schema.org 對 BreadcrumbList 的定義是：「A BreadcrumbList is an ItemList consisting of a chain of linked Web pages, typically described using at least their URL and their name, and typically ending with the current page.」它繼承自 Thing > Intangible > ItemList。

Google 那邊還有一條數量下限，很多教學會漏掉：「define a BreadcrumbList that contains at least two ListItems」——一條麵包屑路徑至少要有兩個 ListItem。只有一項的麵包屑不符合規格。

Google 的必填欄位是：

  • BreadcrumbList.itemListElement：「An array of breadcrumbs listed in a specific order」——依特定順序排列的麵包屑陣列。
  • ListItem.item：該麵包屑所代表的網頁網址。
  • ListItem.name：「The title of the breadcrumb displayed for the user」——顯示給使用者看的標題。
  • ListItem.position：「The position of the breadcrumb in the breadcrumb trail」——在整條路徑中的位置。

然後是那個例外：「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，Google 會自動用該頁本身的網址。

這個例外在實作上很有用。很多手寫 schema 的人會在最後一項填一個「當前頁網址」，然後因為分頁參數、追蹤參數之類的原因填錯，反而造成不一致。省略掉是更安全的做法。

Google 建議照「使用者路徑」而不是照網址結構

還有一段指引跟中文圈的習慣做法剛好相反，值得整段抄下來：「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.」

兩個重點：一，麵包屑要反映「使用者通常怎麼走到這一頁」，不是照抄網址目錄；二，連首頁那一層都不是必填的。下面那段範例我還是把首頁放進去了——因為對中文站的讀者來說，路徑上有「首頁」比較好懂，而且這不違規——但你如果覺得多餘，拿掉完全沒問題。

一頁可以有多條路徑

Google 的文件也允許同一頁有多條麵包屑路徑：在同一個 JSON-LD 的 <script> 標籤裡，用陣列放多個 BreadcrumbList 物件。

這適合那種本質上屬於兩個主題的內容，例如一篇同時屬於「WordPress」與「SEO」的文章。不過我自己很少用，因為多條路徑代表你的分類體系有模糊地帶，通常更好的解法是把主分類定下來。

一段可以直接用的 JSON-LD

下面這段是依 Google 文件規格寫的三層麵包屑，最後一層刻意省略 item：

<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": "WordPress 教學",
      "item": "https://example.com/wordpress/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "資訊架構怎麼規劃"
    }
  ]
}
</script>

寫完一定要用 Google 的複合式搜尋結果測試工具或 Search Console 的 URL 檢查工具實際驗一次。結構化資料最麻煩的地方在於寫錯不會報錯，只會安靜地不生效。

WordPress 上怎麼做

如果你用 Rank Math，官方知識庫的說明是：先啟用 Schema 模組，再到「Rank Math SEO → General Settings → Breadcrumbs」設定（需要開啟進階模式）。可調的項目包括分隔符號、首頁連結、是否隱藏當前文章標題、以及是否顯示分類。

輸出方式有三種：在佈景主題範本裡呼叫 PHP 函式、在文章或頁面裡插入短代碼、或在 Elementor 裡用 Breadcrumbs 小工具。第三種有個容易漏掉的前提：官方文件寫明這個小工具「is available only when Elementor Pro and Rank Math PRO are installed」——兩邊的付費版都要有，只買其中一個是叫不出來的。短代碼是

，PHP 的寫法是：

<?php if (function_exists('rank_math_the_breadcrumbs')) rank_math_the_breadcrumbs(); ?>

官方文件也說明，啟用 Schema 模組之後，麵包屑的結構化資料會自動產生。但這裡有一個實務陷阱：如果你的佈景主題本身也輸出一組麵包屑 schema，就會出現兩份，而且兩份的路徑可能不一致。檢查方式是在頁面原始碼裡搜尋 BreadcrumbList，看它出現幾次。

還有一個更常見的不一致：畫面上顯示的麵包屑跟 schema 裡的路徑不一樣。這通常發生在文章掛了多個分類、而外掛用「主要分類」、佈景主題用「第一個分類」的時候。Rank Math 的文件有提到，顯示分類時「the primary category will be used here if your post includes multiple categories」——會採用主要分類。

如果你對 WordPress 的結構化資料還不熟，可以先看 WordPress 的結構化資料設定指南把基本概念補起來，再回來處理麵包屑這一段會順很多。

換佈景主題時麵包屑最容易斷

提醒一個時間點：換佈景主題的時候，麵包屑常常整組不見，因為它是掛在範本檔裡的。如果你用的是 PHP 函式的做法，新主題的範本裡不會有那一行。

所以換主題之前，把「麵包屑是否還在」列進檢查清單。相關的其他風險我整理在 換 WordPress 佈景主題會發生什麼事裡，主題鎖定造成的短代碼失效也是同一類問題。

七、內部連結成網：樞紐與支線

一條粗麻繩在束結處散開成三股，分別往不同方向延伸出去，比喻樞紐頁面把權重與讀者分流到各支線文章

分類與選單決定的是「骨架」，內部連結決定的是「血流」。骨架排得再漂亮，如果文章之間互不相連，權重就流不動。

樞紐—支線（hub and spoke）的做法在中文圈被講爛了，但實作上真正重要的只有兩條規則，其他都是裝飾。

規則一：樞紐頁必須連到它底下的每一篇支線文章。這是你唯一能保證每篇文章至少有一條入鏈的方式。做法可以是手寫清單，也可以是分類頁列表——但如果是分類頁，就要留意它被 noindex 之後還剩多少導流能力。Google 的爬取預算文件對 noindex 的描述是「Google will still request, but then drop the page when it sees a noindex meta tag or header in the HTTP response」——爬蟲仍然會去要那一頁，看到 noindex 之後才丟掉。但官方文件從頭到尾沒有承諾「noindex 頁面上的連結會被持續跟隨」，所以不要把已經 noindex 的分類頁當成支線文章唯一的入鏈來源。要保險，就用手寫的樞紐清單。

規則二：每一篇支線文章至少要連回樞紐，而且要連到兩到三篇同群的兄弟文章。這一條靠自動化的「相關文章」外掛做不好，因為那些外掛通常按時間或標籤選，選出來的常常是不相關的。

一個實際的樞紐長什麼樣子

抽象講完，給一個具體的形狀。假設你要經營「WordPress 架站」這個主題，樞紐頁不是分類封存頁，而是一篇你自己寫的長文，它回答的是主題層級的問題：架站要決定哪些事、每個決定有哪些選項。

這篇樞紐文裡會出現大約十到十五條指向支線的連結，每一條的錨文字都是那篇支線在回答的具體問題。樞紐頁的價值不在於它自己排名多好，而在於它是一個穩定的分流點。

支線文章則各自打一個具體問題：主機怎麼選、佈景主題怎麼挑、備份怎麼做、SSL 怎麼裝、速度怎麼修。它們彼此之間也會互連，但密度不用高，兩到三條就夠了。

判斷一個樞紐健不健康的方法是：把樞紐頁刪掉，會不會有支線變成孤兒？如果會，代表你的支線之間根本沒有互連，整個群只靠一條線吊著。這種結構很脆弱，樞紐頁一出問題整群都會受影響。

反過來也有一個常見錯誤：支線太多，樞紐頁變成一份三十條連結的目錄。那對讀者是災難，因為他不知道該點哪一條。超過十五條就該考慮把樞紐拆成兩層，例如「主機」自己再變成一個中層樞紐，底下掛主機比較、主機商評測、續約與搬家。

錨文字要有變化，但不要為了變化而變化

前面引過 Google 對錨文字的兩句話：好的錨文字幫助人和機器理解目標頁，但別塞關鍵字。這兩句合起來的實務結論是：用完整、自然的名詞片語，同一個目標頁在不同文章裡用不同角度的說法，但不要刻意堆疊同一個關鍵字。

例如同樣連到一篇講網站速度的文章，在架構文裡我會寫成「三項 Core Web Vitals 指標的修復順序」，在主機文裡會寫成「主機規格對載入速度的實際影響」。這不是為了變化，是因為在不同脈絡下，讀者需要的資訊真的不一樣。實際的做法可以參考 Core Web Vitals 三項指標的實戰修復流程。

孤兒頁怎麼找、怎麼救

孤兒頁的定義是：站內沒有任何一個頁面連到它。找法就是前面那張現況表，被連入次數為 0 的那些。

救法有三種，按優先順序：第一，如果內容有價值，就從相關的樞紐頁與兄弟文章補連結進去；第二，如果內容跟另一篇高度重疊，就合併，把弱的那篇 301 到強的那篇；第三，如果內容已經沒有價值，就讓它回傳 404 或 410。

第三點有官方依據：Google 的爬取預算文件把「對永久移除的內容回傳 404 或 410」列為最佳做法之一。不要為了「保住權重」把所有舊頁面通通 301 到首頁，那只會製造一堆軟性 404。

合併的時候，方向要用資料決定

兩篇打架的文章要合併時，決定誰是贏家的依據不該是「哪篇寫得比較好」，而是「哪篇已經有搜尋表現」。我的判準是看 Search Console 裡的點擊數，不是曝光數。

曝光高但點擊接近零的頁面，通常是排在第二頁到第五頁的長尾曝光，那是雜訊不是資產。用曝光決定贏家，很容易把真正在接單的那篇 301 掉。這個教訓我付過學費。

要判斷內容本身值不值得留，可以參考 E-E-A-T 在內容與技術面的落實做法，以及 排名提升要同時顧的內容、技術與權威性三面。

八、分頁與無限捲動：Google 到底跟不跟得上

列表頁的載入方式是資訊架構裡最容易做壞的技術決策，因為它直接決定「第 3 頁之後的文章存不存在」。

Google 的《Pagination and incremental page loading》文件（最後更新 2025-12-10 UTC）把三種模式列出來：分頁（用上一頁／下一頁／頁碼導覽）、載入更多（按鈕擴充同一頁的結果）、無限捲動（捲到底自動載入）。

然後是關鍵的那一句：「Google’s crawlers don’t ‘click’ buttons and generally don’t trigger JavaScript functions that require user actions to update the current page contents.」——Google 的爬蟲不會「點」按鈕，通常也不會觸發那些需要使用者動作才會更新頁面內容的 JavaScript 函式。

所以純靠 JavaScript 的「載入更多」與無限捲動，等於把第一批之後的所有內容藏起來。文件給的解法是：「include links from each page to the following page using <a href> tags」——用真的 <a href> 連到下一頁。

模式 Google 能否發現後續內容 官方建議的補強
傳統分頁（頁碼連結） 可以，前提是連結是 <a href> 每一頁給獨一無二的網址，例如 ?page=n
載入更多（按鈕） 單靠按鈕不行 同時提供指向下一頁的 <a href> 連結
無限捲動 單靠捲動不行 同時提供分頁網址與 <a href> 連結
用網址片段（#）做分頁 不行 改用查詢參數或路徑；文件明言「Google ignores fragment identifiers」

資料來源：Google Search Central《Pagination and incremental page loading》，查核日 2026-08-06。

兩個很多人還在做錯的細節

第一，rel="next" 與 rel="prev" 已經沒有作用了。Google 文件的原文是「Google no longer uses these tags, although these links may still be used by other search engines.」——Google 不再使用這些標記，但其他搜尋引擎可能還會用。所以留著不會扣分，但不要指望它。

第二，不要把分頁序列的第一頁設成所有分頁的 canonical。官方原文是「Don’t use the first page of a paginated sequence as the canonical page.」正確做法是每一頁的 canonical 指向自己。這個錯誤在 WordPress 上很常見，因為某些外掛的舊版預設就是這樣做的。

分面導覽：電商與作品集站的地雷

如果你的站有篩選功能（依價格、依顏色、依技能篩選作品），那就是分面導覽（faceted navigation）。Google 有專門的文件《Managing crawling of faceted navigation URLs》（跟爬取預算那份一樣，已經從 Search Central 移到爬取基礎架構文件區，最後更新 2025-12-18 UTC）。

它對問題的描述是：因為分面導覽產生的網址看起來都是新的，爬蟲在沒爬之前無法判斷有沒有用，所以「the crawlers will typically access a very large number of faceted navigation URLs before the crawlers’ processes determine the URLs are in fact useless」——會先存取大量沒用的網址才發現它們沒用。連帶造成「If crawling is spent on useless URLs, the crawlers have less time to spend on new, useful URLs.」

官方給的四種處理方式是：用 robots.txt 直接擋掉分面網址、改用網址片段做篩選（因為 Google 一般不支援爬取片段）、用 rel="canonical" 指回未篩選的頁面、以及對指向篩選結果的連結加 rel="nofollow"。

還有一條「不要這樣做」：當某個篩選組合沒有結果時，不要轉址到一個通用的錯誤頁，而是「Return an HTTP 404 status code when a filter combination doesn’t return results.」——回傳 404。

九、重整資訊架構時，怎麼不掉排名

這一節是全篇風險最高的部分。前面做錯頂多是沒做好，這一步做錯是會掉流量的。

Google 有一份《Site moves with URL changes》的官方文件（最後更新 2026 年 6 月 17 日），它給的是完整的步驟順序。我把它整理成可以照打勾的清單，並且標出哪幾步是我實際做的時候會多做一層的。

順序 官方步驟 實作重點
1 準備新站／新結構 設定好 CMS、確認 HTTPS、robots.txt、在 Search Console 驗證所有變體（含 www 與非 www）、確認主機承載得住
2 準備網址對照表 「Determine your old URLs」，逐條列出舊網址與對應的新網址；同時更新 canonical 與 hreflang 標註
3 更新內部連結 官方在這一步就要求把內部連結改成新網址，而不是靠轉址接住
4 規劃轉址策略 「Use server side permanent redirects if technically possible」；決定要一次搬完還是分批
5 開始搬遷 上轉址、確認 canonical 與 robots 規則是最新的、用 URL 檢查工具實測轉址
6 提交變更地址 在 Search Console 提交舊站的變更地址（HTTP 轉 HTTPS 不需要這一步）
7 更新對外連結 聯絡連到舊網址的外部網站、更新社群檔案與廣告活動的連結
8 維持轉址 「Keep the redirects for as long as possible, generally at least 1 year.」——盡可能久，一般至少一年
9 提交新的 sitemap 並監控 提交新 sitemap、移除舊的；用 Search Console 的 sitemap 報表與索引涵蓋範圍報表追蹤

資料來源：Google Search Central《Site moves with URL changes》，查核日 2026-08-06。表格右欄的實作重點為依官方步驟改寫的執行說明。

我會額外做的三件事

第一，改網址之前先做一次完整備份。網址結構是全站性的變更，出錯時逐頁改回來會瘋掉。備份策略我寫在 外掛、主機端與異地備份的三層策略，重點是備份要驗證得回來，不是備了就算。

第二，每一條轉址上線後都用指令實測一次，確認狀態碼是 301 而不是 302，而且沒有轉址鏈。「A 轉到 B、B 又轉到 C」這種鏈在 Google 的爬取預算文件裡被列為要避免的項目。我的做法是用 curl -I 逐條打過去看 HTTP/2 301 與 location 標頭。

第三，內部連結一定要真的改掉，不要偷懶靠 301 接住。官方步驟裡「更新內部連結」是排在「上轉址」之前的，這個順序不是隨便寫的：如果你的內部連結全部指向舊網址，等於全站每一次點擊都要多繞一層。

分批搬還是一次搬

官方文件把「一次搬完或分區段搬」列為轉址策略要決定的事，但沒有給偏好。我的做法是看站的大小：兩百頁以下我會一次搬完，因為分批的複雜度（同時存在兩套結構）反而更容易出錯；超過一千頁我會按分類分批，一批搬完觀察兩週再搬下一批。

觀察什麼？我看兩個數字：Search Console 裡舊網址的曝光是不是穩定下降、新網址是不是同步上升；以及「已找到 – 目前尚未建立索引」的數量有沒有暴增。第二個數字暴增通常代表轉址有問題或內部連結沒改乾淨。

如果你正在做多語系，順序不一樣

多語系網站的資訊架構決策（子網域、子目錄或獨立網域）會直接綁死網址結構，而且改起來比單語系痛苦得多，因為還要重做 hreflang 標註。Google 的搬站文件也把「更新 hreflang 標註」列在準備網址對照表那一步。

如果你的站有這個規劃，建議先把 多語系的子網域、子目錄與 hreflang 取捨看完再定網址結構，順序反過來會很痛。

十、一份可以照做的排程

把上面所有東西壓成一個時間表。我假設你手上是一個已經有內容、但沒認真規劃過架構的站。

階段 做的事 不可逆程度
第 1 週 盤點：匯出 sitemap、拉 Search Console 頁面索引報表、實爬前台建立內部連結圖 零，純讀取
第 2 週 決定分類體系與每個分類的樞紐頁；標記要 noindex 的封存頁類型 低，可回復
第 3 週 補內部連結：樞紐連支線、支線回連樞紐與兄弟文；處理孤兒頁 低
第 4 週 麵包屑：確認只有一份 BreadcrumbList、路徑與畫面一致、用測試工具驗證 低
第 5 週 檢查列表頁分頁是否為真連結、canonical 是否指向自己 中
第 6 週以後 如果確定要改網址結構：備份 → 網址對照表 → 改內部連結 → 上 301 → 提交變更地址 → 監控 高，轉址要維持至少一年

此排程為依前述官方文件步驟所做的實務安排，非 Google 官方建議的時程。

順序的原則是：從零風險的盤點開始，把不可逆的網址變更放到最後。很多人反過來做——先改網址，改完才發現分類體系還要動，於是又改一次。每多改一次，就多一層轉址債。

如果你是完全從零開始建站，那反而輕鬆：在還沒有任何外部連結、也還沒被收錄的時候把網址結構定下來，成本是零。這也是我建議新站在 選定 WordPress 作為架站平台之後，第一件事就是把固定網址設定好、而不是先挑佈景主題的原因。

還沒決定要用哪個平台的話，網站建置工具五大類的比較可以先看一輪——這裡要提醒的是，有些託管型平台不允許你自訂網址結構，那等於資訊架構的一半被平台決定了。

十一、常見的五個錯誤

最後把我最常在別人站上看到的錯誤列出來，都是可以在一個下午修完的。

錯誤一：用 robots.txt 擋標籤頁，以為這樣就不會被收錄。如前所述，robots.txt「不是把網頁排除在 Google 之外的手段」，而且會導致 noindex 讀不到。正確做法是讓它可被爬取、加上 noindex。

錯誤二：把所有舊網址 301 到首頁。Google 的爬取預算文件建議對永久移除的內容回傳 404 或 410。全部丟首頁只會產生大量軟性 404。

錯誤三：麵包屑寫兩份。佈景主題一份、SEO 外掛一份，兩份路徑不一致。在原始碼裡搜尋 BreadcrumbList 就能發現。

錯誤四：分頁的 canonical 全部指向第一頁。官方明說不要這樣做，每一頁的 canonical 應該指向自己。

錯誤五：分類體系照「我想寫什麼」設計，而不是照「別人怎麼找」設計。這一條最難改，因為它需要資料。實務上就是先用關鍵字工具確認每個分類主題真的有搜尋需求，再決定它值不值得當樞紐；用搜尋量、競爭程度與商業價值三個標準判斷關鍵字這套流程也可以直接套在分類命名上。

如果你的站已經有一定內容量，想從長尾補齊支線文章，從客戶提問與社群討論挖長尾關鍵字的方法是我用得最順的一套，因為它挖出來的題目天生就適合掛在既有樞紐底下。

十二、內容站與接案作品集站：同一套原則，兩種長相

前面所有規則都通用，但套到不同型態的站上，長出來的樣子差很多。這一節把兩種常見情況分開講。

內容站：架構的重點在「主題群完整度」

內容站的頁面幾乎都是文章，型態單一，所以架構的難度不在頁面種類，而在主題怎麼切。切太粗會讓一個分類底下混進不相干的東西，切太細會讓每個分類都只有三五篇文、變成薄頁。

我的做法是用「這個分類能不能撐到 10 篇有搜尋需求的文章」當門檻。撐不到就先不要開，把文章掛在上一層。分類可以之後再拆，但拆分類會改網址（如果你的網址帶分類前綴），所以寧可晚開。

內容站還有一個特有的架構風險：時間。三年前寫的文章跟今年寫的文章可能在講同一件事，但兩篇都還開放索引，就變成自己跟自己打架。這種內部競食在盤點時看不出來（兩篇都有意圖、都有入鏈），要靠 Search Console 的查詢層級資料才看得到——同一個查詢字串下，兩個網址輪流出現，兩邊的點擊都很低。

處理方式是合併，方向依前面說的看點擊數而不是曝光數。合併之後把弱的那篇 301 到強的那篇，並且把站內指向舊網址的連結全部改掉。

作品集站：架構的重點在「兩種訪客走不同路」

接案者的作品集站有一個內容站沒有的問題：它同時要服務兩種完全不同的訪客。一種是從搜尋進來的陌生人，他要的是「這個人能不能做我要的東西」；另一種是你自己貼連結過去的潛在客戶，他已經知道你是誰，要看的是特定作品。

這兩種路徑對架構的要求剛好相反。搜尋來的人需要服務頁與作品分類頁（有清單型意圖、值得索引）；你貼連結給的人需要一個好記、好貼的單頁網址。

頁面類型 主要訪客 網址建議 索引建議
服務頁（例如「網頁設計服務」） 搜尋而來 短、含服務名稱 開放，且應是主選單項目
作品分類頁（例如「品牌識別」） 搜尋而來＋瀏覽者 短、含類型名稱 開放，並在頁面上寫一段類型說明
單一作品頁 你主動貼連結的對象 英文短 slug，方便貼進提案信 開放，但不必為它做關鍵字優化
技能／工具標籤（例如「Figma」） 幾乎沒有 不建議建立 noindex 或直接關閉該分類法
案例的自訂欄位篩選（依產業、依預算） 瀏覽者 屬於分面導覽，見前一節 依 Google 分面導覽文件處理

索引處理方式的依據為 Google 的 noindex 與分面導覽文件，查核日 2026-08-06；欄位安排為實務判斷。

作品集站最常見的架構錯誤是把「技能標籤」當成分類體系。你會很想幫每個用過的工具建一個標籤，因為那讓後台看起來很專業。但那些標籤頁沒有人搜、每頁只有兩三個作品，剛好就是第三節說的薄頁災難。

另一個錯誤是把作品頁做成無限捲動的瀑布流。視覺上很漂亮，但依前一節引的官方說法，爬蟲不會捲動也不會點按鈕，第一批之後的作品等於不存在。解法很簡單：瀑布流照做，但同時在頁尾放一組真的頁碼連結。

兩者共通的一件事：先想清楚首頁要承接什麼

不管哪一種站，首頁都是站內連結最多、外部連結也最多的那一頁。所以首頁連出去的對象，等於是你對搜尋引擎宣告的「本站重點」。

我看過太多首頁塞滿「最新文章」的站——那等於每天都在重新宣告一次重點，而且宣告的內容完全由發文時間決定。比較好的做法是首頁固定連向所有樞紐頁，最新文章只佔一小塊。如果你正在思考首頁該放什麼，部落格五種變現方式的門檻與取捨裡的分析可以當參考——你想靠哪一種方式變現，首頁就該優先把流量導到支撐那條路徑的頁面。

常見問題

資訊架構要規劃到什麼程度才算夠？

最低標準是三件事：每一篇文章至少有一條站內連結指向它；每一個開放索引的分類頁上面有實質內容；網址結構在可預見的未來不需要再改。做到這三件事，你的架構就不會拖累 SEO。至於更精緻的樞紐設計、多層分類，那是有內容量之後才需要的問題。

標籤頁到底要不要全部 noindex？

不建議一刀切。判準是「有沒有人會搜尋這個詞、而且要的是一份清單」。如果有（例如「WordPress 佈景主題」），就留著並手動寫描述；如果沒有（例如「2024」「隨筆」），就 noindex。要注意設 noindex 的頁面不能同時被 robots.txt 擋住，否則 Google 的文件明說那條規則不會生效。

中文網址對 SEO 有幫助嗎？

Google 的 URL 結構文件建議用受眾的語言，同時要求非 ASCII 字元做百分比編碼。所以中文 slug 符合官方建議，代價是編碼後的網址很長、複製分享時不好看。查核日 2026-08-06 的官方文件並沒有承諾「中文網址會排比較前面」，我也查不到任何官方的排名效果說明，所以我把它當可讀性決策，不是排名決策。

已經上線兩年的站，還值得改網址結構嗎？

先問一個問題：現在的結構有沒有造成實際問題（例如網址裡有一堆 ID 數字、或分類已經完全對不上內容）。如果沒有，不改。如果有，就照 Google 搬站文件的順序做，並且準備維持轉址「至少一年」。改網址的成本是永久的，只有在收益明確時才划算。

麵包屑一定要顯示在畫面上嗎，還是只要有 schema 就好？

Google 的麵包屑文件說的是「Google Search uses breadcrumb markup in the body of a web page」——它讀的是頁面主體裡的標記。從結構化資料的一般原則來說，標記應該對應頁面上使用者看得到的內容，所以我的做法是兩者都做，而且確保路徑一致。純 schema 沒有畫面的做法我不建議。

網站速度跟資訊架構有關係嗎？

有間接關係。Google 的爬取預算文件把「提升頁面載入效率」列為最佳做法之一，理由是同樣的爬取時間可以取得更多頁面。不過對一般規模的內容站來說，速度優化的主要收益還是在使用者體驗，不在爬取。兩件事可以分開排優先順序。

資料來源

本文所有引用的 Google Search Central 與 WordPress 官方文件，均於 2026 年 8 月 6 日逐頁開啟核對，並在文中標注各頁面自己標示的最後更新日期。官方文件改版頻繁，若你在較晚的日期閱讀本文，建議回到原始連結再確認一次現行版本。

作者 Andes 的頭像

關於作者｜Andes

自架 WordPress 網站與內容經營的長期實作者，寫過的主題涵蓋自架站、SEO、接案與遠距工作。習慣把每一個結論都追回到官方文件或可驗證的數據，價格與規格一律標注幣別與查核日期。這篇的每一條規則都回到 Google Search Central 的網站結構、網址結構、麵包屑結構化資料、noindex 與搬站文件，加上 schema.org 與 WordPress.org 官方說明逐字比對，查核日為 2026 年 8 月 6 日；「三次點擊」那一段則直接引用 2003 年的原始使用者研究，而不是二手轉述。

相關文章

目前趨勢

打造個人品牌的祕訣｜數位遊牧者
個人品牌怎麼經營？數位遊牧與接案者的利基定位、平台選擇與信任訊號
打造獨特的WordPress網站，吸引更多目光｜數位遊牧者
打造獨特的WordPress網站，吸引更多目光
數位行銷
WordPress 網站設計實戰：8 個讓版面更專業的排版與視覺原則
為什麼選 WordPress 架站？2026 年的 5 個理由與 3 個不適合的情況