判断一個 URL 有没有被收錄，很多人习惯用 site: 查一下，看到數字就下结论。但只要換一種方法核對，结果往往對不上：site 说没有，覆盖率报告说已编入索引，日誌里又明明看到被抓過。這不一定是工具出错，而是三種口径統計的根本不是同一件事。
一、site 查询：方便，但只是估算
site 查询返回的是搜尋引擎自己给出的一個近似结果集，它有几個天然限制：
- 结果被去重和折叠。同一模板下高度相似的頁面，可能只展示一部分作為代表，剩下的被省略。
- 數字不精确。同一批 URL，換關鍵詞、換時間点查询，數量會變，這不是收錄量在剧烈波動。
- 不實时。刚刚發布的頁面，site 查询经常要等一段時間才反映出来。
- 受归属影响。多個 URL 内容相近时，查询结果里出現的可能是搜尋引擎選定的那個版本，而不是你輸入的那一個。
所以 site 查询适合粗判「這個站有没有被索引」，不适合用来確認某一條具体 URL 的狀態。
二、覆盖率报告：看的是搜尋引擎認定的版本
Search Console 的頁面索引报告颗粒度更细，但它也有自己的前提：
- 只覆盖你已驗證的资源，子域、目錄属性需要單獨驗證；
- 資料有延迟，通常不是当天狀態；
- 报告里的 URL 是经過 canonical 归並之後的代表 URL，原始 URL 可能被折叠進去，不會單獨出現；
- 「已發現但尚未编入索引」和「已抓取但尚未编入索引」是两種不同狀態，前者說明還没抓，後者說明抓了但没進索引。
換句话说，覆盖率报告回答的是「搜尋引擎怎么归類這條 URL」，而不是「這條 URL 現在能不能搜到」。
三、服務器日誌：只能證明被抓取
日誌是最硬的證據，但它證明的事情很容易被誤讀：
- Googlebot 訪問並拿到 200，只說明抓取成功，不代表已经编入索引；
- 反過来，日誌里没有记錄，也不一定是没抓，可能是被 CDN、缓存层或日誌采样吃掉了；
- 日誌能帮你看到抓取频次、狀態碼、抓取的是哪個 URL 變体，這些信息對排查很有用，但不能單獨用来判定收錄。
四、直接搜尋：最接近用戶视角
用一個頁面上獨有的字符串（例如一句獨特的标题或一串编号）去搜，是判断「能不能被搜到」最直接的方式。注意几点：
- 去掉個性化、登入狀態和地区影响，最好用無痕窗口；
- 搜尋引擎會自動省略與已有结果高度相似的條目，搜不到不代表没索引；
- 頁面被索引但排名很低时，需要翻到很後面才能看到，這属于展現問题，不是收錄問题。
五、一個從粗到细的對照流程
- 先用唯一字符串搜尋，確認這條 URL 是否可被搜到，记錄观察到的時間点。
- 再用 site 查询看整体規模，只關注數量級和趋势，不要纠结具体數字。
- 打開覆盖率报告，看這條 URL 落在哪個狀態，注意它是否被顯示為自己，還是被归並到了別的 URL。
- 翻日誌，確認最近的抓取時間、狀態碼和抓取的 URL 形態，判断是抓取問题還是索引問题。
- 等待一個合理周期後再复查，新頁面的狀態變化本来就需要時間，频繁改動反而會干扰判断。
六、几種常见的誤判
- 把 site 數字当成收錄總數，據此判断站点「掉了多少收錄」。
- 看到日誌有抓取记錄，就認為收錄已经完成，不再處理頁面质量問题。
- 覆盖率报告顯示「已發現但尚未编入索引」，就急着改标题、改内容，其實更该先检查内鏈和入口。
- 用带參數的 URL 去查询，结果被归並到規范版本，于是誤以為頁面没被收錄。
把三種口径当成互相驗證的工具，而不是互相否定的證據：日誌回答「来没来過」，覆盖率报告回答「怎么归類」，直接搜尋回答「用戶能不能找到」。
排查时先明确自己想知道的是哪一個問题，再選對應的口径，比盯着一個數字反复刷新要有效得多。