檢索（Retrieval）：決定頁面排不排得上

先講結論：「被 Google 收錄」跟「會出現在搜尋結果」是兩件事

Google Search Console 的網頁索引報表明明顯示「已索引」，拿文章的目標查詢去搜，卻看不到自己的頁面。這時先別急著補反向連結或重寫標題。已索引只代表 Google 已處理頁面，頁面仍不保證會出現在任何特定查詢中。Google 官方在〈Google 搜尋運作方式〉文件裡也把「已索引但沒有出現在搜尋結果」的可能原因列為內容與查詢不相關、內容品質不足，或 robots meta 規則阻止顯示。

網站管理員能確認頁面是否已索引，也能從搜尋成效報表觀察查詢曝光；但 Google 沒有提供查看單次查詢「候選池」的工具。因此，搜尋不到某頁不能直接證明它卡在檢索層，也不能直接歸因於排名。需求量、查詢相關性、競爭程度、搜尋版面與量測期間都可能影響結果。

一份研究指出，96.55% 的受測網頁沒有從 Google 取得自然搜尋流量（見 Ahrefs 2023 年 12 月的研究）。這項研究分析的是該工具資料庫中約 140 億個頁面，流量也是估算值，不能拿來推算有多少頁面未進入候選池。它能支持的判斷很有限：收錄不等於一定有曝光與點擊。

這篇用資訊檢索的概念，拆解頁面在索引之後仍要面對的查詢相關性問題。它是一套診斷模型，不是 Google 內部系統的逆向規格。還不熟搜尋引擎的完整流程，可先讀Google 搜尋引擎運作原理。

搜尋引擎的三層架構，檢索是中間那道隱形關卡

Google 官方把搜尋運作分成三個階段：爬取（Crawling）、索引（Indexing）、提供搜尋結果（Serving search results），詳見 〈Google 搜尋運作方式（中文版）〉（2026）。到了第三階段，Google 會在索引中尋找相符頁面，再傳回它判斷品質高且與查詢相關的結果。官方文件沒有把檢索與排名列成網站管理員可分開查看的兩個狀態。

若把資訊檢索獨立列出，會比較容易理解問題發生在哪一類工作。索引像圖書館編目，檢索像依讀者的問題找出相關書目，排名則把結果依相關性與品質排出順序。這個比喻只用來釐清概念，不代表 Google 固定先產生特定數量的書單，再交給完全獨立的排名系統。

階段	它在做什麼	用白話講
爬取（Crawling）	發現網址、下載頁面內容	把書搬進圖書館
索引（Indexing）	分析內容、判斷重複頁與標準網址，將資訊存進索引	編目上架
檢索（Retrieval）	依查詢從索引找出可能相關的文件	從目錄篩出候選書單
排名	評估查詢相關性、品質與使用情境，安排呈現順序	把候選書排成推薦順序

把檢索獨立思考的用途，是提醒你先查索引資格與查詢相關性，再談更細的排序優化；不能反過來把「沒有排名」診斷成「沒進候選池」。標題、主要內容、內部連結與其他訊號，也可能同時影響系統對頁面的理解與排序。若重要頁面遲遲未被造訪，可以延伸讀爬取預算是什麼。

「被收錄後，排名遲早會上來」也不是可靠推論。Google 明確說明，即使頁面符合技術要求，也不保證一定會被爬取、索引或提供給使用者。比起猜測內部淘汰率，更可行的做法是查看索引狀態、查詢曝光、頁面內容與實際 SERP。

檢索時發生什麼事？從大型索引找出候選內容

資訊檢索（Information Retrieval，簡稱 IR）研究的是如何從大量資料中找出符合資訊需求的內容。Google 公開說明其爬蟲會處理數十億個頁面，但沒有公布單次查詢會先撈出多少候選文件（見 Google 搜尋運作方式文件，2025 年 12 月）。

反向索引（Inverted Index）是資訊檢索常見的資料結構。一般目錄由文件指向內容，反向索引則由字詞指向含有該字詞的文件清單。要找「預算」出現在哪些頁面，不必每次從頭讀完所有文件，先查「預算」對應的 postings list 即可（見 Stanford NLP Group 的 IR 教材，2009）。

