Google 收錄慢還是沒收錄：三個真實案例的卡點復盤
收錄慢和沒收錄，是兩種病。前者只需要等，後者必須查。這篇不講通用理論，只把三個真實卡點拆開：sitemap 不更新、渲染不可讀、canonical 指錯，再附上我們 7 頁金絲雀從發布到全部收錄的完整時間線。
重點摘要
- 收錄慢是時間問題，沒收錄是鏈路問題。用感覺判斷這兩件事，十次有九次會誤判，用 Search Console 的網址檢查看狀態才作數。
- 剛發布三、五天沒有收錄，不構成任何結論。我們自己的金絲雀實測裡，7 個頁面要到第 14 天才全部進索引。
- 三個卡點裡，sitemap 不更新和渲染不可讀都屬於零報錯的靜默故障，外掛後台一切正常，只有探針能戳穿。
- canonical 指錯最容易被忽略：內容沒問題、抓取也正常，但頁面把該給自己的一票投給了別人。
- 排查順序比排查力度重要。順序錯了，改內容、改標題、反覆提交請求，全是白做。
收錄慢和沒收錄，到底怎麼區分？
先說清楚這兩個詞。收錄慢，意思是頁面最終會進索引，只是要等；沒收錄，意思是它卡在某一步不再往前走了，你等到明年也一樣。兩者的動作完全不同：前者什麼都別做，等著就行；後者必須動手查。
實務裡最容易犯的錯，是把慢當成沒收錄。文章發出去第三天搜尋不到，就開始改標題、改首段、反覆點提交請求，甚至懷疑內容品質要重寫。這套動作沒有幫助，還把原本乾淨的變數攪亂，後面真要排查連基線都沒有。
判斷方法不靠感覺，靠一個具體動作：把完整 URL 貼進 Search Console 頂部的網址檢查框。它給出的狀態，會直接告訴你頁面卡在哪一檔，以及這一檔該做什麼。這套讀法在收錄檢查方法裡寫得更細，我這裡只留結論。
有一個反直覺的事實值得先說：內容品質只影響四檔狀態裡的一檔。也就是說，多數站在急著改內容的時候，真正卡住的往往不是內容。我們在收錄問題排查的原始記錄裡統計過自己站的狀態分布，兇手的分布和直覺差得很遠。
先查狀態：你的頁面卡在哪一檔？
網址檢查的結果基本落在下面四檔裡。把未收錄的頁面各抽幾個過一遍，你就能看出這是普遍問題還是個別問題。
| 狀態 | 意思 | 該做什麼 |
|---|---|---|
| URL is unknown to Google | Google 根本不知道這個頁面存在 | 查 sitemap 裡有沒有它、站內有沒有連結指向它 |
| Discovered – currently not indexed | 知道了，但還沒來抓 | 加內鏈、等，或有限度地手動請求收錄 |
| Crawled – currently not indexed | 抓了，看完決定先不收 | 這時才輪到檢查內容價值和重複度 |
| 已收錄到 Google | 在索引庫裡了 | 別動它，去救別的頁面 |
看這張表時注意一點：如果大量頁面停在 unknown，那是發現層出了問題，改內容毫無意義；如果大量停在 Discovered，通常意味著頁面是孤島，Google 知道它存在卻沒有理由優先來抓。這兩種情況在下面三個案例裡都能對號入座。
還有一種情況是頁面壓根沒進過 sitemap，入口本身就錯了。sitemap 的作用和寫法可以參考sitemap 是什麼，這裡不重複。
案例一：sitemap 不更新，Google 手上是舊版本
第一個案例的表面現象很普通：一個內容站持續更新，排名和收錄卻幾個月沒有變化，日誌裡也沒報錯。站長一直以為 sitemap 每天在更新，因為外掛後台掛著一個綠色的勾。
真實情況是，sitemap 的輸出被快取凍住了。這台站開了物件快取（Redis），sitemap 生成結果被 transient 快取住了，新文章寫進資料庫，但 Google 請求 sitemap.xml 時拿到的還是凍結前那一版。對爬蟲來說，這個站幾個月沒有新頁面。
這類故障的特點是零報錯。外掛認為自己交付了 sitemap，快取認為自己命中了，站長的後台看不到任何異常。你只有兩個辦法戳穿它：一是直接在瀏覽器裡打開 sitemap.xml，看最新那篇文章在不在裡面；二是去 Search Console 的 sitemap 報告，核對 Google 實際讀取的時間與已發現的條數，而不是看外掛後台上次生成的時間。
怎麼確認 sitemap 是活的？
最可靠的一招是發一篇探針文章，發布後立刻打開 sitemap.xml，看它有沒有出現。如果沒出現，先清快取再看一次；清了快取才出現，說明快取策略就是元兇。這台站最後是用 mu-plugin 把 sitemap 從快取裡摘出去才徹底解決的，改完當天新頁就進了 sitemap。
順帶提醒一個排查死角：快取檔案的命名如果不含 sitemap 字樣，按檔名去伺服器上找永遠找不到它。排查時別只按檔名搜尋，要按目錄和時間戳搜尋。
有人會問，sitemap 不更新，是不是提交一次請求收錄就能救回來？不能。手動請求收錄是加速器，前提是頁面本身能被發現。robots、noindex、canonical 與 sitemap 的索引控制這幾個基礎沒打通，加速器加速的是零。
案例二：渲染不可讀，頁面在 Google 眼裡是空的
第二個案例更隱蔽。頁面在瀏覽器裡打開完全正常，文字、圖片、表格都在，但在 Google 抓到的 HTML 裡，正文部分是空殼——內容全靠 JavaScript 在客戶端注入。
Google 確實會渲染 JavaScript，但渲染是要排隊的，而且它渲染出的結果不保證和你瀏覽器裡看到的一致。當正文只在渲染後才出現、且渲染資源被主題腳本攔在後面時，爬蟲拿到的就是一個沒有內容的頁面。它不會報錯，只會把這份空殼拿去判斷價值，結論自然是不收錄。
站長的直覺往往是「我的頁面明明有內容」，於是去改文案、加字數，方向從頭就錯了。判斷這件事要看兩個版本的 HTML，而不是看瀏覽器截圖。
怎麼判斷是渲染問題，還是內容問題？
在網址檢查裡對比兩樣東西：一是「查看已抓取的網頁」裡的 HTML，這是 Google 第一次拿到的原始版本；二是「測試實際網址」裡渲染後的結果。如果原始 HTML 裡沒有正文、渲染後才出現，那就是渲染問題，跟內容品質無關。
修復方向有三個，按成本從低到高：把關鍵正文改為伺服器端輸出，讓首屏內容直接進初始 HTML；把阻塞渲染的腳本改成延後載入；用預渲染或靜態化把渲染結果提前生成。核心原則只有一條——正文必須在初始 HTML 裡就能讀到，別把它交給某個可能不執行的腳本。
同類問題還包括內容藏在分頁標籤、摺疊面板或需要互動才載入的模組裡。凡是「要點一下才看得到」的內容，都要假設爬蟲看不到，除非它確實在初始 HTML 裡。抓取、索引與速度這條鏈路的關係，在技術 SEO 的抓取與索引指南裡系統講過。
案例三：canonical 指錯，頁面把票投給了別人
第三個案例最冤：頁面能抓、能渲染、內容也紮實，就是長期不進索引。查到最後，問題出在 canonical 標籤上——頁面宣告自己的標準版本是另一個 URL。
canonical 的作用是告訴 Google「這一堆相似頁面裡，請以哪一個為準」。一旦某個頁面的 canonical 指向了別處，Google 就會把它的訊號合併到目標頁，被指向的那個頁面收不到票，自己也可能被排除在索引之外。常見成因有三類：模板變數寫錯，所有頁面都指向了首頁；遷移或換網域後舊網址沒跟著換；分頁與篩選參數處理不當，變體頁互相指向。這類錯誤不報錯，只看頁面本身發現不了。
怎麼核對 Google 實際選中的標準網址？
別只看 HTML 裡寫了什麼，要看 Google 選了哪個。網址檢查裡有一欄明確寫著 Google 選擇的標準網址，如果它和你頁面的真實網址不一致，就是這裡出了問題。批次排查可以抓一批頁面的原始碼，比自己宣告的 canonical 與自身 URL 是否一致，成本很低。
修復時注意一個坑：改完 canonical 後要清快取再驗證，帶快取返回的 200 是假象。canonical 的定義與常見誤用，可以參考Canonical 是什麼意思那一篇，裡面把該指向自己的幾種場景列全了。要讀懂 Google 眼裡的頁面版本，URL Inspection 實戰是必須過的一關。
收錄到底要多久？7 頁金絲雀的 D+14 時間線
說完三個卡點，回頭講「慢」。很多老闆的焦慮來自一個錯誤預期：以為頁面發出去，隔天就該在 Google 裡搜尋到。事實不是這樣。
我們做過一次金絲雀實測：7 個頁面在 09-18 當天發布，此後逐日檢查收錄狀態。前面幾天是零收錄，中途陸續進來，直到第 14 天才達到 7/7 全部收錄。整個過程沒有做任何特殊操作，也沒有出故障——這就是一個權重正常的站在當下的正常速度。
這個實測有兩個直接結論。第一，收錄以週為單位計時，不是以小時。第二，發布後第三到第七天沒有收錄，屬於正常區間，此時任何「搶救」動作都是多餘，還會污染變數。真正該做的是等，並且在等待期裡把內鏈和 sitemap 這些確定性的工作做紮實。
順帶說一句，外面那些「多少天收錄」的經驗談，多半是不可重現的。Reddit 上有一篇公開討論，原帖標題《Recently hit 6.4 mil monthly organic traffic for a SaaS website. Here’s the 40 tips that h…》，參與者包括 /u/levi815、/u/DrJigsaw 等。來自 Reddit 公開討論的這類貼文，讀時要分清哪些是長期動作、哪些只是單次結果——收錄卡點從來不是靠一條技巧點著的。
如果你想知道哪些頁面在拖後腿，抓取預算和日誌是更靠得住的證據，方法見日誌分析與抓取預算。
一張排查順序表
把上面的內容壓成一張表。順序是按「證偽速度」排的，能在幾分鐘內排除的放前面。
| 順序 | 查什麼 | 怎麼驗 | 常見兇手 |
|---|---|---|---|
| 1 | 未收錄頁的狀態分布 | GSC 網址檢查逐頁看狀態 | 大量 unknown = 發現層問題 |
| 2 | sitemap 的真實狀態 | 瀏覽器打開 sitemap.xml，核對該頁在不在 | 快取凍結、新頁不在其中 |
| 3 | Google 拿到的 HTML | 網址檢查對比已抓取版本與渲染結果 | 正文靠 JS 注入，初始 HTML 是空殼 |
| 4 | canonical 指向 | 看 Google 選擇的標準網址是否等於自身 | 指向首頁、舊網域或變體頁 |
| 5 | 內鏈入度 | 看未收錄頁有沒有站內連結指向 | 孤島頁、只有分頁入口 |
| 6 | 這時才輪到內容 | 對照已收錄頁找差距 | 重複、拼湊、無獨立價值 |
順序的重要性在於止損。市面上的教學大多讓你從第 6 步開始，直接改內容；而我們經手的收錄排查裡，兇手幾乎都藏在前 5 步。前 5 步全部乾淨，再談內容，才不算浪費。Google 收錄完整指南和抓取、索引、排名的流程兩篇，可以作為這張表的背景閱讀。
修好之後，該盯哪幾個數字？
修好不等於結束。收錄是會被重新弄壞的，換主題、裝外掛、遷伺服器、改快取策略，任何一個動作都可能讓今天正常的鏈路重新斷掉。所以要留下可複查的數字。
我盯四個：全站已編入索引的頁面數、sitemap 上次被讀取的時間、未收錄頁的狀態分布、canonical 與自身 URL 的一致率。前兩個按週看，後兩個按月抽查一批就夠。異常會先變成一個數字，再變成事故。
還有一個槓桿值得單獨說：內鏈。未收錄頁大多是孤島，從已收錄、主題相關的頁面給出連結，是最快也最可控的動作。錨點文字用目標頁的真實標題，別堆關鍵字。批次頁面尤其要注意模板化網站的索引風險，可參考程式化 SEO 模板頁與索引風險，以及 WordPress 站常見的外掛—索引—內容連動問題，見WordPress 外掛與索引速度。
最後一句提醒：收錄只是入場券，進了索引庫不等於有排名，有排名也不等於有詢價。若收錄和流量都修好、詢價仍無變化，那是另一個問題，別在收錄線上繼續加碼。
常見問題
文章發布多久沒收錄才算異常？
按我們的金絲雀實測，7 個頁面到第 14 天才全部收錄。因此兩週以內沒有收錄，先不要下定論，把它當成正常等待期，同時確認 sitemap 裡有它、站內有內鏈指向它。超過這個週期仍未收錄，再按上面的順序表逐項排查。
反覆點「請求編入索引」能加快收錄嗎？
不能。請求收錄的配額有限，而且官方提示寫得很清楚：多次提交同一網址並不會改變排隊順序。它只是加速器，前提是頁面本身能被發現。給已收錄的頁面提交，等於白燒配額。
外掛後台顯示 sitemap 正常，還需要自己核對嗎？
需要。sitemap 凍結屬於零報錯的靜默故障，外掛認為自己交付了、快取認為自己命中了，後台一切正常。唯一可靠的辦法是直接打開 sitemap.xml 看最新頁面在不在，再去 Search Console 核對 Google 實際讀取的時間和條數。
canonical 寫錯了，Google 會不會自己糾正？
不要指望它。Google 有時會忽略明顯錯誤的 canonical，但這屬於例外，不是你可以依賴的機制。正確做法是讓每個頁面的 canonical 指向自身，改完後清快取，再用網址檢查確認 Google 選擇的標準網址是否已經跟上。
收錄慢的站，是不是內容品質不行？
不是。內容品質只影響四檔狀態裡的「Crawled – currently not indexed」這一檔。大量頁面卡在 unknown 或 Discovered，說明問題在發現與抓取層，改內容等於修錯了零件。
資訊來源＝實測：tianwenseo 收錄排查記錄（三個卡點：sitemap 不更新／渲染不可讀／canonical 指錯；sitemap 凍結事故根因＝twwl Redis transient 快取凍結，已用 mu-plugin 修復）；金絲雀實測：7 個頁面 09-18 發布，D+14 達成 7/7 收錄。公開資料：Reddit 公開討論帖《Recently hit 6.4 mil monthly organic traffic for a SaaS website. Here’s the 40 tips that h…》（參與者 /u/levi815、/u/DrJigsaw 等）；tianwenseo.com/google-indexing-problems-three-real-cases-tw/（繁體原版，可核）。
本頁由簡體版機器翻譯，尚待人工審核。