网站 SEO 技术优化清单怎么落到工程上：把每条检查写成可判定的记录
本文只讨论清单的结构方法：把每条 SEO 检查项拆成判定条件、证据形式、执行环境与责任人，按“仓库内可判定、运行时才可判定、只能外部核实”三层分类，并说明缺数据时结论只能停在待核实。本次未提供清单正文或可核验来源，因此不给出具体条目本身，也不评价任何条目的效果。
先给结论：在没有可读的清单正文、也没有站点抓取数据的情况下，无法判断某条 SEO 检查项对你的站点是否必要，更无法判断它是否有效。开发者实际能做的，是把清单从“待办列表”改造成“可判定的记录”——每条检查写清判定条件、证据形式和执行环境，判不了的明确标注待核实。本文只讨论这个结构方法。本次没有提供清单正文或可核验来源，所以不列举具体条目，也不对任何条目的效果下判断。
先按“证据从哪来”分层#
同一份清单里的条目，可信度并不相同。分层的依据不是重要性，而是证据获取位置。
| 层级 | 证据来源 | 能否在仓库内完成 | 结论强度 |
|---|---|---|---|
| 代码层 | 模板、构建产物、配置文件 | 可以 | 可复核，能写成断言 |
| 运行时层 | 线上响应、日志、抓取记录 | 需要部署环境 | 依赖抓取范围与时间窗 |
| 外部层 | 搜索引擎侧的处理结果 | 不可以 | 只能标注待核实 |
分层的直接好处是：代码层可以进 CI，运行时层可以出报告，外部层则不该被写成“已完成”。把三者混在一个清单里，最容易出现的情况是代码层全绿，就被当成整体通过。
一条检查项至少要有四个字段#
- 判定条件：什么状态下算通过，要能写成是非判断，而不是“优化一下”。
- 证据形式：通过时留下什么，例如构建产物中抽取的字段清单、某次抓取的响应头记录。
- 执行环境：仓库、预发还是线上，不同环境得出的结论不能互相替代。
- 责任人：谁在什么时机复核。没有责任人的条目，通常会在两轮迭代后失效。
四个字段里最容易被省掉的是证据形式。省掉它，检查就退化成口头确认，下一次没人能证明它曾经成立。
示例：检查项的记录形状#
下面只是数据形状的演示，未执行，也未对任何真实站点运行；其中的条目名称仅作占位，不代表推荐某条具体优化。
# 未执行的示例：只展示字段结构
CHECKS = [
{
"id": "example-canonical",
"scope": "repo", # repo / runtime / external
"predicate": "每个可索引页面的 canonical 指向自身绝对 URL",
"evidence": "从构建产物中抽取的 canonical 字段列表",
"owner": "web",
"status": "unknown", # unknown / pass / fail
},
]
把 status 的默认值设为 unknown 而不是 pass，是为了让“没查过”和“查过且通过”在数据上分开。这个区分看起来琐碎，但它决定了报告能不能被信任。
常见误用#
- 把“检查过”当成“通过”：执行了脚本不等于断言成立，要看证据是否覆盖了目标范围。
- 用标题代替正文：只看到清单标题就推断条目内容，等于把摘要当全文。
- 缺数据时给效果结论：没有抓取记录和对照，任何关于收录、排名或流量的判断都缺少依据，应停在待核实。
- 条目只增不减：清单不设退役机制，会积累大量无人复核的陈旧项。
什么时候可以把结论升级#
一条检查项从“待核实”变成“已验证”，需要同时满足：判定条件可复述、证据可复现、执行环境明确、时间窗记录在案。缺任何一项，结论都只能停在“在某个环境下、某个时间点观察到”。搜索引擎侧的处理结果不在开发者可控范围内，本次没有相关材料，标注待核实。
最小可用做法是：先只挑能进 CI 的代码层条目，把它们写成断言并跑起来；运行时层的条目单独出一份带时间戳的报告；外部层单独列一栏，明确写“待核实”。这样清单长度会缩水，但每一条都能被追问。