以只有三個頁面的索引為例：A 談預算編列，B 談設計風格，C 同時談兩者。反向索引會把「預算」指向 A、C，把「設計風格」指向 B、C。查詢「室內設計 預算」時，系統可以從兩份清單找候選，不必逐頁掃描。這只是資料結構示意；實際系統還可能做斷詞、查詢改寫、同義詞處理、布林條件或語意檢索，不能假設多詞查詢一律取聯集或交集。

TF-IDF 與 BM25 能幫助理解字詞檢索的基本思路，相關介紹可看BM25 如何決定你餵給 LLM 的素材與用 TF-IDF 理解關鍵字權重。BM25 的評分包含查詢詞在文件中的出現頻率、反文件頻率，以及依文件長度調整詞頻的正規化。它不是單純計算關鍵字出現幾次（評分定義見 Apache Lucene 的 BM25Similarity 文件，2026）。

反文件頻率會讓少見詞比遍布整個文件集的常見詞更有區別力；BM25 的 k1 控制詞頻飽和，代表同一詞持續重複時，分數增幅會逐漸縮小；b 控制文件長度正規化的程度。這能解釋為何把同一詞重複很多次不會帶來線性成長，卻不能推論重複完全沒有影響，更不能把 BM25 當成 Google 現行系統的完整公式。

召回率（recall）與精確率（precision）都是資訊檢索的評估指標。召回率是「所有真正相關的文件中，系統找回多少」；精確率是「系統找回的文件中，有多少真的相關」。兩者可用來評估同一組檢索結果，也能延伸到排序結果，不能直接把 recall 等同檢索層、把 precision 等同排名層（定義見 Stanford NLP Group 的評估說明，2009）。

觀察維度	檢索候選	排序與呈現
主要問題	哪些文件可能符合查詢	哪些結果更適合放在前面
常見技術概念	字詞、語意、查詢改寫、過濾條件	相關性評分、品質、情境與新鮮度
計算考量	快速縮小需要進一步處理的範圍	對結果套用更多評分與呈現處理
網站端可做的事	確保可索引、主題清楚、用詞符合讀者	提供符合需求且可查證的內容與良好體驗
診斷限制	Search Console 不顯示查詢候選集合；site: 也不能把問題切成檢索或排名

假設某個測試集合有 200 份相關文件，系統傳回 500 份，其中 160 份相關，召回率是 160÷200＝80%，精確率是 160÷500＝32%。這組數字只示範公式，不代表 Google 的候選數量。真正做 SEO 時，沒有人能先知道整個索引裡「真正相關文件」的總數，因此也無法替某個 Google 查詢算出完整召回率。

網站端可做的是排除可爬取、索引與 canonical 問題，再用查詢曝光及實際 SERP 評估內容是否對應需求。Google 沒有公開固定候選數量，也沒有公開到足以判斷外部連結、標題或內部連結只在哪個內部階段介入。

五個診斷面向：檢查頁面與查詢是否對得上

下面五個面向是網站端的排查清單，不是 Google 公開的固定五道閘門，也不代表系統依序採用 AND 邏輯淘汰頁面。

第一道：查詢字詞的命中（詞彙比對）

查詢字詞、自然變體與同義概念都能幫助系統理解主題。重要內容應放在可見且能出現在渲染後 HTML 的主要文字區塊，不要只做成圖片文字或 CSS 產生的內容。Google 能執行 JavaScript 並使用渲染後 HTML 建立索引，但頁面仍可能遇到資源阻擋或渲染問題（見 Search Central 的 JavaScript SEO 基礎說明，2026）。

沒有逐字出現查詢，不代表頁面一定找不到；但產品名稱、型號與讀者慣用詞若完全缺席，系統與讀者都更難確認頁面談的是同一件事。可先搜尋頁面原始碼與渲染後 HTML，確認目標名稱出現在主要內容，不是只藏在 alt 文字或互動後才載入的區塊。延伸可讀SEO 關鍵字是什麼。

