Discover 底層邏輯：被忽視的優先順序
 |
| 透過最新研究，揭示 Google Discover 的內容推薦邏輯，幫助SEO業者避免技術誤區。 |
長期以來，Google Discover（探索）一直被視為 SEO 的「黑盒子」。多數 SEO 業者僅能依賴 Google 官方文件的模糊指南或零散的觀察。然而，根據 Metehan Yesilyurt 2026 年最新 SDK 研究，我們終於能深入 Discover 的內容推薦流程（Content Pipeline），研究其底層運作邏輯，也許能導正過往技術誤區，重新審視那些決定內容生死、卻常被開發者忽視的技術細節。
優先導讀：Discover 內容處理的九大階段
 |
| 了解 Google Discover 的九大關鍵階段，揭示內容從產出到推送的完整流程。 |
在進入技術細節前，我們必須先理解內容從產出到出現在使用者手機中，究竟經過了哪些關卡。根據 SDK 框架分析，Discover 的運作機制可拆解為以下九個關鍵階段：
- 檢索與解析 (Crawling & Understanding)：
Google 爬取網頁內容，並透過實體提取（Entity Extraction）分配知識圖譜 ID (MIDs) 以識別主題。 - 讀取中繼資料 (Meta Tags Parsing)：
這是決定內容外觀的關鍵，系統會抓取標題、作者與圖片資訊，並存在嚴格的「硬編碼（hardcoded）優先序」。 - 內容屬性分類 (Content Classification)：
判定內容類型（如即時新聞、長青內容或短影音），並分配至 13 種不同的叢集類型 (Clusters)。 - 阻擋機制檢查 (Blocking Check)：
確認該內容或網站是否被列入黑名單，或檢查是否包含會導致流程中斷的特定標籤。 - 興趣媒合 (Interest Matching)：
透過 NAIADES 系統，將內容的 MID 與使用者的個人興趣標籤進行精準比對。 - 點閱率預測 (CTR Prediction)：
透過伺服器端模型（pCTR）預測該內容對該使用者的吸引力。 - 生成饋送流版面 (Feed Layout Building)：
根據預測結果與實驗分組（A/B Testing），編排個人化的動態時報版面。 - 內容推送 (Delivery)：
透過 gRPC 持續連線技術，將內容即時傳送到裝置上，系統甚至能在瀏覽中途抽換或重排內容。 - 紀錄回饋 (Feedback Recording)：
追蹤點擊、忽略或隱藏等行為。一旦點擊「隱藏」，該內容將被永久標記（Tombstoned）不再呈現。
一、 權力階級：Metadata 「硬編碼」排序邏輯
許多 SEO 專家習慣將優化重點放在 Open Graph (OG) 標籤上，認為這是 Discover 抓取標題、作者與圖片的主要來源。但從反編譯的代碼（如 dkpg.java）中發現，Discover 的解析器存在一個硬編碼的後備鏈（Hardcoded Fallback Chain），且其優先序與大眾認知大相徑庭。
 |
| 了解 Discover 的硬編碼排序邏輯，JSON-LD 標籤優先於 OG 標籤，確保最佳內容呈現。 |
1. Schema.org JSON-LD 是真正的王者
Google 強烈偏好且優先解析 JSON-LD，但也會參考 OG 作為補充／備援，如果 JSON-LD 中已定義了特定欄位，系統將直接採用。具體的優先順序如下：
a.標題 (Title)：
- Schema.org 結構化資料 (TEXT_TYPE_TITLE)
- og:title
- twitter:title
- 一般 HTML <title> 標籤
b.作者 (Author)：
- Schema.org 結構化資料 (TEXT_TYPE_AUTHOR)
- HTML 中的 author name 屬性
c.發布者 (Publisher)：
- Schema.org 結構化資料 (TEXT_TYPE_PUBLISHER)
- og:site_name
2.優先順序洞察：
綜合上述解讀，如果你的網站同時設定了 JSON-LD 與 OG 標籤，但兩者內容不一致，Discover 會優先呈現 JSON-LD 的版本。依賴 OG 標籤而不優化結構化資料忽略 JSON-LD，就是跳過了 Google 預設的最優先抓取管道，讓系統進入「後備」（Fallback）邏輯。
雖然過去很長時間 OG 標籤是有效的，但若要精準控制內容在 Discover 上的呈現，專業做法應該是主動提供（JSON-LD），以確保系統在第一時間就讀取到您最想呈現的資訊，而不是等系統找不到首選資料後才啟動後備機制。
二、 隱藏殺手：流程瞬斷的「阻擋標籤」
 |
