Newsletter Subscribe

Enter your email address below and subscribe to our newsletter

第五章：技术 SEO（Technical SEO）——我会这样把“底盘”打稳

Share your love

我做 technical-seo 的时候，心态特别明确：内容写得再好，技术底盘烂，收录/排名/转化都容易卡壳。
这一章，把我会怎么做、怎么排查、怎么落地写出来：404与301、Sitemap、robots.txt、canonical/noindex、速度、移动端适配。

小提醒：技术SEO不是让你“讨好搜索引擎”，而是让抓取更顺、理解更准、体验更好。Google 自己也强调：抓取与索引依赖你提供的可访问性信号（链接、Sitemap、robots、规范化等），而体验信号（Core Web Vitals 等）是整体系统的一部分。

Table of Contents

1）404 错误与 301 重定向：我最怕“好心办坏事”

1.1 404 到底要不要修？我会先分类型

很多人一看到 404 就慌，开始全站重定向到首页。我一般不这么干，因为 Google 明确提到：404 并不一定是坏事，很多时候它就是正确的状态；盲目批量重定向（尤其指向首页）反而会制造更多问题。

我会把 404 先分成这几类（按优先级从高到低）：

  • 重要页面的 404（必须修）：带自然流量/外链/转化的页面突然挂了
  • 误链导致的 404（要修链接源头）：站内旧链接、导航、相关文章模块指错
  • 正常下线的 404（可以不修）：活动结束、过期内容彻底删除，且没有替代内容
  • Soft 404（必须修）：页面显示“没了/空内容”，但服务器却返回 200，导致抓取浪费和索引混乱

我判断“是不是 Soft 404”的标准非常简单：页面对用户等同不存在，但状态码却是 200。Google 对 soft 404 的定义就是这种情况。

1.2 我什么时候用 301？什么时候宁愿保留 404？

我会按“用户意图是否有匹配的替代内容”来决定：

✅ 适合 301 的情况

  • A 页面永久迁移到 B 页面（内容高度一致或升级版）
  • 产品改款、分类合并、URL 规范化（例如大小写/参数统一）
  • 旧文被新文完整替代（且旧文有流量/外链价值）

✅ 保留 404/410 的情况

  • 内容确实不存在，也没有合理替代
  • 为了避免把大量无关请求“挤占抓取预算”
  • 垃圾 URL、被刷出来的无意义路径（这里更需要从源头处理参数与爬虫策略）

我做 301 有个底线：绝不把大量 404 统一 301 到首页。这类“看似修复”经常让相关性更乱。

1.3 我常用的“404/301处理表”

场景 我会怎么做 状态码建议 备注
旧文被新文替代 旧文 -> 新文做跳转 301 旧文标题/内链也同步更新
产品下架但有替代款 下架页 -> 替代款/同类聚合页 301 替代页要能满足同意图
活动结束且无替代 直接下线 404/410 别硬跳首页，避免误导
Soft 404 修状态码/补内容/正确跳转 改为404或301 Soft 404 会干扰抓取与索引 :contentReference[oaicite:5]{index=5}

2）XML Sitemap 与 HTML Sitemap：我会把它当“抓取导航”

2.1 XML Sitemap：我怎么做才不浪费？

Sitemap 的作用不是“让你马上排名”，而是帮助搜索引擎更智能地抓取，尤其是：

  • 新站、页面很深、内链不够强
  • 大站、更新频繁、URL数量多
  • 需要明确告诉引擎“哪些页面最值得抓/更常更新”

Google 的官方文档里讲得很清楚：你可以创建并提交 Sitemap，也可以在 robots.txt 里声明 Sitemap 位置。

我做 XML Sitemap 的硬规则：

  • 只放你希望被索引的 URL
  • 必须是可抓取、返回 200、且是规范化版本（canonical）
  • 别把参数页、筛选页、站内搜索结果页塞进去（除非你非常确定它们是“有搜索价值的落地页”）

Google 也提供了关于 Sitemap 字段与实践的建议（哪些字段重要、什么时候用 RSS/Atom 等）。

2.2 HTML Sitemap：我什么时候会做？

如果是内容站或企业站，我常常会补一个 HTML Sitemap（给人看的站点地图页），原因很现实：

  • 用户迷路时能快速定位
  • 让重要分类/栏目形成“聚合入口”
  • 顺便做一层高质量内链（尤其对深层页面很友好）

我推荐的seo插件里面包括市面主流的都有这个功能，可以生成一个可视化的页面给大家看

2.3 我常用的 Sitemap 结构示意图

Sitemap（抓取导航）结构示意 sitemap_index.xml sitemap_posts.xml sitemap_products.xml 只放：200 + 可抓取 + canonical 的URL（避免参数垃圾）

3）robots.txt 设置：我用它“控抓取”，但不拿它“控收录”

