网址收录工具，日志中应该核对哪些字段：一份协作交付清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /02a96ca03029.html
📄
网址收录工具，日志中应该核对哪些字段：一份协作交付清单
用网址收录工具排查收录问题时，日志里最该核对的字段是：请求时间、请求的完整URL、HTTP状态码、User-agent、来源IP、Referer、响应体大小、抓取耗时，以及服务器返回的X-Robots-Tag等响应头。判断收录异常时，不能只看状态码是200就放心，还要确认这个URL是否被robots.txt拦截、是否返回了noindex、是否把内容渲染成了空壳。多人协作时，把这些字段固定成一张核对表，能减少“我这边看是好的”这类返工。
一个假设例子：为什么只核对状态码会漏掉问题
假设某团队上线了一批商品页，发现部分页面迟迟没有出现在搜索结果里。运维同学打开访问日志，看到这些URL的HTTP状态码都是200，于是判断“服务器没问题，是搜索引擎还没收录”。但SEO同学进一步核对字段后，发现三件事：第一，这些URL的User-agent是普通浏览器，而不是搜索引擎的抓取程序，说明搜索引擎根本没有来抓过；第二，日志里出现了搜索引擎抓取程序请求robots.txt的记录，但目标页面没有对应抓取记录；第三，页面响应头里有X-Robots-Tag: noindex。
这个例子的结论是：状态码200只代表服务器成功返回了内容，不代表页面允许被索引。多人协作时，如果交付物只有一句“状态码正常”，下一个人就无法判断问题出在抓取、索引还是展示环节。把字段列全，责任边界才清楚。
抓取阶段要核对的字段
抓取阶段关注的是“搜索引擎有没有来、来了几次、拿走了什么”。建议核对以下字段：
- 请求时间：按小时或按天聚合，判断抓取频率是否骤降，以及是否与发布、改版时间吻合。
- User-agent：区分真实搜索引擎抓取程序与普通浏览器、监控脚本、第三方工具。只有确认是目标搜索引擎的抓取程序，这条记录才能用于判断抓取行为。
- 请求的完整URL：包含协议、主机名、路径和查询参数。带参数的URL和不带参数的URL要分开统计，避免把重复抓取误判成正常覆盖。
- 来源IP：用于辅助确认抓取程序身份。IP可以伪造，所以它只能作为辅助证据，不能单独作为判断依据。
- HTTP状态码：200、301、302、304、404、410、429、5xx要分别统计。429和5xx过多，可能意味着服务器在拒绝或拖慢抓取。
常见错误是把所有User-agent混在一起统计，得出“抓取量很大”的结论，实际大部分是监控和爬虫工具产生的流量。协作交付时，应明确写出筛选条件，例如“仅统计目标搜索引擎抓取程序的记录”。
索引阶段要核对的字段
抓取成功不等于允许索引。索引阶段要核对：
- X-Robots-Tag响应头：检查是否含有noindex、nofollow等指令。它作用在HTTP层，容易被忽略。
- HTML中的meta robots：与响应头可能同时存在，两者冲突时以更严格的限制为准。
- robots.txt抓取记录：确认目标搜索引擎抓取程序是否请求过robots.txt，以及返回状态是否正常。robots.txt的抓取限制不等于可靠的索引移除，它只控制抓取，不保证页面从索引中消失。
- canonical标签指向：日志本身看不到canonical，但可以结合抓取记录判断搜索引擎是否频繁抓取被指向的规范URL。
- 响应体大小：如果返回200但响应体极小，可能是空壳页、错误页或前端渲染未完成。
这里要强调一个判断条件：站点地图提交成功，不代表页面一定被收录。站点地图只是发现渠道之一，收录还取决于内容质量、重复情况和抓取预算。协作时不要把“已提交站点地图”当作收录完成的证据。
多人协作时的交付格式建议
为了让接手的人不用重新查一遍，交付记录可以固定成下面这种结构。以下为格式示例，不是真实项目数据：
- 核对范围：写明时间区间、主机名、URL路径规则、筛选的User-agent。
- 字段清单：逐项列出请求时间、完整URL、状态码、User-agent、来源IP、Referer、响应体大小、抓取耗时、X-Robots-Tag。
- 异常项：每条异常写清“现象—可能原因—已定位的原因”。例如“目标URL无抓取记录”可能原因是robots.txt拦截、内链缺失或站点地图未包含，未定位前不要写成唯一结论。
- 待确认项：把需要其他角色确认的内容单独列出，例如“需前端确认响应头配置”“需内容确认页面是否重复”。
常见错误是只丢一份原始日志，不写筛选条件和结论。另一个人打开后，面对几十万行记录，很难判断哪些是有效抓取、哪些是噪声。
容易混淆的字段与判断条件
Referer字段在搜索引擎抓取中经常为空，这属于正常现象，不能因为Referer为空就判断抓取异常。抓取耗时字段要结合状态码看：耗时高且伴随5xx或429，说明服务器压力可能是原因之一；耗时高但状态码正常，则未必影响收录。
HTTPS只代表传输加密，不保证页面安全无漏洞，也不直接保证排名。核对日志时，不要把协议从HTTP换成HTTPS当作收录问题的解决方案。不同搜索引擎的抓取程序名称、支持指令和日志格式需要分别核查，不能拿一个搜索引擎的日志结论直接套用到另一个。
下一步，把这套字段清单落到团队的交付模板里：先固定筛选条件，再逐项填写状态，最后把异常项拆成“可能原因”和“已定位的原因”。这样下一个人接手时，能直接看到核对到了哪一步，而不是从头再查一遍日志。
