爬取、索引與排名有什麼不同？搜尋可見度的三道關卡

先說結論：搜尋不到之前，先判斷卡在哪一關

頁面「已被發現」只代表搜尋引擎知道這個網址；「已爬取」代表爬蟲曾下載頁面；「已索引」代表系統分析內容後，把選定版本放進可供搜尋的資料庫；「有排名」則是某次查詢發生時，這個已索引頁面被判定為相關且有用，因而出現在搜尋結果。

這四個狀態不能互相替代：

• Sitemap 裡有網址，不代表搜尋引擎已經爬取。
• 爬蟲成功取得 200 頁面，不代表一定會索引。
• 已索引，不代表每個你期待的關鍵字都有曝光。
• 有曝光，也不代表排名、標題與摘要足以帶來點擊。

因此，診斷順序應固定為：先確認能不能存取，再確認是否被索引，最後才分析查詢、內容與排名。 如果頁面根本未索引，先改標題關鍵字通常解決不了問題；如果頁面已索引且有曝光，反覆提交 sitemap 也不會直接提高排名。

第一關是爬取：網址被知道後，內容還要真的拿得到

Google 把爬取描述為下載已發現頁面的文字、圖片與影片。這之前還有一個容易被混用的動作：發現網址。搜尋引擎可能從既有頁面的連結、網站導覽、外部連結或 sitemap 得知新網址，但知道地址不等於已經到訪。

爬取是否成功，主要看以下條件：

• 網址能從可檢索連結或 sitemap 被發現。
• 伺服器與 DNS 可用，回應不是持續 5xx、逾時或錯誤轉址。
• 頁面不需登入，Googlebot 能公開存取。
• robots.txt 沒有禁止對應爬蟲讀取該路徑。
• 重要內容經頁面呈現後仍能被讀到，而不是只留下一個空殼。

Googlebot 會依演算法決定爬哪些網站、多久回訪及一次取得多少頁面，也會在伺服器出錯時降低速度。提交 sitemap 或要求建立索引，是提供線索與請求，不是排隊保證書。小型內容站通常不必先追求「crawl budget 技巧」；清楚的內部連結架構、穩定回應與乾淨網址，往往更接近真正問題。

robots.txt 是爬取規則，不是可靠的移除索引工具

robots.txt 可以阻止爬蟲取得頁面內容，卻不保證網址永遠不出現在索引。若其他頁面仍連到被阻擋的網址，搜尋引擎可能只根據外部訊號知道它存在，卻無法讀到頁面上的 noindex。

若目標是讓公開頁面不要出現在 Google 搜尋結果，官方建議讓爬蟲能讀取頁面，再使用 noindex；若內容本身不該公開，則應使用登入或存取控制。兩者解決的不是同一種問題。

第二關是索引：爬過之後，系統仍要理解與選擇版本

索引不是把所有抓到的 HTML 原封不動存起來。Google 會分析文字、圖片、影片、title、替代文字等訊號，理解頁面主題，並判斷它是否與其他網址重複、哪個網址應成為 canonical（代表版本）。

頁面已成功爬取，仍可能沒有被索引，例如：

• 頁面含 noindex 指令。
• 它是轉址網址，而不是最終目標。
• 內容與另一頁高度重複，系統選了其他 canonical。
• 頁面內容薄弱、近似錯誤頁，或呈現後難以理解。
• 系統尚未完成處理，或目前選擇不收錄。

Search Console 的 Page indexing report 會把「未索引」依原因分組，但官方提醒，未索引不必然是錯誤。轉址、重複版本、篩選參數頁與刻意 noindex 的頁面，本來就不需要追求 100% 收錄。真正要問的是：希望使用者從搜尋進入的 canonical 頁面，是否被正確索引？

canonical 也是訊號而非命令。永久轉址與 rel="canonical" 是較強訊號，sitemap 收錄則是較弱訊號；若站內連結、canonical、轉址與 sitemap 各自指向不同版本，搜尋引擎仍可能選擇和你宣告不同的網址。處理重複頁時，應讓這些訊號一致，而不是只在 HTML 加一行標記。

第三關是排名：已索引只取得參賽資格，不是保證上榜

