网站迁移SEO清单

网站迁移是对网站的平台、域名、协议、信息架构、URL结构或渲染系统进行的受控变更。只有当用户、爬虫和分析工具能够通过稳定的路由访问到预期内容，且团队能够证明有价值的可见性得以保留时，迁移才算完成。

清单： 网站迁移SEO。时间框： 中等规模网站在上线前6–12周开始；预留最后5个工作日用于变更冻结，上线日用于专人验证，以及至少4周的持续监控期。负责人： 一位迁移主要负责人对整个发布负责，由指定的工程、SEO、分析、内容和基础设施负责人提供支持。

为何存在此清单，以及为何在此处执行

此发布控制层位于SEO流程 中，它接收来自技术基线审计 的爬取和索引证据、来自内容清单与审计 的保留/合并/删除决策，以及来自主题地图与信息架构 的目标层级结构。在判断重定向或预发布环境之前，这些输出必须已经存在。

在目标结构获批之后、生产路由冻结之前执行此清单。如果执行过早，团队会将重定向映射到可能还会变化的目标。如果执行过晚，路由、模板、分析或上线沟通可能已难以安全纠正。

重定向映射是风险最高的单件产物，因为它将旧路由与新路由连接在一起。每个有价值的旧URL应一对一地映射到最能保有其目的的最接近目标。切勿将首页用作万能兜底：这会让访问者感到困扰，并掩盖缺失的目标。

输入与输出

输出是与上线操作的合同。没有负责人、证据或验收条件的电子表格不能算作交接。

清单

每个条目说明了什么、为什么、怎么做、使用什么工具，以及可观察的完成条件。仅可使用更严格的规则或基于文档的基线来替换阈值。

阶段一：迁移前清单

1. 构建合并URL清单。 做什么： 合并来自爬取、XML站点地图、分析、Search Console、反向链接导出、CMS记录、付费广告活动和服务器日志的所有可发现的旧URL。为什么： 没有任何单一来源包含所有有价值或被请求的URL；导航中不存在的页面仍可能有链接、流量或合同重要性。怎么做： 在保留原始来源值的同时，规范化协议、主机、大小写、尾部斜杠、参数和编码字符。仅在记录每个URL的来源后进行去重。工具： 爬虫、CMS导出、分析、Search Console、反向链接数据和日志。完成条件： 每个来源均标注了日期，每行均有标准化的URL和发现来源，重复项已解决，来源总计与最终清单相符。

2. 分类每个URL的处理方式。 做什么： 将每个URL标记为保留、移动、合并、删除或待调查。为什么： 在内容决策明确之前，无法正确映射重定向。怎么做： 结合流量、转化、反向链接、索引状态、内容质量、业务需求和意图；记录证据和审批负责人。工具： 清单工作簿和内容审计。完成条件： 100%的范围内URL具有一种处理方式、一个负责人、一个目标或删除理由，并且在冻结时没有未解决的"待调查"行。

3. 捕获已签名的基线。 做什么： 保留上线前的自然搜索会话数、点击量、展示次数、转化数、收入、已索引URL、爬取错误、响应代码、正常运行时间和性能数据，针对优先模板和目录。为什么： 没有标注日期的比较点，正常波动和迁移损害看起来一样。怎么做： 导出至少28天的可比数据，标注活动和季节性，识别需要每日审核的优先URL。工具： 分析、Search Console、爬虫、排名数据和监控。完成条件： 基线为只读、可复现、已分段、带时间戳，并已获得SEO和分析负责人的批准。

阶段二：重定向映射

4. 尽可能一对一映射来源。 做什么： 将每个被移动或合并的旧URL分配给具有相同主要意图的最接近新URL。为什么： 精确的目标为访问者保持连续性，并为爬虫提供一致的替换信号。怎么做： 比较主题、产品、地理位置、语言和任务；将合并映射到保留页面，并记录有意的删除。切勿将不匹配的URL映射到首页。工具： 重定向映射工作簿、清单和目标爬取。完成条件： 每个变更的来源恰好有一个已批准的结果，每个目标都相关且在范围内，首页兜底映射数为零。

5. 在上线前验证重定向机制。 做什么： 测试状态码、目标、查询行为、大小写变体、协议、子域名、尾部斜杠、文件和广告活动URL。为什么： 看起来正确的电子表格仍可能产生循环、链式重定向、吞没有效页面的通配符规则或返回错误的目标。怎么做： 生成预发布或代理规则，请求每个来源，跟踪跳转，并将最终URL与已批准的映射进行对比。工具： 自动化HTTP测试、爬虫和服务器配置审查。完成条件： 100%的已映射来源通过一次永久重定向跳转到达已批准的200目标；循环、链式重定向、临时重定向和错误目标为零。

6. 协调规范标记、链接和站点地图与重定向。 做什么： 使规范URL 、内部链接、hreflang引用、结构化数据、信息源和XML站点地图直接指向最终URL。为什么： 在继续发布旧URL的同时进行重定向会产生冲突的迁移信号，并浪费爬虫请求。怎么做： 爬取每个引用来源并将标准化目标与重定向映射进行对比。工具： 爬虫、渲染的HTML、站点地图解析器和配置差异比较工具。完成条件： 最终页面自引用规范标记（除非已批准的异常另有规定），指向重定向URL的内部引用为零，新站点地图仅包含规范200 URL。

