Schema 還值得做嗎：企業站的優先順序取捨（2026）

這兩年再聊 Schema，最容易犯的錯，不是不會寫，而是還在用 2021 年、2022 年那套想象。很多團隊還把 FAQ、HowTo、Review 星標當成結構化資料的主戰場，覺得只要外掛一開、JSON-LD 一掛，搜尋結果就會更花、更亮、更容易拿點選。現實已經不是這樣了。

從 2023 年到 2025 年，Google 一直在收縮和重排 rich results 的展示邏輯。Google 在 Changes to HowTo and FAQ rich results 裡已經明確說過：FAQ rich results 主要只給政府和健康類權威站點；HowTo rich results 也已經退出 Google Search 的常規展示舞臺。也就是說，很多企業站、外貿站、B2B 站過去最愛加的兩種 Schema，今天對可見展示的幫助，已經很有限。

但這不等於 Schema 沒用了。真正的問題變成了：哪些結構化資料現在還值得做，哪些只是“外掛預設生成、做了也不太產生搜尋收益”，以及企業站到底該把精力放在哪裡。本文就只講這個。

核心判斷：Schema 還值得做，但不值得再當“快速拿展示”的捷徑

Google 在 Introduction to structured data markup 和 search gallery 裡一直講得很清楚：結構化資料的核心價值，是幫助 Google 更明確理解頁面內容，並讓頁面有資格進入某些 richer search features。注意，是“有資格”，不是“必展示”。

這句話很重要。因為很多團隊把 Schema 理解成了一個直接換 CTR 的開關。今天更穩的理解應該是：Schema 是內容理解層和候選資格層的一部分，不是保證展示的門票，更不是能替代內容、頁面和信任訊號的捷徑。

Google 在 general structured data guidelines 裡也明確寫著：即使標記完全正確，Google 也不保證一定展示 rich result。這個提醒很值錢。因為它直接說明了一件事，Schema 的 ROI 不能只用“有沒有出展示”來判斷，還要看它是不是在幫頁面理解、資訊對齊和長期維護上減少歧義。

FAQ 和 HowTo 為什麼不該再當企業站主攻方向

這件事其實不用再靠經驗判斷，Google 自己已經說了。FAQ rich results 現在主要保留給政府和健康類權威站點。HowTo rich results 也早就退出了 Search 的常規展示路徑。Google 在官方部落格裡甚至直接說過，對大多數站點來說，就算保留這類結構化資料，也不會再經常看到原來那種可見結果。

把時間線說精確一點(很多文章還在含糊其辭):

所以如果今天還有企業站把“批次加 FAQ Schema”“全站自動套 HowTo Schema”當成一條高優先順序 SEO 專案，方向大機率已經偏了。不是說絕對不能有，而是說它不再值得佔據前排資源。

別把“還能加”誤解成“還值得優先做”

Google 在 FAQ/HowTo 的官方說明裡也講得很清楚：你可以不主動刪掉這些結構化資料，它們本身不會因為存在就傷害搜尋。但“不傷害”不等於“值得優先做”。這兩件事要分開。

如果一個企業站現在技術資源有限，頁面基礎問題還很多，抓取、收錄、連結可抓取、重複 URL、頁面模板質量都還沒梳順，那繼續花大量時間在 FAQ 和 HowTo 上，通常不是最划算的投入。它們今天更像可有可無的補充項，不是主線專案。

現在更值得做的，不是“炫”的 Schema，而是穩定、貼頁面事實的 Schema

如果把 2025 到 2026 的實際優先順序往下排，企業站和 B2B 站更值得優先看的，通常是這些：

• Breadcrumb
• Organization
• Article
• Product
• Review / AggregateRating，但前提很嚴格

它們的共同點，不是“最容易長出花哨展示”，而是更貼近頁面真實內容，也更容易長期維護。Google 在 organization markup 更新說明 和 product variants 支援說明 裡其實也體現出同一條線：更重視真實商品、真實組織、真實頁面結構，而不是泛化裝飾型 Schema。

Article Schema 仍然值得做，但它是“配套項”，不是內容質量替代品

