重定向映射是迁移的真相来源：每个已知的公共 URL 在启动之前都会收到一个明确的、以证据为主导的决策。这可能是“将相同的 URL 保持在 200”、“永久移动到真正的替代品”、“返回真正的 404/410”或“保留进行调查”——单独记录实施和测试证据。
301 重定向映射：简短的答案
重定向映射是每个旧公共 URL 的迁移控制记录。这并不意味着每一行都会收到 301。每个 URL 都会收到基于证据的结果：保留相同的地址并返回 200、永久移动到真正的替代品、暂时留在其他地方、返回真正的 404 或 410，或者在发布前进行调查。地图还必须记录最终目的地、内容和元数据操作、所有者、测试结果和发布后证据。
| 决定 | HTTP 结果 | 当它是正确的时候 |
|---|---|---|
| 保留 | 200 | 首选公共 URL 和页面用途仍然有效 |
| 永久移动 | 301 / 308 | 新 URL 处存在真正的替换 |
| 暂时搬家 | 302 / 307 | 来源应保持为长期首选 URL |
| 删除 | 404 / 410 | 内容已消失且不存在相关替代内容 |
| 留置调查 | 尚未发布 | 所有权、替换、流量、链接、政策或状态不清楚 |
首先确定迁移类型
| 改变 | 公共 URL 会改变吗？ | 重定向映射角色 |
|---|---|---|
| 仅托管或 CDN 移动 | 否 | 记录状态奇偶性和遗留重定向保存；不要发明 URL 移动 |
| CMS、框架或设计变更 | 也许 | 尽可能保留现有路径；仅映射真正的更改 |
| HTTP 到 HTTPS 或主机名规范化 | 是，通过协议或主机 | 使用可预测的规则并验证每条有价值的路径都达到相同的最终资源 |
| 路径或信息架构变更 | 是的 | 在发布前制定明确的从旧到新的决策 |
| 域、子域、合并或拆分 | 是的 | 映射每个重要的 URL 并协调属性、链接、站点地图和监控 |
不要仅仅因为域名迁移、新 CMS、重新设计、新内容策略和不必要的 URL 清理合并在一起，因为它们共享启动日期。 Google 建议在可行的情况下一次更改一个主要维度。分离变更类型使故障更容易诊断和回滚。
冻结迁移范围和所有权
| 控制 | 需要做出决定 |
|---|---|
| 发射边界 | 包括域、子域、目录、区域设置、平台、资产和环境 |
| 真实来源文件 | 一张受控地图、唯一 URL 键、版本、日期、所有者和批准状态 |
| 变更控制 | Who can add, edit, approve, implement, test, or roll back a row |
| 释放门 | 更改重定向或 DNS 之前必须完成哪些工作 |
| 通讯 | Who receives launch notices, incidents, decisions, and evidence |
从多个来源构建旧 URL 库存
| 来源 | 它可以显示的 URL | 限制 |
|---|---|---|
| CMS或数据库导出 | 已发布、草稿、私有、附件、分类、自定义类型 | 可以省略由代码、插件或服务器创建的路由 |
| XML 站点地图 | 先前声明用于发现和索引的 URL | 可能已过时、不完整或仅包含首选 URL |
| 全爬行 | 链接页面、资产、状态代码、Canonicals、元数据、替代项 | 无法自行找到未链接或无法访问的 URL |
| 搜索控制台 | 已索引、已爬网、已链接、站点地图和效果 URL | 报告是抽样、延迟、分组的，而不是完整的清单 |
| 分析和转换系统 | 访问过的着陆页、营销活动、转化和历史旅程 | 未跟踪、阻止或零访问的 URL 将不存在 |
| 服务器和 CDN 日志 | 来自用户、机器人、应用程序和旧链接的真实请求 | 保留、机器人验证、隐私和访问各不相同 |
| 反向链接和提及工具 | 链接页面、媒体、PDF、旧营销活动 URL | 每个提供商都有不同且不完整的索引 |
| 广告、电子邮件、社交、QR、应用程序和业务资料 | 自然搜索库存之外的目的地 | 通常由不同的团队和帐户拥有 |
没有一个导出是完整的网站。合并来源，保留其出处，并调查分歧，而不是让最新的抓取覆盖历史。
在不丢失证据的情况下标准化 URL
- 准确存储发现的原始 URL。
- 分别解析方案、主机、端口、路径、查询、片段和编码。
- 使用记录的主机名、大小写、斜杠和参数规则创建标准化比较键。
- 保留片段以进行链接 QA，即使它们未在 HTTP 请求中发送。
- 在了解参数的功能、流量、链接、活动和重复行为之前，不要删除参数。
- 仅在保留所有源、性能、反向链接和所有权证据后进行重复数据删除。
使用决策就绪的重定向映射模式
| 现场组 | 必填栏目 |
|---|---|
| 身份 | 唯一行 ID、原始旧 URL、规范化旧 URL、源系统、页面类型、区域设置 |
| 证据 | 当前状态、可索引性、规范、流量、转化、反向链接、内部链接、所有者 |
| 决定 | 保留、重定向、删除、合并、调查；原因;批准人；批准日期 |
| 目的地 | 建议的 URL、预期状态、最终 URL、目标状态、目标规范、相关性证明 |
| 内容和搜索引擎优化 | 标题、描述、H1、内容、媒体、架构、hreflang、元数据、日期、内部链接操作 |
| 实施 | 规则所有者、平台、模式或显式规则、发布、依赖、回滚 |
| 测试 | 第一响应、跳跃、最终状态、最终规范、身体相关性、移动设备、区域设置、测试日期、测试人员 |
| 监控 | 启动响应、Google 选择的规范、点击、错误、日志活动、事件、下一次审核 |
将决策与实施状态分开
| 尺寸 | 示例值 | 为什么要分开 |
|---|---|---|
| 批准的结果 | 保留、重定向、删除、保留 | 代表业务和 SEO 决策 |
| 实施状态 | 未启动、已构建、已分阶段、正在运行、已回滚 | 显示实际发生的情况 |
| 测试结果 | 未测试、通过、失败、阻止 | 防止“已配置”被误认为“正在运行” |
| 发布后状态 | 健康、关注、事件、解决 | 保留监控和事件历史记录 |
优先考虑风险而不删除长尾
| 优先证据 | 为什么这很重要 |
|---|---|
| 收入、合格潜在客户或辅助转化 | 保护商业上有用的旅程 |
| 搜索点击次数、展示次数和索引历史记录 | 确定已建立的有机切入点 |
| 相关外部链接和推荐流量 | 保护来自站点外部的发现、信任和访问 |
| 导航、内部链接和营销活动依赖 | 揭示重要旅程中嵌入的 URL |
| 法律、支持、帐户、结账或产品功能 | 低流量 URL 在操作上可能仍然至关重要 |
| 未知但重复请求的旧 URL | 日志可能会揭示当前报告遗漏的价值 |
优先级决定审核顺序和监控深度，而不是 URL 是否值得做出决定。每个已知的公共 URL 仍然需要明确的结果。
尽可能保持有价值的 URL 不变
重新设计不需要新的段头。如果受众任务、首选地址、语言和所有权仍然有效，请保留 URL 并记录 200 保留。然后通过中的控件来比较新旧页面 规范 URL 和重定向 和 SEO网站架构.
- HTTP 状态、可索引性、首选主机名和自规范。
- 标题、描述、H1、主要内容、媒体、日期和结构化数据。
- 内部链接、面包屑、分页、相关内容和导航。
- Hreflang、语言切换器、Open Graph、提要、站点地图和 API 参考。
- 表单、转换、同意、分析、广告和第三方集成。
仅对真正的替换使用永久重定向
| 更换测试 | 问题 |
|---|---|
| 观众 | 同一个访客是否会合理地想要该目的地？ |
| 任务和意图 | 它是否完成相同的工作或提供最接近的完整替代品？ |
| 主题和范围 | 它是否涵盖了基本主题、产品、服务、位置或政策？ |
| 语言和市场 | 它是否适合相同的区域设置和商业可用性？ |
| 证据和下一步行动 | 用户可以验证相同的声明并继续旅程吗？ |
类似的关键字是不够的。在地图中记录简短的相关性说明，以便审批者可以在编写代码之前质疑弱匹配。
仅当一个目的地可以拥有合并任务时才进行合并
| 整合格局 | 安全时 | 不安全时 |
|---|---|---|
| 一份指南中有几篇重叠的文章 | 该指南保留了有用的问题、证据和内部旅程 | 目标是通用类别或失去独特价值 |
| 重新设计的服务所有者的旧服务页面 | 优惠、受众、地点和下一步行动保持不变 | 不同的服务被迫进行广泛的概述 |
| 遗留类别到维护的中心 | 该中心真正帮助用户发现迁移的资源 | 集线器为空、无索引或不相关 |
谨慎选择永久和临时状态代码
| 代码 | 对于迁移的意义 | 使用 |
|---|---|---|
301 | 永久搬家 | 大多数永久 URL 移动的首选服务器端选择 |
308 | 永久移动，同时保留请求方法 | 在平台行为和非 GET 请求需要时有用 |
302 | 发现；临时搬家 | 来源应保持为长期首选 URL |
307 | 临时移动，同时保留请求方法 | 请求方法处理很重要的临时路由 |
Google 将服务器端 301 和 308 视为永久重定向信号。仅当源确实保留为预期的长期 URL 时才使用临时重定向。不要为了追求假定的排名优势而切换代码。
当没有任何内容替换页面时，使用真正的 404 或 410 响应
| 结果 | 正确情况 | 用户体验 |
|---|---|---|
404 未找到 | 资源不可用且不存在相关替代 | 具有真实 404 状态的品牌有用错误页面 |
410 走了 | 所有者故意删除资源并希望声明它已消失 | 清晰的解释和有用的导航以及真实的 410 状态 |
| 相关301 | 替代品真正满足相同的用户需求 | 立即到达最终有用目的地 |
当内容被删除并且不存在类似的替代品时，Google 建议使用 404 或 410。自定义错误设计可能包含有用的导航，但服务器响应仍必须传达失败信息。返回 200 的友好页面是软 404，不是成功的迁移。
不要将每个已停用的 URL 都发送到主页
| 旧网址 | 更好的决定 |
|---|---|
| 旧的“关于”页面 | Redirect to the current About page if it is the true replacement |
| 已停产的产品，有直接的后续产品 | 仅当继任者真正满足相同需求时才重定向；解释这一变化 |
| 具有常青活动中心的过期活动 | 当集线器保留预期任务时保留存档或重定向 |
| 已删除文章且没有有用的替代品 | 返回 404 或 410，而不是不相关的主页重定向 |
仅当转换可证明一致时才使用模式
| 规则类型 | 适用案例 | 控制 |
|---|---|---|
| 精确的一对一规则 | 高价值、异常、合并、重命名或不规则 URL | 地图中明确的源和最终目标 |
| 图案规则 | 稳定的转换，例如旧主机到新主机且路径不变 | 发布前枚举匹配的 URL 并测试排除 |
| 后备规则 | 很少有道理 | 切勿让它隐藏未映射的 URL 或创建主页软 404 |
- 列出该规则将匹配的所有已知 URL。
- 列出受保护的例外和更高优先级的确切规则。
- 测试编码字符、大写字母、尾部斜杠、参数、文件和区域设置路径。
- 证明生成的目标存在并且与每个匹配的源相关。
- 防止规则将目标重定向回其自身。
直接重定向至最终目的地
| 失败 | 示例 | 修正 |
|---|---|---|
| 链条 | A → B → C | A → C |
| 协议和主链 | http → https → www → 最终 | 当平台安全支持时结合标准化 |
| 循环 | A → B → A | 修复规则优先级并排除最终目标 |
| 重定向到错误 | A → B (404) | 修复或选择有效的相关目的地 |
| 重定向到另一个重定向参数变体 | A → B?x=1 → B | 除非需要参数，否则指向最终的规范 URL |
Googlebot 可以遵循重定向链，但 Google 建议直接指向最终目的地，并将不可避免的链保持在较低水平。每一个额外的跃点都会增加用户、爬虫、活动、应用程序和分析的延迟和另一个故障点。
显式处理协议、主机、端口、斜杠、文件和参数
| 网址维度 | 迁移决定 |
|---|---|
| HTTP 和 HTTPS | 选择安全的首选版本并在重定向主机上保留证书 |
| www 和非 www | 选择一个公共主机并将每条路径直接发送到其等效主机 |
| 默认端口和暂存主机 | 让它们远离公共规范、链接、站点地图和索引 |
| 尾部斜杠和index.html | 选择一个最终会议；避免为每个请求创建链 |
| 大小写和编码 | 根据服务器行为和真实 URL 所有权保留或规范化 |
| 查询参数 | 保留所需的功能和活动数据；仅在有证据的情况下删除重复或过时的参数 |
| 图片、PDF 和下载 | 将重要的索引或链接资产映射到实际替换资产 |
一起更新所有标准化信号
- 旧 URL 将批准的永久重定向直接返回到最终 URL。
- 最终URL返回200，没有被屏蔽或者noindex。
- 最后一页有一个使用首选协议、主机、路径和区域设置的自引用 Canonical。
- 内部链接、面包屑、导航和提要使用最终 URL。
- 当前站点地图列出了最终的可索引 URL，而不是重定向源。
- 结构化数据、开放图谱、API 参考和活动目标使用预期的最终 URL。
将多语言映射重建为完整的集群
当语言集群中的任何 URL 发生更改时，请为每个成员更新自规范、相互的 hreflang、语言切换器、内部链接和站点地图替换。切勿仅仅因为缺少翻译而将马来语或中文页面重定向到英文。使用区域设置控件 马来西亚多语言 SEO.
保留内容和元数据，而不仅仅是地址
| 图层 | 批准前比较 |
|---|---|
| 目的和可见内容 | 受众任务、主要答案、服务或产品范围、证明、常见问题解答、CTA |
| 搜索演示 | 标题、描述、H1、图像、发布和修改日期 |
| 指标控制 | 状态、机器人、Canonical、hreflang、分页、站点地图包含 |
| 含义和实体 | 结构化数据、作者、组织、产品、服务、位置、标识符 |
| 媒体和文件 | 图片 URL、替代文本、说明文字、视频、PDF、下载、所有权和权利 |
| 旅程和测量 | 内部链接、表格、WhatsApp、电话、结帐、同意、分析和事件 |
保护暂存而不将块复制到生产环境
| 分段控制 | 发射风险 |
|---|---|
| 身份验证或网络限制 | 可以屏蔽外部QA工具；生产不能继承它 |
| 测试页上没有索引 | 必须从可转位生产模板中删除 |
| 禁止暂存 robots.txt | 机器人阻塞可防止爬虫看到页面级 noindex，并且不得取代生产规则 |
| 临时主机名 | 启动后不得出现在 Canonicals、hreflang、结构化数据、提要或站点地图中 |
测试每个重定向的两个视图
| 测试视图 | 它证明了什么 |
|---|---|
| 不遵循重定向 | The first response has the expected status and Location header |
| 跟随完整的旅程 | 目的地、跳数、最终状态、规范、语言、内容和功能正确 |
- Request the exact old URL without automatically following.
- 将实际的第一个状态和位置与批准的行进行比较。
- 遵循有界跳数限制并检测环路。
- 确认最终 URL、状态、内容类型、区域设置、Canonical、机器人和有意义的正文。
- 存储时间戳、环境、测试人员或脚本版本以及证据。
- 在循环、意外链、不相关的目标、5xx 或阻塞的关键页面上释放失败。
运行代表性旅程测试，而不是单独进行状态检查
| 旅程 | 要验证什么 |
|---|---|
| 搜索登陆页面 | 旧结果到达正确的最后一页、答案、语言和 CTA |
| 导航和面包屑 | 没有链接依赖于重定向，层次结构保持一致 |
| 表格、WhatsApp、电话、预订或结账 | 转换工作和源/活动/语言上下文被保留 |
| 图像、PDF、提要、应用程序和 API 使用者 | 资产解析，内容类型正确，客户端不会中断 |
| 404并删除内容 | 真实的错误状态，有帮助的界面，没有意外的可转位软 404 |
根据风险和规模选择推出策略
| 情况 | 实用方法 |
|---|---|
| 中小型场地，一举一动 | Google 通常建议在完成准备后将 URL 一起移动 |
| 场地非常大或运营风险高 | 试点一个稳定的部分，学习，然后在受控组中推广 |
| 托管迁移且 URL 没有明显更改 | 重点关注基础设施奇偶性、抓取访问、容量、TLS、DNS 和旧版重定向 |
| 需要域名迁移和重新设计 | 尽可能单独进行更改，以便搜索和事件信号可以解释 |
仅将地址变更用于符合条件的域名迁移
| 移动 | 使用 Search Console 更改地址？ |
|---|---|
| example.com 到 example.net | 是的，重定向和验证准备就绪后 |
| a.example.com 到 b.example.com | 是的，对于已验证的域/子域移动 |
| 仅 HTTP 至 HTTPS | 否 |
| 同一域中的 www 到非 www | 否 |
| 在同一域内移动路径 | 否 |
| 托管或 CDN 更改而无需更改公共 URL | 否 |
使用同一帐户验证相关的旧属性和新属性，保留验证文件或标签，并在域移动之前检查手动操作、删除、设置和旧控件。该工具补充了正确的重定向；它不会取代它们。
使用受控的启动顺序
- 冻结批准的地图、备份配置和内容，并指定发布所有者。
- 部署最终页面、资产、证书、机器人规则、分析和验证控制。
- 从生产输出中删除仅暂存的 noindex、访问块和临时主机。
- 启用批准的重定向并立即运行自动旧 URL 列表。
- 验证关键旅程、最终 Canonicals、hreflang、结构化数据、内部链接和站点地图。
- 提交或更新站点地图；仅当搬迁符合条件时才使用地址变更。
- 记录发布时间、证据、已知异常和回滚决策窗口。
启动后监控新旧 URL
| 窗户 | 主要检查 |
|---|---|
| 最初的分钟和小时 | 可用性、TLS、DNS、5xx、循环、密钥重定向、表单、分析、机器人、noindex |
| 第一天 | 完整映射列表重新爬网、日志、404/410、意外链、站点地图处理、URL 检查示例 |
| 第一周 | 新旧 Search Console 覆盖范围和性能、选定的 Canonicals、流量、转化、反向链接和推荐错误 |
| 接下来的几个月 | 信号传输、挥之不去的旧 URL、季节性比较、内容质量、重定向需求、域名和证书续订 |
当 Google 重新抓取和处理移动时，可能会出现暂时的可见性波动。这并不能证明忽略错误或承诺恢复日期是合理的。按页面组进行细分，并分别诊断技术、内容、需求、跟踪和业务变更。
在启动前定义事件触发器和回滚边界
| 事件信号 | 立即响应 |
|---|---|
| 关键页面返回 5xx、循环、块或 noindex | 停止发布路径，恢复访问或最后一次已知的正确配置，然后重新测试 |
| 大量未映射或不相关的重定向队列 | 禁用错误规则，保留确切的例外，更正地图并重新部署 |
| 跟踪或转换失败 | 先恢复客户路径；标记报告差距并避免错误的绩效结论 |
| 谷歌选择了意想不到的 Canonicals | 将状态、内容、内部链接、站点地图、重定向、区域设置和 Canonical 信号作为一个系统进行比较 |
根据正常错误率、流量、转化量和关键旅程使用特定于业务的阈值。没有普遍的百分比下降证明迁移失败。
保持重定向足够长的时间并维护旧的基础设施
Google 建议尽可能长时间地保留网站移动重定向，通常至少一年，以便在重新抓取 URL 时可以重新分配信号和链接。从用户的角度来看，有用的重定向可能值得无限期保留。在请求仍然到达时保持旧域、DNS、证书和重定向托管运行，并更新内部和高控制外部链接以减少对重定向的依赖。
经过验证的 SEOWithJack 迁移示例
SEOWithJack WordPress 到静态的迁移使用 53 行状态图，而不是一揽子重定向规则。当前的自动保存审核验证了 27 个原始文章 URL：26 个在其原始路径上保持匹配，一个旧的 SEO URL 永久重定向到其综合初学者指南。它还保留源 Rank Math 证据，测试 301、404 和 410 决策，并将生产 DNS 保留在迁移步骤之外，直到暂存和主机检查获得批准。
| 验证控制 | 目前的证据 |
|---|---|
| 重定向映射行 | 53 |
| 保留原始文章 URL | 27 |
| 原创文章路径直接匹配 | 26 |
| 通过永久重定向整合原始文章 | 1 |
| 生产 DNS 因构建而更改 | 否 |
您可以复制的紧凑行模板
| 旧网址 | 决定 | 目的地 | 为什么 | 预计 | 实际 | 业主 |
|---|---|---|---|---|---|---|
| /old-service/ | 重定向 | /services/current/ | 相同的服务和受众任务 | 301 → 200 | 待测试 | 搜索引擎优化+开发 |
| /useful-guide/ | 保持 | /useful-guide/ | 稳定的首选 URL | 200 | 等待奇偶校验 | 内容 |
| /obsolete-no-replacement/ | 删除 | — | 没有有用的替代品 | 410 | 待测试 | 内容营销 |
| /unknown-legacy/ | 保持 | — | 需要日志和反向链接审查 | 没有发布 | 打开 | 需要业主 |
最终释放门
- 每个已知的公共旧 URL 都有一个已批准的结果或明确的阻止状态。
- 所有永久重定向都直接指向相关的最终 200 个 URL。
- 删除的页面返回真实的 404 或 410 状态，而不是主页或软 404 响应。
- Canonical、机器人、hreflang、链接、站点地图、模式、元数据、媒体和转换通过比较。
- 登台控制不能泄漏到生产中，生产主机也不能泄漏到登台证据中。
- 自动列表测试和代表性用户旅程在发布环境中通过。
- 监控、事件所有权、备份和回滚决策已准备就绪。
重定向映射不能保证什么
完整的地图不能保证排名、流量、索引速度、转化率或固定的恢复日期不变。 Google 处理每个 URL 的移动，暂时的波动是正常的。重定向是一种规范化信号；内容、内部链接、抓取访问、站点地图、站点质量、需求、竞争、平台行为和业务运营仍然很重要。负责任的承诺是受控实施、经过验证的证据、快速诊断和记录在案的决策。
301 重定向地图常见问题解答
每个旧网址都需要 301 吗？
不。每个已知的公共 URL 都需要一个决定，不一定是重定向。将有效 URL 保持在 200，重定向真实的动作，在不存在相关替换时返回 404 或 410，并保留不清楚的情况进行调查。
301和308都是永久的吗？
是的。谷歌将两者视为永久重定向信号。 308 还保留请求方法。根据平台和应用程序要求进行选择，而不是排名神话。
删除的页面应该重定向到主页吗？
只有在极少数情况下，主页才真正取代了相同的任务。谷歌警告称，将许多不相关的旧 URL 重定向到一个页面可能会让用户感到困惑，并可能被视为软 404。使用相关替代品或真正的 404/410。
404 比不相关的 301 更糟糕吗？
不会。当不存在有用的替代品时，真正的 404 或 410 才是诚实的技术成果。不相关的重定向会损害用户旅程，并且可以被解释为软 404。
我应该在重新设计期间更改 URL 吗？
除非现有地址或架构存在真正的用户、业务、安全或维护问题。保留有效的 URL 可以消除迁移风险，并使重新设计专注于体验。
我可以使用 JavaScript 创建重定向吗？
Google 可以处理一些客户端重定向，但建议尽可能使用服务器端永久重定向。 JavaScript 添加了渲染和失败依赖项，应该作为后备方法，而不是默认的迁移方法。
可接受多少重定向跃点？
设计目标之一：旧 URL 直接指向最终目的地。谷歌可以跟踪链条并建议将不可避免的链条保持在较低水平，但爬虫限制并不是性能目标。
重定向应该保留多长时间？
Google 建议尽可能长时间地保留网站移动重定向，通常至少一年。当人们、机器人、链接、活动或应用程序仍然请求旧 URL 时，将有用的重定向保留更长时间。
我什么时候应该使用 Search Console 地址更改？
在重定向准备好从一个域或子域到另一个域或子域的合格移动后使用它。请勿将其用于 HTTP 到 HTTPS、www 规范化、同域路径更改或公共 URL 未更改的托管移动。
我如何知道迁移已完成？
没有单一的瞬间。确认旧请求达到批准的结果，最终页面正常且选择适当，Search Console 和日志显示预期传输，关键旅程转换，事件得到解决，并且重定向基础设施保持不变。
官方参考资料
- 谷歌：网站随着网址的变化而移动
- Google：在不更改 URL 的情况下更改托管
- Google：重定向和搜索
- Google：解决抓取错误和软 404 问题
- Google：规范 URL 最佳实践
- Google：URL 结构最佳实践
- Google：构建并提交 XML 站点地图
- 谷歌：要求谷歌重新抓取网址
- 谷歌：机器人元标记规范
- Google Search Console：地址更改
- Ahrefs：网站迁移指南
- Ahrefs：SEO 重定向
- Backlinko：网站迁移 SEO 清单
- Semrush：网站迁移清单
在 URL 更改之前共享旧网站和建议的结构。启动前的重定向规划比流量开始下降后更容易。