完整 301 Redirect Map 指南

Redirect Map 是迁移时的唯一依据：每个已知公开 URL 都要在上线前得到一个有证据的明确决定。结果可能是“原 URL 保持 200”、“永久迁移到真正替代页面”、“返回真实 404／410”，或“暂停并继续调查”；实施状态与测试证据则分开记录。

301 Redirect Map：先说结论

Redirect Map 是每个旧公开 URL 的迁移控制记录，并不代表每一行都要做 301。每个 URL 都应根据证据得到明确结果：保留原地址并返回 200、永久迁移到真正替代页面、临时转向其他位置、返回真实 404／410，或在上线前继续调查。表格还要记录最终目标、内容与元数据处理、负责人、测试结果及上线后证据。

决定	HTTP 结果	何时正确
保留	`200`	首选公开 URL 与页面目的仍然有效
永久迁移	`301` / `308`	新 URL 存在真正替代页面
临时迁移	`302` / `307`	源 URL 仍应作为长期首选
移除	`404` / `410`	内容已消失且没有相关替代页面
待调查	暂不发布	归属、替代页面、流量、外链、政策或状态不清楚

先识别迁移类型

变化	公开 URL 是否变化？	Redirect Map 的作用
仅更换主机或 CDN	否	记录状态一致性与旧 Redirect 保留情况，不要虚构 URL 迁移
更换 CMS、框架或设计	可能	尽可能保留现有路径，只映射真正变化
HTTP 转 HTTPS 或主机名统一	是，协议或主机变化	使用可预测规则，并验证每个重要路径到达相同最终资源
路径或信息架构变化	是	上线前建立明确旧—新决定
域名、子域、合并或拆分	是	映射每个重要 URL，并协调资产、链接、Sitemap 与监控

不要因为它们共用一个上线日期，就把域名迁移、新 CMS、重新设计、新内容策略与不必要的 URL 清理同时进行。Google 建议在可行时一次只改变一个主要维度。分开变更类型，更容易诊断问题与回退。

冻结迁移范围与责任

控制项	必须决定
上线边界	包含哪些域名、子域、目录、语言、平台、资产与环境
唯一依据文件	一个受控 Map、唯一 URL Key、版本、日期、负责人和批准状态
变更控制	谁能新增、修改、批准、实施、测试或回退一行
发布门槛	更改 Redirect 或 DNS 前必须完成什么
沟通	谁接收上线通知、事故、决定与证据

从多个来源建立旧 URL 清单

来源	可能发现的 URL	限制
CMS 或数据库导出	已发布、草稿、私有、附件、分类与自定义类型	可能遗漏代码、插件或服务器生成的 Route
XML Sitemap	曾声明用于发现与索引的 URL	可能过时、不完整，或只含首选 URL
完整抓取	可链接页面、资产、状态码、Canonical、元数据与 Alternate	无法单独发现孤立或不可访问 URL
Search Console	已索引、已抓取、已链接、Sitemap 与表现 URL	报告可能抽样、延迟、聚合，并非完整清单
Analytics 与转化系统	有访问的着陆页、活动、转化与历史旅程	未追踪、被阻止或零访问 URL 会缺失
服务器与 CDN 日志	用户、爬虫、应用与旧链接的真实请求	保留期、爬虫验证、隐私与访问条件不同
外链与提及工具	有外链页面、媒体、PDF 与旧活动 URL	每个供应商索引都不同且不完整
广告、邮件、社交、二维码、应用与商家资料	自然搜索清单之外的目标 URL	通常由其他团队和账户负责

没有任何一次导出等于完整网站。应合并来源、保留出处，并调查来源之间的差异，而不是让最新抓取覆盖历史。

规范化 URL，但不要丢失证据

规范化流程

原样保存发现的 URL。
分别解析协议、主机、端口、路径、查询、Fragment 与编码。
按记录的主机名、大小写、斜线与参数规则生成规范化比较 Key。
Fragment 虽不发送到服务器，仍应保留用于链接 QA。
在理解参数功能、流量、外链、活动与重复行为前，不要删除参数。
保留全部来源、表现、外链与归属证据后再去重。

使用可决策的 Redirect Map 字段

