改版、换模板、调整目录结构时，最容易出问题的地方往往不是页面好不好看，而是蜘蛛原本走得通的那条路，在新版本里断了。等日志里出现大量 404、抓取量明显下滑再回头查，排查成本会高很多。把抓取预演固定成上线流程里的一步，能省下不少返工。
预演要回答的三个问题
不需要覆盖全站每一个地址，先把三件事确认清楚：
- 可达性：从首页出发，经过栏目页、列表页，能不能一路点到目标详情页，中间有没有被 403、404 或重定向循环挡住。
- 可解析：链接是写在 HTML 源码里的 a 标签，还是靠脚本执行后才生成。前者蜘蛛拿到源码就能顺着走，后者要看渲染环节是否稳定。
- 可归因：同一篇内容是不是出现了多个地址，canonical 指向哪一个，Sitemap 里写的又是哪一个。三者不一致时，抓取容易花在副本上。
怎么在预发布环境跑一遍
- 从线上 Sitemap、服务器日志、内链抓取结果里各拉一份 URL 清单，合并去重，作为预演样本。
- 在预发布环境用命令行工具或爬虫程序顺着内链走一遍，记录每个地址的状态码、跳转次数和最终落地地址。
- 把预发布的结果和线上做对比，重点看原本返回 200 的地址现在变成了什么。
- 抓取页面源码，确认目标链接确实出现在 HTML 里，而不是只在渲染完成之后才出现。
预发布环境本身要点到为止：加 IP 白名单或访问认证，避免测试内容被真实蜘蛛抓走。预演的目的是发现问题，不是让测试站参与线上竞争。
上线前的检查清单
- 核心入口页返回 200，页面上有指向主要栏目的可跟随链接。
- 列表页到详情页的链接写在 HTML 中，不依赖点击或滚动加载才出现。
- 分页、筛选、排序参数生成的地址，要么可抓取且内容稳定，要么明确屏蔽，避免产生大量近似地址。
- Sitemap 里的 URL 与线上实际地址一致，抽样访问均能返回 200，不再包含已下线的旧地址。
- robots.txt 没有误封新目录，也没有把整站样式和脚本一起挡掉。
- 改过地址的页面准备好了 301，跳转层数控制在最少，最终落地地址与 canonical 一致。
- 页面主体内容在源码中可见，标题、正文和链接不是全部由脚本注入。
- 移动端与桌面端使用同一套地址，不要把用户导向另一套 URL 结构。
灰度上线与观察窗口
站点体量较大时，可以先把新模板放给一部分栏目，观察几天日志：这些路径的抓取是否正常、状态码分布有没有异常、回访节奏有没有变慢，稳定后再全量切换。这样即使出问题，影响范围也可控。
上线后的一两周内，重点看三件事：旧地址的 301 是否被正确跟随、新地址有没有被抓到、有没有突然冒出大量 404。抓取量上升或下降都可能有多重原因，不必因为一两天的数据波动就立刻回滚；但如果持续走低，并且日志里能看到明确的断点，就该按上面的清单逐条回查。
预演不能保证蜘蛛一定来抓，也不能保证收录。它能把修路这件可控的事提前做完，剩下的交给时间和持续的内容更新。
把这份检查做成团队里固定的上线动作，比出了问题再翻日志要轻松得多。