SEO 域名迁移前期准备有哪些?「少输便是赢」的完整攻略
域名迁移最坑的不是技术。
是那些你以为”做完了”但其实没做的环节。
301 重定向配了,sitemap 提交了,Change of Address 也点了。看起来一切正常。
然后流量开始跌。
域名迁移的本质 :不是一个技术操作,是一个持续一年的项目管理工程。准备阶段占 90% 工作量,迁移当天只占 5%。如果你觉得迁移当天是手忙脚乱的,说明准备不足—— 迁移当天应该是无聊的才对 。
这篇文章给出完整框架。读完后你会知道:什么情况该迁移、怎么判断是否正常恢复、哪里容易踩坑。
一、先想清楚:该不该迁移?
域名迁移是 不对称赌注 。
上行空间有限(最好的情况是流量不变),下行空间无限(流量永久丢失,品牌认知断裂)。在没有明确收益的前提下,完全不建议执行迁移操作。
判断标准
| 情况 | 该不该迁移 | 判断依据 |
|---|---|---|
| 品牌重塑已确定 | 该迁移 | 新品牌名搜索排名第 1,AI 正确识别 |
| ccTLD 限制国际可见度 | 该迁移 | .co.uk 对全球搜索不友好 |
| 合并竞争域名 | 该迁移 | 多域名互相蚕食流量 |
| ”域名看起来更好” | 不迁移 | 主观判断,无数据支撑 |
| ”竞争对手换了” | 不迁移 | 盲目跟风 |
| ”品牌升级”但搜索不认 | 不迁移 | 流量会丢 |
核心判断方法 :搜索新品牌名,排名第 1 是否是你?如果不是,迁移后用户搜品牌名会找到竞争对手。
AI 时代的新检查项
ChatGPT、Claude、Perplexity 已经是重要流量来源。迁移前必须测试:在 AI 搜索中问”XX品牌是什么”,看回答是否正确描述你的品牌。
为什么重要 :AI 模型的训练数据有”记忆”。如果你的旧域名在训练数据中出现多次,模型会记住旧域名。迁移后,AI 推荐流量可能持续丢失。
解决方案 (提前 3-6 个月准备):
| 动作 | 目的 |
|---|---|
| Wikipedia 页面更新 | AI 训练数据主要来源 |
| Organization schema 绑定新域名 | 结构化数据识别品牌-域名关系 |
| 新闻报道绑定新名称 + 新域名 | 外部引用强化关联 |
二、四阶段框架:把迁移项目化
一次完整的域名迁移 :
| 阶段 | 核心任务 | 工作占比 |
|---|---|---|
| 决策 | 判断是否迁移、指定负责人 | 5% |
| 准备 | 审计、清理、映射、测试 | 90% |
| 迁移 | 执行重定向和 DNS 切换 | 5% |
| 后迁移 | 12 个月监控 | 持续 |
核心认知 :域名迁移不难,但繁琐—— 繁琐到惩罚每一个跳过的步骤 。失败通常不是因为技术问题,是因为准备阶段的某个环节被跳过了。
指定直接负责人
迁移涉及项目管理、技术 SEO、工程三个领域。没有单一负责人的迁移,不会在当天失败——会在 6 个月后发现某个子域名从未重定向。
分工参考 :
| 角色 | 职责 |
|---|---|
| 项目负责人 | 时间表、回滚决策、DNS 切换时机 |
| 技术 SEO | canonical、sitemap、Change of Address |
| 工程/开发 | 重定向配置、第三方集成 |
三、准备阶段:90% 工作量
这是决定成败的阶段。按照清单执行,不要跳过任何步骤。
3.1 审计当前状态
爬取比站点地图重要 ——站点地图是你认为重要的,爬取日志是真实被访问的。
| 审计任务 | 工具 | 输出 |
|---|---|---|
| 全站爬取 | Screaming Frog | 所有 URL、状态码、标题、canonical |
| Search Console 数据 | GSC 导出 | 16 个月点击/展示、排名查询词 |
| 服务器爬取日志 | 日志分析工具 | 真实被爬取的 URL |
| 子域名检查 | DNS 配置检查 | 所有解析的子域名 |
判断标准 :爬取日志 URL 数 > 站点地图 URL 数 = 正常。如果只映射站点地图,其余 URL 会 404。
3.2 审计新域名历史
购买而非注册的新域名,必须检查历史问题:
| 问题类型 | 检查方法 | 处理方式 |
|---|---|---|
| Search Console 人工处罚 | 查看”人工处罚”报告 | 提交复议或放弃 |
| 历史 disavow 文件 | 检查是否有上传 | 重新审核外链 |
| 垃圾外链 | Ahrefs/SEMrush | 加入 disavow |
3.3 构建 URL 映射表
错误做法 :通配符重定向所有旧 URL 到首页。
为什么错误?Google 判断为”软 404”——用户点击链接期待具体内容,落地却是首页。权重不传递,流量永久丢失。
正确做法 :逐页映射。多语言站点需同步更新 hreflang 配置——旧域名的 hreflang 标签指向新域名对应语言版本,否则多语言索引混乱。
AI 辅助 URL 映射 (大规模站点的实用技巧):
对于数千 URL 的站点,手动映射不现实。用 LLM 处理模糊匹配:
Prompt 示例:旧 URL: /blog/2021/03/15/how-to-improve-seo新 URL 候选: /articles/seo-guide /blog/seo-tips-2024 /guides/search-optimization
任务:根据语义相似度选择最匹配的新 URLLLM 擅长处理标题相似、路径结构变化的模糊匹配。人工审核 LLM 输出,效率提升 5-10 倍。
映射表字段 :
| 字段 | 说明 |
|---|---|
| 旧 URL | 从爬取日志导出 |
| 新 URL | 对应的新域名页面 |
| 重定向类型 | 301(永久)或 302(临时) |
| 状态 | 待映射/已映射/已验证 |
3.4 Redirect-By Header:调试利器
迁移后排查重定向问题时,这个技术技巧能节省大量时间:
在重定向响应中添加自定义 header:
HTTP/1.1 301 Moved PermanentlyLocation: https://newdomain.com/pageRedirect-By: migration-2024-05作用 :
- 快速确认重定向来自迁移配置
- 排查 CDN/Nginx/Apache 多层重定向链
- 区分历史重定向和迁移重定向
实现方式:
| 服务器 | 配置示例 |
|---|---|
| Nginx | add_header Redirect-By "migration-2024-05"; |
| Apache | Header always set Redirect-By "migration-2024-05" |
| Cloudflare | Page Rules → Add Header |
3.5 非 Web 部分的迁移清单
很多人只迁移网站,忘了这些:
| 组件 | 检查项 | 遗漏后果 |
|---|---|---|
| API 端点 | 回调地址、webhook 配置 | 第三方集成失效 |
| OAuth 回调 | Google/Facebook/GitHub 登录 | 用户无法登录 |
| CORS 配置 | 允许域名列表 | 前端请求被阻止 |
| Cookies | domain 属性 | 登录态丢失 |
| Package registries | npm/GitHub Packages 配置 | CI/CD 失败 |
| 移动 App SDK | API 域名配置 | App 功能失效 |
判断标准 :搜索代码库中的旧域名,逐项检查配置位置。
3.6 站点速度优化
迁移期间爬取压力会激增。Googlebot 和 Bingbot 会高强度爬取新域名。
为什么要优化 :
- 爬取预算有限,响应慢 = 爬取少 = 索引慢
- 用户访问变慢 = 跳出率升高 = 排名下降
优化清单 :
| 项目 | 措施 |
|---|---|
| 服务器响应时间 | 迁移前扩容或优化后端 |
| CDN 配置 | 确保新域名 CDN 生效 |
| 静态资源缓存 | 缓存策略正确配置 |
| 数据库查询 | 爬取高峰期的慢查询优化 |
判断标准 :迁移前用 PageSpeed Insights 测试新域名,Core Web Vitals 通过。
3.7 测试所有环节
迁移前必须测试——不是点几个页面看看,是用爬虫工具全站测试。
| 测试项 | 工具 | 判断标准 |
|---|---|---|
| 重定向链完整性 | Screaming Frog | 成功率 ≥ 95% |
| canonical 正确性 | Screaming Frog | 不指向旧域名 |
| 内链无断裂 | Screaming Frog | 无 404 |
| OAuth/第三方回调 | 手动测试 | 登录、支付正常 |
判断标准 :重定向成功率低于 95% = 不要迁移。CDN 边缘节点(Cloudflare/CloudFront)缓存可能残留旧域名规则,需清理后再测试。
3.8 团队协作时间线
如果你不是一个人在战斗,沟通时间表决定迁移顺畅度:
| 时间节点 | 沟通对象 | 沟通内容 |
|---|---|---|
| T-6 周 | 技术团队 | 迁移计划、重定向配置工作量 |
| T-4 周 | 市场/运营 | 品牌物料更新时间表 |
| T-2 周 | 客服/销售 | FAQ、客户通知模板 |
| T-1 周 | 全员 | 迁移窗口确认、紧急联系人 |
| T+1 天 | 客户/用户 | 正式通知(邮件、公告) |
| T+1 月 | 全员 | 恢复进度报告 |
四、迁移当天:操作顺序很重要
4.1 DNS TTL 降低
迁移前 48 小时,将旧域名 DNS TTL 降低到 300-600 秒。
为什么 :DNS 缓存最长可达 TTL 值。TTL 过长 = 切换后部分用户仍访问旧服务器 = 流量丢失。
操作 :
| 时间 | 操作 |
|---|---|
| T-48h | TTL 从默认值(通常 3600-86400)降到 300 |
| T-0 | DNS 切换到新服务器 |
| T+48h | TTL 恢复正常值 |
4.2 robots.txt 特别规则
新域名 robots.txt:允许爬取(不要先禁止再开放,容易被误判)。
旧域名 robots.txt :迁移后必须 清空或返回 404 。
为什么 :如果旧域名 robots.txt 仍存在且包含 Disallow: /,Google 会停止爬取旧域名,重定向链断裂。
正确做法 :
旧域名迁移后 robots.txt:# 选项 1:返回 404# 选项 2:空文件(无任何内容)# 错误:Disallow: / ← 这会阻止爬取4.3 操作顺序
顺序错误会导致索引混乱:
- 新域名服务器部署完成
- robots.txt 设为允许爬取
- DNS 切换(TTL 已提前降低)
- Search Console 提交 Change of Address
- 提交新 sitemap
- 实时监控日志
加速索引技巧 :sitemap 添加 lastmod 标记迁移日期,搜索引擎会优先爬取标记更新的页面。
4.4 实时监控
| 监控项 | 工具 | 判断标准 |
|---|---|---|
| 重定向成功率 | 服务器日志 | ≥ 95% |
| 404 错误数量 | GSC 实时报告 | 不激增 |
| 爬取日志 | GSC 爬取统计 | 正常爬取 |
| 用户访问异常 | GA | 无异常跳出 |
判断标准 :重定向成功率 < 95%,立即排查或回滚。
4.5 不要放弃旧域名
旧域名至少保留 1-2 年(Google 官方建议),理想情况更长:
| 保留项 | 原因 |
|---|---|
| DNS 记录 | 重定向链起点 |
| SSL 证书 | HTTPS 重定向需要 |
| 重定向服务 | inbound links 持续生效 |
判断标准 :放弃旧域名 = 所有外链断裂 = 流量永久丢失。
五、迁移后监控:持续 12 个月
5.1 正常恢复周期
Google 官方数据 :迁移后流量损失 30-40%,恢复周期 6-12 个月。
| 时间节点 | 正常表现 | 有问题的信号 |
|---|---|---|
| 第 1 周 | 流量跌 30-40% | 跌幅 > 50%,重定向成功率 < 95% |
| 第 2-4 周 | 新域名索引数接近旧域名 | 索引停滞,大量 404 |
| 第 2-6 个月 | 核心词排名逐步恢复 | 核心词消失,流量持续下跌 |
| 第 6-12 个月 | 流量回到基准线 | 流量仍 < 迁移前 50% |
超过 6 个月未恢复 = 有问题 。排查重定向链、canonical 配置、新域名历史。
5.2 异常处理
| 异常信号 | 可能原因 | 处理方法 |
|---|---|---|
| 索引数停滞 | robots.txt 阻止、sitemap 未提交 | 检查配置 |
| 核心词排名消失 | canonical 冲突、内容差异 | 对比新旧内容 |
| 流量持续下跌 | 重定向链断裂、外链丢失 | 检查重定向 |
| 404 激增 | URL 映射遗漏 | 补充映射 |
六、不要打包其他变更
Google 官方建议 :一次改一个变量。
| 打包操作 | 问题 |
|---|---|
| 品牌重塑 + 域名迁移 | 搜索引擎信任重建周期加倍 |
| 域名迁移 + 平台迁移 | 技术问题难以定位 |
| 域名迁移 + URL 结构重组 | 映射表复杂度指数增加 |
判断标准 :如果必须打包,每个变量独立测试。不确定 = 分步执行。
七、一页检查清单
迁移前打印这张清单,逐项确认:
决策阶段 :
- 迁移收益明确(品牌重塑/国际化/合并域名)
- 新品牌搜索排名第 1
- AI 搜索正确识别新品牌
- 指定直接负责人
准备阶段 :
- 全站爬取完成(Screaming Frog/Sitebulb)
- Search Console 数据导出(16 个月)
- 新域名历史审计(无处罚)
- URL 映射表完成(逐页映射)
- AI 辅助映射已人工审核
- 重定向配置测试通过(成功率 ≥ 95%)
- Redirect-By Header 已配置
- 非 Web 组件清单已检查(API/OAuth/CORS)
- 站点速度优化完成
- 回滚方案已测试
- 利益相关者已通知
迁移当天 :
- DNS TTL 已提前降低
- 新域名 robots.txt 允许爬取
- DNS 切换完成
- Change of Address 已提交
- 新 sitemap 已提交
- 实时监控就绪
迁移后 :
- 旧域名重定向服务保持运行
- 旧域名 robots.txt 已清空或 404
- 第 1 周监控报告
- 第 1 月恢复进度报告
- 6-12 个月持续监控
总结
域名迁移的核心原则:
| 原则 | 判断依据 |
|---|---|
| 不对称赌注 | 没有明确收益就不迁移 |
| 准备优先 | 90% 工作量在准备,迁移当天应该无聊 |
| 项目化执行 | 指定负责人、时间表、测试流程、回滚方案 |
| AI 时代新要求 | 检查 AI 搜索对品牌的认知 |
| 不打包 | 一次改一个变量 |
记住两句话:
AI 模型没有 Change of Address 工具。 训练数据有记忆,迁移前必须预先影响训练数据。
域名迁移不难,但繁琐到惩罚每一个跳过的步骤。 失败不是因为技术问题,是因为准备阶段的某个环节被跳过了。
常见问题
Q:什么情况下应该做域名迁移?
A:三种情况建议迁移:品牌重塑已确定(新品牌搜索排名第1)、ccTLD 限制国际可见度(如 .co.uk 对全球不友好)、合并竞争域名。主观判断如”域名看起来更好”、“竞争对手换了”不建议迁移——域名迁移是不对称赌注,上行有限下行无限。
Q:迁移当天的正确操作顺序是什么?
A:新域名服务器部署完成 → robots.txt 设为允许爬取 → DNS 切换(TTL 已提前降低)→ Search Console 提交 Change of Address → 提交新 sitemap → 实时监控日志。顺序错误会导致索引混乱。DNS TTL 需提前 48 小时降到 300 秒,切换后 48 小时恢复正常。
Q:域名迁移后流量恢复要多久?
A:根据 Google 官方数据,迁移后流量损失 30-40%,恢复周期 6-12 个月 。第1周流量跌 30-40% 正常,第2-4周新域名索引数接近旧域名,第2-6个月核心词排名逐步恢复。超过 6 个月流量仍 < 迁移前 50% = 有问题。
Q:旧域名迁移后还要保留吗?
A:Google 官方建议 至少保留 1-2 年 ,理想情况更长。放弃旧域名 = 所有外链断裂 = 流量永久丢失。旧域名是重定向链的起点,没有它,所有 inbound links 失效。DNS 记录、SSL 证书、重定向服务必须持续维持。
Q:域名迁移对 AI 搜索有什么影响?
A:AI 模型训练数据有”记忆”,旧域名在训练数据中出现多次会被记住。迁移后 AI 推荐流量可能持续丢失——AI 模型没有 Change of Address 工具。提前 3-6 个月准备:更新 Wikipedia 页面、Organization schema 绑定新域名、新闻报道绑定新名称+新域名。
参考来源 :
- Google 网站迁移指南
- Google Change of Address 工具
- Google 论坛:旧域名重定向保留时长 Product Expert 建议至少 1-2 年
- Screaming Frog SEO Spider
- Google 爬取统计报告
支持与分享
如果这篇文章对你有帮助,欢迎分享给更多人或赞助支持!