Blog · 2026-08-30
新站一頁都沒被索引？先查 canonical 跟 sitemap 有沒有打架
收錄掛零先別急著改內容：用 URL 檢查 API 看 lastCrawlTime，全空代表訊號在打架——把 canonical、og:url、JSON-LD、sitemap 四個位置對齊、逐筆驗到 200、重送 sitemap，通常就解了。
站上線好幾個星期，sitemap 交了、內容也不是薄頁，Search Console 的收錄數還是 0。最常見的反應是回頭改文章、換標題，或安慰自己「新網域就是要等」。先停一下：一頁都沒被索引，通常不是品質問題，而是網站對搜尋引擎講了兩套互相矛盾的話——這種問題改內容改不好，查對地方才修得掉。
先看 lastCrawlTime：全空＝Google 根本沒來，不是來了嫌爛
用 Search Console 的 URL 檢查 API（urlInspection().index().inspect()）把全站網址掃一遍，重點看兩個欄位：coverageState 跟 lastCrawlTime。這兩個欄位把「沒被收錄」拆成兩種完全不同的病：
lastCrawlTime有值、狀態是「已檢索 - 目前尚未建立索引」：Google 來過、看完、決定先不收。這時才輪得到內容品質、樣板重複度的問題。lastCrawlTime全空、狀態卡在「已找到 - 目前尚未建立索引」甚至「Google 無法辨識的網址」：Google 連抓都沒抓。內容寫得再好它也沒看過，問題在技術訊號，不在文章。
我們處理過的「整站掛零」新站，掃下來 lastCrawlTime 清一色是空的。這個欄位一空，就可以跳過內容焦慮，直接查訊號。
真兇長這樣：sitemap 說 A、canonical 說 B、B 又被 308 轉回 A
去識別化後的實際案例，三行就能看懂：
sitemap 的 <loc> → https://example.com/reviews/foo （無副檔名）
頁面的 canonical → https://example.com/reviews/foo.html （帶 .html）
實測 foo.html → 回 308，轉回無副檔名的 /reviews/foo
站在 Google 的角度走一遍：照 sitemap 來抓 A，A 頁上的 canonical 說「正式版是 B」，去抓 B，又被 308 丟回 A。兩個訊號來回踢皮球，Google 不會幫你猜哪個算數，它的做法是延後處理，或乾脆放棄建立索引。
這個雷在靜態託管平台上特別好踩：例如 Cloudflare Pages 會自動把 /foo.html 308 轉到 /foo——檔案系統上放的是 foo.html，對外正式網址卻是無副檔名的 /foo。產生器照檔名輸出帶 .html 的 canonical，sitemap 又輸出無副檔名的 loc，兩段程式各自看都「沒錯」，錯在不一致。
要對齊的四個位置，少一個都還在打架
一頁的正式網址在站上不只出現一次，以下四個位置必須逐字元一致：
<link rel="canonical"><meta property="og:url">- JSON-LD 裡 WebPage / Article 這類節點的
"url" sitemap.xml的<loc>
修法不是開四個檔案各改一次，而是在產生器裡定義唯一的「正式網址」函式，四個位置全部從同一個值輸出。靠人工同步四份字串，遲早再打架一次。
順帶一個常見的鄰居問題：sitemap 的 loc 混進建置目錄的路徑前綴，線上直接 404。我們踩過更陰的版本——驗證腳本裡一行「好心」的 fallback 自動把前綴剝掉再比對，寫錯的 loc 因此每輪檢查都過，連續綠了非常多輪都沒人發現。教訓：fallback 只能吸收已知且正確的形式差異（例如平台的無副檔名網址），不能拿來吸收錯誤。寫每行 fallback 前先問一句：這是在容錯，還是在掩蓋 bug？
驗收只有一條標準：每筆 loc 直接回 200
改完不能只看「頁面打得開」。瀏覽器跟帶 -L 的 curl 都會自動跟轉址，308 根本看不到，所以要關掉自動跟隨來量：
# 不帶 -L，才看得到真實狀態碼
curl -s -o /dev/null -w "%{http_code}\n" "https://example.com/reviews/foo"
標準：sitemap 裡每一筆 <loc> 直接請求都要回 200。回 308 算失敗——代表 loc 寫的不是正式形式；404 更不用說。另外抽幾頁確認三位一體：實際請求的網址、頁面 canonical、og:url 三者完全相同。
最後一步最多人漏：回 Search Console 重新提交 sitemap。不重送，Google 手上還是舊檔案，矛盾訊號會繼續留在它的排程裡，前面全部白改。
對齊之後還是卡「已找到」？換查內鏈
四處對齊解決的是「訊號矛盾所以不抓」。如果訊號乾淨了，頁面還是長期卡在「已找到 - 目前尚未建立索引」，下一個常見兇手是內部連結太稀：頁面只掛在 sitemap 裡，站內幾乎沒有別頁引用它，Google 判定它不重要，就不排隊來抓。
我們在一個高競爭產業的內容站做過內鏈配平：配平前有 49 頁只有 1 條入鏈，補到全站 116 頁每頁入鏈都 ≥ 4 之後，該站收錄率達 153/173 頁（約 88%）。做法一樣走自動化——把「每頁被引用次數」當成建置時的守門指標，輸出前先算一遍，不足的頁面自動從相關頁補連結，而不是靠編輯記得互連。
結語：把這套檢查寫成腳本，掛進部署管線
整理一下查案順序：URL 檢查 API 看 lastCrawlTime → 全空就對齊 canonical / og:url / JSON-LD url / sitemap loc 四處 → 逐筆 loc 驗 200（關掉轉址跟隨）→ 重送 sitemap → 還卡就查內鏈。每一步都是可程式化的檢查，值得寫成腳本掛進部署流程，每次上線自動跑，別靠上線後人工想起來。如果你的新站也卡在收錄掛零，或想把這類檢查自動化省下反覆排查的時間，可以找我們聊聊——把 URL 檢查 API 的實際回應拉出來看，通常很快就能定位是哪一層在打架。