Drupal SEO 的名聲並不完全配得上它的實力。隨便問一圈，總有人會告訴你 Drupal 開箱即用就很適合搜尋，而說這話的人往往是拿十五年前對另一個平台的記憶在做比較。一套原裝的 Drupal 11 安裝，既沒有中繼描述欄位，也沒有 XML 網站地圖，URL 變更時沒有自動轉址，而且在編輯手動輸入別名之前，內容一直在 /node/123 上回應。

這不是在批評這個專案。核心刻意把自己的範圍維持得很小，把一切帶有立場的東西推給貢獻模組，而這正是大型 Drupal 網站能比多數平台調得更精細的原因。但這也表示開箱即用這個說法承擔了非常多的分量，也表示一個 Drupal 網站的搜尋表現，幾乎完全取決於第一天裝了哪些模組，以及有誰把它們設定成什麼樣子。

以下是這套技術堆疊在 2026 年 9 月的實際狀況：核心做了什麼，哪些貢獻模組替你補上了別的系統免費奉送的能力，只有 Drupal 上才會出現的失敗模式有哪些，以及當初這些事一件都沒做的網站，修起來要花多少錢。

Drupal 開箱即用適合 SEO 嗎。 不適合。核心給你的是路徑別名、canonical 連結標記和一個很強的多語言路由層，但它不提供中繼描述、不提供 XML 網站地圖、不處理轉址，也不輸出結構化資料。這些來自四個貢獻模組：Pathauto、Metatag、Simple XML Sitemap 和 Redirect。缺了它們的 Drupal 網站不是最佳化得差，而是根本沒有做過最佳化。

Drupal 核心真正為你做的事

核心給了你三樣要緊的東西，而且這三樣都做得確實好。

核心的 Path 模組讓你可以為任何路由掛上一個人類看得懂的別名，於是一個節點可以在 /services/tax-advice 上回應，而不是在它的內部路徑上。核心會保存這個別名，並依它來解析請求。核心不會做的事情是替你想出這個別名，所以在一個有 2,000 個節點的網站上，得有人手動打完 2,000 條別名，而現實中從來沒有人真的打完。

核心還會在實體頁面上輸出連結關係。檢視一個節點會產生指向別名 URL 的 rel="canonical"，以及指向未加別名 URL 的 rel="shortlink"，考慮到有好幾個商業平台不裝外掛根本做不到這一點，這已經相當可觀。正是這一個行為，讓下面要談的重複路徑問題通常只是撐得過去，而不是致命的。

第三樣是語言。核心的多語言堆疊會處理路徑前綴、依語言劃分的別名，以及已翻譯實體上的替代語言連結，這是 Drupal 搜尋故事裡最強的一部分。

其餘的一切都是貢獻模組。在你自己新增之前，內容類型上不存在中繼描述欄位，沒有網站地圖，沒有轉址表，刪掉一個節點只會留下一個 404，再無其他。

事實上不可或缺的四個模組

drupal.org 上帶著 SEO 標籤的模組有幾十個。其中四個不是選配，凡是漏掉任何一個的 Drupal 專案，都會留下一個競爭對手沒有的破口。

Pathauto

Pathauto 依據 token 模式產生別名，例如 blog/[node:title] 這樣的模式，會在節點儲存時自動產出別名。它是 Drupal 裡最接近人人都裝的模組，有 464,471 個網站回報使用，目前的穩定版是 2026 年 5 月 4 日發布的 8.x-1.15，支援 Drupal 10.2 與 11。它相依於 Token 模組。

決定 Pathauto 是幫忙還是添亂的設定是更新動作，它控制標題改變、模式因而產出不同別名時會發生什麼事。Pathauto 可以什麼都不做，可以直接把舊別名換掉，也可以建立新別名並保留一條從舊別名過來的轉址。你要的是第三種，而這個選項只有在裝了 Redirect 模組時才會出現。停留在較弱預設值上的網站，會悄悄為每個節點累積好幾條仍然活著的別名。

Metatag

Metatag 是 Drupal 頁面得以擁有中繼描述的唯一途徑，同時也負責 Open Graph 與 Twitter Card 的輸出。Damien McKenna 自 2012 年起一直在維護它，有 332,868 個網站回報使用，2025 年 9 月發布的 2.2.0 需要 Drupal 10.3 或 11。

它的運作方式是依實體類型與 bundle 設定預設值，寫成 token 模式，再在上面疊加以節點為單位的覆寫。常見的失敗是某個模式在整個內容類型裡解析出完全一樣的結果，於是好幾百個頁面共用同一條描述。這比沒有描述更糟，因為它等於告訴檢索器這些頁面可以互相替換。

Simple XML Sitemap

