前端发布别只测页面能打开：canonical路由回归该怎么验

前端发布后，产品页正文、按钮和接口都正常，canonical却在站内切换时指向上一个产品。这类回归很容易漏过：常规冒烟测试只直接打开一个URL，没有走客户端导航，也没有比较原始HTML与脚本执行后的页面头部。

给发布检查增加canonical用例，重点不是多抓几张截图，而是记录同一条路由在不同进入方式下的声明值和数量。以下是一套面向已有SSR或客户端路由网站的测试思路，不要求更换框架，也不把规范网址检查等同于排名测试。

先把预期值写成独立的测试数据

为代表性页面记录公开URL、预期canonical及为何采用该地址。至少考虑产品详情、分页和语言版本。预期值应由网站认可的URL规则确定，不要直接从被测页面读出canonical，再拿它和自己比较。

带跟踪参数的同一内容可能规范到干净地址，但真正不同内容的分页或语言路径不能机械截掉。预发布域名与正式域名的区别也要明确；测试环境的索引控制另行设置，不能为了让测试通过就公开原本应受限的预览站。

同一页面走三条路径

1. 直接请求：保存最终响应URL、状态码和初始HTML中全部canonical声明。
2. 页面接管完成：用项目可识别的页面就绪状态等待渲染，再读取DOM中的全部声明；不要只取第一个标签。
3. 站内导航：从另一个产品进入目标页，随后后退、前进，检查正文所代表的产品与canonical是否仍对应。

一个教学用例是从产品A切到产品B。若正文已经是B，canonical仍是A，应追查路由状态、共享head组件或异步数据覆盖。反过来，A的初始HTML正确，首次加载后却变成首页，则要查默认值是否覆盖了服务端结果。两类问题触发条件不同，不适合用同一条“刷新正常”结论关闭。

断言数量、值和对应内容

建议保存实际观察到的完整地址，包括协议、主机、路径和必要参数。通常希望页面有一个明确的canonical声明；发现多个标签，不能假定最后一个必然生效。还应检查HTTP响应是否另有冲突的Link头，避免只修HTML而遗漏另一处声明。

Google的JavaScript SEO说明要求不要通过JavaScript把canonical改成与原始HTML不同的地址，并提醒多个或冲突声明可能产生非预期结果。这针对的是同一页面的声明一致性；客户端真正导航到另一个页面时，仍要更新为新页面的正确值。

需要定位两阶段输出者时，可以参考光算的SSR与hydration的canonical冲突排查，将首次加载和站内切换分开记录。测试发现冲突后，应修复URL生成来源，而不是在页面尾部再注入一个标签试图覆盖。

失败记录要能交给开发复现

保留发布版本、进入路径、预期值、原始HTML值、最终DOM值和页面正文标识。若怀疑短暂漂移，增加开发环境的变更观察；只在结束时读取一次，无法证明中途没有被改写。固定等待几秒也未必可靠，慢接口与缓存可能改变时序。

这套检查通过，说明测试覆盖的路由场景没有出现已定义的声明回归。它不证明Google一定采用该canonical，也不证明整站SEO无问题。把可重复的技术断言放进发布流程，再通过授权的Search Console数据观察搜索端结果，两部分分别报告即可。