對內容站、企業部落格、教學文章來說，Article 相關結構化資料仍然值得保留。Google 在 Article structured data 文件裡持續支援這類標記。它的意義，是幫助 Google 更明確理解文章標題、圖片、作者、釋出時間這類基礎欄位。

但這類 Schema 的問題在於，很多站會把它誤解成“只要掛了 Article，文章就更容易排”。這個邏輯並不成立。Article 更像是對已有內容實體的清晰描述，不會替代選題、內容深度、證據、內鏈和站內結構。你可以把它理解成資訊對齊，不是排名魔法。

Product Schema 的價值，取決於你是不是真的在賣清楚的產品

如果網站裡是明確的產品頁，Product Schema 仍然是高價值項。尤其是 Google 在 2024 年新增了對 Product variants 的支援之後，產品變體管理比以前更值得認真做。

但這裡有個邊界。不是所有“服務介紹頁”“解決方案頁”“產品能力頁”都適合硬套 Product。結構化資料最怕的，就是頁面現實型別和標記型別不一致。你明明是企業服務頁，卻用 Product 偽裝成商品頁，這類做法短期可能過測試，長期並不穩。

對 B2B 企業站來說，更現實的判斷通常是：

• 真實單品頁、型號頁、SKU 頁，優先考慮 Product。
• 品牌/組織層資訊，優先做 Organization。
• 教學文章、觀點文章、行業文章，優先做 Article。
• 不要為了追求 rich result，把所有頁面都往商品模型裡塞。

Breadcrumb 為什麼經常被低估

很多人提 Schema，先想到星星、FAQ 摺疊、價格、庫存，卻忽略 Breadcrumb。其實 Breadcrumb 這類結構化資料沒有那麼“炫”，但很穩。它幫 Google 理解頁面所在層級，也幫搜尋結果更清楚展示路徑。這對產品頁、分類頁、文章頁都很實用。

而且 Breadcrumb 往往和真正的可抓取連結體系是一體的。你如果麵包屑本身就亂，層級也沒梳清，光補一個 JSON-LD，效果通常有限。這一點會和我們已經排進去的 連結可抓取、Orphan Pages 一起連起來。

所以 Breadcrumb 值錢的地方，不只是它是一個支援的 Schema 型別，而是它通常逼著你把層級、父子關係、站內路徑和連結系統先梳順。它更像結構治理，而不是裝飾項。

Organization 和品牌實體資訊，反而更符合現在的搜尋環境

Google 在 2023 年底擴充套件了 organization markup 的支援，邏輯很明確：Google 更在意品牌、組織、聯絡資訊、標識資訊這些更穩定的實體層訊號。對企業站來說，這種結構化資料未必總帶來顯眼的 rich result，但它更符合長期的品牌確認和實體理解。

對天問這種企業官網語境來說，真正值得做的，不是到處堆花樣 Schema，而是確保站點的組織資訊、logo、聯絡方式、品牌歸屬、站點層級這些基礎訊號清楚、一致、長期可維護。

Google 在 Organization 文件 裡給出的建議也很剋制：沒有強制必填項，但建議把真正對使用者有用、對實體消歧有幫助的資訊儘量補全。這個方向本身就說明了，Organization 更像品牌基礎設施，而不是花式增強。

Review 和 AggregateRating 不是不能做，但最容易做成違規區

很多企業站最迷戀的還是星標。問題也最多。Google 在 Review snippet 文件 裡寫得很清楚，哪些物件能用、哪些場景不合規、什麼叫 self-serving reviews，都不是可以隨便碰的。

尤其是企業自己給自己掛組織評分、服務評分、彙總第三方平臺評價，又把它包裝成自己頁面上的 rich result 候選，這類做法風險很高。不是語法過了就沒事，Google 還會看 guideline。這個邊界，很多外掛不會替你判斷。

外掛自動生成，不等於策略正確

這是 WordPress 和很多建站系統裡最容易被忽略的問題。Rank Math、Yoast、Shopify 外掛、模板主題，都會自動幫你生成一些 Schema。自動生成當然方便，但它解決的是“有沒有輸出”，不是“輸出得對不對、值不值得、和頁面是否一致”。