核心不輸出任何形式的網站地圖。Simple XML Sitemap 是標準答案，有 137,418 個網站在用，2025 年 11 月 26 日發布的 4.2.3 需要 Drupal 10.3 或 11。它可以索引實體、檢視與自訂連結，還會輸出 hreflang 與圖片項目，這在多語言專案裡意義重大。

依 bundle 設定它，而不是全站一刀切。預設的誘惑是把什麼都包進去，結果就是把分類詞彙頁、使用者個人檔案和未加篩選的檢視清單全推進網站地圖，等於告訴搜尋引擎你最單薄的頁面才是重點。

Redirect

Redirect 提供手動轉址，更重要的是提供 canonical URL 強制：它可以把對某段內容的每一個非 canonical 請求都轉到 canonical 路徑。有 265,749 個網站在用它，2026 年 4 月 24 日發布的 8.x-1.13 支援 Drupal 10 與 11。

有一點值得直說。專案頁面目前掛著一則招募共同維護者的公告，對一個承擔了這麼多分量的模組來說，這是一個需要盯著的維護風險，而不是迴避它的理由。它仍然受 Drupal 安全公告政策涵蓋。

其他平台沒有的 Drupal SEO 陷阱

每個節點至少有兩個活著的 URL

這是從別的系統轉過來的人最感意外的一點。在 Drupal 裡加了別名，並不會讓內部路徑退休。/node/123 會繼續以 200 回傳完整頁面，而且只要更新動作允許它們留存，這個節點曾經被賦予的每一條別名也都一樣。

核心的 canonical 標記能減輕損害，Google 把 canonical 標註當成強訊號而不是指令，把它排在與轉址同級、高於網站地圖收錄的位置。但強訊號不是保證。穩妥的解法是 Redirect 模組的 canonical 強制，它把重複項變成永久轉址，於是根本沒有什麼需要再去整併。

分類詞彙頁會不斷增生

核心會為每一個分類詞彙產生一個清單頁。在有自由標籤詞彙表的網站上，這表示一個標籤一個頁面，其中大多數只掛著一兩個節點，標題來自範本，也沒有描述。好幾百個這樣的頁面，就是一個誰都沒有刻意製造出來的內容單薄問題。

依詞彙表逐一決定，而不是全站統一。真正有編輯價值的分類可以被索引，並配上手寫的描述。自由標籤詞彙表則從網站地圖裡排除，多數情況下再加上 noindex。

檢視分頁與 ?page= 留下的痕跡

核心的每一個檢視清單都用 ?page= 參數分頁，而每一個這樣的位址都是獨立的 URL。Google 的指引是序列中的每一頁都應該有自己的 URL 和自己的 canonical，而不是把 canonical 指回第一頁，並且 rel next 與 rel prev 已經不再被使用。

Drupal 特有的部分在於，同一個檢視上的公開篩選器與排序會與分頁器相乘。一個帶三個公開篩選器、結果有四十頁的清單，產生的可定址 URL 遠遠多於它實際擁有的內容，而且每一個都會真的算繪出來。

分面與參數爆炸

分面搜尋，通常是架在 Search API 之上的 Facets 模組，正是在這裡，問題從不整齊升級成檢索預算問題。2026 年 9 月 1 日發布的 Facets 3.0.6 支援 Drupal 10.1 與 11，有 56,746 個網站在用。它同樣掛著招募共同維護者的公告。

Google 警告，檢索器要走過數量極其龐大的分面導覽 URL之後，才能確認這些 URL 通向的地方並無用處，而這個過程既消耗你的檢索預算，也消耗它們的運算資源。及早決定哪些分面組合可被索引，其餘的擋掉，並保持參數順序穩定，讓同一組篩選條件永遠產出同一個 URL。

發布狀態的反覆

一個先以未發布狀態建立、帶著暫定標題、一週後又用另一個標題發布的節點，會在建立時產出一條別名，在發布時再產出一條。如果更新動作設錯了，兩條都活著，兩條都可被檢索。再乘上一支編輯團隊和一年的產出，別名表最後會比節點表還大，而這正是一次 SEO 稽核在拿活著的 URL 數量對照已發布節點數量時要找的模式。

Drupal 裡的結構化資料

有兩條路，而這個選擇比看起來更要緊。

Schema.org Metatag 擴充了 Metatag，在頁面 head 裡輸出 JSON-LD，涵蓋二十五種以上的 schema 類型。2026 年 2 月 19 日發布的 3.0.4 版支援 Drupal 9、10 與 11，有 66,363 個網站在用。和 Redirect、Facets 一樣，它也在招募共同維護者。

它的優勢是完整繼承了 Metatag 的那套繼承模型：依 bundle 的預設值、拉取欄位值的 token、以節點為單位的覆寫，以及永遠不必看到原始 JSON 的編輯人員。它的限制是你只能表達這個模組建模過的東西，而深度巢狀的 schema，也就是一件商品一旦牽涉到報價、評論與退貨政策時所需要的那一類，用 token 欄位拼出來會很彆扭。