第二道：語言與地區篩選

語言、地區與使用者位置會影響搜尋結果。Google 依演算法判斷頁面語言，不使用 hreflang 或 HTML 的 lang 屬性來偵測語言；hreflang 的用途，是標示同一內容的不同語言或地區版本。每個版本要列出自己與所有替代版本，版本之間也要互相回指，否則註解可能被忽略（見 Google 對本地化版本的說明，2025）。

第三道：時效性與內容類型

查詢會影響搜尋結果頁出現的功能與內容形式。Google 舉例說明，在地服務查詢可能顯示在地結果，視覺主題查詢則更可能顯示圖片。Google 也有多套「query deserves freshness」系統，在查詢預期需要新資訊時顯示較新的內容；這不代表所有舊內容都會被某個固定閘門刷掉（見 Google 搜尋運作方式與排名系統指南，2025 年 12 月）。

自查時直接看目標查詢的 SERP：結果以文章、產品頁、影片還是圖片為主？近期內容是否占多數？如果查詢明確包含「最新」「價格」或版本名稱，而你的頁面日期與資料都停在舊版，時效就是合理的檢查方向。不要因為前幾頁剛好都很新，就把「半年內更新」寫成演算法門檻。

第四道：結構化的排除指令

noindex 會要求 Google 不將頁面顯示在搜尋結果；rel="canonical" 是強訊號，但 Google 仍可能選擇另一個標準網址。robots.txt 控制爬取，不保證網址不被索引：若其他頁面連向被阻擋的網址，Google 仍可能只依網址與外部資訊建立索引，搜尋結果摘要通常很有限（見 robots meta 標籤規格、robots.txt 簡介與 標準網址指定方式的官方說明）。

這三項不能統稱為「必然在檢索前排除」。操作細節可分別讀robots.txt 介紹、noindex 介紹與SEO Canonical URL 標準網址。

第五道：主題與實體的相關性門檻

Google 會分析文字內容、標題、alt 屬性、圖片與影片來理解頁面，也會依查詢尋找相符頁面。網站端應明確交代談論對象、屬性與關係，避免同名品牌或產品混淆；但外部無法量測固定的「實體相關性門檻」（見 Google 搜尋運作方式文件，2025 年 12 月）。

最常漏掉的情況，是頁面只寫內部產品代稱，沒有寫出搜尋者使用的通用名稱。若頁面介紹「晨光計畫」，卻沒說它其實是「企業雲端備份方案」，搜尋者與系統都少了一層對照。相關概念可延伸閱讀Entity SEO。

這五項會互相影響。建議順序是先看索引與排除指令，再看語言版本、時效、內容形式與查詢相關性。表格列出四種常見誤判：

檢查相關性時，不要只問「頁面有沒有這個關鍵字」。把目標查詢寫在旁邊，逐項核對四件事：搜尋者想解決什麼問題、目前結果偏好哪種頁面、你的頁面是否明確交代主題、重要資訊是否真的出現在主要內容。若頁面連搜尋者要比較的價格、規格、適用對象或限制都沒回答，補一個詞通常不會解決內容落差。若問題只是品牌代稱沒有對應通用名稱，也不必為此重寫整篇，補上清楚定義即可。

你看到的症狀	常被誤判成	比較可靠的查法
頁面已索引，但目標查詢沒有曝光	權威度不足，繼續補外連	檢查需求量、查詢意圖、內容相關性、內部連結與量測期間；不能直接判定候選池情況
改了 title、補了 schema，排名不動	排名因素還不夠強	檢查 canonical、noindex 與內容是否符合需求；結構化資料不保證顯示複合式搜尋結果
新內容上線一週，搜尋沒有曝光	一定是沙盒效應	用網址檢查確認索引，再評估需求、相關性、內部連結與量測時間
site: 搜得到該頁，目標查詢卻排不上去	檢索沒問題，只有排名弱	site: 結果不保證完整，也不能揭露一般查詢的候選狀態；改看實際 SERP 與 GSC 曝光資料

