為什麼 WordPress 對 SEO 友善？拆解 8 支 WordPress SEO 外掛的評分機制
AI 文章延伸
選擇平台後可直接帶入閱讀脈絡，快速整理重點、補齊盲點，並延伸到同站相關文章。
昨天跟朋友聊到「WordPress 對 SEO 特別友善」這件事，發現這個說法在很多人心中已經變成一種迷思——好像 Google 對 WordPress 有特別的演算法偏好。但事實沒那麼神祕，這個友善是可以被解釋、也可以被複製的：WordPress 把搜尋引擎在意的事情，預設就替你做掉了：permalink 結構漂亮、語意化 HTML 完整、結構化資料一鍵輸出、sitemap 自動產生、每篇文章天然帶內鏈⋯⋯這些直接決定「Google 看不看得懂你網站」的細節，作者完全不用煩惱，內容就已經跟搜尋引擎對齊。
但我們在討論網站體質時，聚焦點往往在「速度」——LCP 幾秒、Lighthouse 幾分、要不要改成 SPA、要不要全站靜態化，彷彿快就能贏。可是 Google 的優先序其實不是這樣排：先理解你，再決定排不排你。一個結構清楚但跑得慢的網站，會贏過一個跑得快但結構亂的網站；速度只是體質相當的兩個網站在搶同一個關鍵字時，最後的決勝點。換句話說，大家拼命優化的速度，很多時候是在主菜還沒上桌前先衝去挑調味料。
為了把「為什麼 WordPress 友善」這個直覺觀察拆成可以套用到任何網站的原則，我請 AI 把現在最主流的 8 支 WordPress SEO 外掛原始碼挖出來分析，想知道兩件事：第一，Google 真的有偏心 WordPress 嗎？第二，這些外掛是怎麼定義「一篇文章 SEO 好不好」的？
結論先講：Google 沒有偏心 WordPress，但 WordPress 預設把一堆 SEO 基礎建設做掉了，作者只要寫內容。下面把整個研究攤開來講。
Google 真的偏心 WordPress 嗎？官方說法是「沒有」
先看 Google 自己的說法。Google Search Advocate John Mueller 在多次公開場合都明確否認過「Google 對 WordPress 有偏好」這件事，他的核心論點是：Google 的排名演算法不會去判斷一個網站背後用的是什麼 CMS，無論你用 WordPress、其他平台或是純手刻，都不會因為平台本身得到加分或扣分。Search Engine Journal 直接下了標題〈WordPress Not Inherently Better For SEO〉——WordPress 本質上並沒有比較適合 SEO；Search Engine Roundtable 整理同主題訪談時則用了〈Google Doesn’t Give WordPress Preferential Treatment〉——Google 並沒有給 WordPress 優待。
那為什麼大家覺得 WordPress 站「就是比較容易排上去」？因為這是觀察結果，不是規則。WordPress 的核心程式 + 主流主題 + Yoast/Rank Math 這類外掛，預設就把一堆 SEO 基礎建設做掉了，作者根本不用想那些細節，網站就已經符合 Google 抓取與理解的最佳實務。
換到自己手刻的網站，例如用 Next.js、Astro、Hugo，或更原始一點的純 HTML，這些事情就要自己顯式做一遍——沒做就沒效，但這跟用什麼 CMS 一點關係也沒有。
反直覺：速度不重要嗎？
那速度呢？WordPress 站常常 LCP 三、四秒起跳，理論上 Core Web Vitals 應該很差，怎麼還能排上去？
Mueller 也回答過這個問題，業界的整理可以參考 Inbound Design Partners 的這篇〈Why Core Web Vitals May Not Matter As Much As You Think〉——標題就是結論，CWV 的重要性被高估了。Mueller 多次表達的觀點是：CWV 比較像一個 tiebreaker（決勝負的條件），當兩個站內容品質相當、結構相當的時候，比較快的那個贏；但如果一個站結構好、內容深，另一個站快但結構亂，結構好的那個贏。
換句話說，Google 的優先序是「能不能理解你」大於「你跑多快」——這就解釋了為什麼一個 LCP 4 秒、塞滿外掛的 WordPress 站，反而能贏過 Lighthouse 100 分但是 SPA 沒做 SSR、缺 schema、沒內鏈的 Next.js 站。
理解了這點，「WordPress 結構清楚」這件事就值得拆開來看——拆完之後，你會發現這些東西每一條都可以搬到別的技術組合上。
WordPress「結構清楚」的 10 個具體面向
下面這 10 點是我把幾支主流 SEO 外掛的預設輸出，以及 WordPress 核心 + 主流主題的預設行為比對之後整理出來的。每一條都附上「可移植到任何技術組合的原則」。
1. Permalink 友好
WordPress 預設給你 /category/post-title/ 這種人類可讀、有語意、單字之間用連字號（-）連起來的網址。可移植原則：
- 用連字號
-不要底線_（搜尋引擎處理底線的歷史包袱比較重） - URL 含主題關鍵字
- 層級淺（最多 2-3 層）
- 沒有查詢字串、沒有 session id
2. 語意化 HTML 骨架
WordPress 主題（特別是 block themes）預設輸出大概是這樣：
<header><nav>...</nav></header>
<main>
<article>
<h1>標題</h1>
<time datetime="2026-04-23">...</time>
<section>...</section>
</article>
</main>
<footer>...</footer>可移植原則：用 <article>、<section>、<nav>、<main>、<aside>、<time datetime="">，不要整頁都是 <div>——爬蟲靠這些標籤判斷「主內容」在哪，避免把側欄、相關文章誤認為內容。
3. 標題層級嚴謹
WordPress 編輯器強制每篇文章只有一個 H1（自動套文章標題），內文段落會自動是 H2/H3。可移植原則：一頁一個 H1、H2 → H3 不跳級、標題寫的是「這段在講什麼」而不是「點我」。
4. Meta 三件套
<title>、meta description、canonical。WordPress + Yoast/Rank Math 自動處理。可移植原則：每頁都要有，description 控制在 120-160 字、實際描述頁面內容（不是品牌口號）。
5. 結構化資料（JSON-LD）
WordPress SEO 外掛預設輸出 Article、BreadcrumbList、Organization、WebSite 的 JSON-LD。這就是為什麼 WordPress 文章常常有 rich snippets——作者、發布日期、星等——直接出現在搜尋結果裡。可移植原則：至少加 Article（含 datePublished、author、headline）、BreadcrumbList，首頁加 Organization + WebSite（含 SearchAction）。Astro 直接在 layout 塞 <script type="application/ld+json"> 就好。
6. 自動 sitemap.xml + 開放的 robots.txt
WordPress 從 5.5 開始內建 /wp-sitemap.xml，且預設 robots.txt 開放並指向 sitemap。可移植原則：
- 動態產生 sitemap，新文章上架要自動更新（不是手動維護）
- robots.txt 一定要存在、含
Sitemap:指向、不要誤 disallow - 提交到 GSC
7. 內鏈密度
WordPress 因為有 category、tag、related posts、上下篇導覽，每篇文章天然有 5-10 條內鏈。Google 用內鏈判斷主題權威度與爬取優先級。可移植原則：每篇文章自動或手動加：相關文章、上下篇、分類列表、tag 連結。孤兒頁面（沒有任何內鏈指向）幾乎不會排名。
8. 圖片 alt + srcset + lazy
WordPress 編輯器強制提示填 alt，wp_get_attachment_image() 自動輸出 srcset、sizes、loading="lazy"。可移植原則：圖片描述具體（不是 image1.jpg）、響應式來源、原生 lazy load。
9. RSS feed
WordPress 預設 /feed/。雖然不直接是排名因子，但幫助 Google Discover、IndexNow 與其他爬蟲快速發現新內容。可移植原則：產 RSS/Atom feed，並在 <head> 加 <link rel="alternate" type="application/rss+xml">。
10. 穩定的發佈頻率訊號
WordPress 文章有明確的 published、modified 日期，會出現在 sitemap 的 <lastmod> 與 schema 的 dateModified。Google 用這判斷「這站是否還活著、值不值得常爬」。可移植原則：sitemap 要有正確 <lastmod>、文章 schema 要有 dateModified。
這 10 條串起來看會發現一件事：WordPress 的 SEO 優勢全部是預設值的勝利，沒有一點是 Google 偏心。如果你用的技術組合也把這 10 條做到，效果是一樣的。
8 支 WordPress SEO 外掛怎麼定義「SEO 分數」
研究完「為什麼友善」，我接著想看「業界怎麼把 SEO 量化成分數」。這部分是這次研究最有趣的地方——8 支外掛開出 8 種解法，反映出非常不同的設計哲學。
Yoast SEO：每題一分，加總算成績
像中學老師改一份選擇題試卷——每一題都一樣重要，答對幾題就是幾分，最後換算成 0 到 100。Yoast 的核心分數叫 linkdex，裡面到底有哪幾題、每題具體怎麼算其實看不到（演算法封裝在編譯過的 npm 套件裡），但從它跟 WordPress 連接的程式碼可以確認：所有檢查項目同等權重，加總後映射到 0-100。
等級切分也非常乾脆：
- 🔴 Bad：1-40
- 🟡 OK：41-70
- 🟢 Good：71-100
設計哲學：把判斷簡單化，作者不用糾結哪題比較重要，全做完就對了。
Rank Math：每題不同分，全部公開
像考駕照——筆試多少分、路考多少分、扣幾分、扣什麼項目，全寫在公告板上，你算得出來自己為什麼及格或不及格。Rank Math 是 8 支裡面演算法最透明的，公式直接寫在原始碼裡：
分數 = (通過項目權重總和 / 全部項目權重總和) × 100每一項檢查的權重也都寫死在程式裡，每個人都可以打開來看。比較有趣的是它把「整個網站」跟「單篇文章」的項目混在一起算，最高權重的幾項是：
| 項目 | 權重 |
|---|---|
| safe_browsing（安全瀏覽） | 8 |
| ssl | 7 |
| permalink_structure | 7 |
| noindex 檢查 | 7 |
| h1 唯一存在 | 5 |
| description meta | 5 |
可以看到 Rank Math 認為「網站基礎設施」（SSL、安全瀏覽、永久連結結構）比「單篇文章寫得好不好」更重要。設計哲學：每一項檢查的份量都攤開來給你看，你算得出每一分是怎麼來的。我自己最後在內部工具裡採用的就是這個風格。
AIOSEO（TruSEO）：作業送出去，老師在遠端改
像把作業掃描上傳到雲端，分數從遠端跑回來給你看，但你看不到老師怎麼改的。AIOSEO 號稱有 TruSEO 評分系統，但拆原始碼會發現——評分不是在你的網站上算的，是打到 AIOSEO 自家伺服器（https://analyze.aioseo.com/v3/analyze/）那邊算完再傳回來。本地只留 3 項基礎檢查（內容長度、標題長度、有沒有圖片或影片）給斷線時用，完整評分演算法都鎖在 AIOSEO 雲端。
設計哲學：演算法是公司的商業資產，使用者只負責看結果。對 AIOSEO 來說維護成本最低，可以隨時調演算法不用發外掛更新；對使用者來說透明度最低，沒辦法驗算分數怎麼來的。
Slim SEO：根本不考試，直接幫你寫完作業
像補習班直接幫你把作業寫完，不打分數，因為「該做的都做了」。Slim SEO 是這次研究最讓我意外的一支——它完全沒有頁面評分介面，純粹在背後默默把事情做掉：自動產生 meta 標籤、Schema 結構化資料、Open Graph、Sitemap、麵包屑、Canonical、Robots.txt，連圖片缺 alt 都幫你自動補。它甚至有 AI 自動產 title 和 description 的功能，但就是不打分數給你看。
設計哲學：作者不該被分數綁架，把該做的事情自動做掉就好。這呼應了「適切技術」的概念——選恰好足夠的方案，不要為了分數而過度設計。
SmartCrawl：錯一題扣固定分
像國中段考——總共 19 題，錯一題扣 5.26 分（100 ÷ 19），每題份量一樣。SmartCrawl 用的就是這個最簡單的公式：
分數 = 100 - (失敗項數 / 總檢查項數) × 10019 題分兩類：一類是檢查文章原始內容（標題長度、關鍵字是否在 title 等，9 題），另一類是檢查渲染後的網頁（圖片 alt、內鏈外鏈、副標關鍵字等，7 題）。結果只有三檔：100 分 = Good、低於 100 但有錯 = Needs Improvement、根本沒填關鍵字 = No Focus Keyword。
設計哲學：簡單透明，但不告訴你哪題比較重要。如果你少寫了一個 description，跟少設一個 canonical，扣分一模一樣，但實際對 SEO 的傷害天差地遠。
Squirrly SEO：選錯題目可能直接零分
像考論文——選對題目比寫得漂亮重要。如果你選了一個全網搜尋量爆表、競爭度滿格的關鍵字，文章寫得再好都很難擠進前 20 名。Squirrly 用「綠燈／紅燈」搭配扣分，每項任務有兩個資訊：完成沒、沒完成扣幾分。挖出來的權重大概是這樣：
| 任務 | 扣分權重 |
|---|---|
| 關鍵字競爭度合理 | 15 |
| Audit 分數 ≥ 70% | 5 |
| LSI 語意關聯詞策略 ≥ 30% | 5 |
| 內鏈 ≥ 5 條 | 5 |
| Nofollow 檢查 | 5 |
注意第一行——8 支裡面唯一把「關鍵字選得好不好」列為最重要的外掛，比所有技術項目都重。Squirrly 還會檢查「文章是否在 3 個月內更新過」這種其他外掛沒看過的「內容新鮮度」指標，提醒你舊文章該回頭整理。
設計哲學：選對戰場比優化技術重要——這個視角是其他外掛缺少的。
SureRank：不打分數，只給待辦清單
像家裡的清潔提醒 App——不告訴你今天家裡乾淨幾分，只列出「還有哪些地方該打掃」。SureRank 是 Brainstorm Force 最近推出的新外掛，它連分數都不給，只在介面上顯示「還有 X 項待修」這個徽章。
每個檢查項分四種狀態：失敗（會被列入清單）、警告、通過、建議——但只有「失敗」會出現在徽章數字裡。比較貼心的是它有「忽略」機制，讓使用者可以標記「這項我刻意這樣做的，不要再提醒我」（例如某個頁面就是要 noindex，不該被當成錯誤一直扣分）。
設計哲學：拋棄分數遊戲，只給優先處理清單。Slim SEO 是「全部幫你做掉」，SureRank 是「告訴你還有什麼沒做」，兩支都不相信「滿分」這件事有意義。
Xagio SEO：紅綠燈，沒有數字
像汽車儀表板——綠色就 OK，黃色該注意，沒有「你開車技術 87 分」這種事。Xagio 也不給 0-100 分，每項就用綠色或黃色標示通過與否。檢查項目分兩類：跟焦點關鍵字相關的（標題裡有沒有關鍵字、URL 裡有沒有關鍵字、副標裡有沒有等）、跟技術相關的（標題長度、描述長度、媒體有沒有、連結數量）。
比較特別的是它把「內容好不好讀」也納入評分，用了一條叫 Flesch-Kincaid 的可讀性公式：
rate = 206.835 - 1.015 × wordsPerSentence - 84.6 × syllablesPerWord簡單講就是「句子越短、單字越短，越好讀」。這套公式只算英文，套到中文意義不大，但思路值得借鑑——內容好不好讀本身就是 SEO 的一環，不是只有 meta 跟 schema 重要。
三大設計哲學
把 8 支外掛攤開比一比，會看到三條截然不同的路線：
| 派別 | 代表外掛 | 核心理念 |
|---|---|---|
| 分數派 | Yoast、Rank Math、AIOSEO、SmartCrawl、Squirrly | 給數字讓使用者追求滿分 |
| 清單派 | Slim SEO、SureRank | 不給分數，只列待辦事項 |
| 色塊派 | Xagio | 視覺化通過/未通過，不量化 |
分數派裡面，Rank Math 的加權公式最透明（每項權重都看得到）、Squirrly 的關鍵字競爭度視角最獨特、Yoast 的等級切分最簡潔。清單派的 Slim SEO 主張「把事情做掉就好，不要讓作者去追分數」、SureRank 主張「告訴你還有什麼沒做就好」。色塊派的 Xagio 在中間，提供視覺反饋但不糾結數字。
哪一種比較好？這跟你的品質量化哲學有關——如果你信「設定明確的通過門檻可以避免無限拉扯」，分數派比較適合你；如果你信「作者該專注內容，工具默默把基礎建設做掉」，清單派比較適合你。
把這些原則整合到自己的工具裡
研究做完後，我把學到的東西整合進了 codotx 內部用的 seo-audit skill。最後採取的設計：
- 權重結構參考 Rank Math——明確的加權公式，可驗算
- 單頁分數和站點分數拆開——避免 SSL 這種站點層的項目把所有頁面分數同步偏移
- 加入 Squirrly 的「關鍵字競爭度」維度——從 GSC 自動取每篇文章曝光最高的 query 當焦點關鍵字，再丟給 DataforSEO 算競爭度
- 加入 SureRank 的 ignore 機制——常青頁、刻意 noindex 的頁面不該重複扣分
- 加入內容新鮮度檢查——這是 Squirrly 教我的
整套流程把 WordPress 那 10 條結構優勢拆成 0-100 可量化的分數，套用在我們用 Astro 寫的官網上——實際跑出來的分數曲線，跟我們在 GSC 看到的搜尋表現有合理相關，分數高的頁面排名也比較穩。
回到一開始那個反直覺的問題——「WordPress 的 HTML 那麼亂，為什麼 SEO 還是好？」現在的答案是：HTML 亂不亂從來不是重點，結構清不清楚才是——WordPress 把結構部分做對了，剩下的亂只是「裝飾性的雜訊」，Google 看得懂哪些是主內容、哪些不是，一個都不會弄錯。
如果你也在自架靜態網站、或在評估該不該換 CMS，先別管「平台選誰比較有利」這個假議題，直接拿這 10 條去檢查你現在的網站，做完該做的，剩下的交給 Google。
延伸思考
這篇文章的觀點建立在幾個前提上，值得進一步思考：
- Mueller 的「沒有偏心」等於演算法真相嗎——WordPress 佔全球 40% 市佔率，Google 的爬取與解析 pipeline 對它的熟悉度遠高於其他 CMS，這種結構性的「de facto 偏心」跟官方口徑未必一致。
- CWV 只是 tiebreaker，有沒有閾值邊界——Mueller 的例子都是「結構好 vs 結構壞」的極端對比，但 LCP > 4s 觸發 mobile-first 的 poor page experience 時，是否直接降權而非只是「平手時輸」，他沒畫清楚。
- 10 條原則混了兩種效果——sitemap/RSS/lastmod 影響的是「被發現機率」，schema/語意 HTML/內鏈影響的是「被排名機率」，兩者不完全等價，做齊之後的收益分配也不一樣。
其他領域也有類似的現象：
- 「預設值的勝利」= Convention over Configuration——WordPress 的 SEO 優勢跟 Ruby on Rails 的開發速度、iOS 的設計一致性同構，都是框架替使用者做出「大家都應該這樣做」的預設選擇，把正確做法設為零成本路徑。
- 評分三派 ≈ 管理學的 KPI / OKR / Traffic Light Reporting——分數派（Rank Math 加權公式）像 KPI、清單派（Slim SEO、SureRank）像 OKR / Definition of Done、色塊派（Xagio）像儀表板紅黃綠燈。選哪一派其實是管理哲學問題，不是技術問題。
- 「先理解、再排名」在 LLM / AEO 時代同樣成立——大語言模型檢索引用時比 Google 更依賴結構化線索，這 10 條的重要性不減反增。站內結構之外，AEO 還多了一條讀者主導的新訊號：讀者能把你設為 Google 偏好來源，主動推你進 AI 概覽與焦點新聞。
常見問題
Google 真的不會給 WordPress SEO 加分嗎？
不會。John Mueller 在多次公開場合明確否認過。WordPress 表現好的原因是它預設把 SEO 基礎建設做掉了（schema、sitemap、permalink、內鏈），不是 Google 給優待。其他技術組合只要把同樣的基礎建設做到位，效果一樣。
想開始做網站 SEO，這 8 支外掛該選哪個？
如果你重視「演算法透明、可驗算」選 Rank Math；如果你重視「不要被分數綁架」選 Slim SEO；如果你想要「強調關鍵字選擇而非技術細節」選 Squirrly。Yoast 是最老牌、社群討論最多，但功能跟 Rank Math 高度重疊。AIOSEO 因為演算法在遠端，不建議追求透明度的使用者選用。
用 Astro、Next.js 或 Hugo 蓋的網站，沒有這些 SEO 外掛怎麼辦？
文章裡那 10 條結構原則就是你的 checklist。每一條都可以在前端框架裡手動實作：JSON-LD 用 <script type="application/ld+json">、sitemap 用框架內建的 sitemap 套件（Astro 有 @astrojs/sitemap、Next.js 有 next-sitemap）、內鏈用相關文章/上下篇元件。把這 10 條做齊，效果不會比裝 Rank Math 的 WordPress 站差。
Core Web Vitals 真的不重要嗎？
不是不重要，是「重要程度被高估」。Mueller 自己說 CWV 比較像 tiebreaker——當兩個站結構與內容相當時，比較快的那個贏。但結構好但慢的站，會贏結構亂但快的站。先把結構做對，再優化速度，順序不要顛倒。
Google 偏好來源
喜歡我們的內容嗎？一鍵將我們設為偏好來源，未來在 Google 焦點新聞與 AI 概覽中就能優先看到我們的文章。