网站 SEO 技术优化清单：哪些项能脚本核对，哪些必须人工确认
一句话回答
技术 SEO 检查项的可验证程度并不相同。按「证据从哪里来」分成静态可取、渲染后可见、只能人工判断三层，可以减少漏检和误报；正文给出可脚本化的核对项、需要渲染才能判定的部分、脚本无法判断的部分，以及一次最小可复现的执行顺序。清单只能保证检查过且结论可复核，不保证收录或排名；涉及搜索引擎规则细节的部分本次无材料，待核实。
这份清单要解决一个具体问题：技术 SEO 检查项很多，但它们的可验证程度并不相同。如果按主题罗列，容易漏检，也容易把「脚本跑通了」当成「没问题」。更稳妥的组织方式是按「证据从哪里来」分层。需要先交代限制：本次没有可用的正文素材，下面只给出开发者可以自行核验的检查框架，不引用任何搜索引擎的具体排名规则；涉及规则细节的部分应以对应引擎的官方文档为准，这些文档本次未提供，待核实。
一、先按证据来源分三层#
- 静态可取：直接抓 HTML 或响应头就能判定，结论可复现。
- 渲染后可见：需要执行 JavaScript 或读取渲染结果才能判定。
- 只能人工：涉及取舍和业务判断，脚本只能报警，不能定论。
这个划分的价值在于：同一层内的项可以放在同一轮跑，跨层混在一起时，静态结果会被渲染差异污染。
二、可以脚本核对的项#
| 检查项 | 判定方式 | 典型误报 |
|---|---|---|
| robots.txt 可达与语法 | 请求 /robots.txt，看状态码与是否误 Disallow 全站 | 测试环境与生产环境规则不同 |
| sitemap 可达与自洽 | 看状态码、XML 能否解析、条目 URL 是否返回 200 | 只抽样，长尾页面漏检 |
| canonical 指向 | 逐页对比 canonical 与当前 URL | 分页页、参数页被统一指向首页 |
| 状态码分布 | 批量请求，统计 200/301/404/5xx | HEAD 与 GET 结果不一致 |
| 元信息重复 | 全站 title、description 去重统计 | 模板默认值本身合法，不算错误 |
| 内链孤立页 | 从首页做广度遍历，统计不可达页面 | 需要登录的页面被算成孤立 |
三、必须渲染后才能判定#
客户端渲染的站点，抓到的 HTML 可能只有空壳。主要内容是否出现在渲染结果里、懒加载图片是否真的带 src、筛选参数是否生成了可抓取的链接，这些都不是一次静态请求能回答的。适用条件是：只有当页面依赖 JavaScript 输出主要内容时才需要这一层；纯服务端渲染的站点可以跳过，但应在记录里写明跳过理由。
四、脚本给不出答案的部分#
- canonical 选得对不对：两个 URL 都能访问时，哪个是规范版本属于业务判断。
- 结构化数据与可见内容是否一致：JSON-LD 能解析，不代表字段与页面上实际展示的信息相符。
- 页面是否回应了查询意图：需要把实际检索词与落地页逐条对应来看。
五、一次最小可复现的执行顺序#
- 固定基线：记录抓取 UA、时间窗、URL 样本量与来源（sitemap 还是内链遍历）。
- 先跑状态码与可达性；5xx 和不可达页不排掉，后面的统计都会被污染。
- 再跑元信息与 canonical 的一致性检查。
- 渲染层单独跑一轮，与静态结果对比差异。
- 每条结论写成「检查项 / 命令 / 结果 / 判定 / 待人工确认」，人工项单独列。
# 未执行的示例：仅演示核对顺序，域名为占位（example.com）
# 环境：bash + curl；本文未在任何环境实际运行
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/robots.txt
curl -sS https://example.com/ | grep -o '<link[^>]*rel="canonical"[^>]*>'这里不给出预期输出：结果取决于你自己站点的配置，未经实际运行不能当作结论。
六、清单的边界#
清单能保证的是「这些项被检查过、结论可复核」，不能保证任何收录或排名结果。具体规则与阈值请以各搜索引擎官方文档为准；本次材料未提供相关文档，待核实。
如果要把这份清单交给别人重放，最该补齐的不是更多检查项，而是每项的证据记录方式：命令、输入样本、判定标准，以及哪些结论被标记为待人工确认。
