网站 SEO 技术优化清单：哪些能自查，哪些只能标注待核实

先说明材料边界#

本次可用素材只有主题标题「网站 SEO 技术优化清单」，没有清单正文、条目、工具说明或官方文档链接。因此本文不列出“应该检查哪二十项”，也不对任何搜索引擎的收录规则、抓取行为或排名机制下结论——这些内容在本次材料中无法核实，只能标注待核实。下面讨论的是更基础的一件事：一份这样的清单交到开发者手里，需要具备什么形状，才不至于变成一份没人能判定的文档。

清单能回答的，和不能回答的#

把问题拆成三类，边界会清楚很多。

• 站点内部事实：某个 URL 返回什么状态码、响应头里有什么、某个文件是否存在、页面里有哪些链接。这类问题可以靠读取自己的配置或请求自己的站点得到答案，属于清单能直接判定的范围。
• 需要外部方确认的事实：某页面是否已被收录、某个标签是否被按预期解析。这类结论只能由外部系统的反馈支撑，清单本身写不出答案，只能规定“怎么取得证据”。
• 结果性承诺：排名、流量、被检索或引用的概率。任何清单都不构成这类保证，本文也不提供。

从材料只能确认存在“网站 SEO 技术优化清单”这一类文档，它具体包含哪些检查项，本次未提供，待核实。

一条检查项至少要有四个字段#

以下是建议的结构，不是来自材料的规范：

1. 判定对象：具体到 URL 路径、文件名或响应头名，避免“站点整体”这类无法执行的描述。
2. 判定条件：可观测的取值或布尔条件，例如“状态码为 200”。条件必须能被第二个人独立复核出同一结果。
3. 证据：判定当时的原始片段与时间，例如响应头原文、请求时间、请求的完整 URL。
4. 责任与复核：谁改、何时复核、什么条件下回滚。

示例：检查项的数据形状#

下面是一段未执行的示例，仅示意字段，不对应任何真实站点；域名与取值均为占位。

{
  "id": "PLACEHOLDER-001",
  "target": "https://example.com/",
  "condition": "HTTP status == 200",
  "evidence": {
    "observed_at": "YYYY-MM-DDTHH:MM:SSZ",
    "raw": "（此处填写响应头原文，本次未采集）"
  },
  "owner": "YOUR_TEAM",
  "review_by": "YYYY-MM-DD"
}

这段 JSON 没有在任何环境运行或校验，字段名与取值都是占位。它想说明的只有一点：证据必须和判定条件写在同一行记录里，否则事后无法判断这条到底有没有通过。

哪些格子必须写“待核实”#

• 具体搜索引擎的规则、阈值与工具行为：本次未核验官方文档，待核实。
• 任何工具的版本、价格与可用性：待核实，不要凭印象填写。
• 改动前后的性能或流量对比：没有采集记录就不写数字；确实要写统计数字时，须带上统计对象、时间窗、单位与比较基期。

维护方式#

清单一旦进入版本管理，它就从文档变成了变更记录：每次修改留下 diff，每条判定留下证据，回滚有明确条件。这样即便条目内容将来需要按官方文档重写，结构仍然可用。

清单的价值不在于条目多，而在于同一条能被不同的人重复判定出同一个结果。