為什麼優化排名因素救不了檢索失敗

排名比較的前提，是搜尋系統已抓取並索引頁面，而且判斷它可能符合查詢。問題在於，外部看不到 Google 對單次查詢建立的候選集合。沒有曝光時，把原因直接寫成「未進候選池」只是猜測；把所有責任推給權威度，也同樣站不住腳。

實用的診斷順序是：確認 Google 知道哪個網址、能不能爬取、是否允許索引、選了哪個 canonical，再檢查頁面是否回答同一個查詢需求。這些條件正常後，才評估連結、內容品質與其他競爭因素。遇到排名不動，不必立刻往反向連結投入資源。

多個頁面的主題與意圖高度重疊時，GSC 中可能看到同一查詢由不同頁面輪流取得曝光。這不代表搜尋系統必然因同網域有相似內容而「困惑」，也不是平均分票的證據。先用查詢與頁面維度查看實際資料；若重疊確實造成排名不穩、維護重複或轉換分散，再合併內容，或讓各頁對準不同搜尋意圖。

內部連結、主題權威與候選池的關係

網站端能做的不是把頁面「送進候選池」，而是讓重要頁面容易被發現，並讓主題與頁面關係足夠清楚。

第一個動作是補上有用的內部連結。Google 官方把「讓內容能透過內部連結被找到」列為一般搜尋與 AI 搜尋都適用的做法。清楚的錨點與網站架構也能幫助使用者理解頁面關係；但不能斷言孤兒頁一定會在某個固定相關性閘門被排除（見 Google 對 AI 功能與網站的說明，2025 年 12 月）。完整操作可看內部連結是什麼與SEO 友善的網站架構。

第二個動作是建立真正有用的相關內容。把必要的支撐頁面用清楚架構串起來，有助於讀者理解主題；但 Google 沒有公開可量測的「主題權威門檻」，也不能保證文章越多越容易出現在搜尋結果。不要為了補齊主題地圖，大量生產重複或空泛頁面。

第三個動作是正確使用結構化資料。它能向 Google 提供頁面含義的明確線索，並讓支援的類型有資格取得特定搜尋功能；有資格不等於保證顯示。Google 的 Article 結構化資料文件目前沒有 required properties，只有建議屬性。

FAQ rich result 則已退場。Google 在文件更新紀錄中寫明，這項功能自 2026 年 5 月 7 日起不再出現在 Google 搜尋結果，6 月也移除了相關文件。因此，不能再把 FAQ 或 Article 標記說成檢索加速器。

導航型、資訊型、交易型查詢，檢索的閘門長得不一樣

不同查詢背後的需求不同。這會影響哪些內容相關、搜尋結果頁會出現哪些形式，也會改變適合競爭的頁面類型。導航型、資訊型與交易型是分析意圖的實用分類，不是 Google 公布的固定三分法。

導航型查詢通常是在找特定品牌、網站或頁面，例如直接搜尋公司名。品牌名稱、官網內容與可查證公開資訊要彼此一致。若有實體據點，名稱、地址與電話也應維持正確；純線上服務則不必硬加不存在的在地資訊。

資訊型查詢是要理解概念或解決問題，例如「檢索是什麼」。內容要回答問題所需的範圍，但篇幅長不等於更相關，也沒有公開證據顯示資訊型查詢固定使用較大的候選集合。刪掉與問題無關的段落，通常比硬湊完整更有用。

交易型查詢帶有比較或行動需求，例如「某某方案 價格」。價格、供應情況、地區與頁面類型可能影響相關性。網站應提供真實、現行且符合自身商業模式的交易資訊，不能用結構化資料替代頁面上看得到的內容。

實際判斷時，先看 SERP 上出現的是首頁、文章、產品頁、分類頁、圖片還是影片，再對照 GSC 的查詢資料。沒有哪一種頁面固定只能服務一種意圖。

AI 搜尋把檢索搬到舞台中央：RAG 與向量檢索

