SEO 技术优化清单的判定口径：每条检查的触发、证据与处置
清单的价值不取决于条目数量，而取决于每条能否给出可复现的通过/失败证据。本文给出“触发条件—判定证据—处置动作”的三段结构，区分可自动化与必须人工判断的检查项，并说明搜索引擎侧规则需以官方文档核实；本次未联网核验，不提供具体规则来源。
写一份 SEO 技术优化清单，难点通常不在“列得够不够全”，而在“这一条别人能不能复现出同样的结论”。本次写作没有可用的官方文档正文，也未联网核验，因此下文不给出任何搜索引擎的具体规则细节与阈值；凡涉及搜索引擎行为的判断，都应以对应官方文档为准（待核实）。这里只讨论清单本身的结构与判定口径，这部分不依赖具体版本。
一条清单项至少要有三段#
把每条检查写成“触发条件 + 判定证据 + 处置动作”，是让清单从文档变成工具的最小改动。
- 触发条件：什么时候该跑这条检查。是每次部署后、每周巡检，还是只在 URL 结构变更时。
- 判定证据：凭什么说它通过或失败。证据应当是一条命令的输出、一个响应头的值、一个页面上可定位的字段，而不是“看起来正常”。
- 处置动作：失败之后谁做什么。是阻断发布、开单跟踪，还是仅记录。
缺了第三段，清单就只是检查表；缺了第二段，清单就只是愿望清单。
判定证据要能落地#
常见的写法问题是把结论当证据，例如“页面应可被正常抓取”“canonical 应正确”。这类表述无法判定。可判定的写法会落到具体对象上：状态码是多少、重定向链有几跳、某个标签在页面上出现几次、sitemap 能否被解析成结构化结果。
下面的清单条目是一个未执行的示例，域名 example.com 为占位，字段设计用于说明结构，不代表任何真实检查结果：
{
"id": "home-status",
"group": "抓取",
"trigger": "每次生产部署后",
"evidence": "对 https://example.com/ 发起 GET，记录状态码、content-type 与重定向链",
"pass": "状态码 200，重定向链为 0 跳",
"owner": "web-platform",
"on_fail": "阻断发布，定位到路由或网关配置"
}对应的取证命令同样是示例，未在本机执行，输出需以实际环境为准：
curl -sS -o /dev/null -D - https://example.com/注意这条只验证“首页对单个请求的响应”，不验证搜索引擎会如何对待它。两者不能互相替代。
哪些能自动化，哪些不能#
按检查对象粗分，可以避免把无法自动判定的条目硬塞进流水线。
| 检查对象 | 是否适合自动化 | 说明 |
|---|---|---|
| HTTP 状态码、响应头、重定向链 | 适合 | 结果确定，误报低 |
| robots.txt 与 sitemap 的可访问性与可解析性 | 适合 | 只验证“能取到、能解析”，不推断抓取结果 |
| canonical、hreflang 等标签的唯一性与格式 | 部分适合 | 格式可判，选得对不对需人判断 |
| 结构化数据是否与页面可见内容一致 | 不适合 | 需要阅读页面语义 |
| 内链锚文本是否自然、内容是否满足检索意图 | 不适合 | 属于编辑判断 |
表格中的“适合”只表示技术上可稳定判定，不表示该检查的结果会带来何种搜索表现。搜索表现涉及搜索引擎内部逻辑，本文无法给出结论。
分组与责任要一起写#
分组建议沿抓取链路展开：发现（sitemap、内链）、抓取（robots、状态码、重定向）、解析（标签、结构化数据、渲染后内容）、索引候选（重复与规范化）。这样分组的好处是失败时能顺着链路往上找原因，而不是在一堆平铺条目里猜。
每组至少写一个 owner。没有责任人的条目，在故障发生时通常最先被跳过。
维护：把不确定性留在清单里#
搜索引擎侧的规则会变，工程侧的实现也会变。建议每条记录最近一次判定的日期、执行环境和结论；对无法确认的部分直接写“待核实”，并写明需要查哪份官方文档。这比在条目里写一个看似确定的结论更可靠。
另外，清单不应承诺排名或流量结果。它能回答的只是：站点在某一时刻、某一环境下，某些可观测的技术条件是否满足。超出这个范围的部分，需要有实测记录才能讨论。
