先说这份清单和别的不一样的地方：它不按顺序做，按影响面做。
平铺几十项的清单有个通病——所有项目看起来同等重要，读者不知道先做哪个。但实际影响天差地别：robots.txt 挡住了整个站，和某个页面少了一个图片的 alt 属性，显然不是一回事。
所以按五层排：能不能被抓到（整站级，最优先）→ 能不能被索引（页面级）→ 抓到的是什么（渲染与内容）→ 加载体验（Core Web Vitals）→ 国际化（多语言站）。上一层没解决，下一层做得再好也没意义。
第一层：能不能被抓到（整站级）
这一层出问题，影响的是整个站，永远排第一。
- robots.txt 有没有挡住。 改完之后不要凭感觉，用 Search Console 的 robots.txt 报告看 Google 实际读到的版本和时间
- CDN、WAF 或服务器防火墙有没有拦住 Googlebot。 按 IP 段批量屏蔽的策略最容易误伤，尤其是站点被攻击过、加了严格规则之后
- 服务器稳定性。 大量 5xx、响应超时，会直接压低抓取预算
- 站点地图。 存不存在、有没有提交、里面的 URL 是不是规范地址（而不是带参数的、跳转前的、或者已经 404 的）
验证方法：Search Console 的 robots.txt 报告 + 网址检查工具里点「测试实际网址」，看抓取有没有成功。
外贸站特别要注意的一点：如果服务器在国内、主要访客在海外，海外的抓取和访问延迟都会被放大。用境外节点实测一次响应时间和状态码，比在国内看要准。
第二层：能不能被索引（页面级）
抓取成功不等于会被收录。这一层最常见的问题是上线流程留下的痕迹：
- noindex 忘了摘。 建站或改版时加的 noindex，上线后没有移除——这是最典型的低级错误，而且症状很隐蔽：页面能打开、能抓到，就是不收录
- canonical 指错了。 指向另一个页面、指向不存在的页面、或者全站 canonical 都指向首页。canonical 是给 Google 的强信号，指错了后果比没有更严重
- 内容太薄或高度重复。 产品页之间只差一个型号、参数表是图片、描述是复制的，这类页面被判定为低价值很正常
- 筛选页、参数 URL、分页产生大量近似页面。 尤其是带颜色、规格、排序参数的电商型独立站
验证方法：网址检查工具会直接告诉你 Google 的判断，比如「已排除：被 noindex 标记」「Google 选择的规范网址与用户声明的不同」。这个结果比任何第三方工具都权威，因为它就是 Google 自己的判断。
第三层：抓到的是什么（渲染与内容）
这一层决定的是 Google 拿到的页面里有没有你要表达的东西。
重要内容必须落在服务端输出的 HTML 里。 如果产品描述、规格参数、FAQ 要靠 JavaScript 执行之后才出现，那就存在风险：抓取和第二轮渲染之间有时差，复杂的框架还可能渲染失败。
检查方法很简单：在网址检查工具里打开「查看已抓取的网页」，看 Googlebot 实际拿到的 HTML 源码里有没有正文。如果那里是一片空或者有大量 `
`，问题就找到了。
需要检查的关键元素：
- 标题标签与 H1
- 正文内容
- 内部链接（是不是真的 ``，而不是靠 JS 点击）
- 结构化数据
- 图片（含 alt 属性）
这一层对 AI 搜索同样成立。Google 在 AI 功能的官方说明里，把「确保重要内容以文字形式提供」列为最佳实践之一——同样的内容，藏在 JS 里对常规索引和 AI 功能一样不可见。
第四层：加载体验（Core Web Vitals）
三个指标，先说清楚概念再谈优化：
| 指标 | 衡量什么 | 良好 | 需改进 | 差 |
|—|—|—|—|—|
| LCP | 加载：最大可见元素渲染完成的时间 | ≤ 2.5s | 2.5–4.0s | > 4.0s |
| INP | 响应：交互到下一帧的延迟 | ≤ 200ms | 200–500ms | > 500ms |
| CLS | 视觉稳定：内容的意外偏移 | ≤ 0.1 | 0.1–0.25 | > 0.25 |
INP 已于 2024 年 3 月 12 日正式取代 FID。 如果还有 checklist 让你优化 FID，那份清单已经过时了。FID 只测首次交互前的输入延迟，INP 测的是整页交互的完整响应链路。
评估方式是 75 百分位，不是平均值。 数据来自 CrUX（Chrome 用户体验报告）的真实用户数据，滚动 28 天。含义是：四分之三的访问都要达到「良好」区间，这个页面才算通过。
这条机制解释了一个常见困惑：实验室工具跑绿了，Search Console 还是显示「需要改进」。 原因有两个——
一，Lighthouse 是在你自己的机器上跑一次模拟加载，而判定用的是真实设备上的真实访问分布；
二，实验室工具根本测不了 INP（模拟加载里没有人去点击），只能用 TBT（总阻塞时间）做代理。所以实验室分数和现场数据对不上是正常的，不要对着 Lighthouse 的分数反复优化。
低流量的页面还有个坑：样本不足时会回退到站点级数据，一个产品页可能显示一个它自己根本没造成的失败指标。
关于优先级，说一句可能反共识的话：Google 官方对页面体验的定位一直是「众多排名因素之一」，在相关性和质量接近的页面之间起决胜作用，不是主导因素。所以不要为了把 LCP 从 2.6 秒压到 2.4 秒去删除有价值的内容。先解决明显的问题（未压缩的大图、过多的追踪脚本、没有缓存），再谈微调。
外贸站在这一层的常见病因：服务器在境内导致的海外 TTFB 偏高、产品图直接上传原图、同时挂了多套追踪脚本、字体文件没有处理。
第五层：国际化（多语言站）
如果站点只有一个语言，这一层可以跳过。有多个语言或地区版本时，核心是 hreflang——它的作用是让 Google 把正确版本呈现给对应地区的用户，不是排名因素。
这一层最容易出的错是代码写错：英国要用 `en-GB` 不是 `en-UK`，欧盟不是国家所以 `en-EU` 无效，单独写地区不写语言也无效。完整规则和排查方法写在多语言独立站SEO（hreflang）里，这里不展开。
一张可执行的排查表
| 层级 | 影响面 | 用什么查 | 典型症状 |
|—|—|—|—|
| 能否抓取 | 整站 | robots.txt 报告、网址检查的抓取测试 | 大量页面长期未收录 |
| 能否索引 | 页面 | 网址检查的索引判断 | 页面能打开但不收录 |
| 抓到什么 | 页面 | 网址检查 → 查看已抓取的网页 | 收录了但内容读不到、排名差 |
| 加载体验 | 模板 | Core Web Vitals 报告、PageSpeed Insights | 移动端表现明显差于桌面 |
| 国际化 | 版本 | 网址检查、hreflang 校验 | 错误语言版本出现在错误地区 |
按这个顺序从上往下查，每修完一层重新验证一次，再进入下一层。
五个常见错误
把技术SEO当成一次性项目。 站点改版、换模板、加插件、迁移服务器之后，前面几层都可能重新出问题。建议每次上线后跑一遍前两层。
只看工具分数不看 Google 自己的判断。 第三方工具可以帮着发现问题，但最终判定要看 Search Console——那才是 Google 实际怎么处理你的页面的。
改了 robots.txt 不验证。 改完之后不去看报告，等于没改。语法错误、规则冲突都可能让文件失效。
为了性能分数牺牲内容。 前面说过，页面体验是众多因素之一。删掉产品细节去换 0.2 秒，通常不划算。
忽略移动端。 评估按设备分开，很多站点桌面端全绿、移动端全线飘红，而 B2B 采购商在手机上看产品页的比例并不低。
探索者SEO顾问团队做技术诊断时的顺序和这份清单一致——先看整站能不能被抓，再看单页能不能被索引，最后才谈性能和细节。跳过前两层直接优化 Core Web Vitals，是最常见的无效投入。
如果你刚接手一个站点、不确定技术层面有没有硬伤，可以先把 robots.txt、noindex 和 canonical 这三样查一遍，这是投入产出比最高的十分钟。需要人系统性过一遍，联系项目顾问，电话 15617834052，邮箱 931519643@qq.com。收录相关的排查见新站不收录怎么办，完整的诊断流程参考网站SEO诊断清单。
常见问题
技术SEO清单应该按什么顺序执行？
按影响面，不按清单顺序。第一层整站能否被抓取（robots.txt、WAF、服务器、站点地图），第二层页面能否被索引（noindex、canonical、内容质量），第三层抓到什么（渲染与正文），第四层加载体验（Core Web Vitals），第五层国际化。上一层没解决，下一层做得再好也没意义。
Core Web Vitals 现在是哪三个指标？
LCP（加载，≤2.5s 为良好）、INP（响应，≤200ms 为良好）、CLS（视觉稳定，≤0.1 为良好）。INP 于 2024 年 3 月 12 日正式取代 FID，还在优化 FID 的清单已经过时。
为什么 Lighthouse 分数很高，Search Console 还是显示需要改进？
两个原因。一是评估用 CrUX 真实用户数据的 75 百分位，不是你自己机器上跑一次的模拟结果；二是实验室工具测不了 INP（模拟加载没有用户交互），只能用 TBT 做代理。两者对不上是正常的。
页面打不开是什么原因导致不收录？页面能打开但不收录呢？
能打开但不收录，通常是第二层的问题——noindex 忘了摘、canonical 指错、内容过薄或与其他页面高度重复。用网址检查工具可以直接看到 Google 给出的排除原因，那比第三方工具的猜测准确。
Core Web Vitals 有多重要，值得花大力气优化吗？
Google 官方对页面体验的定位是「众多排名因素之一」，在相关性和质量接近的页面之间起决胜作用，不是主导因素。建议先解决明显问题（未压缩大图、过多追踪脚本、无缓存），不要为了几十分之一秒牺牲有价值的内容。
多语言站点一定要做 hreflang 吗？
如果你有面向不同语言或地区、内容实质相同的多个版本，就该做。它的作用是让正确版本呈现给对应用户，不是排名因素。单语言站点不需要。常见错误是代码写错，如英国应为 en-GB 而非 en-UK。