做抓取測試时最常见的動作，是把 URL 贴到浏览器里打開，看到頁面正常渲染，就認為蜘蛛也能抓。這個判断只在少數情况下成立。浏览器带着本地缓存、Cookie、登入態，可能還挂着代理；而蜘蛛拿到的是一份全新的、没有這些上下文的請求。两者看到的结果不同，能走的路径自然也不同。
浏览器和蜘蛛的差异在哪几處
- 身份不同：浏览器請求的 UA 是你自己，蜘蛛是它自己的 UA。服務器、CDN、防火墙都可能按 UA 分流，返回不同頁面，甚至直接拦截。
- 来源 IP 不同：地域限流、IP 信誉库、机房網段拦截，都會让同一條 URL 在两邊得到不同结果。
- 狀態不同：Cookie、登入態、會话參數决定了頁面返回什么内容。蜘蛛没有這些，拿到的是“未登入版本”。
- 脚本执行不同：浏览器會执行 JS，蜘蛛是否执行、执行到什么程度，取决于引擎。源碼里没有的連結，渲染後可能有；反過来也存在。
一套可以复用的抓取測試流程
第一层：入口有没有放行
先確認 robots.txt 没有挡住目标目錄，再確認 CDN 與防火墙没有把搜尋引擎的 UA 或 IP 段拦下来。這一步最容易被忽略，因為它在浏览器里永遠看不出問题——你自己的 UA 本来就在白名單里。
第二层：狀態碼與响應头
用不带 Cookie 的方式請求一次，检查返回碼是否為 200，是否有多余的重定向跳轉，响應头里有没有 noindex、canonical 指向別處，或者按 UA 變化的 Vary 設定。重定向鏈每多一跳，抓取路径就多一次消耗。
第三层：内容里有没有可以繼續走的連結
看返回的 HTML 源碼，而不是渲染後的画面。列表頁的分頁、詳情頁的上下篇、面包屑，這些連結是否真的寫在了源碼里。如果連結只存在于脚本执行之後，就要確認执行 JS 的抓取方式能不能拿到它們。
第四层：回到日誌確認
測試工具返回的结果只是推断，日誌才是事實。观察目标 URL 在服務器日誌里是否出現真實蜘蛛的记錄，訪問频率和返回碼是否與预期一致。工具放行不等于蜘蛛會来。
几類典型的誤判
- 用在线工具测完就当结论。工具的 UA、IP、渲染能力和真實蜘蛛不同，能通過不代表真實抓取能通過，反之亦然。
- 只测首頁和栏目頁。深层 URL 常常是參數最多、最容易被規則挡住的一批，抽样要覆盖到它們。
- 測試环境和线上环境不一致。測試时放行的規則，上线後可能被另一條策略覆盖。
- 忽略缓存层。缓存按 UA 或设备分流时，蜘蛛拿到的可能是缓存里的舊版本頁面，里面的連結早已失效。
- 把渲染结果当成源碼。一些工具預設执行脚本並展示渲染後的 DOM，看上去連結齐全，實际源碼里空無一物。
把測試變成例行動作
新目錄上线、改版、調整 robots 或防火墙規則之後，都值得把目标 URL 跑一遍上面的流程。把通過測試的 URL 存成一份清單，隔一段時間再抽样复查，配合日誌做對照，能比較早地發現放行規則被改動，或者某類模板突然返回空内容這類問题。
抓取測試解决的是“這條路通不通”，不是“蜘蛛一定會走”。通路只是前提，走多深、走多快，還要看站点整体的结构和信号。
另外，測試结论最好记錄下時間、UA、返回碼和当时的規則配置。环境變化很快，一份没有上下文的“測試通過”记錄，過两周基本没法复用。