在生成式 AI 系統裡，檢索對答案內容的影響更容易看見。RAG（Retrieval-Augmented Generation，檢索增強生成）把生成模型與外部檢索來源結合：先取得相關文件或片段，再讓模型依這些內容產生答案。原始 RAG 論文（Lewis 等人，2020 年）使用密集向量索引作為非參數記憶，並讓生成模型以取回的段落為條件。延伸可看RAG 是什麼。

這不代表所有大型語言模型都必須先檢索，也不能把 Google 的 AI Overviews 或 AI Mode 直接定義成單一、固定的 RAG 管線。Google 在AI 功能說明文件公開確認的是：兩項功能可能使用 query fan-out，同時發出多個跨子題與資料來源的相關搜尋；要成為支援連結，頁面必須已索引，並符合在一般搜尋中顯示摘要的資格。

字詞檢索（lexical retrieval）與密集向量檢索（dense retrieval）是兩種常見做法。下面的表格只比較技術特性，不代表 Google 的傳統藍色連結只靠字詞檢索，也不代表 AI Overviews 與 AI Mode 只靠向量檢索。

比較項	字詞檢索（Lexical）	密集向量檢索（Dense）
主要比對方式	字詞、詞頻與倒排索引中的命中	查詢與文件向量之間的相似度
相對優勢	精確詞、產品代碼、特殊術語、人名與日期	同義改寫、自然語句與概念相近的內容
內容端做法	寫出讀者會用的名稱與識別碼	用清楚上下文完整回答問題
常見搭配	混合檢索同時執行字詞與向量查詢，再合併兩邊結果

向量檢索把查詢與文件轉成向量，再用距離或相似度尋找概念相近的內容。它能找出沒有相同字詞的語意近鄰，但逐字精準命中的任務可能更適合字詞檢索。Microsoft 的 Azure AI Search 混合搜尋文件把產品代碼、特殊術語、日期與人名列為字詞搜尋表現較好的情境，也說明其混合搜尋會平行執行全文與向量查詢，再用 Reciprocal Rank Fusion 合併結果。

這個限制與效果都依嵌入模型、資料、查詢和系統設定而變，不能說所有向量檢索必然找不到專有名詞。對網站內容而言，穩妥做法仍是把型號、編號與正式名稱寫清楚，同時提供足夠上下文。沒有逐字命中仍可能相關；反過來，堆疊同一詞也不能彌補內容偏題。相關概念可看Grounding 介紹。

AI 可能產生錯誤答案，也就是AI 幻覺。但不能把某個品牌頁面沒有被檢索，直接寫成模型產生錯誤答案的單一原因。檢索品質、來源內容、提示、模型行為與答案生成都可能影響結果。網站能控制的是公開資訊是否清楚、一致且可查證，並追蹤實際搜尋結果中的錯誤描述。

Google 在AI 功能說明中指出，AI 功能可能使用 query fan-out，同時發出多個相關搜尋來整理支援資訊。這不表示單一頁面必須涵蓋所有子題。為每個可能分支硬塞內容，反而會讓頁面失焦。細節可以延伸查詢擴展 Query Fan-out。

Google 在AI 功能說明中也明確表示，網站不需要為 AI Overviews 或 AI Mode 增加特殊 schema.org 標記、AI 文字檔或其他機器可讀檔案；一般 SEO 技術要求仍然適用。這些功能的流量會計入 Search Console 搜尋成效的「網頁」搜尋類型，而不是提供獨立的引用保證。

五步診斷你的頁面到底有沒有進候選池

嚴格來說，網站端無法確認頁面是否進入某次查詢的內部候選池。下面五步的目標，是排除可觀測的技術問題，找出頁面與查詢之間的落差，而不是替 Google 內部階段貼標籤。

第一步：用實際查詢做抽樣觀察

用目標查詢觀察目前 SERP，記錄出現的頁面類型、內容角度與功能版面。site: 可輔助找特定網域或網址，但 Google 明確說明結果不一定完整，已索引網址也不保證出現在相關的 site: 查詢中；未加其他查詢字的 site: 結果，除了常把較短網址放前面，其餘排序相對隨機（見 Google 對 site: 運算子的說明，2025 年 12 月）。

