网站 SEO 技术优化清单：面向开发者的分层核对顺序
在只有标题、没有正文材料的前提下，本文不复述所谓官方清单条目，而是把 SEO 技术优化拆成“可抓取—可索引边界—语义结构与性能指标—回退”四层核对顺序，说明每层怎么验证、失败时怎么退回，并标明具体阈值与条目优先级需以官方文档为准（待核实）。
本次写作只拿到一个标题《网站 SEO 技术优化清单》，没有正文、没有发布方名称，也没有发布时间。所以能由标题支持的窄结论只有一条：存在一份以“清单”形式组织的 SEO 技术优化事项。清单的具体条目、优先级和适用范围，本次材料未提供，下文不做代入式复述。下面给的是面向开发者的核对顺序与验证方式，属于工程建议，不是来源事实；凡涉及指标阈值、官方条目编号的地方，一律标为待核实。
第一层：能不能被抓取#
这一层只回答一个问题——需要被索引的页面，爬虫能不能拿到。建议按下面顺序核对，任何一项不通过，后面的优化都无意义。
- robots.txt 是否误封整站或文档目录，尤其注意测试环境规则被带到生产。
- sitemap 是否只包含需要索引的 URL，已下线页面是否已移除。
- 需要索引的地址是否返回 200，而不是 302 链、软 404 或 JS 空壳。
- 服务端返回的 HTML 里是否已含正文——依赖客户端渲染的页面，建议先在关闭脚本的条件下检查一次。
以上都是从工程角度提出的检查项，不代表发布方清单的原始排序。
第二层：该不该被索引#
API 平台站点通常同时存在三类页面：营销页、文档页、接口端点。建议把“可索引边界”单独当成一项配置来管，而不是混在页面模板里。
- 文档页一般希望被索引，接口端点一般不希望；两类路径建议用不同规则处理。
- noindex、canonical、robots.txt 三者不要互相打架：一处允许、一处禁止，最终结果取决于实现细节，容易排查困难。
- 鉴权页、后台页、带查询参数的接口结果页，建议显式给出状态码或索引信号，而不是靠“看起来没被收录”来判断。
边界条件：如果站点有多语言或多域名，canonical 与 hreflang 的指向需要成对核对，单边修改容易出现互相指向。
第三层：语义结构与性能指标#
标题层级、页面标题、结构化数据这类项属于“可读性对机器友好”的范畴，改动成本低、回退也简单，适合放在可抓取与边界之后。性能指标方面，具体指标名称与合格阈值由各搜索引擎官方定义，且会调整，本次未核验，以官方文档为准（链接待核实）。建议把指标当成定位问题的入口，而不是验收目标函数。
一份建议核对表的形状
| 核对项 | 怎么核对 | 失败时怎么退回 |
|---|---|---|
| sitemap 可达性 | 直接请求 sitemap 地址，看状态码与条目数 | 保留上一版本文件，按版本切回 |
| robots.txt 规则 | 对比生产与预发两份内容差异 | 规则随发布留档，按路径撤回 |
| 重定向链长度 | 抽查入口 URL 的跳转次数 | 保留旧规则映射表 |
| canonical 指向 | 抽样页面确认指向自身或目标页 | 模板级开关回滚 |
演示用的占位配置
下面这段仅为格式演示，未在任何环境执行，域名与路径均为占位。
# 占位示例，未执行
User-agent: *
Allow: /
Disallow: /admin/
Sitemap: https://example.com/sitemap.xml第四层：改动要可回退#
清单类工作的风险不在“做得不够多”，而在“一次改太多”。robots.txt、重定向规则、canonical 模板这三类改动的影响面都是路径级的，建议每次只动一类，记录变更人、时间与影响路径，并保留上一版本。出现异常时，按路径撤回比整站回滚更快。
- 不要在清单很长时选择全量上线。
- 不要把“搜索排名提升”写进验收标准——本次没有任何材料支持这类承诺。
- 不要用未核实的真实站点做规则试探。
清单最终要落到可核对、可回退的动作上；条目从哪来、优先级怎么排，仍需回到发布方文档逐条核对，这部分本次无法提供。
