Shopify 评价迁移上线前 QA 检查清单

Shopify 产品评价不只是页面上的社交证明。它会影响产品页信任感、导购判断、客服问题、转化率，以及某些项目里搜索引擎读取的结构化数据。

主题上线、评价应用更换、产品 handle 清理或目录迁移，都可能让评分悄悄断开。店铺看起来仍然很完整，但评价数量可能错误，旧的被隐藏评价重新出现，富结果标记消失，或者评价组件拖慢产品页。这份清单就是为了在上线前隔离这些风险。

先建立来源清单，再动主题。列出当前评价在哪里、由哪个应用管理、如何导出、使用哪个产品标识，以及上线后每个字段应该进入哪个目标位置。

不要只看总评价数。需要记录评分、评价正文、评价人名称、邮箱哈希或客户引用、产品 ID、产品 handle、SKU、变体引用、图片、视频、问答、商家回复、审核状态、语言和原始日期。

• 主题改造开始前，先导出当前评价数据。
• 把每个评价应用字段映射到新应用、主题组件、metafield 或 API 目标。
• 标记发生过 handle、SKU、变体或 canonical URL 变化的产品。
• 区分已发布、隐藏、标记、导入、激励评价和待审核评价。
• 保留产品级评价数量基线，用于上线后对比。

大多数评价迁移问题，本质上是匹配问题。评价可能挂到错误产品上，在变体之间重复，因为旧 handle 改动而消失，或者因为审核状态没有迁移而重新发布。

能用稳定的 Shopify product ID，就优先使用 product ID。如果迁移依赖 handle 或 SKU，一定要测试被改名、合并、拆分、归档或移动到新集合的产品。这些边界情况通常最能暴露真实风险。

• 优先用 Shopify product ID 匹配；只有在有明确 fallback 规则时，才依赖 handle 或 SKU。
• 检查重复 SKU、退役变体、套装产品和导入的 marketplace listing。
• 确认隐藏、拒绝、待审核和被标记评价保持原来的审核状态。
• 除非有法律或客服原因，否则保留原始评价日期和商家回复。
• 决定产品下架、重定向或替换后，评价应该如何处理。

不要只测试一个有五条干净评价的畅销产品。主题需要覆盖无评价、一条评价、上百条评价、图片评价、长评论、短评论、低星评价、翻译内容和不可售变体等状态。

评价组件常常因为小细节破坏页面：星级行在移动端换行，筛选器和 sticky 加购栏重叠，应用 CSS 覆盖主题样式，或者懒加载评价在用户阅读时造成页面跳动。

• 测试无评价、少量评价、大量评价和图片评价产品。
• 检查移动端、平板、桌面端、支持时的深色模式，以及常见浏览器宽度。
• 验证排序、筛选、分页、有用投票、媒体图库和提交评价状态。
• 确认评价摘要不会和价格、变体选择、订阅组件或 sticky CTA 重叠。
• 如果店铺有多语言，测试评价、评分标签和应用 UI 的本地化显示。

评价迁移可能改变结构化数据，即使可见设计没有问题。如果过去的 aggregate rating 或 review schema 由主题、应用或自定义代码输出，需要确认新实现输出有效且不重复的标记。

标记要真实。搜索引擎并不需要每个页面都有评价结构化数据，虚假或不匹配的评分反而会带来风险。目标是让产品页准确、可抓取，并且内部信号一致。

• 在重点产品页验证 Product、AggregateRating 和 Review schema。
• 确保评分数量、平均分和页面可见评价与结构化数据一致。
• 检查评价 tab、懒加载、应用 iframe 或 hydration 是否会隐藏爬虫需要的内容。
• 避免重复应用组件输出重复或冲突的 schema。
• 确认 noindex、canonical、sitemap、redirect 和 hreflang 仍然匹配产品 URL 计划。

评价应用可能把脚本、CSS、字体、媒体图库、分析事件和第三方请求添加到每个产品页。要在最终组件安装后测量性能成本，而不是只看空白 staging 主题。

同时确认 consent 和隐私行为。如果评价服务商收集邮箱、图片、客户身份或分析事件，主题不应该绕过 consent banner，也不应该发布团队原本想保密的数据。

• 比较评价组件加载前后的产品页体积、请求数、布局偏移和交互延迟。
• 检查应用脚本是否只在评价体验出现的页面加载。
• 确认评价提交、图片上传和邮箱收集流程符合 consent 要求。
• 测试应用异常或第三方脚本被阻断时，PDP 是否仍可使用。
• 确保分析和 tag manager 中的评价互动事件只记录一次。

主题发布前，选择一个能代表整个目录的评价迁移样本。包括畅销品、无评价产品、含大量图片的产品、带重定向的旧产品、多语言产品，以及任何商业上高度依赖信任信号的产品系列。

保存上线前后的截图和导出文件。只有团队清楚哪些应用设置、主题 section、snippet、product ID 和评价导出需要恢复，回滚计划才真正可执行。

• 对至少 20 个重点产品比较评价数量和平均评分。
• 每个主要集合、模板、地区和语言至少检查一个产品。
• 保存 PDP 顶部摘要、评价列表、评价表单、schema 测试和移动端布局截图。
• 把最终导出、导入日志、应用设置、主题版本和负责人列表放进上线文件夹。
• 定义回滚触发条件：评分错误、评价缺失、schema 错误、提交失败或明显性能回退。