Shopify 主题重做前，先做这份网站审计

一个慢、乱、难编辑的 Shopify 商店，不一定需要整站重做。有时正确答案是整理模块系统、减少应用、清理模板、补齐文档。只有当基础结构真的阻碍增长时，重建才是值得的。

这份审计适合已经觉得网站难维护，但还说不清具体原因的团队。你可以在写改版 brief 前、找开发前，或下一轮活动排期前先做一遍。

不要只看首页。先列出首页、产品详情页、集合页、购物车、落地页、博客模板、政策页，以及市场团队会用到的活动模板。然后标记哪些正在使用，哪些是遗留，哪些重复，哪些没人敢动。

这一步是为了找编辑债务。如果有六个类似落地页模板，但团队只敢用其中一个，问题不是缺设计，而是缺治理。

• 从 Shopify 后台导出或截图模板列表。
• 给每个模板标记：使用中、遗留、重复、未知。
• 记录谁可以在不找开发的情况下安全编辑这个模板。

Shopify section 不只是视觉区块，它是给市场团队使用的小工具。好的模块有清楚的字段、合理的默认值、可预览状态、内容边界，并且足够支持真实活动，而不是把所有控制都丢给编辑。

打开最常用的模块，检查字段是否符合团队真实写内容的方式。如果一个模块要求上传桌面和移动图片，但没人知道裁切比例，这是内容运营问题。如果 CTA 一长就换三行，这是设计系统问题。

• 每个模块是否有清楚用途和可识别名称。
• 图片比例、标题长度、CTA 规则和可选字段是否有记录。
• 只为旧活动存在的一次性模块，应该移除或合并。

应用在后台看起来可能很轻，但在前台会带来脚本、布局偏移、样式冲突和重复 UI。评价、订阅、组合销售、搜索、会员、分析和 upsell 工具都需要检查。

每个应用都要回答四个问题：出现在哪里，支持什么业务结果，谁负责维护，如果未来替换会影响什么。没人能回答的应用，就是审计的一部分。

• 检查产品页、购物车、账户页和落地页里的应用注入内容。
• 记录哪些脚本在所有页面加载，但功能只在少数页面出现。
• 保留有明确业务目的和负责人的应用。

不要只读代码来审计主题。选一个真实活动，比如新品发布、季节性落地页、套装促销或批发询盘页，让非开发成员在 staging 里用现有主题搭建。

观察他在哪里停住，哪里需要设计确认，哪里必须找开发。这通常会暴露最有价值的范围：可能是活动模板弱、产品 metafield 不一致、图片裁切不清楚，或购物车无法支持促销机制。

审计结束后，把问题分成三条路径。整理适合品牌和页面大体没问题，但代码、模块或文档混乱的情况。改版适合体验、层级和转化路径已经不匹配业务的情况。重建适合主题架构、应用栈或数据模型已经限制团队运营的情况。

这个判断应该基于页面和流程，而不是情绪。一个商店可能只需要新的 PDP 系统，不需要重做首页；也可能只需要清理应用策略，不需要 Headless。

• 整理：保留体验，清理主题和编辑方式。
• 改版：更新 UX、信息层级、模板和活动系统。
• 重建：当前基础结构已经限制长期运营。