抓取量下降、新頁面迟迟不被訪問，很多站長的第一反應是“改点什么”。今天加几條内鏈，明天換一版 Sitemap，後天又去調服務器，改了一圈却说不清是哪一步起了作用。更稳的做法是先把問题定位到某一层，再動手。

下面這套顺序，從离蜘蛛最近的地方開始，逐层排除。

第一层：日誌里蜘蛛到底来没来

打開服務器日誌，按蜘蛛的 User-Agent 過滤，先看目标 URL 有没有請求记錄。這一步决定了後面所有方向。

• 完全没有记錄：問题在“發現”环节。可能是没有内鏈指向、入口太深、Sitemap 未提交或被忽略、robots.txt 里被挡，也可能整站抓取量本身就在下滑。
• 有记錄但次數极少：問题在“調度”环节。跟站点整体權重、更新频率、抓取预算有關，單頁改内鏈的效果有限。
• 记錄很多但反复抓同一批 URL：說明新 URL 没進入待抓队列，回到發現环节检查。

第二层：来了但拿不到頁面

有請求记錄，但狀態碼不是 200，就要顺着狀態碼往下查。這一步经常被忽略，却最容易解释“抓取量突然掉了”。

• 403：多為安全策略、防火墙或 CDN 規則誤拦，尤其是對特定 UA 或高频 IP 的拦截。
• 429、503：服務器在主動降速。短時間可能是保護，長時間持續會让蜘蛛降低訪問频次。
• 5xx 连續出現：蜘蛛會减少訪問，恢复後也要一段時間才回到原来的节奏。

响應時間同样要看。首字节時間過長、頁面迟迟返回不完，蜘蛛容易中途放弃，或者把该 URL 的優先級往下調。

第三层：拿到頁面但讀不到内容

狀態碼正常、HTML 也返回了，但正文和連結没被识別，常见原因有几個：關键内容靠 JS 渲染、首屏之外的内容延迟加载、正文被大量 DOM 层层包裹、或者把重要文字放在图片里。

做法是用抓取工具模拟一次，對比渲染前後的 HTML，看連結和文字是否出現在初始响應中。如果只在渲染後才出現，就要评估蜘蛛执行脚本的成本。

第四层：能讀，但没有可跟的連結

頁面本身没問题，可蜘蛛讀完就停了，說明出站内鏈不足。检查几点：

• 列表頁、詳情頁之間的連結是否用真正的 a 标簽，而不是点击事件。
• 重要頁面是否只從首頁几步之外才能到達，路径是否绕。
• 是否存在一批只靠站外連結或 Sitemap 才能被發現的“孤立頁面”。
• 分頁、篩選、标簽頁是否形成大量低價值 URL，稀释了抓取。

内鏈的作用不只是传递權重，更是给蜘蛛画出可走的路。路径断了，Sitemap 提交再多也补不回抓取深度。

第五层：Sitemap 與提交渠道

前面几层都正常，再来看 Sitemap。检查文件是否能正常訪問、URL 是否與线上一致、是否混入了 404 或重定向地址、lastmod 是否長期不變。Sitemap 是补充發現渠道，不是替代内鏈的手段，把它当成兜底更合适。

為什么要按這個顺序

先確認蜘蛛到没到，再看它拿到什么，最後才看它有没有路可走。顺序反了，容易在還没確認發現环节的情况下就去優化内鏈，改完也看不出效果。

一份可执行的排查清單

1. 過滤日誌，確認目标 URL 是否有蜘蛛請求。
2. 統計狀態碼分布，找出非 200 的占比。
3. 检查响應時間，定位慢頁面。
4. 用抓取工具對比渲染前後 HTML，確認内容是否可见。
5. 检查内鏈路径，確認目标頁面從入口几步可達。
6. 核對 Sitemap 内容與线上 URL 是否一致。
7. 只改一處，观察日誌變化，再决定下一步。

抓取問题很少是單一原因造成的，但每次只動一個變量，日誌會告诉你答案。這比一次性大改要可控得多。