看收錄數字的人，大多经歷過這種场景：昨天還是一萬二，今天變成九千，過一周又慢慢爬回去。如果每次都当成故障来處理，既耗時間，也容易把本来正常的狀態改坏。更實际的做法是先给波動分類，再决定要不要動手。
收錄量是個结果數字
它同时受三件事影响：蜘蛛来不来、来的时候抓到什么、索引系統最後留不留。這三件事里，只有一部分是站点能直接控制的。把數字当成單一指标去盯，很容易把抓取侧的临时變化誤判成内容問题。
- 自然浮動：新頁面進索引、老頁面被替代、索引重算，都會让數字上下走。
- 抓取侧變化：来訪频率下降、响應變慢、部分目錄被規則挡住。
- 索引侧變化：canonical 归並、近似重复折叠、頁面被判為低價值。
可以先观察的几種波動
幅度小、時間短、能自己回来
几天内上下浮動百分之几到十几個百分点，之後回到原来的量級，通常不需要處理。索引系統本身有刷新节奏，站点几千上萬個 URL 的时候，數字很难是一條直线。
集中在新發布的内容上
新增了一批頁面，總數先涨後落，落回去的量恰好接近新增量，多半是這批新頁面在观察期内被重新评估。先看它們的内容是否完整、是否有獨立價值，不用急着改模板。
和改版、模板調整同期出現
结构調整之後收錄數字變化是正常的。這段時間更适合盯抓取错誤和頁面返回狀態，而不是盯總量。等结构稳定两到四周再看趋势，判断會准得多。
需要動手排查的信号
抓取侧
- 服務器日誌里蜘蛛請求量明顯下降，同时 5xx、超时或连接重置增多。
- 某個目錄整体不再被訪問，检查 robots.txt、防火墙和 CDN 規則有没有誤伤。
- 响應時間變長，尤其是列表頁、搜尋结果頁這類動態生成的頁面。
索引侧
- 抽查頁面發現 canonical 指向了別的 URL，而這不是你設定的。
- 同模板的頁面被大面积折叠，索引里只剩少量代表頁。
- 頁面本身没改，却從索引里登出，並且没有對應的抓取错誤。
站点侧
- 内鏈结构變了，原本能点到的頁面层級變深或者入口消失。
- 分頁、篩選、排序产生了大量新 URL，把索引空間挤占掉。
- 頁面内容被大幅精简，正文量掉到明顯低于同類頁面的水平。
一套可以复用的排查顺序
- 先看服務器日誌，確認蜘蛛還来不来、抓的是哪些目錄。
- 再看抓取错誤，把 5xx、超时、被拒绝的請求挑出来。
- 用站点查询命令抽样几個目錄，看是整体登出還是個別頁面登出。
- 按模板分组對比：同一個模板下收錄比例是否一致。
- 检查 canonical 和索引指令，確認没有互相冲突的規則。
- 最後才回到内容层，看頁面是不是真的變薄了。
顺序別反。上来就改内容，往往動的是一层本来没問题的東西，反而把可對比的基线弄丢了。
別被單次快照带偏
第三方工具的數字和站点後台、日誌之間本来就有口径差异，單次取數只能当參考。真正有用的是同一指标连續两到四周的趋势，以及按目錄、按模板拆分之後的分组结果。總量下降但某個目錄在稳步增加，這本身就是一條有價值的线索。
收錄數字适合用来發現異常，不适合用来判断某一次調整的成败。看趋势，看分组，別盯單点。