阶段三：预发布环境验证

7. 在不使其可公开索引的情况下测试预发布环境。 做什么： 在阻止搜索引擎索引该环境的同时，完整爬取预发布版本。为什么： 团队需要爬虫级别的证据，但不允许重复站点进入搜索结果。怎么做： 对外部爬虫使用访问控制，然后在生产站点依赖JavaScript渲染的情况下运行经过身份验证的内部爬取。将预发布环境的屏蔽视为临时发布配置，而非直接复制到生产环境的内容。工具： 经过身份验证的爬虫、浏览器和响应头检查。完成条件： 预发布环境的预期清单可供测试团队爬取，未经授权的公共索引已被阻止，生产上线清单明确移除了仅用于预发布环境的控制措施。

8. 验证模板和优先流程。 做什么： 测试每个模板的代表性页面，以及导航、搜索、表单、注册、结账、本地化、分页、筛选和错误页面。为什么： 首页通过测试无法揭示产品页面上的规范标记错误或抑制分析数据的已损坏同意状态。怎么做： 创建设备与模板矩阵，测试新会话和回访会话，并为每个结果记录截图或响应证据。工具： 浏览器、可访问性检查器、结构化数据验证器、分析调试器和事务测试。完成条件： 每个范围内的模板和主要流程在约定的浏览器和设备上通过测试，零严重缺陷未关闭。

9. 将预发布环境与已批准的合同进行对比。 做什么： 对比标题、描述、标题标签、规范标记、爬虫指令、结构化数据、内部链接、响应代码、内容和分析标签与旧站点及目标规格的差异。为什么： 平台迁移经常丢失元数据或改变渲染方式，即使可见内容看起来完好。怎么做： 使用匹配的设置爬取旧生产环境和预发布环境，按模板分类差异，仅批准有意的变更。工具： 爬取差异报告和源码检查。完成条件： 每个实质性差异要么已纠正，要么列为已批准的变更并附有负责人和理由；意外的noindex、规范标记、内容和跟踪变更为零。

10. 冻结发布候选版本。 做什么： 冻结URL清单、重定向映射、路由定义、规范标记和爬虫规则、站点地图生成、分析和同意设置、DNS/CDN计划以及不相关的生产部署。为什么： 测试结果仅适用于所测试的版本。怎么做： 标记发布产物，将变更限制在事件路径内，并要求重新测试受紧急编辑影响的任何内容。工具： 部署系统、变更日志和批准记录。完成条件： 已命名的不可变候选版本已就位，访问受限，所有异常均有负责人，每次冻结后的变更均附带测试结果。

阶段四：上线日

11. 执行单一责任人运行手册。 做什么： 按批准的顺序部署路由、应用程序、DNS/CDN、分析、站点地图和监控。为什么： 并行的无序变更使故障难以隔离，且回滚不安全。怎么做： 一位迁移负责人调用每个步骤，指定的操作员记录完成情况，验证者在下一个依赖步骤之前测试证据。工具： 运行手册、部署日志、DNS检查和共享事件频道。完成条件： 每行均有实际时间、操作员、结果和证据链接，没有仅凭口头确认即标记完成的依赖项。

12. 运行上线冒烟测试。 做什么： 测试首页、爬虫文件、站点地图、每个模板至少一个URL、每个优先流程、分析数据接收情况以及分层抽样的重定向来源。为什么： 在缓存和爬虫扩散问题之前检测到广泛故障，是最快速安全响应的关键。怎么做： 从生产网络外部进行测试，使用桌面端和移动端，验证服务器交付的HTML和渲染输出，并与冻结的预期结果进行对比。工具： 爬虫、浏览器、HTTP客户端、分析实时视图和事务监控器。完成条件： 关键页面返回预期的状态和内容，优先重定向到达其确切目标，分析事件以正确URL到达，所有阻止上线的检查均通过。

13. 提交并验证发现信号。 做什么： 发布最终的站点地图，确认爬虫和规范标记行为，并为少量优先URL请求检查。为什么： 清晰的发现信号有助于爬虫遇到目标集，而不将提交视为索引的保证。怎么做： 每个生产站点地图提交一次，检查代表性新URL，并记录Google报告的规范标记和索引状态。工具： 站点地图与索引 和URL检查 。完成条件： 站点地图可访问且包含冻结的规范清单，代表性检查显示无生产屏蔽或错误的规范标记，每个警告均有负责人。

阶段五：上线后监控

14. 将前72小时作为事件窗口进行监控。 做什么： 持续或以最短可行间隔监控正常运行时间、5xx、4xx、重定向失败、延迟、爬取量、分析数据接收、转化、站点地图处理和优先流程。为什么： 基础设施和路由缺陷会迅速显现，而搜索表现需要更长时间，不应将其作为唯一的上线警报信号。怎么做： 与已签名的基线进行对比，按模板和目录细分，并将警报路由至当值负责人。工具： 日志、分析、爬虫、运行时间监控 和事件仪表板。完成条件： 仪表板无未解释的上线关键警报，每个事件均有负责人和时间戳，24、48和72小时审查已签署。