在 Twig 範本裡手寫 JSON-LD 給你完整的控制權，代價是失去編輯介面。在一個範本數量不多、手邊又有開發者的網站上，這往往是更划算的交換。在一個有六十種內容類型和一支內容團隊的網站上就不是了，因為每改一次 schema 都會變成一次部署。

選一條路。我們最常見到的失敗，是兩條路並行跑著，輸出兩個在發布日期上互相矛盾的 Article 區塊。

多語言 Drupal 與 hreflang

這是 Drupal 真正配得上它名聲的地方，值得明確寫出來，因為這篇文章的其餘部分談的都是缺口。

核心自帶語言相關模組，一旦啟用內容翻譯，Drupal 就會在已翻譯實體上輸出替代語言連結，不需要任何貢獻模組幫忙。路徑前綴、依語言劃分的別名和依語言劃分的選單，都是開箱就能用的。

Google 對在地化版本的要求是：每個版本既要列出自己，也要列出其餘所有版本；這些標註必須是雙向的；並且要有一個 x-default 作為備援。Drupal 的翻譯模型自動滿足前兩條，因為替代項是從翻譯集產生的，而不是由編輯手動輸入的。相較於那些把 hreflang 做成外掛欄位、誰都可能忘記填的平台，這是實打實的優勢。

仍然有兩件事會出問題。x-default 的值不會自動設好，需要透過 Metatag 或範本補上。還有，只翻譯了一部分的集合會產出一些指向回退到來源語言頁面的替代項，而這比乾脆不做標註還要糟。

效能與 Core Web Vitals

Drupal 的快取層屬於核心，做得很好，而且經常因為某次沒人記得收尾的除錯而一直被關著。

算繪快取會把片段連同可快取性中繼資料一起存起來：描述該片段所依賴資料的快取標籤、描述它隨什麼而變的快取脈絡，以及一個最長有效期。當底層實體發生變化時，標籤會自動失效。中繼資料寫錯了，你要麼送出過期頁面，要麼什麼都快取不了。

Internal Page Cache 向匿名訪客提供完整頁面。Dynamic Page Cache 透過快取除個人化部分以外的一切，向任何使用者提供頁面。而 BigPipe 自 Drupal 8.1 起進入核心，並自 8.5 起成為標準安裝設定檔的一部分，它會在第一個回應已經送出之後，再把那些個人化佔位符以串流方式送達。

就 Core Web Vitals 而言，要點很有限。BigPipe 改善的是感知載入速度，而當它要填入的佔位符沒有預留空間時，反而可能讓 Cumulative Layout Shift 變差。Drupal 網站的 Largest Contentful Paint 通常由主視覺圖片和彙整後的 CSS 套件決定，而不是由算繪快取決定。Drupal 11.4 新增了在 PHP 擴充可用時產生 Brotli 壓縮的 CSS 與 JavaScript 資源，對任何自行提供靜態資源的網站來說，這都是一個乾脆俐落的收益。

大版本升級會破壞什麼

Drupal 的大版本升級不是換平台，但它會以特定且反覆出現的方式破壞搜尋能見度。

貢獻模組通常是罪魁禍首。如果 Metatag 還沒有適配目標版本，網站卻在缺了它的情況下上線，全站的中繼描述會一次全部消失，而且直到兩週後曝光數下滑之前沒有人會注意到。網站地圖模組也一樣，Redirect 的情況更糟，因為失去 Redirect 會讓 canonical 強制停擺，所有舊別名統統復活。

第二個原因是沒能撐過搬遷的設定。Metatag 預設值、Pathauto 模式和網站地圖的 bundle 設定都存放在組態裡，一個只匯入了內容卻沒有匯入組態的重建網站，回來時帶著預設模式，同樣的內容卻換了 URL。

動手之前先做一次完整檢索，把每個頁面的 URL、狀態碼、標題、描述和 canonical 都記錄下來，事後再拿同樣的檢索做一次比對。我們的 Drupal 遷移指南談了各條版本路徑以及與之綁定的期限。

Drupal 各版本目前的處境

時機會改變你合理的第一步是什麼。Drupal 11.4.0 於 2026 年 7 月 1 日發布，11.4.x 分支的安全支援持續到 2027 年 6 月。2022 年 12 月 15 日發布的 Drupal 10 將在 2026 年 12 月 9 日終止生命週期，而 Drupal 12 排在 2026 年 12 月 7 日那一週，測試版預計在 2026 年 9 月中旬出現。

實際的結果是，在寫下這段話的時候，一個 Drupal 10 網站大約只剩三個月的安全涵蓋範圍。任何在 Drupal 10 網站上委託的 SEO 工作，都應該排在升級之後而不是之前，因為反過來做等於付兩次錢：一次是修中繼資料，另一次是模組版本抬升、輸出隨之改變的時候。