當使用者送出查詢，搜尋系統才會從索引中找出候選內容，依相關性、有用性、品質與查詢情境提供結果。Google 官方說明，可能考慮語言、地點、裝置等資訊，也使用多套自動化系統理解查詢、頁面、連結與內容；不存在一個可以單獨解釋所有排名的分數。

這就是為什麼 URL Inspection 顯示「URL is on Google」，實際搜尋某個詞仍可能看不到。這個狀態只表示網址具備出現在結果中的資格，不代表：

• 它與你手動輸入的查詢最相關。
• 它會在每個地點、裝置與時間出現。
• 它的排名高到落在你檢查的前幾頁。
• 搜尋結果一定採用你寫的標題與摘要。

排名診斷要從「這個頁面服務哪一個讀者任務」開始，而不是只問有沒有放進關鍵字。Google 的 people-first content 指南建議檢查內容是否完整、可靠、具原創價值，讀者看完能否達成目標。可先用搜尋意圖判斷流程確認查詢需要的答案、格式與證據，再用 Search Console Performance report 觀察實際查詢、曝光、點擊、CTR 與平均排名趨勢。

同一個「搜尋不到」，可能是三種完全不同的故障

觀察到的狀態	目前能確定什麼	優先檢查	不該先做什麼
URL unknown／尚未發現	搜尋引擎可能還不知道網址	內部連結、sitemap、正式網址是否正確	先重寫整篇關鍵字
Discovered – currently not indexed	已知道網址，但尚未完成爬取與索引	伺服器穩定、連結路徑、等待合理時間	每天重複提交
Crawled – currently not indexed	已爬取，但目前未放入索引	內容完整性、重複、canonical、呈現結果	把 robots.txt 當收錄開關
Duplicate／另選 canonical	系統把訊號歸到另一代表網址	canonical、轉址、站內連結、sitemap 一致性	為每個版本各寫一點不同文字
Indexed，沒有曝光	已具備提供結果資格	目標查詢、意圖、內容差距、觀察期間	繼續要求建立索引
有曝光，點擊很低	頁面已進入部分結果，但吸引力或位置有限	查詢別排名、標題準確性、SERP 版型	只看全站平均 CTR

URL Inspection 的「已索引版本」不是即時頁面；它反映 Google 最近掌握的版本。Live Test 則能檢查現在是否可存取與可能可索引，但不涵蓋所有索引判斷，尤其不能保證 canonical 選擇與最終收錄。修正後應同時記錄最後爬取日期與修改日期，避免拿舊檢索結果判斷新版本。

完整教學案例：12 篇文章，為什麼只有 3 篇有曝光？

以下是虛構教學案例，用來示範分層診斷，不是 MKT Notes 的實際 Search Console 結果。

一個新咖啡知識站發布 12 篇文章。站長搜尋 site: 只看到少數結果，便認為「Google 沒有收錄」。但逐層整理後，資料如下：

階段	頁數	被排除或尚未通過的原因
已列入 sitemap	12	這只是站方提交的清單
Google 已發現	10	2 篇沒有內部連結，sitemap 又用了錯誤主機名
已成功爬取	8	1 篇被 robots.txt 阻擋，1 篇曾持續回傳 5xx
canonical 已索引	6	1 篇含誤設 noindex，1 篇與分類頁重複且被選為替代頁
近 28 天有搜尋曝光	3	另外 3 篇雖已索引，仍沒有進入可見的查詢結果

不能用 3 ÷ 12 = 25% 就宣稱「索引率 25%」，因為最後一列是曝光，不是索引。這組資料至少有三個不同分母：

團隊依關卡處理：先修正 sitemap 主機名並從樞紐頁連到兩篇孤立文章；解除錯誤 robots 規則、修復 5xx；移除誤設 noindex，並把重複分類頁的 canonical、站內連結與 sitemap 統一。這些是技術上可以直接驗證的修正。

剩下三篇「已索引但無曝光」則不急著重送。團隊替每篇指定一組預期讀者問題，檢查實際搜尋結果需要的是選購比較、沖煮步驟還是故障診斷，再補足缺少的示例與限制。後續觀察以頁面與查詢篩選的曝光、點擊趨勢為主，不用未登入的單次手動搜尋當唯一證據，也不把之後的任何成長全歸因於這次修改。

八步診斷流程：每次只修正最前面的失敗關卡

