我测试的 14 个电商首页中，有一个对研究请求返回了 CloudFront 403 错误。SEO Evaluator v2 将错误文档当作店铺本身进行了诊断。
它报告了 13 个可操作的 SEO 问题：缺少元数据、规范链接、图片、结构化数据、hreflang 等。随后它声称该首页正在阻止所有用户和爬虫，并且现有排名将会下降。
请求被阻止了。这就是所有证据显示的内容。
这个案例改变了评估器的方向。在 AI 系统对页面评分之前，它必须证明自己检索到了目标页面。在它将某个观测结果称为问题之前，它必须将该观测结果与适用的要求以及可复现的后果联系起来。
我使用相同的模型，在相同的 14 个首页快照上运行了原始评估器和一个修订后的 v2.1 提示。修订版本将可操作的声明减少了 77.3%，并移除了所有固定阈值的发现。请注意这个数字。这并不意味 v2.1 的准确率提高了 77.3%，因为我并未完成完整的人工真实标注；它衡量的是当原始评分规则被移除后，输出减少了多少。
我的结论是：AI 电商 SEO 审计应该交给运营人员一份有证据支撑的待复核清单，而不是一个容易诱导团队盲目修改的分数。
测试设置
样本涵盖了 14 个公开的电商网站：10 个 Shopify 商店、两个 WooCommerce 商店和两个无头 Shopify 实现。我从公开的平台展示中选择了这些网站，没有使用私有的 Search Console、分析工具、Merchant Center、服务器日志或管理后台数据。
爬虫尝试抓取了 105 个页面，涵盖首页、集合或分类页、产品页和内容模板。其中 103 个页面返回了可评估的内容。两个例外情况不同：一个首页对研究请求返回了 403 错误，一个产品 URL 返回了 404 错误。
对于每次尝试，我都保存了状态、最终 URL、HTML 大小、标题、元描述、规范链接、H1 和标题结构、字数、链接、图片、结构化数据类型以及平台信号。配对模型测试仅评估了 14 个首页。两个版本都收到了相同的确定性快照，并被禁止浏览以获取额外证据。
模型是 DeepSeek v4 Pro，每个评估器在单独的调用中运行。这产生了 28 个输出。然后我将每个报告的行标准化为三组之一：
- 可操作的声明；
- 不可用或依赖于私有数据；
- 附录项目，包括可访问性、安全性或社交预览观察结果，这些并非 SEO 发现。
这个分类告诉我评估器声明了什么。它不是一个人工真实标签。
v2 和 v2.1 之间有何变化
| 度量指标 | SEO Evaluator v2 | SEO Evaluator v2.1 | |---|---:|---:| | 发现总行数 | 164 | 65 | | 可操作的声明 | 154 | 35 | | 紧急声明 | 31 | 1 | | 固定阈值发现 | 41 | 0 | | 不可用/私有数据行 | 8 | 9 | | 附录/非 SEO 行 | 2 | 21 |
可操作发现的数量从 154 降到了 35，减少了 119 条声明。紧急声明从 31 条降到了 1 条。v2.1 还将更多观察结果移到了附录中，而不是让它们影响 SEO 诊断。
发现较少并不自动意味着更好。评估器可能会变得沉默，从而遗漏真正的问题。我尚未公布精确率或召回率，因为这 229 条合并的发现行没有完整的独立人工标签。
我能验证的范围更窄：v2 的 41 个发现依赖于不应作为跨站点 SEO 规则的固定阈值。v2.1 没有产生任何此类发现。
原始评分奖励了无根据的确定性
第一个评估器包含的规则包括：
- 商业页面应包含 900–1500 个单词；
- 可见文本应超过原始 HTML 的 5%；
- 元描述应保持在固定的 150–160 字符范围内；
- 首页应保持在未指明的 HTML 大小、响应时间或链接数量限制以下；
- Open Graph 图片缺失会影响 SEO 严重性；
- 一次原始 HTML 抓取即可支持关于抓取预算、现场 Core Web Vitals、索引效率或移动端性能的声明。
这些规则使评分变得容易。但它们并没有使诊断结果站得住脚。
Google 的 SEO 入门指南指出，对于搜索而言，不存在神奇的最低或最高内容长度，也没有理想的标题数量或顺序。根据 Google 的摘要文档，元描述没有固定限制；摘要会根据需要被截断，并且可能来自页面内容。关键词堆砌是被禁止的。不建议使用通用的关键词密度百分比。
页面大小、响应时间、标题结构和社交预览元数据仍然值得关注。错误在于将一个诊断性观察结果，仅仅因为其超过了一个泛化数字，就变成了排名问题。
一旦每个类别都对总分有贡献，模型就会倾向于填满每个类别。分数将不确定性转化为了扣分。
403 页面曾是边界测试
被拦截的主页暴露出比糟糕的字数规则更严重的问题。
v2 版本将 CDN 错误文档视为目标页面，继而推断出它无法观察到的后果。我所知道的只是研究用户代理被拦截了。这并不能对普通购物者、Googlebot、索引状态、历史排名或排名下降得出任何结论性的东西。
修订后的评估器在同一快照中只保留了一个发现：请求的 URL 对此测试返回了 403。然后它就停止了。九个依赖主页内容的检查被标记为不可用，因为主页从未被成功抓取。
这就是我期望的行为。一次有用的审计可以停下来。
我的第一道关卡现在问：
- 请求是否到达了预期的最终 URL？
- 响应是真实页面、同意墙、机器人挑战、软 404、错误模板，还是缓存中介？
- 内容是否标识了预期的网站和页面类型？
- 当检查依赖 JavaScript 时，页面是否被渲染？
- 根据此证据，哪些结论仍无法得出？
如果前三个问题的答案不确定，则不应继续进行内容和结构化数据的发现。
原始 HTML 无法回答所有 SEO 问题
最初的评估器经常跨越观察和不可访问状态之间的界限。
一个公开的 HTML 快照可以显示该响应中传递的 canonical 元素。它无法显示 Google 选择了哪个 canonical。它可以揭示源 HTML 中的产品结构化数据。但没有 Feed 和账户，它无法确定 Merchant Center 的一致性。实验室运行可以在受控条件下诊断性能，但它不是现场 Core Web Vitals。web.dev 解释了实验室和现场数据回答不同问题的原因，并且 Lighthouse 不直接测量现场 INP。
修订后的版本在缺乏所需来源时明确将这些领域标记为不可用：
- Google Search Console 索引和所选 canonical；
- 现场 Core Web Vitals；
- 服务器日志爬取行为；
- 全站孤页和内部链接分析；
- 仅提供原始 HTML 时的渲染 DOM；
- Merchant Center Feed 一致性；
- 流量、排名和转化影响。
一个不可用的行不是报告的弱点。它是围绕证据的边界。
v2.1 做得更好的地方
修订版删除了通用总分和等级评分。取而代之的是，它将观察结果与诊断、不可用检查以及附录条目分开。现在，一个发现需要一条可追溯的链条，从证据到适用的要求，再到后果。
这改变了几项常见的发现：
- 多个 H1 和标题跳级通常是编辑或可访问性方面的观察，除非显示了具体的内容问题；
- 缺少 Open Graph 资源移至社交预览备注；
- 响应时间和 HTML 大小保持为诊断性质，除非使用适当的方法进行测量；
- Search Console、渲染页面、Merchant Center 和现场性能相关声明变为不可用，而非猜测；
- 一个商店可能从所提供的首页快照中未收到任何经核实的 SEO 问题。
一个 WooCommerce 首页没有产生需要处理的 v2.1 SEO 问题；它有三条附录备注。另一个网站也没有收到经核实的 SEO 问题，而其 H1 观察结果保留在可访问性附录中。零必须是一个有效的答案。
修订后的提示仍然犯错了
我不会原封不动地发布 v2.1。
它有时会将首页缺少 Organization 或 WebSite Schema 描述为一个机会，而没有说明该标记对于该页面是必需的、符合条件的或有用的。一个较弱的模型重新引入了 HTML 大小和首页字数的“典型”范围，即使提示禁止了无依据的基准。
输出格式还允许已通过的检查出现在发现数组中。在某些行中，verified 仅表示已观察到一个值，而不是该值是一个经过验证的问题。
模型的选择很重要。在试点期间，DeepSeek Flash 在范围和推断方面宽松得多。DeepSeek Pro 更一致地遵循了边界，但遵循提示仍然不是验证。
下一个版本需要一个 Schema 验证器。一个发现应被拒绝，除非它包含：
- 观察到的证据和来源；
- 适用的页面或范围；
- 适用的要求或记录在案的最佳实践；
- 在该案例中观察结果造成问题的原因；
- 仍然不可用的信息；
- 修复前的验证步骤。
一个已通过的项目不能也是一个发现。同样，当检索本身未经验证时，依赖项检查也不能通过验证。我会在代码中强制执行这两个条件，而不是要求模型记住它们。
我在店铺运营中如何使用 AI SEO 评估器
我会把评估器放在人工调查之前，作为收集问题的入口，而不是最终审批人。
它的职责是收集证据、归类相关观察结果、识别需要其他数据源的检查项，并准备一个小型审查队列。运营人员随后根据需要验证模板、渲染页面、Search Console、分析工具、爬虫输出或Merchant Center。
我不会让它根据评分批量编辑标题、规范标记、robots规则、结构化数据或内部链接。这些修改如果存在于共享的Shopify主题或应用中，可能影响数千个URL。
具体到电商领域，审查应遵循页面类型：
- 首页： 品牌/实体清晰度、可爬取的分类路径，以及仅适合该页面的结构化数据。
- 集合页或分类页： 可爬取的产品链接、分页、筛选策略、规范行为以及有用的分类上下文。
- 产品页： 价格与库存一致性、变体、规范行为、产品结构化数据、媒体以及商家政策上下文。
- 内容页： 意图覆盖范围、通往商业页面的路径、相关的作者信息以及重复内容。
Google的电商网站结构指南强调导航、分类、子分类与产品之间的可爬取链接。仅靠首页评分无法验证这一体系，它最多只能建议下一步爬取方向。
实用的验收清单
在根据AI生成的SEO发现采取行动前，我会询问：
- 目标页面是否确实被检索到？
- 证据是原始HTML、渲染后的DOM、实验室数据、现场数据、Search Console、数据源还是完整爬取结果？
- 该建议是否依赖捏造的通用阈值？
- 该项目属于SEO、可访问性、安全性、社交分享还是一般质量？
- 引用的要求是否适用于该页面类型？
- 声称的后果能否复现？
- 修复方案是针对单个页面还是跨模板共享？
- 如何证明问题已解决？
如果评估器无法回答前五个问题，我会将该项目保留为观察项，而非开具修复工单。
我的结论
在此次对比测试中，SEO Evaluator v2.1生成了一个更小、更诚实的审查队列。最大的改进并非结构化数据检查项或更详细的评分，而是一个词：不可用。
这一结果适合那些已了解如何通过爬虫、渲染页面、Search Console和平台设置验证发现的运营人员。它不适合任何追求一键评分加自动修复的人。本次测试中最危险的输出并非遗漏的标题，而是对错误文档的确信诊断。
先运行检索关卡。然后选取五项发现，逐一追溯其证据和要求，并剔除所有无法通过该审查的项目。剩余的数量比你最初的评分更有用。如果团队还要用加权分数评估工具，同样的证据纪律也应当进入 EcomAgentTools 评分方法。
常见问题
AI 能否执行 Shopify SEO 审计？
它可以收集公开页面证据并准备审查队列。完整的Shopify审计还需要模板级爬取、渲染页面检查、Search Console、现场性能数据、分析工具，有时还需要Merchant Center或应用配置。在这些来源确认之前，应将AI输出视为初步分类。
AI SEO 审计中误报的原因是什么？
常见原因包括：将固定阈值作为通用规则呈现、强制模型找出问题的评分分类、对错误页面或机器人验证页面的分析、从公开HTML中声称私有数据，以及忽略页面类型或平台行为的建议。
SEO发现数量越少越好吗？
并非如此。安静的评估器可能遗漏真实问题。需对照人工审核的真实情况进行准确性衡量，跟踪误报和有害的修复建议，并保持"不可用"检查项的可见性。本次测试中，数量减少证明去除了固定阈值噪音，但并未证明整体精度。
AI 应自动修复规范标签或结构化数据吗？
不应根据单页评分操作。规范标记和结构化数据的更改通常存在于共享的主题、模板或应用中，可能影响大量URL。需在代表性模板上验证问题，测试生成的标记，审查平台默认设置，并在部署前要求审批。