字段组	必要列
身份	唯一 Row ID、原始旧 URL、规范化旧 URL、来源系统、页面类型、Locale
证据	当前状态、可索引性、Canonical、流量、转化、外链、内部链接、负责人
决定	保留、Redirect、移除、合并、调查；理由；批准人；日期
目标	建议 URL、预期状态、最终 URL、目标状态、目标 Canonical、相关性证明
内容与 SEO	Title、Description、H1、内容、媒体、Schema、hreflang、元数据、日期、内部链接处理
实施	规则负责人、平台、模式或明确规则、发布、依赖、回退
测试	首个响应、跳数、最终状态、最终 Canonical、正文相关性、手机、Locale、测试日期、测试人
监控	上线响应、Google 所选 Canonical、点击、错误、日志活动、事故、下次审核

把业务决定与实施状态分开

维度	示例值	为何分开
批准结果	KEEP、REDIRECT、REMOVE、HOLD	代表业务与 SEO 决定
实施状态	NOT_STARTED、BUILT、STAGED、LIVE、ROLLED_BACK	显示实际发生了什么
测试结果	NOT_TESTED、PASS、FAIL、BLOCKED	防止把“已配置”误认为“已生效”
上线后状态	HEALTHY、WATCH、INCIDENT、RESOLVED	保留监控与事故历史

按风险排序，但不要忽略长尾 URL

优先证据	为何重要
收入、合格线索或辅助转化	保护有商业价值的旅程
搜索点击、曝光与索引历史	识别已建立的自然入口
相关外链与引荐流量	保护站外发现、信任与访问
导航、内部链接与活动依赖	发现嵌入重要旅程的 URL
法律、支持、账户、结账或产品功能	低流量 URL 仍可能对运营至关重要
未知但反复被请求的旧 URL	日志可能发现当前报告遗漏的价值

优先级决定审核顺序与监控深度，而不是某个 URL 是否值得处理。每个已知公开 URL 都仍需要明确结果。

尽可能保持重要 URL 不变

重新设计并不要求更换 Slug。如果受众任务、首选地址、语言与归属仍然有效，就保留 URL，并记录为 200 KEEP。然后通过 Canonical URL 与 Redirect 与 SEO 网站架构的控制项比较新旧页面。

KEEP 行仍需一致性检查

HTTP 状态、可索引性、首选主机与自引用 Canonical。
Title、Description、H1、主要内容、媒体、日期与结构化数据。
内部链接、面包屑、分页、相关文章与导航。
hreflang、语言切换器、Open Graph、Feed、Sitemap 与 API 引用。
表单、转化、同意、Analytics、广告与第三方整合。

只有真正替代页面才使用永久 Redirect

替代页面测试	问题
受众	同一访客是否会合理地需要目标页？
任务与意图	是否完成相同任务，或提供最接近的完整替代？
主题与范围	是否覆盖核心主题、产品、服务、地点或政策？
语言与市场	是否适合同一 Locale 与商业可用范围？
证据与下一步	用户能否验证同一主张并继续旅程？

关键词相似并不够。应在 Map 中记录简短相关性说明，让批准人能在写入代码前质疑薄弱映射。

只有目标页能承接合并任务时才合并

合并模式	安全条件	不安全条件
多篇重叠文章合并为一篇指南	指南保留有用问题、证据与内部旅程	目标只是泛分类页，或丢失独特价值
旧服务页合并到新服务主页面	方案、受众、地点与下一步仍然对应	不同服务被强行送到泛概览
旧分类合并到持续维护的 Hub	Hub 真正帮助用户发现迁移资源	Hub 为空、Noindex 或无关

有意识地选择永久与临时状态码

状态码	迁移含义	用途
`301`	永久移动	大多数永久 URL 迁移的首选服务器端方式
`308`	永久移动并保留请求方法	平台行为或非 GET 请求需要保留方法时使用
`302`	临时移动	源 URL 应继续作为长期首选
`307`	临时移动并保留请求方法	临时路由且请求方法处理很重要

Google 把服务器端 301 与 308 视为永久 Redirect 信号。只有源 URL 确实仍是长期首选时才使用临时 Redirect。不要为了猜测的排名优势反复更换状态码。

没有替代页面时返回真实 404 或 410

结果	正确情况	用户体验
`404 Not Found`	资源不可用且没有相关替代页面	使用品牌化实用错误页，但保持真实 404 状态
`410 Gone`	负责人有意移除资源，并明确说明已永久消失	清楚说明与有用导航，但保持真实 410 状态
相关 301	替代页面真正服务相同需求	直接到达最终有用目标

Google 建议在内容已移除且没有相似替代页面时返回 404 或 410。自定义错误页可以提供有用导航，但服务器响应仍必须表达失败。一个友好页面如果返回 200，就是 Soft 404，而不是成功迁移。

不要把所有下线 URL 都送到首页

