跳至主要內容

FAQ Schema 還有用嗎?2026 年失效的三個 SEO 做法

作者:Clone發布日期:修改日期:分類:SEO優化閱讀時間:約 11 分鐘

已停用 SEO 做法示意圖,三張標記卡片上蓋著停用印章,旁邊仍亮著的是結構化資料與內容品質
目錄
  1. 先講結論:三件事已經不成立
  2. FAQ 複合式搜尋結果:兩則公告,一個明確的日子
  3. HowTo:已經走了三年,但還在很多文章裡
  4. llms.txt:Google 講得比任何人都直白
  5. 那生成式 AI 功能到底要做什麼?
  6. 沒有失效的部分
  7. 怎麼自己查,不必相信任何人
  8. 我們自己的校訂紀錄
  9. 常見問題
  10. FAQPage 標記現在該拆掉嗎?
  11. 那頁面上的常見問題區塊還要不要寫?
  12. llms.txt 做了到底有沒有用?
  13. 現在還有哪些結構化資料類型是有版位的?
  14. 既然 AI 功能不需要特殊標記,那要做什麼?

寫這篇的直接原因是:我們自己的網站上有九篇 SEO 文章,其中四篇在推薦一個 2026 年 5 月就已經停止運作的功能。

發現的時候有點難堪——我們把「不寫沒有依據的東西」當成全站的原則,結果自己的內容停在 2023 年的認知。這篇把該校訂的東西一次講完,順便把查證方式寫下來,讓你可以自己驗,不必相信我們。

先講結論:三件事已經不成立

做法現況官方依據
FAQ Schema(複合式搜尋結果)2026-05-07 起停止顯示,文件 2026-06-15 整份移除Google 文件更新紀錄
HowTo 複合式搜尋結果2023-09 移除,2026 年仍未恢復Google 文件更新紀錄
llms.txt 影響 Google 排名Google Search 完全忽略Google AI 優化指南

三件事的共同點是:它們曾經是真的,只是現在不是了。而 SEO 內容最容易過期的地方,正好是這種「曾經正確」的部分——它不像明顯的錯誤會被人指出來,它只是安靜地失效。

FAQ 複合式搜尋結果:兩則公告,一個明確的日子

Google 在文件更新紀錄裡留了兩則。

2026 年 5 月 8 日加上停用通知,原文寫得沒有模糊空間:

This feature will no longer appear in Google Search starting May 7, 2026.

2026 年 6 月 15 日把整份 FAQ 結構化資料文件移除,理由是「這個功能已經不再顯示在 Google 搜尋結果中,如 5 月的更新紀錄所公告」。

這次沒有例外。2023 年那一輪限縮還保留了政府與醫療網站的顯示資格,這一次是整個功能下架。

所以現在標 FAQ Schema 等於什麼? 等於一份不會產生版位、但也不扣分的標記。它仍然是合法的 schema.org 型別,Search Console 不會報錯。要不要留是成本問題,不是風險問題——如果你的 FAQ 是從同一份資料自動輸出的,留著幾乎沒有維護成本;如果每次改問答都要手動同步兩個地方,那就拆掉。

真正要檢查的是另一件事:標記裡的問答,頁面上有沒有真的寫出來。這條規則沒有變,而且是 Google 對生成式 AI 功能唯一給得出的可操作建議。我們自己就踩過——有兩篇文章的 frontmatter 寫了問答、但內文從來沒有那個段落,等於標記宣稱了頁面上不存在的東西。

FAQ 停用時間線圖,展示公告停用、功能關閉、文件下架三個時間點,以及關閉之後標記仍然合法

HowTo:已經走了三年,但還在很多文章裡

HowTo Schema 的文件在 2023 年 9 月就整份移除了,Google 當時的公告把 HowTo 與 FAQ 的變動寫在同一篇。2026 年的複合式搜尋結果庫裡沒有它,也沒有任何恢復的跡象。

它之所以還活在中文 SEO 內容裡,是因為「教學文要標 HowTo Schema」聽起來很合理。合理不等於還有效。

替代做法:流程與步驟改用 ItemList。它語意正確、不會產生無效項目,生成引擎一樣讀得到。本站七個服務頁的「怎麼進行?」段落就是這樣做的——不是因為 ItemList 有版位(它單獨使用時也沒有),而是因為它誠實描述了「這是一個有順序的清單」。

llms.txt:Google 講得比任何人都直白

這一條最值得完整引用,因為坊間的說法落差最大。

Google 的 AI 優化指南(2026 年 5 月 15 日新增,7 月 10 日更新)原文:

You don’t need to create new machine readable files, AI text files, markup, or Markdown to appear in Google Search (including its generative AI capabilities), as Google Search itself doesn’t use them.

以及:

Doing so will neither harm nor help your site’s visibility or rankings in Google Search, as Google Search ignores them.

同一份文件在 6 月 15 日還特別補了一則更新紀錄,說明加註的原因是「回應社群的疑問,釐清這些檔案對 Google 搜尋並非必要——但你想維護它也沒關係」。

那 llms.txt 到底該不該做? 我們自己的網站有一份,而且是動態產生的。理由不是排名,是三件事:產生成本接近零、部分非 Google 的檢索服務與編碼代理確實會讀、以及它逼你把網站的內容地圖想清楚一次。

