入口頁跑起来之後，大部分判断都要落到日誌上：蜘蛛有没有来、来了多少次、抓的是哪些 URL、每次返回了什么狀態。日誌本身不提升抓取，但它决定了你在遇到問题时是拿着資料排查，還是靠感觉反复改頁面。很多入口頁的調整之所以来回折腾，原因就是日誌留得太少或太短，等到想回看时已经没東西可看。
至少该留下哪些字段
如果條件允许，訪問日誌里這几項尽量齐全，被 CDN 或反向代理包一层时尤其要注意：
- 請求時間，明确标注时区，避免跨时区团队對不上号；
- 客戶端 IP，並確認能取到真實来源 IP，而不是代理节点 IP；
- User-Agent 原始字符串，不要提前做過滤或归一化；
- 請求方法、完整 URL 连同查询串；
- HTTP 狀態碼與响應字节數；
- 响應耗时；
- Referer，用来判断蜘蛛是從哪條路径進来的。
字段缺失往往在排查时才發現。比如只有狀態碼没有完整 URL，就無法判断是哪個連結出了問题；只有 UA 没有 IP，就没办法区分正常抓取和被伪装的請求。
留存周期與轮轉方式
常见的做法是按天切分、压缩归档，保留三十到九十天。選這個区間的原因很實际：一個 URL 從首次被發現到被反复抓取，中間往往跨越數周，留存窗口太短，就看不到完整鏈路。
- 按天切分，方便做同日對比和前後對比；
- 归档时压缩，控制磁盘占用；
- 清理之前先確認目前有没有正在跟進的問题，避免删掉正在用的證據；
- 多台服務器的话，尽量统一采集到一處，否則排查要在几個终端之間来回切。
用日誌能回答的几類問题
蜘蛛到底来没来
先按 UA 中的蜘蛛标识過滤，再看 IP 段是否對得上。需要提醒的是，UA 是可以伪造的，單靠這一個字段很容易誤判。更稳妥的方式是 UA、IP 段、請求特征三者交叉驗證：同一来源的抓取频率是否稳定、訪問的路径分布是否符合抓取习惯、是否伴随大量無意义的随机路径。
抓了哪些、漏了哪些
把日誌里的 URL 去重，和入口頁上實际存在的連結清單做對比，差异就是线索。某個連結一直没出現，可能是位置太深、被 robots 規則挡住、由脚本生成而抓取端拿不到，也可能是頁面本身没被訪問過。這一步不需要复杂工具，两張表對一遍就能看出方向。
返回了什么
狀態碼的分布比單條记錄更有價值。5xx 集中出現，說明服務端不稳定；大量 3xx 要检查跳轉鏈是否過長；404 集中出現，通常意味着連結清單和线上實际 URL 已经不一致，頁面改過而連結没同步。响應耗时也值得留意，個別 URL 明顯慢，往往會被抓取端降低優先級。
容易踩的几個坑
- 只儲存聚合报表，不保留原始日誌，出問题时無法回溯到單條請求；
- 日誌時間不带时区，跨团队沟通时反复確認；
- 把 CDN 节点 IP 当成蜘蛛 IP，統計出来的来訪量完全失真；
- 日誌分散在多台机器、多個目錄，没有统一收集入口；
- URL 中带敏感參數或令牌，未做脱敏就直接長期留存。
一個简單可行的落地方式
- 每台入口頁服務器開啟訪問日誌，按天轮轉，先保證有原始資料；
- 用统一采集把日誌归到一處，至少支持按 URL、狀態碼、UA 過滤；
- 每周固定看一次狀態碼分布和来訪次數，形成基线，異常才顯得出来；
- 發現問题时拉出当天原始日誌逐條核對，而不是只看匯總數字；
- 調整入口頁之後，用調整前後的日誌對比来判断變化，而不是凭印象。
日誌不解决抓取問题，它只是让「這件事有没有真的發生」變得有據可查。
把日誌留存当成一項基础工作来做，成本不高，但能省下大量反复猜测的時間。入口頁數量一多，没有日誌几乎無法判断哪個环节出了偏差。