想象一家商店，所有仪表盘看起来都很正常。首页已被索引，Lighthouse 全绿，结构化数据验证器也没有报错。但就在同一时刻，Google 购物里的价格与购物车里的价格不一致，移动端的筛选抽屉把键盘用户困住，每一笔购买都被记录两次。
这些问题都不会在一次快速的健康检查中暴露出来。因为在线商店是一个相互连接的系统，而不只是页面的简单集合。产品数据会流入页面、结构化数据和购物信息流。脚本和第三方标签决定了整个页面的加载速度。结账把兴趣转化为营收，而数据分析本应准确记录整段旅程。当其中一环出问题，它会悄无声息地扭曲其他所有环节。
这就是为什么一份有用的电商审计跟踪的是购物者，而不是站点地图。下面的清单从发现商店开始，到订单完成为止。它会给你一份按优先级排序的真实问题清单，每个问题都附有证据、负责人，以及明确的“何时算修好”的验证方法。
什么时候做这次审计，以及为什么顺序很重要
在接手新的电商客户时、在改版或平台迁移之后、在大型增长冲刺之前，或者例行检查发现全站性回退时，做一次完整审计。轻量检查预留三到六个小时，一次能真正测遍每个重要模板的标准审计则预留一到两天。针对日志、信息流或数据分析的深度排查通常需要另算时间。
这个顺序是刻意安排的。如果 Google 无法索引你的分类页，评判转化摩擦就没有意义；如果购买标签触发了两次，相信漏斗报告也没有意义。
一次重复的购买事件并不能证明销量更多，如果 Google 看到的价格与购物车里的价格不同，再快的产品页也谈不上健康。所以审计是分阶段推进的。它从“能否被发现”开始，再到产品真实性、速度与购买本身，最后才进入衡量环节。
开始之前，先把需要的东西准备好。也就是说，你需要以下访问权限：
- Search Console，
- Analytics，
- 标签管理器，
- 商品目录或信息流数据源，
- Merchant Center，
- 一份站点近期变更记录。
阶段 1：搜索引擎能找到你的商品目录吗？
1. 构建一个能代表整个商店的样本
大多数电商缺陷都藏在共用模板和异常的产品状态里。一个干净的首页无法告诉你筛选后的分类页、变体逻辑、缺货或结账是什么情况。所以你应该先确认自己测试的是正确市场、货币和语言下的线上生产站点。然后针对以下每一项至少挑选一个 URL：
- 首页
- 一个重点分类页
- 一个更深的分类页或一个已获批准的筛选页
- 一个典型产品
- 一个带变体的产品
- 一个缺货或已停产的产品
- 一个站内搜索结果页，包括一个无结果的页面
- 购物车、结账页和订单确认页
对任何看起来有风险的模板，再补一个棘手或异常的例子。你的分析工具中的落地页报告和一份商品目录导出会帮你做出选择。
当每个重要模板和结账状态都有了一个具名的测试 URL，而所有无法测试的内容都标注为“未测试”时，这一步就算完成。
2. 检查可抓取性、索引、规范标签和站点地图
如果抓取路径是断的，发布更多产品只会成倍增加受影响的 URL 数量。混乱的信号也会让问题更难诊断。robots 规则可能说一套，而规范标签和站点地图又说着完全不同的一套。
检查 robots.txt、XML 站点地图、响应码、robots meta 标签和响应头、规范标签、分页以及内部链接。用 Search Console 中的 URL 检查工具看看 Google 实际为你的样本页面选择了哪个规范 URL。然后把站点地图与现实情况对比。它应当列出可正常访问、可被索引、返回 200 状态的页面，而不是重定向、错误页、被 noindex 的页面或重复页面。
当你想作为落地页的页面返回 200、可被抓取、遵循一致的规范与索引策略，并出现在站点地图中时，这一步就算完成。每一个重要的排除项都应该有解释或负责人。
3. 顺着链接走：重定向、错误与 JavaScript
一家商店在浏览器里看起来可能很完整，而爬虫和辅助技术看到的却是单薄得多的一份。运行爬虫找出断掉的内部链接、重定向链、重定向循环和软 404。然后把渲染后的页面与原始 HTML 对比。产品卡片、分页、面包屑和分类链接都应该是真实存在且可被抓取的，重要内容也不应只依赖 JavaScript。
当内部链接直接指向最终地址、错误页返回正确的状态码、重点产品无需依赖无限滚动就能被找到时，这一步就算完成。
4. 测试分类、筛选、分页和站内搜索
分类和筛选系统可能同时为搜索引擎制造抓取陷阱，也为购物者带来挫败感。一个页面可以技术上可被索引，但如果其中一半产品都不相关，它依然是个糟糕的落地页。
在桌面端和移动端都试试这些筛选器。检查多选、“全部清除”、结果数量、排序、分页或“加载更多”，以及那些返回空结果的筛选组合。看看筛选器生成的 URL，并与商店的索引策略对照。同时注意，一长段分类文案是否把产品网格挤到了首屏以下。
当这些控件行为一致、随机筛选组合不会意外变成落地页、购物者撤销筛选后不会丢失当前位置时，这一步就算完成。
阶段 2：产品数据说的是真话吗？
5. 核对产品标识、价格、库存与变体
一个字段出错不仅会误导购物者，还可能一路导致结账时的不一致。与此同时，数据可能格式完美，内容却依然是错的。
挑选若干有代表性的产品，在所有出现位置对比名称、品牌、SKU、GTIN 或 EAN、所选变体、价格、货币、库存状态、图片和关键规格。检查页面上展示的内容、结构化数据、商家信息流、购物车和结账页中的这些内容。把促销商品、变体商品、缺货、预售和已停产产品都涵盖进来。
当抽样出的事实数据在所有界面上都一致，而任何有意的差异（例如品牌与制造商之别）都在数据模型中明确说明时，这一步就算完成。
6. 用购物者实际看到的内容验证结构化数据
结构化数据只有准确描述页面时才有用。验证器会欣然接受“InStock”，而页面和结账流程却都在说该产品不可购买。所以你应该把每种产品状态都放进 Google 富媒体搜索结果测试或 Schema.org 验证器里跑一遍。然后把标记中的数值与可见内容和源信息流对比。对于带变体的产品，检查你的标记方式和规范设置是否与页面实际构建方式相符。
当抽样的合格页面没有缺失必需属性、标记内容与可见内容一致，且只有当购物者能在该产品页上看到评价和评分时才对其进行标记时，这一步就算完成。
阶段 3：商店对真实购物者来说够快吗？
7. 先依据真实用户数据衡量核心网页指标
真实用户数据和一次 Lighthouse 运行回答的是不同的问题。Lighthouse 帮你复现问题，但它无法告诉你真实购物者的体验是合格还是不合格。
从 PageSpeed Insights 和 Search Console 中的核心网页指标报告入手。注意这些真实用户数据是针对该确切 URL，还是只有整个站点的数据。Google 的“良好”阈值按第 75 百分位衡量，分别是：
- LCP（加载）：不超过 2.5 秒
- INP（响应性）：不超过 200 毫秒
- CLS（视觉稳定性）：不超过 0.1
移动端和桌面端要分开看。如果没有真实用户数据，就把结果记为未知，并将实验室结果视为暂定。未知不等于绿色。
当每个重点模板在每个设备类型上都有真实用户数据的判定结论，或者明确说明缺少数据，并记录了数据来源和日期范围时，这一步就算完成。
8. 找到原因，而不只是分数
像“压缩图片”或“减少 JavaScript”这类通用建议常常错过真正的瓶颈，还会产生一堆对失败指标毫无帮助的工作。要找到具体是哪个元素、哪个请求或哪个脚本该负责。
找出 LCP 元素以及是什么在延迟它。然后检查那些常见的嫌疑对象，例如图片尺寸、首屏图片上的懒加载、阻塞渲染的 CSS、字体加载、第三方脚本、长任务、缓存、服务器响应时间、布局偏移来源，以及被重复加载的标签。
在相同条件下重复测试，并比较一个稳定的统计量，而不是你最好的那一次成绩。记住，总阻塞时间（TBT）是有用的实验室信号，但它不是 INP。
当每一项重要的性能发现都指明了失败的指标、受影响的模板、可复现的原因和负责人时，这一步就算完成。
加入我们的新闻通讯
免费获取最新提示、趋势和优惠。
阶段 4：人们真的能买到东西吗？
9. 在真实的购物控件上测试移动端可用性和无障碍性
自动化评分无法覆盖每一次交互。一家商店可能通过扫描，但筛选抽屉把键盘焦点困住，Cookie 横幅遮住“加入购物车”按钮，或者尺码选择器没有无障碍标签。
在 360 到 390 像素的手机宽度下测试，放大文字，并只用键盘走完整段旅程。观察菜单、抽屉和对话框中的焦点顺序与可见性。检查标签、按钮、表单错误提示和触控目标是否依然合理可用。
当购物者能走完主要旅程而不被隐藏控件或焦点陷阱困住，并且移动端没有任何东西遮挡价格、库存状态、变体选择、“加入购物车”按钮或结账入口时，这一步就算完成。
10. 以受控测试的方式走一遍购物车和结账流程
一个看得见的结账按钮并不能证明结账流程可用。结账缺陷属于商业事故，它们同样会损害你的数据分析。
要测试它，先把一个普通产品和一个变体商品加入购物车。修改数量、移除一件商品，如果有优惠券就应用一张（或故意用一张无效的）。然后测试访客结账和账户结账、配送选项、支付选择、校验错误、返回按钮和移动端布局。使用测试订单或一条已获批准的不产生扣款的路径。未经许可，绝不下真实订单。
当购买流程完成或到达约定的测试边界、总价保持正确、错误提示告诉人们该怎么做，并且任何被阻断的路径都有证据和业务影响记录时，这一步就算完成。
阶段 5：你在正确地衡量这段旅程吗？
11. 核验数据分析、重复标签与用户同意
重复的标签会虚增页面浏览量、加入购物车事件和购买数。缺失或格式错误的数值会让营收报告不足以作为决策依据。目标很简单：一次购物者操作应该产生一个事件，并带有正确的产品、金额、货币、交易 ID 和同意状态。
列出每一个标签管理器容器、Google 标签、广告像素、联盟脚本和服务端集成。然后，在一次受控会话中，追踪 view_item、add_to_cart、begin_checkout 和 purchase。把浏览器发送的内容与 GA4 DebugView 及后端的订单记录进行对比。在购物者做出同意选择的前后都要测试。
当每个操作都恰好触发一次对应事件、购买事件带有稳定的交易 ID、金额和货币与后端对得上，且非必要标签遵守同意政策时，这一步就算完成。
12. 将 Search Console 和 Merchant Center 与你的发现对照
一次本地页面测试无法展示每一个已索引的规范 URL、站点地图警告、产品被拒或丢失的搜索查询。反过来，仪表盘上的一条警报也可能描述的是早已修复的问题。
在 Search Console 中检查你的重点 URL，审阅产品报告和商家商品报告，并把 Merchant Center 诊断结果与你在线上站点看到的情况对照。记下日期，因为重新抓取和信息流处理都滞后于上线发布。
当每一个重要的仪表盘问题都能与现场证据对应上，或被标记为等待数据生效，且每个未解决问题都有负责人时，这一步就算完成。
阶段 6：购物者会信任这家商店吗？
13. 检查信任信号、联系方式、配送与退货
隐藏或相互矛盾的商业信息会让购物者犹豫，并推高客服工单量。对比页头页脚、联系页面、结账页和政策页面。
当企业身份清晰、配送、退货和支付相关表述在整段旅程中保持一致，且没有任何无法验证的信任徽章时，这一步就算完成。
14. 检查 HTTPS、混合内容与前端卫生
这不是渗透测试，而是基本的数据卫生问题。确认 HTTP 在一步之内重定向到 HTTPS、证书有效、没有混合内容，且表单能正确提交。检查控制台是否有严重错误。如果某个问题看起来是真正的安全漏洞，交给专家处理，而不是凭一条通用警告自行诊断。
当重点页面和结账流程都能安全加载、重定向只需一步、表单行为符合预期时，这一步就算完成。
从发现到修复
15. 把发现转化为有负责人的整改队列
一份以截图或分数收尾的审计并不能降低风险。一个损坏模板引发的五十个症状，不该变成五十张互不相关的工单。按根本原因归组这些发现。注明它是组件、模板、信息流规则还是跟踪配置的问题。把受影响的 URL 留作证据。然后排定优先级：
- P0： 正在发生的、阻断业务的故障，或关键的全站性问题
- P1： 你有把握的重大缺陷
- P2： 影响范围有限的重要问题
- P3： 需要持续观察的改进项
当每一项重要发现都有一个负责人、一个截止日期、一个“已修复”的判定测试，以及一个发布后复查的日期时，这一步就算完成。
交付成果
交付一份带版本号的文档或表格，每项发现占一行，并在顶部写一段简短摘要。每一行都应涵盖：
- 实际行为，
- 预期行为，
- 受影响的 URL，
- 证据以及收集时间，
- 严重程度与把握程度，
- 可能的原因，
- 建议的修复方式，
- 负责人以及能证明已完成的测试。
但请记住，不要因为有人关闭了工单就把问题标记为已修复。只有当测试在生产环境中通过时，才算验证完成。
适用工具
想扎实完成第一轮检查，你不需要任何付费订阅。你只需要这些免费工具：
- Google PageSpeed Insights ：获取真实用户数据（在可用时）和 Lighthouse 诊断
- Google Search Console ：用于索引、站点地图、URL 检查、核心网页指标和结构化数据报告
- Google 富媒体搜索结果测试 和 Schema.org 验证器 ：用于结构化数据
- Chrome DevTools 和 Lighthouse ：用于网络、性能、布局偏移、无障碍和控制台检查
- Google Tag Assistant 和 GA4 DebugView ：用于事件跟踪
- SSL Labs Server Test ：用于 TLS 配置
如果你想要一条捷径，AmICited 能让你把所有这些证据汇集在一起，并保留基线供日后比对。性能影响 视图按 LCP、INP、CLS 和服务器响应时间对比各模板。URL 检查 和站点地图与索引 跟踪重点 URL 的索引情况。产品 和商品结构 展示商品目录中哪些部分承载了最大的商业权重。报告中心的注释功能 把每次发布与之后发生的变化关联起来。工具提供证据。而什么是对的、哪些取舍可以接受，仍然由店主、开发者或分析师来决定。
审计之后
把每个已确认的问题送到能解决它的专业流程中：抓取和渲染问题交给技术 SEO 审计 ，真实用户性能不达标交给核心网页指标整改 ，筛选面和库存状态问题交给分类与产品审查 ，跟踪问题则交给负责数据分析的人。
不必在每次修复后重跑整个审计。重测受影响的区域，为发布添加注释以便看清之后的变化，并让常规健康检查去捕捉下一次回退。
回到那家看起来一切正常的商店
还记得开头那家商店吗？它的首页已被索引，Lighthouse 全绿，验证器也干干净净。可 Google 购物显示的是错误价格，筛选抽屉把键盘用户困住，每一笔销售都被计算了两次。
没有任何仪表盘标记出其中任何一项。而这份清单本可以抓住全部三个问题：第 5 步的价格不一致、第 9 步的焦点陷阱，以及第 11 步被重复计算的购买。每一个都在购物者路径的某处出问题，而这正是审计要看的地方。
这就是跟随购物者而不是站点地图能带给你的东西。你不再问“这个站点看起来健康吗？”，而是开始问四个更难的问题。人们能找到产品吗？商店对产品的说法是真的吗？他们真的能买到吗？而你能看到他们买了吗？一家能对这四个问题都回答“是”的商店，比一家分数完美的商店状态更好。
所以，挑出你的样本 URL，留出时间，从阶段 1 开始。第一轮总是最慢的。之后，这份工作主要就是确保你修好的东西一直保持修好的状态。