旧 URL	更好的决定
旧关于我们页面	如果新关于我们是真正替代，就 Redirect 到新关于我们
有直接后继产品的停产页	只有后继产品真正满足同一需求时才 Redirect，并说明变化
过期活动与长期活动 Hub	保留归档，或在 Hub 承接预期任务时 Redirect
无有用替代的已移除文章	返回 404／410，而不是无关首页 Redirect

只有转换规律可证明一致时才使用模式规则

规则类型	适用情况	控制
精确一对一规则	高价值、例外、合并、改名或不规则 URL	Map 中明确源与最终目标
模式规则	稳定转换，例如旧主机到新主机且路径不变	发布前列出命中 URL 并测试排除项
兜底规则	很少合理	不能隐藏未映射 URL 或制造首页 Soft 404

模式规则安全测试

列出规则会命中的全部已知 URL。
列出受保护例外与更高优先级精确规则。
测试编码字符、大小写、尾斜线、参数、文件与语言路径。
证明每个命中源生成的目标都存在且相关。
防止规则把目标再次 Redirect 到自身。

直接 Redirect 到最终目标

问题	例子	修正
链式 Redirect	`A → B → C`	`A → C`
协议与主机链	`http → https → www → final`	平台安全支持时合并规范化
循环 Redirect	`A → B → A`	修正规则优先级并排除最终目标
Redirect 到错误页	`A → B (404)`	修复或选择有效相关目标
Redirect 到继续跳转的参数变体	`A → B?x=1 → B`	除非参数必需，否则直接指向最终 Canonical URL

Googlebot 能跟随 Redirect Chain，但 Google 建议直接指向最终目标，并尽量减少无法避免的链。每多一跳，就增加用户、爬虫、活动、应用与 Analytics 的延迟和故障点。

明确处理协议、主机、端口、斜线、文件与参数

URL 维度	迁移决定
HTTP 与 HTTPS	选择安全首选版本，并保留 Redirect 主机的证书
www 与非 www	选择一个公开主机，每个路径直接到对应地址
默认端口与 Staging 主机	不要出现在公开 Canonical、链接、Sitemap 与索引中
尾斜线与 index.html	选择一种最终规范，避免每次请求都产生多跳
大小写与编码	根据服务器行为与真实 URL 归属保留或规范化
查询参数	保留必要功能与活动数据；只有有证据时才移除重复或过时参数
图片、PDF 与下载	把重要已索引或有外链资产映射到真正替代资源

同步更新全部 Canonical 信号

目标信号一致性

旧 URL 按批准结果直接永久 Redirect 到最终 URL。
最终 URL 返回 200，且未被阻止或 Noindex。
最终页使用首选协议、主机、路径与 Locale 的自引用 Canonical。
内部链接、面包屑、导航与 Feed 使用最终 URL。
当前 Sitemap 列出最终可索引 URL，而非 Redirect 源。
结构化数据、Open Graph、API 引用与活动目标使用预期最终 URL。

把多语言映射重建为完整配对组

语言配对组中任何 URL 发生变化时，都要为每个成员更新自引用 Canonical、双向 hreflang、语言切换器、内部链接与 Sitemap Alternate。不要仅因漏掉翻译，就把马来文或中文页 Redirect 到英文。请使用马来西亚多语言 SEO 的 Locale 控制方法。

不只保留地址，也要保留内容与元数据

层面	批准前比较
目的与可见内容	受众任务、主要答案、服务或产品范围、证据、FAQ、CTA
搜索呈现	Title、Description、H1、图片、发布日期与修改日期
索引控制	状态、Robots、Canonical、hreflang、分页、Sitemap 收录
含义与实体	结构化数据、作者、组织、产品、服务、地点与标识符
媒体与文件	图片 URL、Alt、说明、视频、PDF、下载、归属与版权
旅程与衡量	内部链接、表单、WhatsApp、电话、结账、同意、Analytics 与事件

保护 Staging，但不要把阻止规则带到正式站

Staging 控制	上线风险
身份验证或网络限制	可能阻止外部 QA 工具；正式站不能继承
测试页 Noindex	必须从正式可索引模板移除
Staging robots.txt Disallow	Robots 阻止会让爬虫看不到页面级 Noindex，也不能替换正式规则
临时主机名	上线后不能出现在 Canonical、hreflang、结构化数据、Feed 或 Sitemap

对每个 Redirect 测试两个视角

测试视角	证明什么
不跟随 Redirect	首个响应具备预期状态与 Location Header
跟随完整旅程	目标、跳数、最终状态、Canonical、语言、内容与功能正确

自动化逐行测试