所以，site: 找得到不能證明頁面通過一般查詢的候選池，找不到也不能定位成檢索故障。Google 建議用 Search Console 網址檢查工具診斷特定網址。

第二步：用網址檢查工具確認索引狀態與阻擋訊號

到 Google Search Console 的網址檢查工具，輸入完整網址，查看 Google 已知的索引狀態、頁面擷取結果、是否允許建立索引、使用者宣告的 canonical 與 Google 選擇的 canonical。工具顯示「網址已在 Google 上」仍不保證它會出現在特定搜尋結果，因為工具不檢查所有顯示條件（見 網址檢查工具說明，2026）。對 GSC 不熟可先看Google Search Console 介紹。

第三步：檢查頁面是否真的含目標查詢字詞

查看原始 HTML 與網址檢查工具中的渲染結果，確認主要內容對使用者與 Google 都看得到。Google 能處理 JavaScript 內容，但仍有渲染與資源存取限制；目標詞自然出現在標題、說明或主要內容，有助於釐清主題，卻不是公開的最低檢索門檻。相關限制可看JavaScript SEO。

第四步：用網頁索引報表看整站的排除比例

如果很多頁面同時受影響，到網頁索引報表查看未索引原因分布。「重複網頁，Google 選擇的標準網頁與使用者不同」表示 Google 索引了它判定的 canonical，而不是目前檢查的網址。這時比較目前頁面、宣告的 canonical 與 Google 選擇的 canonical，再抽樣檢查內容相似度、內部連結與 sitemap（報表說明見 Google 的網頁索引報表文件，2026）。

第五步：檢查有沒有自相殘殺的候選池內耗

在 GSC 以查詢篩選，再比較各頁的曝光、點擊與排名變化，比 site: 更適合觀察頁面是否反覆替換。搜尋成效資料多數會歸到 canonical URL，因此解讀前也要先確認標準網址（見 成效報表的維度與資料分組說明，2026）。

同一查詢有多個自家頁面取得曝光不一定是問題。只有在意圖重疊造成排名不穩、維護混亂或轉換分散時，才考慮合併、重新分工或調整內部連結。別把「多頁出現」直接命名為關鍵字自相殘殺。

從被索引走到被檢索：四個立即上手的修正

完成診斷後，依問題類型採取動作：

1. 在 HTML 主體使用讀者熟悉的名稱。不要只放內部代稱；把產品類型、正式名稱、型號與讀者會查的說法寫清楚。
2. 修正誤設的排除訊號。分開檢查 robots.txt、noindex 與 canonical，確認重要頁面符合原本預期。
3. 補上有用的內部連結。從語意相關頁面，以清楚錨點連向目標頁；不要只因某頁流量高就硬加連結。
4. 補足真正缺少的子題。只有在使用者需求需要時新增支撐內容，不為了「主題權威」大量生頁。

修改後，回到網址檢查工具確認索引狀態，再用 GSC 搜尋成效觀察該頁是否開始取得相關查詢的曝光。不要把 site: 當成驗收標準；標題、內容、內部連結與站內 SEO本來就可能同時影響理解與排序。

把檢索放回它該在的位置

GSC 顯示「已索引」，目標查詢卻看不到頁面，只能證明索引資格與查詢表現不能混為一談。它沒有告訴你 Google 在哪個內部階段排除了頁面。

可執行的判斷框架很簡單：用網址檢查工具確認索引資格與 canonical，再從 GSC 搜尋成效查看相關查詢是否有曝光。接著檢查主要內容、內部連結、noindex、robots.txt、語言版本與頁面類型是否符合預期。資訊檢索能幫你理解「為什麼已索引仍不保證被查到」，Search Console 與實際頁面證據才是診斷依據。

先挑一個長期沒有目標查詢曝光的頁面，照這套順序檢查。若技術狀態正常，就回到搜尋需求與內容本身，不要把看不到的候選池當成可以被工具直接驗證的事實。