网站迁移 SEO 怎么做：301、映射表与上线排查清单（2026）
网站迁移 SEO 的关键不只是做 301，而是把迁移类型、URL 映射、资源迁移、Search Console 和上线监控整条链路接顺。
网站迁移 SEO 的关键不只是做 301，而是把迁移类型、URL 映射、资源迁移、Search Console 和上线监控整条链路接顺。
网站迁移最怕的，不是上线当天报错，而是上线当天看起来没事，过几天流量开始往下掉。再去查，发现问题不是一个，是一串。旧 URL 没有一对一跳转，开发环境的 noindex 没撤，canonical 还指着旧地址，图片和 PDF 丢了一批，站内链接还在跑老路径。到这一步，排查就很费劲了。
Google 近年的迁移文档其实讲得很清楚。site move with URL changes 讲的是 URL 变化时该怎么迁。changing your hosting 讲的是只换基础设施、不改用户可见 URL 的情况。两类事情不能混着处理。混了，后面就很难判断风险到底来自哪一段。
这篇文章不讲空话，只按实际项目顺序来。先分清迁移类型，再做 old-to-new 映射，再查重定向、资源、结构信号、Search Console 和上线监控。你会发现，网站迁移 SEO 说到底不是某一个技巧，而是一套项目管理动作。
很多团队一张嘴就是“网站改版”。但对 SEO 来说，改版不是一个词，而是几类完全不同的事情。Google 把它分得很清楚，核心就在于用户可见 URL 有没有变。
| 迁移类型 | 用户可见 URL 是否变化 | 主要风险 | 优先参考动作 |
|---|---|---|---|
| 只换主机 / CDN | 不变 | DNS、抓取可访问性、缓存和日志切换 | 按 hosting move 处理 |
| URL 结构调整 | 变化 | 映射表、301/308、内部链接更新 | 按 URL move 处理 |
| 换域名或子域名 | 变化 | 全站信号迁移、Change of Address、品牌识别 | 域名迁移专项处理 |
| 换 CMS 且改 URL | 变化 | 模板丢内容、资源丢失、重定向失真 | 按高风险迁移项目处理 |
如果用户可见 URL 变化了，就别把它当成单纯的“换服务器”。如果 URL 没变，也不要为了图省事去配一堆没必要的迁移动作。先把项目归类，这一步能帮你少走很多弯路。
网站迁移一失败，常见场景都很像。团队想“一步到位”，于是域名换了、路径改了、模板换了、内容重写了、图片重新传了、还顺便接了新的分析代码。结果上线后掉了，你根本没法判断是哪一步拖了后腿。
Google 的站点迁移文档 明确建议迁移前先把新站准备好并充分测试。放到执行上，更稳的理解就是：一次尽量少动变量。能拆成两次做，就别压成一次做。
比如，换域名和换设计不要绑在同一天。换 CMS 时，如果能先保住原有 URL 规则，就先保住。内容重写，如果不是必须，也最好放到迁移稳定之后。迁移项目里最值钱的不是“改得多”，而是“问题能定位”。
很多人做迁移，第一反应是把全站 URL 导出来。导出当然要做，但先后顺序不对。更稳的顺序是：先找最不能掉的那批页面，再去补完整列表。因为项目资源有限，测试窗口有限，优先级一定要分。
高价值 URL 通常来自四块数据：Search Console 的点击和展示、分析工具里的落地页和转化、外链工具里的高权重落点、服务器日志里的高频抓取 URL。把这几块合在一起看，优先级就出来了。
| 数据来源 | 最该看什么 | 迁移里的用途 |
|---|---|---|
| Search Console | 高点击、高展示页面 | 确定不能掉的搜索资产 |
| 分析工具 | 高转化落地页 | 识别业务优先页面 |
| 外链工具 | 有优质外链的 URL | 避免链接权益丢失 |
| 服务器日志 | Googlebot 高频抓取页 | 判断抓取重点和异常 |
| Sitemap / CMS 导出 | 全量 URL 清单 | 补足映射覆盖范围 |
如果你们站已经在做数据归因和日志分析，那迁移前最好顺手把这两篇一起过一遍：SEO 数据分析清单 和 服务器日志分析指南。迁移不是单靠开发解决，数据侧也得先站好位。
URL 变化型迁移里，最关键的文件不是设计稿，也不是上线排期，而是映射表。Google 在 How to move a site 里写得很直接，要先准备当前 URL 和对应新 URL 的映射，再开始配置重定向。
映射表不是一列旧地址、一列新地址这么简单。它至少还要告诉团队三件事：是否真的存在对应页、该做永久重定向还是干脆返回 404/410、这个 URL 是不是高优先级测试对象。没有这些字段，映射表后面很难执行。
| 旧 URL | 新 URL | 处理方式 | 优先级 | 备注 |
|---|---|---|---|---|
| /old-service-a/ | /service-a/ | 301 | 高 | 核心询盘页 |
| /blog/old-guide/ | /guides/new-guide/ | 301 | 中 | 有外链，需重点测试 |
| /outdated-product/ | 无 | 410 | 中 | 无等价替代内容 |
| /pdf/catalog-2023.pdf | /downloads/catalog.pdf | 301 | 高 | 文件页也要迁 |
这里最忌讳的，是把大量旧页面一把梭到首页，或者统一跳到某个“相关分类页”。Google 文档 明确提醒过，不相关的重定向容易被系统当成 soft 404。真正稳的做法，还是一对一到最相关的新页。
很多讨论网站迁移的人，最后只剩一句“记得做 301”。这句话不算错，但太粗了。Redirects and Google Search 讲得更完整：如果是永久迁移，优先用服务端永久重定向，也就是 301 或 308。重点是服务端、永久、直达。
真正影响迁移质量的，不只是代码写成 301 还是 308，而是下面这几件事有没有做对：
Google 现在对多跳 redirect 的容忍度比早些年高，但官方仍建议尽量直接到最终地址。不是因为系统完全认不出来，而是因为多一跳，抓取和用户访问都多一层损耗。
很多网站迁移掉量，不是因为文章没迁过去，而是因为“看起来是配角”的东西丢了。图片路径没跟过去，PDF 下载地址失效，JS 和 CSS 资源换路径后被屏蔽，canonical 还是旧站地址，hreflang 还是旧 URL。页面表面活着，底层信号已经断了。
Google 的迁移文档 明确提到，images、videos、downloads、JavaScript、CSS 这些嵌入资源也应纳入迁移计划。不是可选项，是必查项。
| 对象 | 常见遗漏 | 后果 | 上线前检查点 |
|---|---|---|---|
| 图片 / PDF | 文件路径变了但没跳转 | 文件流量丢失，页面素材失效 | 抽查文件 URL 返回码和新路径 |
| JS / CSS | 静态资源被拦或未部署 | 渲染异常，内容理解受影响 | 抓页面源代码和资源请求 |
| Canonical | 仍指向旧地址 | 新页无法稳定接管索引信号 | 抽查重要页 canonical |
| Hreflang | 多语言地址未更新 | 地区版本互相指错 | 核对双向引用和目标 URL |
| 结构化数据 | 模板搬过去但内容不匹配 | 结构信号失真 | 看新页面可见内容是否一致 |
这一块和 技术 SEO 指南、Schema 指南 是一脉相承的。迁移不是只搬文本，而是把整张页面的搜索信号一起搬过去。
迁移项目里最冤的一种损失，就是内容、重定向、资源都做得差不多了，结果上线后被一个开发期设置卡住。最常见的就是 noindex 忘撤、robots.txt 把关键目录挡住、防火墙把 Googlebot 拦了、密码墙没关。
changing your hosting 和 URL 迁移文档都在提醒同一件事：新环境必须让 Googlebot 正常访问。尤其是换主机或 CDN 的项目，迁移成功与否，往往不是“代码能不能跑”，而是“Google 能不能顺利抓”。
如果你们还牵涉 DNS 切换，Google 文档建议提前把 TTL 调低，再做切换。这样传播更快，回滚也更灵活。这个动作看起来偏运维，但对迁移窗口很关键。
很多团队上线后才想起 Search Console。其实这一步应该提前。旧站和新站相关 property，要先验证好。域名迁移项目尤其如此，因为后面还可能会用到 Change of Address。
迁移当天和迁移后，Search Console 主要看四块：新 sitemap 是否成功读取、索引状态是否开始转移、是否出现大量 Not Found 或 soft 404、URL Inspection 抽查关键页时看到的 canonical 和抓取状态是否正常。对于少量关键页，URL Inspection 请求重新抓取 可以用；但大规模迁移，官方仍建议优先靠 sitemap 让 Google 发现大量新 URL。
如果是换域名，Search Console 里还要确认旧 property 和新 property 都在可用状态。这样后面无论是验证迁移进度，还是提交 Change of Address，都不会被卡住。
迁移后短期波动很常见。真正不该做的，是只看几个关键词今天涨了还是跌了。迁移项目的判断方式，应该更像看漏斗。旧 URL 的流量有没有往下走，新 URL 的流量有没有接起来，旧站抓取有没有逐步减少，新站抓取有没有起来，错误报告是不是集中在少数模板问题上。
Google 在 site move 文档 里也说得很现实，网站迁移后会有波动，大站恢复时间会更长。所以，迁移后第一周到前几周，重点不是追排名截图，而是查链路有没有断。
如果你们本身就有日志侧能力，建议把旧站和新站日志一起看。Googlebot 还在抓哪些旧地址，哪些新地址一直没进抓取队列，这些都比“某个词今天第几名”更有诊断价值。
很多人把 301 当成终点。其实 301 更像缓冲带。Google 建议 旧地址的重定向尽量至少保留一年。从用户体验和历史链接角度，能保留更久通常更稳。
但另一边，站内链接不能长期依赖 301 过日子。导航、正文内链、面包屑、HTML sitemap、图片引用、下载链接、结构化数据里的 URL，都应该尽快改成新地址。否则站内一直在给爬虫和用户制造多一跳。
这件事和 锚文本优化指南、内链优化指南 直接相关。迁移稳定之后，第二批该做的不是“继续改版”，而是把内部路径彻底理顺。
重点不在重定向，而在 DNS、访问性、缓存、日志和 Googlebot 能否顺利抓到新基础设施。上线后要同时看新旧环境的流量和抓取。
重点在映射表、301/308 直达、模板保留主内容、静态资源不丢、站内链接同步改新。大部分掉量事故，都出在这类项目。
这是风险最高的一类。除了全站映射和永久重定向，还要准备 Search Console property、必要时使用 Change of Address，并长期保留旧域名上的跳转。
正常。迁移后出现波动很常见。关键不是有没有波动，而是新旧 URL 的替换、抓取和索引转移是不是在正常推进。
不应该。没有高度相关性的统一跳首页，容易被当成 soft 404。更稳的做法是一对一跳到最相关的新页面；没有对应内容，就返回合理的 404 或 410。
不用。少量关键页可以用 URL Inspection 请求重新抓取，大量 URL 还是更该靠 sitemap。Google 官方就是这么建议的。
不需要。只换 hosting 的项目，重点是访问性、DNS、缓存和抓取切换，不是重定向。
至少一年更稳。对老外链多、历史页面多的网站，保留更久通常更安全。
网站迁移 SEO 不是“上线前配几个 301”这么简单。它更像一条链。旧地址、映射表、重定向、资源文件、结构信号、Search Console、站内链接、上线监控，这几段只要断一段，过去积累的搜索信号就会漏。把链条接顺，迁移才稳。