E-E-A-T 是什麼？SEO 顧問用 Who、How、Why 建立信任

先給結論： E-E-A-T 是 Google 用來描述「內容值不值得信任」的四個面向——經驗（Experience）、專業（Expertise）、權威（Authoritativeness）、信任（Trust）。它不是一個你可以查詢的分數，Google 也明確說明 E-E-A-T 本身不是特定排名因素。所以正確的做法不是「去提高 E-E-A-T」，而是回答三個能被讀者實際查證的問題：這篇內容誰負責（Who）、怎麼產生（How）、為什麼要做（Why）。這三個問題的答案必須寫在頁面上，看得到，才算數。

E-E-A-T 是什麼、不是什麼

先把邊界劃清楚，後面的判斷才不會走偏。

四個面向可以用一句話各自說明：

• Experience（經驗）：內容是否來自實際接觸過該事物的人。
• Expertise（專業）：內容是否具備處理該主題所需的知識深度。
• Authoritativeness（權威）：在這個主題上，這個人或這個網站是否被視為合理的資訊來源。
• Trust（信任）：內容是否準確、誠實、來源清楚。Google 把信任列為其中最重要的一項。

這四個詞是評估語言，不是執行指令。要把它變成可執行的動作，得換成 Who、How、Why。

Who：這篇內容誰負責？

Google 在內容自我評估的指引中建議，內容應該讓讀者一眼看得出是誰寫的，並且在讀者會期待署名的地方放上署名。這一段要做到三件事。

1. 姓名要看得見。 頁面上要有實際的人名，不是「編輯部」「小編」這種無法對應到任何人的標籤。

2. 姓名歸姓名，角色歸角色。 這一點在結構化資料上特別重要。Google 的 Article 結構化資料文件明確要求：author.name 只放作者的名字，不要加入職稱、敬稱或其他任何資訊。所以正確與錯誤的寫法是：

3. 要有可以往下查的地方。 Google 建議署名能連向作者的背景資訊，並在結構化資料中使用 url 或 sameAs 指向能識別該作者的頁面。本文目前使用已驗證的 LinkedIn 與 GitHub 個人檔案作為 sameAs；站內作者頁一旦建立，才會補上 author.url。在作者頁實際存在之前，不應該先填一個還不存在的網址——結構化資料只能標記真實存在的東西。

示例情境（非客戶案例、非成效證明）

一個網站的文章底部寫著「本文由編輯團隊撰寫」。讀者想確認撰寫者的背景，但頁面上沒有姓名、沒有可點擊的連結，也沒有任何說明。此時要補的不是「更多關鍵字」，而是一個具體姓名、一個角色標示，以及一個能查到這個人的連結。本段為說明用的假設情境，不是客戶案例，也不代表任何已驗證的成效。

How：這篇內容怎麼產生？

Google 的指引把「內容如何產生」列為讀者合理會想知道的事，特別是牽涉到自動化或 AI 協助時，建議說明產製方式。這一段回答的是方法，不是結論。

要揭露的內容包括：

• 資料從哪裡來（官方文件、自家網站的後台觀察、公開資料）。
• 用什麼方式整理（人工審閱、既有流程、是否有工具輔助）。
• 誰審閱過、什麼時候審的。
• 這些資料不能推論出什麼。

最後一項最常被略過，但它是信任的關鍵。舉例來說，Search Console 的曝光量是「這個查詢的結果頁曾經出現過這個網址」的觀察值，它不等於點擊、不等於詢問、更不等於成交。把曝光量寫成「成效」，就是把觀察值當成結論——這會直接損害內容的可信度。

如果你想知道這些觀察值該怎麼正確讀、哪些數字可以拿來比較、哪些不行，可以參考用 Search Console 追蹤搜尋表現的做法。

Why：為什麼要做這篇內容？

Google 把「為什麼製作這則內容」形容為其中最重要的問題，並區分兩種動機：為了幫助讀者完成某件事，或者主要是為了吸引搜尋引擎的造訪。後者不是 Google 系統想獎勵的方向。

判斷方式很直接：把這篇內容給一個實際有這個問題的人看，他讀完之後能不能做出下一個決定？如果可以，Why 就成立。如果讀完只知道「這個主題很重要」，那這篇內容的存在理由就不夠。