3.1 robots.txt 最常见误区：以为它能“防收录”

Google 在 robots 相关文档里讲得很直白：**robots.txt 主要用于告诉爬虫哪些 URL 可以抓取，主要目的也包括避免服务器被过度请求；它不是用来把网页从 Google 里移除的机制。**如果你要阻止出现在搜索结果里，应使用 noindex 或其他方式（比如认证/密码保护）。

所以我自己的规则是：

  • robots.txt：控制抓取（crawl）
  • noindex：控制索引（index）
  • 想“既不抓也不收录”？通常要组合策略（比如先允许抓取让 noindex 生效，或直接做权限控制）

3.2 robots.txt 我会怎么写（模板 + 安全边界）

# robots.txt（模板示例）
User-agent: *
Disallow: /search/
Disallow: /cart/
Disallow: /checkout/
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

# 声明Sitemap（Google 会在抓取robots时发现） :contentReference[oaicite:9]{index=9}
Sitemap: https://example.com/sitemap_index.xml

我会特别注意：

  • robots.txt 必须放在站点根目录，并遵循规范（编码、路径范围等）
  • 不要误伤 CSS/JS（否则移动端渲染与可用性判断可能受影响，间接伤 SEO；很多站点就栽在这）

4）Canonical / noindex：我用它们来“解决重复”和“控制露出”

4.1 Canonical 是啥？我怎么用得更稳？

我处理重复内容（或近似内容）时，第一反应常常是 canonical。Google 的文档里明确：你可以通过 rel=”canonical” 等多种方法，向 Google 表达你偏好的规范化 URL，用于合并重复或非常相似的页面信号。

我常见使用场景：

  • 带参数的 URL（排序、分页、筛选）
  • 同内容多路径（分类路径不同、大小写不同）
  • 打印版、AMP（如有）等变体

我会避免的 canonical 坑（Google 也列过常见错误）：

  • canonical 指向 404/soft 404
  • canonical 写在 body 里或写多次
  • 把分类页 canonical 到某篇文章（导致分类页失去展现机会）

4.2 noindex 我什么时候用？

当我明确不希望某页出现在搜索结果里（且它不承担SEO入口价值）时，我会用 noindex，比如：

  • 站内搜索结果页
  • 登录/个人中心
  • 购物车/结账流程
  • 测试环境页面（更建议权限隔离）

同时我会牢记一个原则：robots.txt 不是“防收录”的正确工具。

4.3 我常用的“canonical vs noindex 决策表”

问题 更推荐 我为什么这么选 常见反例
同内容多URL Canonical 合并信号，保留一个“主版本” :contentReference[oaicite:14]{index=14} 把所有页都 noindex，入口流量全断
内容薄/功能页 noindex 不想在搜索结果露出，避免低质占位 靠 robots 以为能“防收录” :contentReference[oaicite:15]{index=15}
参数页仍有搜索价值 做可索引落地页 把它当“专题/筛选结果页”建设内容与内链 一刀切 canonical 到主分类，长尾全丢

4.4 决策树“图片”

Canonical / noindex 决策树（technical-seo） Q1：这页是否与另一页“高度重复/非常相似”？ 是：优先 Canonical 指向主版本 否：进入 Q2 Q2：是否希望它出现在搜索结果？ 不希望：noindex（别靠robots防收录）

5）页面速度优化：我做 technical-seo 最“见效”的一块

5.1 我关心哪些指标？不只看分数

速度优化最容易走偏：只盯工具分数，忽略真实用户体验。
我一般会把“数据来源”分两类：

  • 实验室数据（Lab）：Lighthouse、PSI 的模拟测试，适合定位问题
  • 真实用户数据（Field）：实际用户的体验分布，更接近真实排名系统参考

Google 的 PageSpeed Insights 说明里提到，Core Web Vitals 的核心指标是 INP、LCP、CLS，并且会用分位数（如 75th percentile）来评估是否通过。
Chrome 的 Lighthouse 文档也解释了 LCP 等指标的含义与评分逻辑。

另外，Google 也明确：Core Web Vitals 会被其排名系统使用，但它不是唯一因素；相关性仍然更重要。

5.2 我最常用的速度“落地打法”

我做速度优化，一般从这几块下手（因为最常见、收益最大）：

（1）图片与媒体

  • 首屏大图：压缩、改格式（如 WebP）、控制尺寸
  • 懒加载（非首屏）
  • 视频：用封面图 + 点击播放，别自动加载一堆资源

（2）JS/CSS 体积与加载顺序

  • 把“必须的”留在首屏，把“可延后”的延后
  • 合并/拆分合理 chunk（别为了拆而拆）
  • 第三方脚本能少就少（尤其营销追踪一堆叠加）
  • 站长实测下来 element他的块偏向js启动，没有原生古腾堡的速度轻量和快，但是古腾堡给站长总有一种ge手的感觉，不过为了站点速度，站长也是不得不用gutunberg建站