1. 確認頁面本來就應該被搜尋：排除登入頁、購物車、篩選參數、測試頁、重複版本與刻意 noindex 的內容。
2. 檢查正式網址與 HTTP 回應：確認最終 canonical URL 可公開開啟、回傳 200，沒有轉址迴圈、5xx、DNS 或 TLS 問題。
3. 確認搜尋引擎能發現網址：從相關的已知頁面加入可檢索 <a href>，並讓 sitemap 只列 canonical、可索引網址。
4. 檢查爬取限制：核對 robots.txt、登入要求、資源載入及 URL Inspection 的 crawl allowed、page fetch 與最後爬取時間。
5. 檢查索引指令與代表版本：查看 noindex、HTTP X-Robots-Tag、canonical、轉址、Google-selected canonical 與重複內容原因。
6. 檢查呈現後的主要內容：確認標題、正文、連結與必要媒體在搜尋引擎可讀的版本中存在，頁面不是空殼、軟 404 或只有重複樣板。
7. 確認索引後再分析排名：在 Performance report 依頁面與查詢篩選，觀察曝光、點擊、CTR、平均排名及日期趨勢；平均排名只是彙總值，不是固定名次。
8. 記錄修正與等待重新處理：保存修改日、原狀態、修正內容與驗證日。必要時對重要單頁要求重新索引，但不要承諾立即收錄或排名。

七個常見誤判與限制

「瀏覽器能開，就代表 Google 能爬」

你的瀏覽器可能帶著登入狀態、使用不同網路，或沒有遇到針對爬蟲的規則與伺服器錯誤。應查看 URL Inspection、伺服器狀態與實際回應，不用肉眼開啟代替檢查。

「Sitemap 提交成功，就代表已收錄」

成功提交只表示 Google 能讀取清單。每個網址仍要經過發現、排程、爬取、索引與 canonical 選擇；官方不保證所有提交頁面都進入索引。

「用 robots.txt 就能刪除搜尋結果」

robots.txt 阻止讀取內容，不是可靠的 noindex 替代品。若爬蟲看不到頁面，也看不到頁面內的移除指令。

「未索引一定是技術錯誤」

轉址、重複頁與不應搜尋的工具狀態頁，本來就可以不索引。先區分預期排除與真正重要頁面，不追求 100% coverage。

「已索引就應該搜尋品牌外的所有目標詞」

索引只提供候選資格。查詢意圖、內容相對價值、語言、地點、裝置與結果版型都會影響是否出現。

「每天要求建立索引，處理就會更快」

重複按鈕不能取代修正原因。先處理存取、指令、canonical 或內容問題；重要變更完成後再提出一次合理請求並等待重新處理。

「手動搜尋看不到，就是零曝光」

單次搜尋受地點、語言、裝置與當下結果影響。以 Search Console 的頁面／查詢資料和趨勢為主要觀察依據，也要理解報表會彙總、延遲並省略部分查詢。

最後帶走：一張從網址到搜尋結果的檢查清單

• 發現、爬取、索引與排名是相連但不同的狀態。
• 先確認頁面是否應被搜尋，再追求收錄；排除頁不等於錯誤。
• Sitemap 與內部連結協助發現，不能保證爬取或索引。
• robots.txt 管爬取，noindex 管是否出現在搜尋結果；不要混用目的。
• 已爬取未索引時，檢查指令、canonical、重複與呈現後內容。
• 已索引但沒有曝光時，才回到查詢意圖、內容完整性與相對競爭。
• URL Inspection 的索引資料與 Live Test 回答不同問題，兩者都不保證排名。
• Performance report 用來觀察曝光、點擊、CTR 與平均排名趨勢，不把平均值當固定名次。
• 每次只修正最前面的失敗關卡，記錄日期並等系統重新處理。

理解這三道關卡的價值，不是多背三個 SEO 名詞，而是讓每一個動作都有對應問題：連結與 sitemap 幫助發現，伺服器與爬取規則確保存取，索引指令與 canonical 管理代表版本，內容與查詢匹配則決定是否值得被提供。這套「先定位、再處置」的方法，也能避免把正常的頁面分工誤認為關鍵字蠶食，並為後續的 SEO 與 GEO 可見度觀察建立更可靠的技術基線。