15. 稳定后继续监控搜索和索引。 做什么： 至少跟踪四周的页面级点击量、展示次数、索引状态、所选规范标记、爬取错误、目录表现和转化结果。为什么： 爬取、规范标记选择和索引替换落后于基础设施验证。怎么做： 对比同周期数据，区分已移动URL和未变更的控制组，调查聚类问题而非对单日总量做出反应。工具： Google搜索页面 、目录视图 、URL检查、分析和日志。完成条件： 优先目标可发现且可索引，旧URL一致解析到已批准的目标，无法解释的损失已创建工单，所有权转入常规报告节奏。

AmICited中的工具

AmICited提供上线证据和监控界面；已批准的重定向映射和部署日志仍为操作层面的真实来源。

决策规则

以下是发布护栏，并非通用的搜索引擎阈值。请在上线前达成共识，并在风险要求时收紧规则。

回滚是恢复到已知良好的服务状态，而非逆转普通的搜索波动。上线负责人应用约定的规则并记录证据。

可交付成果

交接一个版本化的迁移控制包，工程和SEO团队均可访问。使用工作簿或数据库进行行级记录，使用运行手册进行上线操作，使用仪表板进行实时度量。

其中必须包含：已冻结的清单和来源核对；已批准的重定向映射及负责人和测试结果；匹配的旧站、预发布和新站爬取数据；元数据、规范标记、爬虫规则、站点地图、hreflang、结构化数据、链接和分析差异对比；已签名的基线和优先群组；上线运行手册和恢复流程；数值化回滚规则和决策负责人；以及24、48和72小时证据及四周监控责任归属。

迁移负责人必须能够识别确切的发布版本，证明每项关键测试，重建每个路由决策，并分配每个异常。否则该控制包不完整。

常见问题

重定向映射仅使用当前站点地图。 孤立页面、广告活动URL、反向链接和此前已索引的路由会消失，因此每行电子表格都通过验证，而真实请求却失败。

首页成为默认目标。 用户到达不相关的位置，爬虫信号变得模糊，缺失的内容被伪装成实施进展。

重定向工作正常，但引用仍指向旧地址。 导航、hreflang、规范标记、结构化数据和站点地图持续将爬虫发送通过不必要的跳转和冲突的目标。

预发布环境的保护措施进入生产环境。 复制的noindex、身份验证规则、爬虫屏蔽或CDN策略会破坏可索引性 。需要明确的移除步骤和外部测试。

团队仅验证首页。 一个共享模板可能在首页通过测试的同时错误配置了数千个页面。抽样每个模板并大规模爬取规则。

不相关的发布同时进行。 当平台、分析、同意管理、导航、结账和CDN变更共享同一窗口时，故障变得难以隔离或恢复。

搜索效果评估过早或过于宽泛。 全站总量掩盖了受损目录，一天的波动引发不必要的修复。对比已移动群组、未变更控制组、目录和匹配的时间窗口。

回滚在故障期间才被讨论。 一个好的计划在上线前就明确了阈值、决策者、恢复时间、命令、数据后果和验证顺序。

下一阶段

一旦前72小时稳定，下一步是持续更新与迭代 。它需要来自此清单的已签名基线、最终URL映射、上线注释、目录群组、已知异常、事件历史和指定负责人。没有这些输入，后续的流量损失无法可靠地区分为迁移损害、正常需求变化、内容衰减或衡量失败。

永久保留重定向映射和迁移注释。将非关键发现移入常规报告节奏，并附上严重性、假设、负责人、截止日期和验证方法。

常见问题解答

SEO团队应在何时参与网站迁移？

在路由、模板和平台约束固定之前。SEO需要充足的时间来盘点现有URL、保留有价值的地址、影响新的信息架构、定义重定向行为，并商定可衡量的上线和回滚规则。

如果没有直接替代页面，旧URL是否应重定向到首页？

不应。应将旧URL重定向到满足相同用户意图的最相关页面。如果没有相关目标且内容不应保留，应返回诚实的404或410状态码，而不是将用户和爬虫引向不相关的首页。

迁移重定向应保留多长时间？

只要旧URL仍可能收到访问、链接、书签或爬虫请求，就应保留永久重定向。将其视为持久的路由基础设施，而非数周后即可移除的上线脚手架。

迁移上线前应冻结哪些内容？

冻结已批准的URL清单、重定向映射、规范标记和爬虫规则、站点地图生成、分析和同意配置、DNS和CDN变更，以及不相关的生产发布。紧急修复需遵循指定的变更控制路径。

何时应回滚迁移？

使用上线前商定的标准。对于持续性不可用、大范围5xx响应、主要流程断裂、分析数据丢失或影响相当比例优先URL且无法在约定的恢复窗口内安全修复的路由缺陷等情况，执行回滚。