SEO 技术清单里最容易漏的一列：每条检查项能否被判定
清单失效多半不是漏项，而是条目无法判定。文章按可自证、需外部反馈、内部约定三类拆分条目，给出对象、观测方式、判定条件、失败后果、责任与回归触发这组字段建议，并说明判定条件必须带统计对象、时间窗与基期；清单应入版本库、按变更触发回归。排名与引用结果属于外部系统输出，不在清单可承诺范围内，具体阈值与工具能力待核实。
SEO 技术清单最常见的失效方式不是漏项，而是条目无法判定。一条「检查 canonical 是否正确」在评审时人人点头，到了回归时没人能说清它通过还是失败。本文讨论的是条目该怎么写，才能被工具和人以一致的方式判读。本次没有可用的正文素材，因此不提供具体阈值、工具版本或行业数据，涉及数值的地方一律标为待核实。
第一步：先确定条目属于哪一类#
把三类条目混在一张表里，通常会导致其中一类长期无人验证。
- 可自证类：执行人能直接观测的信号，例如 HTTP 响应头、HTML 源码、robots.txt 与 sitemap 文件内容、跳转链。这类条目应当默认由开发者自查。
- 需外部反馈类：抓取与索引状态。开发者只能间接影响，观测依赖站点所有者侧提供的反馈，无法在代码仓库里断言。
- 内部约定类：URL 命名规范、站内链接结构、重定向策略。它们不是外部标准的强制要求，而是团队为了可维护性定下的规则，判定标准也由团队自己给出。
分类的意义在于：只有第一类能写成自动化断言，第二类只能写成观测与观察记录，第三类需要写清是由谁批准的约定。
条目的最小字段集#
下面这组字段是建议，不是行业标准。目的是让一条检查项在脱离上下文后依然能被读懂。
| 字段 | 要回答的问题 |
|---|---|
| 对象 | 检查的是哪个模板、路由或文件 |
| 观测方式 | 从哪里取值：响应、渲染后 DOM、日志、文件 |
| 判定条件 | 什么情况下算通过，附统计对象与时间窗 |
| 失败后果 | 失败会影响哪类信号的传递 |
| 责任方 | 谁修改、谁复核 |
| 回归触发 | 什么变更之后必须重跑 |
缺「观测方式」的条目，换个执行人就会得出不同结论；缺「回归触发」的条目，通常只在写下的那一次被检查过。
判定条件必须带基期与单位#
「覆盖率不低于某个比例」这类写法本身不完整。需要说明统计对象（哪些 URL 集合）、时间窗（哪段时间）、单位（条数还是比例），以及与哪个基期比较。没有基期的数字在回归时无法判断是变好还是变坏。具体的合格阈值应当由站点规模与业务约束决定，本文不给出数值。
把清单当成代码资产管理#
- 清单入版本库，变更留提交记录，删除条目写明原因，避免「上次有人删了但没人记得为什么」。
- 每条绑定触发条件，例如模板变更、路由调整、域名或证书变更后重跑对应条目，而不是全量重跑。
- 区分断言与观察：可自证条目可以失败即报警，需外部反馈的条目只做记录与趋势对照。
一个条目骨架#
以下仅为字段结构示意，未执行任何校验脚本，字段名可自行替换。
{
"id": "url-canonical",
"object": "详情页模板",
"observe": "渲染后的 HTML head",
"assert": "存在且仅存在一个 rel=canonical，值为绝对 URL",
"window": "每次模板变更后",
"owner": "前端",
"on_fail": "同一内容出现多个可访问地址"
}这段结构只描述「要检查什么」，不包含抓取实现。真正落地时，取值方式与比对逻辑需要单独验证，本文未做该验证。
边界#
清单能覆盖的是可观测的技术信号；排名与引用结果是外部系统的输出，不在清单能够承诺的范围内。清单写得再细，也不能替代对实际抓取行为与索引状态的观测。工具能力、字段名称与阈值取值待核实，建议以对应工具的官方文档为准。