| Discover 的「阻擋機制檢查」會因特定標籤剔除內容，影響優質內容的曝光機會。 |
在 Discover 的九大運作階段中，有一個關鍵環節是「阻擋機制檢查」（Blocking Check）。根據 SDK 數據，有兩個特定中繼標記（Meta Tags）會觸發系統異常（dkma），導致內容在解析階段就被直接剔除：
- notranslate：觸發「禁止翻譯」（DISALLOWED_FOR_TRANSLATION）訊號。
- nopagereadaloud：觸發「禁止朗讀」（DISALLOWED_FOR_READOUT）訊號。
技術警示：
許多 CMS 系統或翻譯外掛可能會自動注入這些標籤。一旦這些標籤出現在 HTML 中，系統會立即拋出錯誤並停止處理該頁面。這意味著你的優質內容可能連進入「興趣媒合」階段的機會都沒有，就死在了技術解析的門檻前。
三、 建立視覺護城河：1200px 大型圖片
在 Discover 的資訊流中，圖片的規格直接決定了內容的「曝光格式」。這不僅是美觀問題，更是點閱率（CTR）的基石。
- 1200px 與「大圖卡」的入場券
若要讓內容具備顯示「大圖卡」（Hero Card）的資格，圖片寬度必須至少達到 1200 像素。如果圖片過小，內容僅會以縮圖形式呈現，這通常會導致點擊量大幅下降。
圖片寬度需達1200px，否則內容僅顯示為縮圖，影響點擊率。 - max-image-preview:large：被遺忘的開關
即便你上傳了高清大圖，如果沒有在<head>加入 max-image-preview:large 設定，Google 可能仍不會以全寬格式顯示圖片。
未加入 max-image-preview 設定，即使上傳高清圖片，Google 也可能不顯示全寬格式。 - 如何指定縮圖？
Google 已證實，它會同時參考 Schema.org 標記與 og:image 來決定縮圖。不過，根據 SDK 解析，og:image 通常是圖片選擇的首要來源，SDK 研究發現，圖片 fallback 鏈較長（og:image → twitter:image → 等），確保 og:image 存在且符合規格是首要步驟。而 Schema.org 的 primaryImageOfPage 可作為強力補強或明確指定核心圖片。
Google 參考 Schema.org 與 og 標記選擇縮圖，確保兩者一致可提升顯示機會。
(以上優先序直接來自 SDK 反編譯分析（dkpg.java 等），詳細代碼邏輯請參考原作)。
為了獲得最佳效果，建議採取以下做法：
- 避免通用圖片： 不要使用網站 Logo 作為 og:image 或結構化資料中的圖片。
- 指定主要實體： 透過 Schema.org 的 primaryImageOfPage 屬性或將 ImageObject 附加到 mainEntity 上，明確告訴 Google 哪張圖才是內容核心。
- 解析度與比例： 建議寬高比接近 16:9，避免過度壓縮，且檔案大小至少 300KB （約 300 Kilobytes）以維持清晰度。
結語：底層邏輯驅動 Discover 增長
 |
| 成功關鍵在於確保技術純淨與精準，優化結構化資料與視覺內容。 |
研究 Discover 底層邏輯後發現，成功的關鍵往往不在於如何「操弄」演算法，而是在於如何確保基礎技術的「純淨」與「精準」。
建議行動清單：
- 結構化資料優先：確保 JSON-LD 中的標題與作者資訊精確無誤。
- 清理致命標籤：檢查源碼，移除不必要的 notranslate 與 nopagereadaloud。
- 視覺標準化：強制要求編輯團隊使用 1200px 以上的大圖，並確認 max-image-preview:large 已正確佈署。
- 監測與迭代：定期查看 Google Search Console 的 Discover 報表，追蹤曝光、點擊、隱藏率變化，快速調整高隱藏內容。
- 驗證工具：使用 Google 的結構化資料測試工具（Rich Results Test）確認 JSON-LD 無錯誤，並檢查 og:image / Schema 是否衝突。
Discover 不是一個隨機的流量來源，而是一個極度依賴純淨技術的推薦系統。有再好的新聞內容，但沒有先優化這些底層訊號，你在這場流量爭奪戰中就注定敗陣。
補充：NAIADES 是什麼？
NAIADES 是 Google Discover 的個人化推薦系統，其主要功能是在內容處理流程的「使用者興趣比對」（User Interest Matching）階段，將內容的實體 MIDs（知識圖譜 ID）與使用者的個人興趣檔案進行精準媒合
根據開發者工具（SDK）的數據顯示，NAIADES 系統透過多種「內容子類型」（Subtypes）來定義個人化邏輯，常見的類型包括：
- 基於實體的個人化 (MID-based)：利用知識圖譜（Knowledge Graph）主題來決定推薦內容。
- 基於搜尋查詢的個人化 (Query-based)：根據使用者過往的搜尋字詞來進行媒合。
- 基於 AI 模式對話的個人化 (AIM thread-based)：根據 AI 模式（AI Mode）下的互動紀錄進行推薦。
- 網站發布商文章訊號 (WPAS)：這代表在 Google 媒體中心（Publisher Center）註冊過的發布商，其內容會在 NAIADES 系統中獲得特殊的分類處理。
- 檢索優先權提升 (RECALL_BOOST)：用於在進入最終排名階段前，提高特定內容從候選池中被提取的優先權。
簡單來說，NAIADES 就像是一個過濾與媒合的黑盒子，它決定了哪些內容符合特定用戶的胃口，並將這些具備特定標籤的內容推送到使用者的饋送流（Feed）中。
(本文基於 Metehan Yesilyurt 的 SDK 研究，結合 Google 官方最新指引，整理出對台灣媒體最實用的洞察與行動清單。)
留言
張貼留言