Drupal 11.1 到 11.4 執行在 PHP 8.3 與 8.4 上，而 Drupal 10 至少需要 PHP 8.1。在共享主機上，真正卡住專案的往往是這個 PHP 下限，而不是 Drupal 這邊的工作本身。

一次 Drupal SEO 專案要花多少錢

先把範圍界定清楚。Drupal SEO 專案不是一份報告，而是在一個具體程式碼庫裡做的設定工作與範本工作，交付物是一個被改動過的網站，不是一份文件。

基礎稽核涵蓋那四個模組的組合及其設定方式、別名表與轉址表、分類法與檢視的曝光面、網站地圖的內容、結構化資料的輸出，以及各層快取。在一個只有幾百個節點的網站上，這是三到五天的工作量。英國技術 SEO 的日費通常落在 600 到 1,200 英鎊之間，所以這種形態的技術 SEO 稽核大致在 2,000 到 5,000 英鎊之間，取決於人員資歷與網站規模。

實作是另一件事，而且通常更大。在一個已有內容的線上網站上安裝並設定 Pathauto、Metatag、Simple XML Sitemap 與 Redirect，意味著批次產生別名、為每一條會改變的別名建立轉址對照表，以及寫出不會塌陷成重複的描述模式。這個階段請按稽核費用的一到兩倍預留預算。

帶分面搜尋的多語言 Drupal 網站會高於這個區間。英國代理商做 Drupal 工作的日費大約是 600 到 900 英鎊，這一點在我們關於 Drupal 開發者費率的指南裡有談，而一個涉及多個翻譯集與分面治理的專案，現實中是十到二十天。

把改動前後的檢索比對當成一項寫明的交付物提出來。沒有它，就沒有任何證據證明真的改變了什麼。

把順序理順

真正管用的順序並不好看。先於一切安裝並設定那四個模組，因為沒有它們就做出的內容決策，之後都會變成重工。接著關掉重複 URL 的曝光面，因為它牽動網站上的每一個頁面。然後是分類法與檢視的曝光面，再來是結構化資料，最後是效能。內容與連結排在技術層穩定之後，絕不在它之前。

Mecanik 依這個順序把工作做成一次技術 SEO 稽核，針對的是 Drupal 程式碼庫及其組態，而不只是一次檢索結果，隨後的實作則由 SEO 稽核服務承接。如果你還在猶豫 Drupal 究竟是不是合適的平台，我們的 Drupal 開發指南以及無頭 CMS 與傳統 CMS 架構的比較會是比這篇更合適的起點。

常見問題

Drupal 開箱即用適合 SEO 嗎？ 不適合。Drupal 核心提供路徑別名、canonical 連結標記與多語言路由，但不提供中繼描述、不提供 XML 網站地圖、不處理轉址，也不輸出結構化資料。這些需要 Pathauto、Metatag、Simple XML Sitemap 與 Redirect 模組，它們全都是貢獻模組而非核心。原裝安裝不是最佳化得差，而是根本沒有做過最佳化。

一個 Drupal 網站實際需要哪些 SEO 模組？ 事實上不可或缺的有四個：負責自動產生 URL 別名的 Pathauto、負責中繼描述與社群標記的 Metatag、負責網站地圖本身的 Simple XML Sitemap，以及負責轉址與 canonical URL 強制的 Redirect。如果你想輸出結構化資料又不願在 Twig 範本裡手寫 JSON-LD，第五個通常是 Schema.org Metatag。

我加了 URL 別名之後，為什麼 /node/123 還打得開？ 因為 Drupal 的別名不會讓內部路徑退休。兩個位址都會以 200 狀態回傳完整頁面。核心會輸出一個指向別名的 canonical 標記，而 Google 把它當成強訊號而不是指令，所以可靠的解法是 Redirect 模組的 canonical URL 強制，它會把重複項變成永久轉址。

Pathauto、Metatag 與 Simple XML Sitemap 相容於 Drupal 11 嗎？ 相容，而且這套核心組合的四個模組都在積極維護。Pathauto 8.x-1.15 支援 Drupal 10.2 與 11，Metatag 2.2.0 需要 Drupal 10.3 或 11，Simple XML Sitemap 4.2.3 需要 Drupal 10.3 或 11，Redirect 8.x-1.13 支援 Drupal 10 與 11。四個都受 Drupal 安全公告政策涵蓋。

在英國做一次 Drupal SEO 專案要花多少錢？ 一次涵蓋模組組合、別名表與轉址表、分類法曝光面、網站地圖與結構化資料的設定稽核，在中等規模網站上需要三到五天，按英國技術 SEO 日費 600 到 1,200 英鎊計算，大致是 2,000 到 5,000 英鎊。實作通常還要再花稽核費用的一到兩倍。