请求精确旧 URL，不自动跟随。
把实际首个状态与 Location 和批准行比较。
以有限跳数跟随并检测循环。
确认最终 URL、状态、内容类型、Locale、Canonical、Robots 与有效正文。
保存时间、环境、测试人或脚本版本与证据。
遇到循环、意外链、无关目标、5xx 或关键页被阻止时阻断发布。

除了状态检查，还要测试代表性旅程

旅程	需要验证
搜索着陆页	旧结果到达正确最终页、答案、语言与 CTA
导航与面包屑	没有链接依赖 Redirect，层级保持一致
表单、WhatsApp、电话、预约或结账	转化可用，来源／活动／语言信息保留
图片、PDF、Feed、应用与 API 消费者	资产可解析、内容类型正确、客户端不损坏
404 与已移除内容	真实错误状态、有用界面、没有意外可索引 Soft 404

根据风险与规模选择上线方式

情况	实用方式
中小型网站的一次协调迁移	Google 通常建议在充分准备后一次完成 URL 迁移
超大型网站或高运营风险	先试点稳定分区，学习后再分批受控发布
无可见 URL 变化的主机迁移	聚焦基础设施一致性、抓取访问、容量、TLS、DNS 与旧 Redirect
希望域名迁移同时重设计	尽可能分开变更，让搜索与事故信号可解释

仅在符合条件的域名迁移使用 Change of Address

迁移	是否使用 Search Console Change of Address？
example.com 到 example.net	是，在 Redirect 与验证准备后
a.example.com 到 b.example.com	是，用于已验证域名／子域迁移
仅 HTTP 转 HTTPS	否
同域名 www 到非 www	否
同域名内移动路径	否
公开 URL 不变的主机或 CDN 更换	否

域名迁移前，要用同一账户验证相关新旧资产，保留验证文件或标签，并检查 Manual Action、Removal、设置与旧控制。这个工具只是补充正确 Redirect，并不能取代 Redirect。

使用受控上线顺序

上线顺序

冻结已批准 Map，备份配置与内容，并指定发布负责人。
部署最终页面、资产、证书、Robots 规则、Analytics 与验证控制。
从正式输出移除仅 Staging 使用的 Noindex、访问限制与临时主机。
启用批准 Redirect，并立即运行自动化旧 URL 清单。
验证关键旅程、最终 Canonical、hreflang、结构化数据、内部链接与 Sitemap。
提交或更新 Sitemap；仅在符合条件时使用 Change of Address。
记录发布时间、证据、已知例外与回退决定窗口。

上线后同时监控新旧 URL

时间窗口	主要检查
最初几分钟与几小时	可用性、TLS、DNS、5xx、循环、重点 Redirect、表单、Analytics、Robots、Noindex
最初几天	完整 Map 重抓、日志、404／410、意外链、Sitemap 处理、URL Inspection 抽样
最初几周	新旧 Search Console 覆盖与表现、所选 Canonical、流量、转化、外链与引荐错误
后续数月	信号转移、残留旧 URL、季节性比较、内容质量、Redirect 请求、域名与证书续期

Google 重新抓取与处理迁移期间可能出现暂时曝光波动。这不代表可以忽略错误，也不能承诺恢复日期。应按页面组分段，并分别诊断技术、内容、需求、追踪与业务变化。

上线前定义事故触发与回退边界

事故信号	立即响应
关键页面返回 5xx、循环、被阻止或 Noindex	停止发布路径，恢复访问或最后已知良好配置，并重新测试
大量未映射或无关 Redirect	禁用错误规则，保留精确例外，修正 Map 后重新部署
追踪或转化失败	先恢复客户旅程，标记报告缺口，避免错误表现结论
Google 选择意外 Canonical	把状态、内容、内部链接、Sitemap、Redirect、Locale 与 Canonical 作为一个系统比较

应根据企业正常错误率、流量、转化量与关键旅程设置专属阈值。没有一个通用下降百分比能证明迁移失败。

长期保留 Redirect，并维护旧基础设施

Google 建议网站迁移 Redirect 尽可能长期保留，通常至少一年，以便 URL 重新抓取时转移信号与链接。从用户角度看，有用 Redirect 可能值得永久保留。只要仍有请求，就要让旧域名、DNS、证书与 Redirect 主机继续运行，并更新内部链接及自己可控制的重要外部链接，减少对 Redirect 的依赖。

经验证的 SEOWithJack 迁移实例

