网站改版SEO怎么做：301重定向、站点迁移与上线排查清单
网站改版是否掉排名，关键不在“换了新设计”，而在你到底改的是主机、平台、URL 还是域名。Google 当前关于站点迁移的文档明确建议：先分清 hosting move 与 URL move，尽量一次只改一类变量，为旧 URL 建立新 URL 映射，使用 server-side permanent redirects，并在上线后持续监控 old/new 流量、抓取和索引。本文按这套逻辑给你一份更适合实操的迁移清单。
// 相关文章
网站改版是否掉排名，关键不在“换了新设计”，而在你到底改的是主机、平台、URL 还是域名。Google 当前关于站点迁移的文档明确建议：先分清 hosting move 与 URL move，尽量一次只改一类变量，为旧 URL 建立新 URL 映射，使用 server-side permanent redirects，并在上线后持续监控 old/new 流量、抓取和索引。本文按这套逻辑给你一份更适合实操的迁移清单。
网站改版最容易出问题的，不是“新设计好不好看”，而是你到底改了什么。对 SEO 来说，换设计、换主机、换平台、换 URL、换域名，风险完全不是一回事。很多团队把这些动作捆在一次上线里，结果一旦流量掉了，根本分不清到底是哪一步出了问题。
Google 当前关于 site move 的文档，其实已经把最关键的原则说得很明确：能分步就分步，一次尽量只改一类变量；如果是 URL 变化，就先把 old-to-new 映射和重定向策略做对；如果只是换主机或 CDN、用户可见 URL 不变，就按 hosting 迁移的逻辑处理，不要把两类问题混在一起。
所以，这篇文章不再按那种泛泛的“改版前、改版中、改版后”老模板来讲，而是先把改版类型拆开，再给你一套更接近 Google 官方文档的迁移顺序。这样做的好处是：你不仅更容易避免掉排名，也更容易在出问题时快速定位。
不是所有“网站改版”都叫同一种迁移。至少可以先分成这 4 类：
Google 在官方文档里把这件事分得很清楚：如果用户可见 URL 发生变化，就看 site move with URL changes；如果只是换 hosting 基础设施，URL 不变，就看 site move with no URL changes。这一步一定要先分清，因为它决定了你后面该不该做 URL 映射、301/308 重定向、Change of Address 等动作。
这是 Google 在 site move 文档里反复强调的核心原则之一：change only one thing at a time。如果你要换域名、换 CMS、换页面结构、顺便重写内容，最好拆开做，而不是压成一次“大升级”。
原因很简单：
更稳的做法通常是：
如果你的网站规模不大，却还要一次性把所有东西都换掉，那至少要接受一个现实：这不是“常规改版”，而是高风险迁移项目。
Google 官方文档在“Determine your old URLs”部分给了很实用的方向：先看 sitemap、服务器日志、analytics 和 Search Console 里真正重要的页面，再建立映射。也就是说，迁移前你最该做的不是“导出全站然后松一口气”，而是先识别哪些 URL 最不能掉。
优先级更高的页面通常包括：
如果你们站已经在用 Search Console 和日志分析，建议把这些数据交叉起来看：
这也是为什么在做迁移前，先读一遍SEO 数据分析清单和服务器日志分析指南，会比只靠肉眼列页面稳得多。
如果你的迁移涉及 URL 变化，那么最关键的基础文件就是映射表。Google 的 URL move 文档要求很清楚：先列出 old URLs，再决定 each old URL should redirect to which new URL，然后按映射去部署重定向。
一个合格的映射表，至少要回答这 3 件事：
这里最常见的错误不是“没有做重定向”，而是做了错误的重定向，例如：
Google 在 site move 文档里明确提醒过：不要把很多 old URLs 重定向到一个不相关的目标，比如首页，这可能被当成 soft 404。只有当多个旧页面被合理合并进一个新页面时，才适合做这种汇总式重定向。
Google 在 site move 和 redirects 文档里给的建议很直接：如果技术上可行，优先使用 server-side permanent redirects，也就是 `301` 或 `308`。这类信号对迁移最稳。
执行时要注意 4 个点：
Google 现在的文档也明确说了，虽然 Googlebot 可以跟随更长的 redirect hops，但仍然建议直接跳最终页；如果实在避免不了，链条也应该尽量低，理想上不超过 3 跳。因为链式重定向不仅影响抓取，也会拖慢真实用户访问。
这一步是很多团队改版后才意识到的问题。Google 在 site move 文档里专门提到：images、videos、downloads、JavaScript、CSS 这些嵌入资源，也要纳入迁移计划。因为它们本身可能在拿搜索流量，也可能直接影响新页面的抓取、渲染和体验。
同时，迁移时还要一起检查这些信号：
rel="canonical" 是否都已改成新 URL。hreflang 是否都已指向新 URL。很多站点改版后排名掉，不是因为“Google 不喜欢新设计”，而是因为 canonical 还在指旧地址、站内链接没改、模板把主内容挤下去了，或者资源文件路径根本没迁完整。
Google 在 URL move 和 hosting move 两类文档里都特别提醒了同一类错误：开发环境里为了避免提前索引而加上的 `noindex`、robots block，如果忘了撤，迁移会直接卡死。这类问题比“内容质量”更先影响结果。
如果你们是换主机而非换 URL，还要额外注意 DNS 相关步骤。Google 的 hosting move 文档建议：至少提前一周把 DNS TTL 降到较低值，例如几个小时，这样切换时传播会更快。同时，上线前要确认新环境没有防火墙或 DoS 配置误伤 Googlebot。
Google 在 site move 文档里明确建议：旧站和新站相关 property 都要提前验证，包含你实际会用到的各类变体。对域名迁移来说，这一步尤其重要，因为后面你还需要用到 Change of Address 工具。
更稳的做法是：
如果是域名或子域名变更，Google Search Console 文档也明确说明：Change of Address tool 可以告诉 Google 这是一个站点迁移。但如果只是 HTTP → HTTPS，则不需要使用这个工具。
Google 对迁移后的预期其实很现实：可见度会波动，这是正常的；中型站点通常需要几周时间让大多数页面完成迁移，更大的网站可能更久。所以，迁移后的监控重点不是“今天某个词掉了没”，而是看迁移过程是不是在正确推进。
更值得看的监控项包括：
如果你只有少量关键页需要补抓，可以用 URL Inspection 请求重新抓取；但如果是大规模迁移，Google 官方建议仍然是以 sitemap 为主，因为 sitemap 对大量 URL 的发现更有效。
Google 在 site move 文档里给出了很明确的时间建议：redirects 尽量保留至少 1 年，从用户角度甚至可以更久。同时，Google 也建议尽快更新自己的 internal links，以及外部高流量链接、社媒资料页和广告落地页。
这背后有两个原因：
也就是说，301 不是终点，而是迁移期的缓冲层。真正更好的状态，还是让站内系统、导航、正文内链和外部关键资料都直接指向新地址。
这种情况不要把它当成 URL 迁移。更关键的是：
Google 也提到，这类 hosting move 之后，Googlebot crawl rate 先暂时下降、再逐步恢复甚至升高，是正常现象。
这类迁移最容易被低估。真正决定成败的通常是：
如果还要顺便换设计，建议把主题或模板测试放到迁移前独立完成，而不是留到上线当天一并发现问题。
这是风险最高的一类，因为你不仅在改 URL，还在改站点身份。更稳的顺序通常是：
不要以为“全站 301 到新首页”就算换域名完成了。对 Google 和用户来说，那通常只是更糟的错误页体验。
正常。Google 官方明确说，重要站点变更后排名会临时波动。关键不是有没有波动，而是重定向、抓取、索引和新 URL 替换过程是否在正常推进。
Google 当前建议是尽量至少保留 1 年。从用户体验角度，能长期保留更稳，但同时也要尽快把内部链接和高价值外部链接直接改成新地址。
不应该。Google 明确提醒过，把大量旧 URL 跳到不相关首页可能被视为 soft 404。正确做法是一对一跳到最相关的新页面；确实删除且无对应内容的页面，则返回合适的 404 或 410。
不用。如果用户可见 URL 没变化，这类迁移重点不在重定向，而在 DNS、抓取可访问性、移除开发期屏蔽，以及新旧服务器日志监控。
如果只是少量关键页，可以用 URL Inspection 请求重新抓取；但大规模迁移时，更重要的是提交 sitemap，因为 Google 官方明确说 sitemap 对站点启动或 site move 时的大量 URL 发现更有帮助。
真正稳的网站迁移，不是上线当天“没报错”就算完成，而是旧 URL、重定向、新 URL、抓取、索引和内部结构这条链路全都接上。只要这条链路断一段，掉的就不只是几个排名，而是你过去积累的整套搜索信号。
