WordPress 迁静态站，
最坑的不是速度，是 301。

迁完站，速度从五秒掉到零点九秒，当天就能看见。三个月后才发现自然流量掉了一半——这时候已经很难查是哪一步出的问题。迁移真正的风险不在技术难度，在旧地址没人管：外链打不开、老客户点进来是 404、收录一条条掉。

迁移时为什么 301 比速度更要紧？

速度影响的是转化率，掉一点还能靠别的方式补。301 影响的是你过去几年攒下的全部入口：谷歌记住的地址、客户收藏的链接、行业目录里的收录、别人文章里的引用。这些东西一旦断掉，不会自己长回来。

而且它有时间差。谷歌发现旧地址 404、把权重转到新地址，中间可能隔几周。这段时间你会觉得「好像还行」，等到流量真的掉了，原因已经埋了三个月。

第一步：把旧 URL 全部扒出来

不要凭印象列。凭印象列出来的，通常只有导航上那几个页面，漏掉的恰恰是最有价值的长尾页——那些年久失修但还在带来询盘的产品页。

五个来源，按可靠性排：

1. 旧的 sitemap.xml。如果是 WordPress 加插件生成的，里面通常是最全的一份清单。下载下来存好，这是你最重要的原始资料。
2. Search Console 的「网页」报告。已编入索引的地址列表，可以导出。这份代表谷歌实际收录过的，价值最高。
3. 服务器访问日志。过去三个月所有被访问过的路径，包括那些没被收录但有人在用的。
4. 站内爬取。用任意爬虫工具从首页爬一遍，把所有内部链接收集起来，能补上 sitemap 漏掉的页面。
5. 外链数据。GSC 的「链接」报告能看到哪些页面有外链——这些是最不能断的，因为权重从那里来。

把这五份合成一张表，去重，你就有了完整的旧地址清单。这一步花两小时，能省掉后面两个月的返工。

第二步：映射表，三种情况分开处理

第三行是重点。很多人图省事，把所有找不到对应页的旧地址一律跳首页。短期看用户不会撞到 404，长期看谷歌会认为这些跳转没有意义，权重不给，还可能判成作弊手法。宁可给 410（明确告诉它内容已删除），也不要假装首页是它的新家。

映射表本身的格式很简单，一行一条：旧路径、新路径、状态码。纯静态托管通常支持一个 _redirects 文件，写完放根目录就生效，不需要额外配置服务器。

/old-product-page/    /products/new-page/    301
/blog/2019/old-post/  /blog/old-post/        301
/legacy-category/     /products/             301

第三步：301 和 302 别用错

这两个状态码的差别，谷歌说得比多数人以为的重要：

“The following table explains the various ways you can use to set up permanent and temporary redirects, ordered by how likely Google is able to interpret correctly (for example, a server side redirect has the highest chance of being interpreted correctly by Google).”

谷歌把各种重定向方式按「被正确理解的概率」排了序：服务器端重定向最高，其次才是 meta refresh 和 JS 跳转。这句话的潜台词是——能用服务器端 301 就别用前端跳转，那些方式它可能看不懂，看不懂就等于没有。

Google 搜索中心 · 重定向与 Google 搜索

301 是永久，302 是临时。迁移必须用 301，因为你要把权重转过去。用了 302 的结果是：谷歌认为旧地址还会回来，于是保留旧地址的收录，新地址迟迟拿不到权重，可能拖几个月。

还要提醒一句关于 meta refresh 和 JS 跳转：能不用就不用。有的建站工具只提供这种方式，短期看着能用，长期是权重漏损。

第四步：canonical 和 sitemap 是不是也要一起切？

迁移里最容易出的一种「半切」状态：新站上线了、旧站还在、两边的 canonical 都指自己，sitemap 里两套地址都在。谷歌这时候看到的是两份内容几乎一样的站点，只能挑一个，另一个降权——而它挑的未必是你想要的那个。

正确做法是三件事同一时刻完成：

• 新站 canonical 自指，指向新地址，不是旧地址。
• sitemap 只留新地址，旧地址一条不留。
• 旧地址全部 301 到新地址，包括首页。

另外要注意 URL 形式的统一。如果新站用的是目录式地址（/service/），但 canonical 写成了 /service.html，而服务器又会把前者 307 到后者，那你就等于让 canonical 指向一个会跳转的地址——谷歌会把它归成「带重定向的网页」，收录优先级直接降级。

第五步：切换那天的顺序

顺序错了会有一段「两边都不认」的空窗。按这个来：

1. 新站在临时地址跑通。所有页面能打开、表单能提交、手机端不错位。这一步旧站完全不动。
2. 301 规则先部署到新站。在还没切域名的时候就把映射表放上去，用临时地址测一遍：随便挑二十条旧地址，看是否都跳到了正确的新页。
3. 切 DNS。改解析，等生效。这时候旧站还可以保留一段时间作为兜底。
4. 提交新 sitemap、请求重抓几个关键页。在 Search Console 里操作，别等它自己发现。
5. 观察两周再拆旧站。GSC 的「网页」报告里，看旧地址是否都被标成「网页会自动重定向」，新地址是否被收录。确认之后再关旧站。

第 5 步最容易被跳过。很多人切完当天就把旧站删了，结果发现某个目录的 301 规则写错了，旧站已经没了，连原始 URL 都查不到。

切换完怎么验证权重真的没掉？

四周内看三个数，比什么都有用：

• GSC「网页」报告里的「网页会自动重定向」数量。这个数字应该先升后降——升说明 301 生效了，降说明谷歌已经把新地址收录、旧地址退场。
• 核心页面的曝光量。迁移后两周内波动正常，四周还比迁移前低三成以上，说明映射有问题。
• 404 报告。旧站关掉之后，如果这里冒出大量以前没见过的地址，说明映射表漏了。

反过来说，如果迁移做得对，通常是加分的：新站更快、结构更干净，核心网页指标改善之后，同等内容下排名会往上走一点。掉权不是迁移的必然结果，是迁移做错的后果。

我们怎么防止这一步出错

我们的做法是把映射表当成交付物的一部分，跟页面一起管：旧地址清单从旧 sitemap 和 GSC 导出，人工过一遍确认没有遗漏，写成 _redirects 文件进版本库。以后再加页面、再改结构，映射表跟着一起改，不会散落在某个人的记事本里。

还有一个原则：旧站不提前关。新站做好、客户确认、域名切换、观察两周，确认没问题才停旧站。这段时间旧站一直正常运行，客户该来的询盘一封不少。

说清能力边界：我们不做黑帽的「权重搬运」，也没有办法让一个内容本来就不行的站因为迁移而排名上升。能保证的是——你原来有的入口，迁移之后一个不少。

准备迁站、或者迁完发现流量在掉，把旧 sitemap 和新站地址发我。我对着看一眼就能判断：是映射漏了，还是 canonical 打起来了。