SEOWithJack 的 WordPress 转静态迁移使用 53 行状态表，而不是一条全站兜底 Redirect。当前自动化保留审计验证了 27 个原始文章 URL：其中 26 个继续匹配原路径，另一个较旧 SEO URL 永久 Redirect 到合并后的入门指南。系统也保留 Rank Math 来源证据，测试 301、404 与 410 决定，并在 Staging 与主机检查获批前，把正式 DNS 排除在迁移步骤之外。

已验证控制	当前证据
Redirect Map 行数	53
保留原文章 URL	27
直接匹配原路径	26
通过永久 Redirect 合并的原文章	1
构建是否更改正式 DNS	否

可复制的精简行模板

旧 URL	决定	目标	理由	预期	实际	负责人
/old-service/	REDIRECT	/services/current/	相同服务与受众任务	301 → 200	待测试	SEO + 开发
/useful-guide/	KEEP	/useful-guide/	稳定首选 URL	200	待一致性检查	内容
/obsolete-no-replacement/	REMOVE	—	没有有用替代	410	待测试	SEO
/unknown-legacy/	HOLD	—	需检查日志与外链	不发布	待处理	待指定

最终发布门槛

满足以下条件前不要上线

每个已知公开旧 URL 都有一个批准结果或明确阻断状态。
所有永久 Redirect 直接指向相关最终 200 URL。
已移除页面返回真实 404／410，而不是首页或 Soft 404。
Canonical、Robots、hreflang、链接、Sitemap、Schema、元数据、媒体与转化通过比较。
Staging 控制不会带入正式站，正式主机也不会污染 Staging 证据。
自动化清单测试与代表性用户旅程在发布环境通过。
监控、事故责任、备份与回退决定已准备。

Redirect Map 不能保证什么

完整 Map 不能保证排名、流量、索引速度、转化率保持不变，也不能保证固定恢复日期。Google 会逐个 URL 处理迁移，短期波动很正常。Redirect 只是 Canonical 信号之一；内容、内部链接、抓取访问、Sitemap、网站质量、需求、竞争、平台行为与业务运营仍然重要。负责任的承诺应是受控实施、可验证证据、快速诊断与有记录的决定。

301 Redirect Map 常见问题

每个旧 URL 都需要 301 吗？

不需要。每个已知公开 URL 都需要决定，但不一定是 Redirect。有效 URL 保持 200，真正迁移才 Redirect，没有相关替代时返回 404／410，不清楚的情况先调查。

301 与 308 都是永久 Redirect 吗？

是。Google 把两者都视为永久 Redirect 信号；308 还会保留请求方法。应根据平台与应用需求选择，而不是排名迷思。

已移除页面应该 Redirect 到首页吗？

只有首页确实替代同一任务的极少数情况才可以。Google 警告，大量无关旧 URL Redirect 到一个页面会令用户困惑，也可能被视为 Soft 404。应使用相关替代页或真实 404／410。

404 比无关 301 更糟吗？

不是。没有有用替代时，真实 404 或 410 才是诚实技术结果。无关 Redirect 会损害用户旅程，也可能被理解为 Soft 404。

重新设计时应该更换 URL 吗？

除非现有地址或架构确实存在用户、业务、安全或维护问题，否则不要更换。保留有效 URL 能降低迁移风险，让重新设计聚焦体验。

可以用 JavaScript 创建 Redirect 吗？

Google 可以处理部分客户端 Redirect，但在可行时建议使用服务器端永久 Redirect。JavaScript 增加渲染与故障依赖，应作为后备而非默认迁移方法。

多少次 Redirect 跳转可以接受？

设计目标应是一跳：旧 URL 直接到最终目标。Google 能跟随链并建议减少无法避免的跳转，但爬虫上限不是性能目标。

Redirect 应保留多久？

Google 建议网站迁移 Redirect 尽可能长期保留，通常至少一年。只要用户、爬虫、链接、活动或应用仍请求旧 URL，就应继续保留有用 Redirect。

什么时候使用 Search Console Change of Address？

在从一个域名或子域迁移到另一个域名／子域且 Redirect 已准备后使用。HTTP 转 HTTPS、www 统一、同域路径变化或公开 URL 不变的主机迁移不使用。

如何判断迁移完成？

没有一个瞬间代表完成。应确认旧请求到达批准结果、最终页面健康且被正确选择、Search Console 与日志显示预期转移、关键旅程能转化、事故已解决，并持续维护 Redirect 基础设施。

官方参考资料

准备重新设计或迁移网站？

最好在 URL 改变前，先分享旧网站与新结构。

通过 WhatsApp 讨论迁移

如何建立并测试完整的 301 Redirect Map