這也是為什麼「先確認一個查詢背後是什麼任務」會排在寫作之前。關於如何判斷一個查詢是否值得做成頁面，屬於另一個主題，可以參考判斷關鍵字是否值得做的流程。

可驗證：看得到的，才能標記

揭露有一條底線：頁面上看不到的東西，不要放進結構化資料。 這是屏柏內部的內容品質關卡，也是結構化資料的基本原則——標記是用來描述頁面內容的，不是用來補頁面沒有的內容。

另外，ProfilePage 這種標記是給「以單一人物或組織為主要焦點」的作者介紹頁使用的，不是給一般文章頁使用。沒有這樣的頁面之前，不需要也不應該加。

執行檢查清單

在一篇內容送審之前，逐項確認：

• 頁面上有可見的作者姓名，不是集體代稱。
• 角色／職稱與姓名分列顯示，沒有混進姓名字串。
• 署名附有一個能實際查到這位作者的連結。
• 作者背景中僅呈現可公開查證的項目，並附有公開網址與查核或觀察日期。
• author.name 只有姓名，沒有其他資訊。
• author.url 只在站內作者頁真的存在時才填。
• 頁面上有可見的發佈日期與更新日期，且與結構化資料一致。
• 有一段說明資料來源、整理方式與審閱時間。
• 有明確寫出這些資料不能推論出什麼。
• 所有舉例都標明是示例，並說明不是客戶案例、不是成效證明。
• 沒有任何排名、流量或成效的保證性語句。
• 沒有標記頁面上看不到的內容（含 FAQ）。
• 這篇內容能讓讀者做出下一個決定，而不只是知道主題重要。

常見的錯誤做法

1. 把 E-E-A-T 當成待辦清單勾選。 補了作者欄位、補了外部連結，但讀者仍然無法確認任何一件事。
2. 用無法驗證的形容詞代替事實。 「資深」「專業團隊」「多年經驗」如果沒有可查證的依據，只會增加懷疑。
3. 把觀察值寫成成果。 曝光量、平均排名的變化都是觀察值，不是成效。
4. 標記超出可見範圍。 頁面沒有 FAQ 區塊卻加上 FAQ 標記，這是標記與內容不一致。
5. 把角色寫進姓名。 這會讓結構化資料中的作者名稱不再是一個人名。
6. 把未附外部證據的背景敘述當成已驗證。 沒有外部證據網址的資格與獎項，不應寫成第三方已查核。

審閱方法、資料來源與限制

方法。 本文的判斷依據為 Google 官方公開文件中對內容自我評估與結構化資料的說明，並對照本站自身頁面的實際狀態進行整理。本文依上述方法整理，並於發布前完成內容檢核。

站內觀察。 本站目前有 784 篇已發佈文章。在 Search Console 觀察窗期 2026-04-25 至 2026-07-23 之間，與 E-E-A-T 相關的查詢變體合計獲得 122 次曝光。

限制（重要）。 曝光量是搜尋結果的觀察值，代表這些查詢的結果中曾出現本站網址，不等於點擊、不等於諮詢、不等於任何成效，也不構成因果證據。本文不以這個數字主張任何改善結果。此外，本文所有舉例皆為說明用途的假設情境，不是客戶案例，也不是實測結果。本文不提供任何排名或流量的保證。

官方資料來源

• Google 搜尋中心｜建立實用、可靠、以使用者為優先的內容（含 Who、How、Why 自我評估問題，以及 E-E-A-T 的說明）
• Google 搜尋中心｜Article（文章）結構化資料（含 author、author.name、author.url、datePublished、dateModified、image、headline 的建議用法）
• Google 搜尋中心｜Profile Page（個人檔案頁）結構化資料（含 mainEntity、sameAs 與單一人物頁面的適用條件）

延伸閱讀

• 待辦太多、不知道先做哪一項時：用影響、信心與成本排出優化順序
• 想了解屏柏實際處理過的網站與 SEO 工作範圍：SEO 作品集

接下來可以做什麼

如果你不確定自己的網站在「誰負責、怎麼產生、能不能查證」這三件事上目前處於什麼狀態，可以預約一次作者署名、資料來源與結構化資料健檢。健檢會逐頁檢視可見署名、日期、來源揭露，以及結構化資料是否與可見內容一致，並列出需要處理的項目與順序。健檢說明現況與待處理項目，不承諾任何排名或流量結果。