网站 SEO 技术优化清单：开发者能自己核验的抓取、索引与回归项

如果你的问题是“上线前该检查哪些 SEO 技术项”，可以先给一个较窄的答案：清单只需覆盖四件事——搜索引擎能否抓到页面、抓到后是否允许索引、索引到的内容是否与用户看到的一致、改动后能否回归验证。排名变化、收录速度和流量提升不在清单能保证的范围内。本次没有提供站点数据，也没有可引用的搜索引擎官方文档正文，所以下文只写检查项与观察方式；涉及具体阈值、指标生效时间和引擎支持范围的地方，一律标注待核实，并以对应引擎的官方文档为准。

先划边界：哪些能验，哪些不能#

可验证的是机器可读的信号：HTTP 状态码、robots.txt 响应、canonical 标签、sitemap 可解析性、渲染后的 DOM 是否含正文与链接、结构化数据语法。不可验证的是“这次改完排名会不会涨”。把后者写进验收标准，清单就会退化成无法执行的承诺。

抓取入口：robots.txt 与状态码#

• robots.txt 放在站点根路径，以 User-agent、Disallow、Allow、Sitemap 字段表达规则；子域名与不同协议、端口各自独立，需分别检查。
• 需要被抓取的页面不应返回 4xx/5xx。返回 200 但正文为空的“软 404”要单独抽查，它不会体现在状态码统计里。
• 最严重的自伤是误屏蔽整站。发布前用抓取工具或命令行确认一次根路径响应，是成本最低的保险。

索引控制：canonical、noindex 与 sitemap#

• 每个可索引页面给出自指 canonical；分页页与带筛选参数的页面，要明确 canonical 指向哪个主版本。
• noindex 可用 meta robots 或响应头表达，两者不要互相矛盾；也不要把 canonical 指向的页面设成 noindex，这会让信号互相抵消。
• sitemap 按 sitemaps.org 协议书写，只放返回 200 且允许索引的 URL。提交后在引擎后台查看解析结果，具体字段与界面待核实。

渲染一致性#

客户端渲染的站点要确认首屏 HTML 是否已包含主要正文、标题与内部链接。检查方法是关闭与开启 JavaScript 各取一次页面，比对正文和链接集合的差异。注意：给爬虫和用户返回不同内容（cloaking）属于违规做法，不在优化范畴，不能作为“提升收录”的手段。

元信息与结构化数据#

title 与 description 应唯一且与正文一致；多语言站点用 hreflang 互相回指，并给出 x-default。结构化数据建议用 JSON-LD，配合官方校验工具检查语法与必填字段。需要提醒的是，结构化数据不保证出现富媒体结果，这一点不要写进对外承诺。

性能与可观测#

Core Web Vitals（核心网页指标）目前包含 LCP（最大内容绘制）、INP（交互到下一次绘制）与 CLS（累积布局偏移）；INP 已取代 FID 成为交互性指标，具体生效时间与分级阈值待核实。采集时把真实用户数据与实验室数据分开记录，并注明设备类型、网络条件与采样窗口，否则数字之间不可比。

发布回归顺序#

1. 预发环境跑一遍上面的可验证项，记录基线。
2. 上线后对比 sitemap 与 canonical 的差异，而不是只看页面是否可访问。
3. 观察服务器日志中爬虫请求的状态码分布，4xx/5xx 占比上升要立即排查。
4. 出问题优先回滚 robots.txt、noindex 这类“开关型”改动，它们的影响面最大也最容易恢复。

常见误区#

• 把“提交 sitemap”等同于“一定收录”。前者只说明 URL 存在，是否收录由引擎判断。
• 用 robots.txt 做“移除索引”。它阻止的是抓取，不保证清除已有索引；需要移除时应使用 noindex 或相应工具，具体行为以官方文档为准。

# 未执行示例：域名 example.com 为占位，请替换后自行运行
# 检查 robots.txt 是否可读
curl -sI https://example.com/robots.txt | head -n 5
# 抽取页面中的 canonical 标签
curl -s https://example.com/ | grep -o '<link rel="canonical"[^>]*>'

上面的命令只是最简骨架，未实际执行，输出取决于目标站点；真实排查还需要处理重定向、压缩与 JS 渲染等情况。把这份清单当作发布前的核对表使用即可——它能减少确定性错误，但不应被写成对搜索表现的保证。