SEO 技术优化清单怎么写：让每条检查项都能被判定
一份可用的 SEO 技术优化清单，关键不在条目多少，而在每条都能写出检查对象、判定证据、自动化程度和复检条件；清单只能排除技术性障碍，不能承诺排名。
一份能用的 SEO 技术优化清单，关键不在条目数量，而在每条检查项都写清了“检查什么、凭什么判定、谁来复检”。否则它只是一串形容词，既无法交给 CI，也无法在出问题时定位。下面按这个标准说明清单该怎么写。
需要先说明材料边界：本次写作只有“网站 SEO 技术优化清单”这一主题名，没有可引用的正文，也未联网核验任何搜索引擎文档的当期版本。因此下文给的是清单的组织方法，不是某家搜索引擎的官方规则汇编；具体阈值与判定规则，应以对应搜索引擎官方文档的当期版本为准。
先判断一条检查项是否可判定#
把“页面要快”“结构要清晰”改写成可验证断言，是写清单的主要工作量。改写时问三件事：检查对象是不是一个具体 URL 或路径；判定依据是不是一段可保存的证据；失败时是否有明确动作。
| 检查项 | 判定证据 | 自动化程度 |
|---|---|---|
| 页面可被索引 | 抓取返回 200，且 meta robots 或 X-Robots-Tag 不含 noindex | 可自动 |
| 规范地址唯一 | link rel="canonical" 为绝对 URL，且与预期规范页一致 | 可自动 |
| 标题不重复 | 全站 title 去重后冲突数为 0 | 可自动 |
| 站点地图可用 | sitemap 可访问，条目 URL 均返回 200 | 可自动 |
| 结构化数据有效 | 可解析，且字段与页面可见内容一致 | 半自动，需人工确认 |
| 渲染后内容可达 | 对比启用与禁用脚本时的抓取结果差异 | 需专门工具 |
“半自动”那一行值得单独说明：结构化数据能通过校验，不代表它与页面内容一致，后者只能靠人看。把这类检查项标成“可自动”是清单最常见的失真。
把清单写成数据结构#
清单一旦进入仓库，就应该能被脚本读取，而不是只存在于文档里。字段建议至少包含：检查对象、断言、证据位置、是否自动、失败后的动作、复检时机。
{
"id": "seo-canonical-001",
"scope": "/docs/*",
"assert": "存在 link[rel=canonical]，且为绝对 URL",
"evidence": "抓取 HTML 的 head 片段",
"automated": true,
"on_fail": "block-release",
"recheck": "每次发布"
}以上为未执行的示例，仅演示字段结构，路径与取值为占位，不代表任何站点的实际配置。
证据分三层，不要只用一层#
- 响应层：状态码、重定向链长度、Content-Type、canonical 响应头。这层最稳定，适合做发布门禁。
- 文档层：title、meta、canonical 标签、结构化数据。改动频繁，适合每次发布后跑一遍。
- 行为层：爬虫访问日志、收录与展示数据。这层口径差异大、有滞后，适合做趋势判断，不适合当单次发布的通过条件。
常见错误是把行为层数据当作唯一证据：抓取量下降可能来自内容更新节奏，也可能来自站点结构调整，单看一个数字无法归因。响应层和文档层的证据更容易定位到具体 URL。
容易漏掉的一类是“退出条件”#
清单通常只写“应该怎样”，不写“什么情况下这条不再适用”。例如某个路径本来就应当不被索引（后台、搜索结果页、参数组合页），如果清单统一要求“必须可索引”，就会制造大量假告警。给每条检查项配一份例外清单，并写明例外需要谁批准、何时复核，比多加十条规则更有用。
清单不能承诺的事#
技术清单能排除“因技术原因无法被抓取或无法被理解”的障碍，不能保证排名、收录速度或流量结果。
因此清单的验收标准应写成“所有检查项均有证据且无阻断级失败”，而不是“排名进入前 N”。前者团队能控制，后者不能。若站点同时对外提供 API 文档页，文档页的可抓取性、状态码与规范地址同样属于清单范围——这部分与接口本身是否可用是两个独立问题，不应混在一次验收里。
落地顺序#
- 先收集止损项：非 200 状态码、重定向链过长、robots 误屏蔽。
- 再统一规范地址与重复内容判定。
- 然后补文档层字段与结构化数据。
- 最后才处理性能类指标，因为它需要独立的度量环境。
按这个顺序，前两步通常就能解释大部分“页面不进索引”的问题，后续条目才有比较的基线。