（3）服务器与缓存

  • CDN（静态资源）
  • 合理缓存策略（Cache-Control）
  • 压缩（gzip/brotli）

（4）渲染路径

  • 减少阻塞渲染资源
  • 首屏关键 CSS 优先

5.3 速度优化对 technical-seo 的意义：我会这样解释给大家听

我通常不会说“速度能让排名暴涨”（这话太满），我会说：

  • 速度与体验信号属于排名系统考虑的维度之一（尤其在同质内容竞争时更关键）
  • 速度更直接影响转化：加载慢 -> 用户走 -> 再好的排名也接不住
  • 技术问题会“吃掉抓取效率”：大量 soft 404、重复URL、慢响应会让抓取资源浪费（间接伤索引）

6）移动端适配：我默认“先移动端，再桌面端”

6.1 我为什么把移动端当第一优先级？

因为 Google 明确推荐响应式设计（Responsive Web Design），并给了移动优先索引的最佳实践：同一 URL 同一 HTML，按屏幕自适应，是最容易维护与实现的方案。

我的落地原则就三句话：

  1. 移动端内容别缺斤少两（标题、正文、内链、结构化数据尽量保持一致性）
  2. 别屏蔽关键资源（JS/CSS 让 Googlebot 能渲染）
  3. 交互要可用（按钮间距、字体、首屏可读、弹窗别挡内容）

6.2 我会做的“移动端技术检查清单”

  • ✅ 首屏文字不用放大也能读（字体、行高）
  • ✅ 点击区域够大（别让用户误触）
  • ✅ 弹窗/遮罩不会一打开就挡住主要内容
  • ✅ 关键图片不会超出屏幕导致横向滚动
  • ✅ 页面可渲染（资源不被 robots 误伤）
  • ✅ 关键内容在移动端也能加载到（别用“点开才加载”的隐藏内容糊弄）

7）我最常用的 technical-seo「17项超强排查清单

7.1 抓取与状态码

  1. 重要页面是否存在 404（且有流量/外链）
  2. 是否存在 soft 404（页面像404但返回200）
  3. 301 是否只用于“永久迁移”且指向强相关替代页
  4. 是否存在链式重定向（A→B→C）或循环重定向（A→B→A）
  5. 站内内链是否大量指向已重定向 URL（应更新到最终URL）

7.2 Sitemap

  1. XML Sitemap 是否只包含可索引 URL（200 + canonical）
  2. 是否有 sitemap index 拆分（大站强烈建议）
  3. robots.txt 是否声明 Sitemap 地址
  4. 是否有 HTML Sitemap/专题聚合页承担“深层内链分发”

7.3 robots 与索引控制

  1. robots.txt 是否放在根目录且规则有效
  2. 是否误伤 CSS/JS（影响渲染与移动端判断）
  3. 需要不收录的页面是否用 noindex 而不是只靠 robots

7.4 Canonical / 重复内容

  1. canonical 是否只写一次、写在 head、且指向 200 的规范URL
  2. 参数页/分页是否有清晰策略（能索引的就建设成落地页，不索引的就规范化或 noindex）

7.5 速度与体验

  1. Core Web Vitals 的 INP/LCP/CLS 是否达标（优先看真实用户数据）
  2. 首屏大图与第三方脚本是否拖慢加载（优先砍“最大资源消耗”）

7.6 移动端

  1. 移动端是否采用响应式设计且内容/结构化数据尽量一致

8）外链资源

8.1

  • Google：构建并提交 Sitemap（含 robots.txt 里声明 Sitemap）
  • Google：robots.txt 入门与注意事项（强调 robots 不是防收录工具）
  • Google：canonical 规范化（合并重复URL信号）
  • Google：排查抓取错误（含 soft 404 定义）
  • Google：Page Experience & Core Web Vitals（排名系统使用，但非唯一）
  • Google：移动优先索引最佳实践（推荐响应式）

8.2 “dofollow 外链”

参考官方文档： Google Search Central – Build and submit a sitemap

9）我写给自己的“最终自检”（确保 technical-seo 真落地）

我每次做完技术SEO改动，都会用这套自检闭环收尾：

  • 改动是否会影响抓取（robots、状态码、重定向）
  • 改动是否会影响索引（noindex、canonical、重复URL）
  • 改动是否会影响体验（速度、移动端）
  • 改动是否会影响内容可达性（内链是否更新到最终URL）
  • 是否留了可追踪证据（变更记录、上线时间、影响页面列表）

看了这么多专业名词，大家不用害怕技术SEO，只要take a deep breath and count to ten，你会发现碰到的问题–还是问题哈哈

相关文章