很多站的問題，不是完全沒有 Schema，而是全站預設吐出一堆並不重要、甚至型別不準的標記。比如所有文章頁預設加 FAQPage，所有服務頁都混進 Review，所有組織頁和產品頁的實體關係說不清。這樣的 Schema，即使語法合法，也不代表策略上划算。

企業站到底該怎麼排 Schema 優先順序

如果只給企業站一個實操順序，我會更建議這樣排：

1. 先核對 Google 目前還支援哪些 rich result 型別，不靠舊經驗判斷。
2. 先保住 Breadcrumb、Organization、Article、真實 Product 這些高確定性項。
3. 再檢查是否有 Review 風險、錯誤型別對映、外掛預設亂標的問題。
4. 最後才考慮 FAQ 之類低優先順序項，要不要留作補充。

這個順序的核心，不是“儘量多做”，而是“先做最不容易浪費資源、最不容易踩邊界、最貼頁面事實的”。這和我們最近在技術簇裡推進的思路是一致的：先修基礎治理，再談花樣增強。

怎麼驗收 Schema 值不值得保留，不要只看 Rich Results Test 透過沒透過

Rich Results Test 很有用，但它只回答一部分問題：語法和支援性大體是否過關。它不回答另外幾件更關鍵的事：

• 這個 Schema 現在還有沒有真實展示機會。
• 這個型別是不是和頁面現實一致。
• 這個標記會不會引導團隊繼續誤配資源。
• 這個標記後面能不能被內容團隊和技術團隊長期維護。

所以更穩的驗收方式，應該把這幾個工具和訊號一起看：

• Rich Results Test：看語法和支援性。
• Search Console 增強報告：看報錯、警告和有效項趨勢。
• 實際 SERP 展現：看這個型別現在是否真有可見收益。
• 頁面內容審查：看標記內容是否真在頁面上存在。

只看測試工具透過，就宣佈“Schema 專案完成”，太早了。

和技術 SEO、實體資訊、頁面型別治理的關係，要一起看

到了 2026 年，Schema 最值錢的地方，已經不只是“多一個標記”，而是它會逼著你回答很多基礎問題：

• 這個頁面到底是什麼型別。
• 這個組織資訊是不是全站一致。
• 這個產品頁是不是真正獨立、清楚、可交易。
• 這條麵包屑路徑是不是和站內結構一致。

也就是說，結構化資料做得好，背後往往不是因為外掛更高階，而是因為頁面型別、實體資訊、站內結構本來就更清楚。這一點和 技術 SEO、連結可抓取、SEO 審計 都是連著的。

最後一句：今天做 Schema，重點不在“加更多”，而在“刪掉錯的，保住值錢的”

如果把今天的 Schema 工作壓成一句話，我會更願意這麼說：別再把它當成一個批次上外掛、批次開模板、批次求花樣展示的專案。現在更值錢的，是先認清 Google 還支援什麼，再保住那些貼頁面事實、貼實體資訊、貼產品結構的標記，把不再有明顯收益、還容易誤導團隊的型別降級處理。

這樣做，頁面會更乾淨，維護會更輕，團隊也不會繼續被過時玩法拖著跑。對企業站來說，這比“多掛幾個看起來很全的 Schema”更有用。

Schema 的核心原則沒變：寫頁面上真實存在、使用者也能看到的東西

這一點，Google 的 general structured data guidelines 一直沒變：你標記的內容應該和頁面內容一致，使用者應該看得到，不能靠編造、隱藏、泛化複製來湊。

所以今天更現實的做法，不是先問“我還能不能靠 Schema 拿花哨展示”，而是先問：

• 這個頁面本來就有清楚的實體資訊嗎。
• 這個標記是不是和頁面事實一一對應。
• 後面能不能長期維護，不會一改模板就全站報錯。

如果這三件事答不上來，那優先順序通常不該太高。

相關閱讀

• 技術 SEO 怎麼做：抓取、索引、Canonical 與渲染排查清單
• SEO 審計怎麼做：從抓取、收錄到內容與內鏈的完整排查清單（2026）
• 連結可抓取怎麼檢查：導航、按鈕、JavaScript 連結與發現路徑排查（2026）
• Index Bloat 怎麼處理：低價值 URL、軟404 與索引膨脹清理順序（2026）