改版交付时，最容易出现的对话是：运营说“网站不太对”，开发回答“我这里能打开”。双方可能都没说错，只是观察的页面和条件不同。首页能显示，不代表旧文章的跳转正确；产品图能在编辑器里看到，也不代表访客请求的图片地址有效。
XunL 网站综合检测适合把这些分散问题先汇成一份有来源的记录。它从公开网址开始，组合访问、解析、页面技术、图片和性能等检查。读报告时，重点应是本次拿到了哪些证据、哪些页面被观察到，以及还缺什么，而不是寻找一个可以代表整站质量的分数。
先选一个入口，再决定要不要指定文章
可以用 https://www.ssevening.com/ 作为操作示例，把完整公开首页填入“网站 URL”。不要填后台编辑地址，也不要把预览令牌和账号参数带进去。如果验收重点是文章主图与预览条件，展开高级选项，选择手动指定文章，并填写同协议、同域名下的一篇公开文章。不同子域名应分别检查，不能把英文子站文章混进主站的组合报告。
运行后先读“本次综合检查的实际覆盖”。页面没有被抽到，就不能凭它没有报错判断正常；没有取得性能或文章信息，也不该改写成已通过。对于完整产品库、历史文章和登录后的功能，应另外建立范围明确的验收任务。
三种发现，交给三类处理动作
第一类是可以定位的访问问题，例如某张图片打不开。交接时记下引用它的页面、图片请求地址和原始响应，开发才知道该修路径、恢复文件还是处理访问策略。只截一张“图片异常”的汇总图，往往还需要重新找现场。
第二类是需要确认用途的设置。例如正式文章带有不索引指令，可能是草稿设置遗留；但搜索结果页或内部检索页使用同类指令，却可能符合原有策略。canonical指向另一地址也应先问清是否在合并重复内容，不能把所有非自引用关系一律改掉。
第三类是优化线索，包括大图、缓存与加载表现。这里要区分本站读取公开材料的结果、Google模拟环境的性能结果，以及是否存在真实用户数据。三种证据的覆盖不同，一项完成不代表另外两项也已经得到结论。
把报告改写成一张可以复查的工作单
例如改版后发现某篇教程引用旧图片，工作单可以写成：“教程页面引用的旧图返回错误；替换为当前素材地址；修改后重新打开文章并复查图片请求。”这比“优化网站图片”明确得多。若同时发现跳转链，应另列一项，避免把图片与重定向问题混在同一张无法判断是否完成的工单里。
每一项保留页面地址、检测时间、观察值、预期行为、负责人和复查结果。修完以后仍从原来的入口检查，特别关注首页导航、地图与页面规范地址是否一致。改了模板或CDN时，还要确认公开页面输出已经更新，不能只看后台保存成功。
一轮工作结束后，可以将报告导出为JSON或Markdown，或打印保留。它的价值是固定当时的证据，便于比较修复前后；报告本身不会替你修改目标站点，也不能证明未覆盖页面完全健康。
验收时经常被混淆的两个问题
为什么报告显示完成，还会有“未知”？
完成表示本次流程已经结束，未知则表示某个问题没有足够材料判断。可能是没有发现合适文章、访问受限或上游暂未提供数据。应补充对应输入或另行核实，不要把未知当成正常，也不要因此丢弃其他已经取得的证据。
综合检测以后，还需要全站查死链吗？
如果目标是验收全部内容，就仍需要明确覆盖范围的全站检查。综合报告适合发现方向和安排优先级，无法替代所有历史入口、全部图片以及动态业务流程的验证。先把能影响客户访问的确定故障修好，再逐步扩大检查范围，交付会更容易判断。
个人微信：ssevening