不該做的是:拿它當賣點、拿它評估 SEO 廠商、或期待做完排名會動。我們自己的如何選擇 SEO 公司先前把它列為五星級的評估項目,那是錯的,已經改掉了。做法本身寫在 llms.txt 完整配置教學,那篇的定位現在也調整成「低成本加分項」。

llms.txt 讀取狀況圖,展示最大的那個搜尋引擎不讀取,只有部分檢索服務會讀

那生成式 AI 功能到底要做什麼?

同一份官方指南給了答案,而且答案無聊得令人安心:

Structured data isn’t required for generative AI search, and there’s no special schema.org markup you need to add.

它建議的三件事是:

  • 繼續做基本功——清楚的技術結構、獨特而有價值的內容,這是在生成式 AI 搜尋裡能見的基礎
  • 發展專家主導的獨特內容,提供超出常識範圍的價值
  • 用 Search Console 的生成式 AI 成效報表看實際表現

換句話說:沒有捷徑型的標記可加。這跟很多 GEO 教學講的不一樣,但這是 Google 自己寫的。

值得一提的是 2026 年 5 月 27 日還推出了「偏好來源」(preferred sources),開始出現在 AI Overviews 與 AI Mode——那是使用者端的選擇機制,不是網站端可以標記的東西。

沒有失效的部分

把話講平衡:下面這些在 2026 年仍然成立,而且比任何標記都重要。

  • Core Web Vitals 三項指標與門檻沒有變:LCP 2.5 秒、INP 200 毫秒、CLS 0.1,取第 75 百分位的真實使用者資料,行動與桌機分開判定。沒有新指標、沒有節奏變更。
  • 結構化資料與可見內容一致:這是官方對 AI 功能唯一給得出的可操作建議,也是最容易違反的一條。
  • 實用內容準則:為人寫、不為排名寫。這條從 2022 年講到現在。
  • 仍有版位的類型:Article、Breadcrumb、Organization、Product、Video、Review snippet、Profile page、Speakable 等,以複合式搜尋結果庫為準。順帶一提,2026 年 1 月 6 日「practice problem」也被移除了——這份清單會繼續縮。

怎麼自己查,不必相信任何人

這是這篇最有用的部分。三個網址,遇到任何「某某 Schema 很重要」的說法都可以自己驗:

  1. Google 文件更新紀錄——每一次文件變動都有日期與原因。想知道某個功能什麼時候沒的,在這裡搜。
  2. 複合式搜尋結果庫——現行有版位的類型清單。不在上面的,就是沒有版位。
  3. AI 功能與網站優化指南——官方對生成式 AI 的立場,2026 年 7 月更新。

判準很簡單:一個 SEO 建議如果指不出上面三個來源的其中一個,就當它是傳聞。

查證方式圖,展示三份官方來源匯聚成一個判準:指得出來源就是有依據,指不出來就當成傳聞

我們自己的校訂紀錄

把話說清楚:這篇不是站在旁邊評論別人。上面每一條我們自己都寫錯過。

2026 年 9 月,我們把站上的相關敘述整批校訂:

也順便講一件事:2026 年 2 月到 9 月之間,這個部落格停了七個月沒有更新。那段時間的精力放在網站改版與自有系統上。停更的代價就是這篇要處理的東西——內容會安靜地過期,而且愈是寫得篤定的句子,過期之後愈難看。


本文引用資料來源:Google 文件更新紀錄Google:AI 功能與網站優化指南Google 複合式搜尋結果庫Google:HowTo 與 FAQ 複合式結果的變動(2023)Google:搜尋結果中的 AI 功能web.dev:Core Web Vitalsllmstxt.org

常見問題

FAQPage 標記現在該拆掉嗎?

不用拆。它不會扣分,維護成本也趨近於零,而且對不使用 Google 的解析器仍有意義。要改的是預期:不要再把它當成「會長出版位」的手段。真正該檢查的是,頁面上有沒有真的寫出那些問答——標記與可見內容不一致才是會出事的地方。

那頁面上的常見問題區塊還要不要寫?

要,但理由換了。問答這種寫法本身就對得上長尾查詢,也讓讀者不必來信問。有價值的是問答的內容,不是外面那層 JSON-LD。判準很簡單:這一題買家真的會問嗎?會就寫,不會就別為了湊標記而寫。

llms.txt 做了到底有沒有用?

對 Google 沒有用——官方明講 Search 完全忽略它,「既不會有幫助、也不會有傷害」。它目前有實際抓取紀錄的是編碼代理與部分非 Google 的檢索服務。成本極低,當加分項無妨,但不該拿它評估 SEO 廠商,也不該期待排名有變化。

現在還有哪些結構化資料類型是有版位的?

以 Google 的複合式搜尋結果庫為準,那份清單就是唯一的答案。撰文時清單上有 Article、Breadcrumb、Organization、Product、Video、Review snippet、Profile page、Speakable 等,沒有 FAQ、沒有 HowTo。這份清單會變,所以不要背它,要去查它。

既然 AI 功能不需要特殊標記,那要做什麼?

Google 自己給的答案是回到基本功:清楚的技術結構、獨特而有價值的內容、以及超出常識範圍的專業內容。另外 Search Console 有生成式 AI 的成效報表可以看實際表現。沒有捷徑型的標記可加,這件事官方講得比任何人都直白。

RELATED

< NEED_HELP />

想把這篇的做法用在自己的系統上?

寫信講現況,我們回你從哪一步開始。 收到後先回覆能不能做。

// WAITING_FOR_INPUT...