日志文件查看改版前怎样保留搜索基础：先做可交付的抓取与索引基线
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b8b2f1c37fc6.html
📄
日志文件查看改版前怎样保留搜索基础：先做可交付的抓取与索引基线
改版前保留搜索基础的核心做法是：在动模板和 URL 之前，先用日志文件查看真实抓取情况，把搜索引擎已经抓过、已经收录、仍有流量的 URL 整理成一份基线清单，改版后逐项对照。日志记录的是爬虫请求，不是排名结果，但它能告诉你哪些地址正在被访问、返回什么状态码，这是判断改版会不会切断搜索入口的第一手依据。
假设一个多人协作的改版场景
假设某内容站要换模板并调整栏目路径，团队三人分工：一人改前端，一人配跳转，一人负责上线检查。改版前没有人导出日志，上线后才发现旧列表页大量返回 404，而新列表页还没有被充分抓取。这个例子说明，问题往往不在新页面做得好不好，而在旧地址是否被平稳交接。
这类返工通常来自三个错误：只看了后台的页面清单，没看爬虫实际请求；只处理了首页和栏目页，漏掉分页与筛选参数；把跳转规则写在模板层，模板一换规则同时失效。多人协作时，任何一项没有写进交付文档，接手的人都可能重复踩坑。
用日志文件查看建立改版前的基线
日志文件查看的目标不是读完所有行，而是筛出与搜索抓取相关的请求，形成可核对的清单。可以按下面的顺序执行：
- 取改版前连续 30 天的原始访问日志，保留未压缩版本，避免后续字段对不上。
- 按 User-Agent 筛出搜索引擎爬虫的请求，把结果单独存成一份文件。
- 提取请求 URL 与状态码两列，按 URL 去重，统计每个地址被请求的次数。
- 把状态码为 200 的 URL 标为“正在被抓取”，3xx 标为“已有跳转”，4xx 与 5xx 单独列出。
- 将这份清单与站点地图、站内链接、已有流量页面交叉比对，标出只靠日志才能发现的地址。
判断结果时注意：日志里出现 200 只说明服务器正常返回了内容，不代表该页已被索引，更不代表有排名。反过来，某个 URL 在日志里很少出现，也不等于它没有被收录，可能只是抓取频率低。把“被抓取”“被索引”“有流量”当成三件事分别记录，改版时才不会误判。
改版前必须锁定的四类地址
- 有流量且返回 200 的页面：改版后应保持可访问，或跳到内容对应的新地址。
- 被大量抓取的分页与列表页：容易在换模板时丢失，需要确认新模板是否仍输出等价链接。
- 带参数的筛选地址：确认哪些参数影响内容、哪些只是排序，避免把有效页面一并屏蔽。
- 返回 4xx 的历史地址：改版是清理的好时机，但要先确认它们确实没有外链和流量，再决定是否保留跳转。
交付时把这份清单写成表格，每行包含旧 URL、状态码、处理方式、负责人、验证方式。多人协作最容易出问题的地方是“处理方式”只写“做跳转”，没有写跳到哪个地址，也没有写由谁验证。
上线后的检查项与判断标准
改版上线后，用同样的方法再取一段日志，与基线对比。可以重点看三件事：
- 原清单中返回 200 的 URL，现在是否仍返回 200 或合理的 3xx，而不是 404。
- 爬虫请求总量是否出现断崖式下降，若下降，先检查 robots 文件、跳转链和服务器响应时间。
- 新地址是否开始被请求，若长期没有，检查站内链接和站点地图是否指向了新地址。
如果发现异常，先区分“可能原因”和“已经定位的原因”。例如抓取量下降，可能是跳转链过长，也可能是服务器在改版期间变慢，还可能是 robots 规则被误改。只有逐项排除后，才能把原因写进结论，不要凭一个现象就断定是模板问题。
下一步建议：在改版排期里单独留出一个“日志对比”节点，指定一人负责导出基线与上线后日志，另一人负责核对清单。把这两份文件和跳转规则一起归档，后续再改版时可以直接复用。
