日誌是 URL 發現最原始的證據
關于 URL 發現，站長手上通常只有三样東西：Sitemap 的提交记錄、後台的抓取統計、以及服務器日誌。前两样是匯總或抽样，只有日誌是逐條留痕的——什么時間、哪個来源、請求了哪個路径、返回了什么狀態碼。想回答「這條内鏈到底有没有被蜘蛛走過」，日誌是最直接的依據。
要注意的是，日誌能說明的是「来過没来過」，不是「會不會收錄」。把它当成發現路径的体检表，比当成效果指标更合适。
先把日誌里的行分清楚
原始日誌混着頁面、静態资源、接口請求和各類爬虫，直接看會糊成一片。建议先按路径聚合，把下面几類分開：
- 入口請求：蜘蛛對首頁、栏目頁、列表頁、Sitemap 文件的訪問。
- 落地抓取：從入口頁連結带出来的詳情頁、文章頁請求。
- 资源請求：css、js、图片、字体，和頁面發現關系不大，先過滤。
- 重复记錄：CDN 回源、负载均衡多节点寫入造成的同一次請求多條日誌。
過滤完之後，剩下的條目才值得逐條對照站点结构。
確認訪問者是不是搜尋蜘蛛
UA 字符串可以随意伪造，只看 UA 容易把掃描器当成搜尋蜘蛛。比較稳妥的做法是同时满足两個條件：UA 匹配，且来源 IP 通過反向 DNS 解析回落到對應域名。這一步做不到全量驗證，但至少能排除掉大部分噪音。
如果站点放在 CDN 後面，日誌里看到的往往是 CDN 节点 IP 而不是真實来源。這时需要開啟真實 IP 透传，或者直接使用源站日誌做核對。
把入口請求和落地抓取對上
按時間顺序排列同一来源的請求，通常能看出鏈條：入口頁被抓取後几秒到几分钟内出現的同源請求，多半就是跟随連結的结果。反過来，如果某個詳情頁只在 Sitemap 被讀取的那一刻前後出現一次，而入口頁之後完全没有它，那說明内鏈這一路没走通——可能是連結被脚本渲染、被 nofollow 标记，或者根本没寫。
這條時間线不需要非常精确，粗粒度的先後關系已经足够判断路径是否成立。
把「從没出現過」的頁面筛出来
更實用的一步是做差集：拿站点的 URL 清單减去日誌中出現過的路径。差集里的頁面大致對應几種情况：
- 站内没有任何内鏈指向它，也没進 Sitemap——典型的孤岛頁面。
- 被 robots.txt 或頁面級規則挡住了入口。
- 連結存在，但指向的是一個重定向或 404，蜘蛛跟到一半就停了。
- 只是日誌保留期太短，頁面被抓的时候记錄已经滚掉了。
前三種是可以動手修的，第四種需要先調整日誌保留策略再判断。
几個常见的誤判
- 缓存命中被当成没抓取：返回 304 或由 CDN 直接响應的請求，可能在源站日誌里看不到完整记錄。
- 日誌轮轉造成断档：按天切割又只保留几天，跨周期的回訪就丢了。
- 把其他爬虫算進来：SEO 工具、监控探针、聚合服務的抓取混在一起，會高估入口的實际效果。
- 只統計次數不看路径：同一個 URL 被反复請求，可能是參數變体造成的重复發現，而不是抓取积极性高。
响應時間也在日誌里
日誌通常带响應耗时字段，這個數字值得單獨看一遍。响應经常超過几秒的頁面，被抓取的频次往往偏低，尤其是内鏈层級較深的部分。服務器稳定性對 URL 發現的影响，很多时候不是「被抓不到」，而是「抓得少」，日誌里的耗时分布能反映這一点。
如果一批頁面同时在某個時間段出現超时，先查那一时段的服務器和資料库压力，再讨论抓取問题，顺序不要颠倒。
把结论落回站点動作
日誌核對的價值在于可以形成閉环。筛出来的孤岛頁面补内鏈，被挡住的入口检查規則，频繁重复的路径统一 URL 形態，响應過慢的頁面排查後端。整体上建议按周或按月做一次核對，把 URL 清單和日誌差集固定成一張表，這样每次改動之後能看出入口结构有没有變化。
比起点開一堆工具猜测原因，一條條日誌對着看更省時間，也更接近事實。