直接回答：网站迁移时如何采集并核对旧 URL 重定向
网站迁移时，应先把网站爬取结果、服务器或 CDN 日志、XML Sitemap、CMS 导出、分析平台、搜索引擎数据和外链数据合并成旧 URL 总表，再按页面主题与用户意图为每个旧地址指定新地址。上线前批量检查响应状态、Location 响应头、最终页面、跳转次数、循环、参数和 Canonical；上线后继续从旧域名日志、404 报告、搜索表现及业务数据中发现遗漏。
最重要的判断标准不是“是否配置了重定向”，而是旧 URL 是否通过一次永久重定向到达真正相关、可访问且可索引的新页面。没有等价内容的旧页面不应全部跳转到首页，应根据情况选择相关栏目、归档页面、404 或 410。
定义：什么是旧 URL 重定向采集与核对
旧 URL 重定向采集，是指在更换域名、目录、CMS、信息架构或页面路由之前，从站内外多个数据源收集曾经存在、仍被访问或仍有搜索与链接价值的旧地址，并对其进行规范化、去重和分级。
旧 URL 重定向核对，是指将每个旧地址的预期去向与服务器实际响应进行比较，确认它使用合适的永久重定向状态码，能够直接到达相关的新页面，并且不存在跳转链、循环、错误参数处理、无效目标或索引配置冲突。
两项工作共同构成迁移中的 URL 治理流程：采集解决“哪些旧地址需要处理”，核对解决“处理结果是否正确”。
真实案例：GOV.UK 的大规模政府网站迁移
GOV.UK 是公开资料较完整的网站整合案例。英国政府建设统一服务平台时，需要逐步接收 Directgov、Business Link，以及众多政府部门和公共机构网站的内容。旧站数量多、路径结构不一致，许多链接还存在于搜索结果、新闻报道、政策文件和公众书签中。
这项工作的难点不只是把内容发布到新平台，还包括长期管理旧域名与旧路径。GOV.UK 团队公开了用于迁移管理的 Transition 工具及相关技术资料。该系统维护旧地址的重定向和归档处理，记录旧站请求，并利用访问数据发现未命中地址和异常规则。
例如，一项政府服务可能在旧部门网站、Directgov 和宣传材料中分别使用不同地址。内容迁到 GOV.UK 后，团队不仅要确定统一的新页面，还要让这些历史入口持续可用。上线后的旧 URL 请求数据则用于找出遗漏路径、错误规则和仍被大量访问的历史内容。
这个案例说明：重定向不是上线当天执行的一张配置表，而是从 URL 发现、内容匹配、规则验证到生产监控的持续流程。
迁移前：从多个数据源建立旧 URL 总表
1. 爬取当前可访问的网站
可使用 Screaming Frog、Sitebulb 或自建爬虫，从首页、栏目页、Sitemap 和已知入口开始抓取旧站。至少记录原始 URL、最终 URL、状态码、页面标题、Canonical、索引指令、内容类型、页面深度和站内链接数量。
爬虫只能发现当前仍可通过链接到达的页面，无法完整覆盖孤立页面、历史活动页和已从导航中移除但仍有访问的地址，因此不能把单次爬取结果视为完整清单。
2. 提取服务器或 CDN 日志
日志能够识别真实用户和搜索引擎仍在请求的旧 URL，是发现历史地址的重要来源。一般可先分析迁移前 90 天的数据；存在明显季节性的业务，应覆盖一个完整业务周期，必要时与上一年度同期数据比较。
建议保留请求主机、路径、查询参数、响应状态、请求次数、User-Agent、来源和最后访问时间。还应分别识别主要搜索引擎爬虫访问过的地址，以及返回 200、3xx、404 等状态的路径。
3. 合并 Sitemap、CMS 和分析数据
从历史 XML Sitemap、CMS 数据库、路由表、静态文件目录、Google Analytics、Adobe Analytics 和 Google Search Console 导出 URL。分析平台可以识别产生过访问或转化的页面，Search Console 可补充获得过点击和展示的搜索落地页。
需要注意，分析平台可能因埋点缺失、数据保留期限或隐私设置而漏数；Search Console 导出也不是完整 URL 数据库。这些来源应相互补充，而不能单独作为迁移清单。
4. 补充外链与历史存档
使用 Ahrefs、Semrush、Majestic 等工具导出存在外部链接的旧 URL。对于运行时间较长的网站，还可以查询互联网档案馆、旧版 Sitemap、历史发布记录和客服知识库，寻找已经下线但仍可能被引用的路径。
5. 规范化、去重并保留原始值
合并数据后，应统一协议、主机名、默认端口、主机大小写、默认首页和已明确等价的参数规则。同时必须保留原始请求值，避免规范化掩盖真实路由差异。例如，某些系统会把 /product 与 /product/ 视为不同路径，也可能区分路径大小写或依赖产品 ID 参数。
总表还应标记每个 URL 的数据来源、访问量、转化、外链、搜索点击、最后发现时间和当前状态。一个地址同时出现在日志、搜索数据和外链数据中，通常应获得更高的处理优先级。
映射阶段：为旧 URL 选择正确的新地址
优先建立一对一映射
旧页面在新站存在等价内容时，应直接重定向到该页面。判断依据不能只看标题，还要比较主题、用户任务、产品或服务对象、语言、地区、时效性和内容层级。
例如，旧站的“企业增值税申报指南”应跳转到新站对应的申报指南，而不是统一跳到“企业服务”栏目或网站首页。相关性越高，用户完成原有任务的可能性越大，搜索信号的承接也越合理。
建立可审计的 URL 映射表
映射表至少应包含旧 URL、新 URL、处理方式、当前状态码、预期状态码、页面类型、流量、转化、外链数量、映射理由、负责人和验证结果。批量规则还应记录匹配范围、捕获组、参数处理方式和例外 URL。
建议为映射结果设置状态，例如“待匹配”“待审核”“已批准”“已部署”“验证通过”和“需修复”。这样可以区分内容决策、技术发布和生产验证，避免把表格中已有目标误认为规则已经生效。
没有等价内容时分类处理
- 内容已合并：跳转到实际承接原主题的新页面。
- 内容被替代：跳转到能够完成原有用户任务的替代页面。
- 只存在上级主题：确认栏目页能够提供明确下一步后，再谨慎跳转。
- 内容永久删除且没有替代：返回 404 或 410，并提供有效站内导航。
- 因法规、审计或公共记录需要保留：建立归档页面，并明确内容日期与状态。
GOV.UK 案例尤其说明了信息保存的重要性。政策文件、历史公告和机构记录可能在业务结束后仍被引用，因此迁移决策需要同时考虑用户任务、搜索价值、法规要求和公共记录责任。
上线前：自动核对重定向规则
核对首次响应与最终目标
永久迁移通常使用 301 或 308。测试程序应直接请求旧 URL，记录首次响应状态、Location 响应头、每一步跳转和最终落地页。不能只查看浏览器最后显示的页面，因为浏览器会自动跟随跳转，并可能使用缓存隐藏中间过程。
检查重定向链和循环
理想路径是“旧 URL → 最终新 URL”。如果出现“旧 URL → 临时地址 → 新地址 → 规范地址”，就形成了重定向链。链条会增加延迟和维护成本，也可能浪费搜索引擎抓取资源。循环则会直接阻止用户和爬虫到达目标页面。
验证目标页面是否真正有效
状态码正确不等于迁移正确。还要确认最终页面返回 200、内容与旧页面相关、允许索引、Canonical 指向预期地址，并且语言、地区、移动端表现和登录权限符合预期。目标页面若返回软 404、被 robots.txt 阻止或设置了 noindex，仍然属于迁移缺陷。
测试参数、编码和特殊路由
电商、搜索和内容平台常包含跟踪参数、筛选参数、中文路径、百分号编码、大小写差异及内容 ID。测试集应覆盖带参数与不带参数的 URL，确认规则不会误删产品编号、语言代码或关键查询条件，也不会把任意未知参数错误带入新系统。
在预发布环境执行全量与抽样测试
可将旧 URL 总表交给脚本或爬虫批量请求，输出实际状态码、实际目标、跳转次数、最终状态和响应时间，再与预期映射表进行差异比较。对于依赖域名、CDN 或边缘规则的配置，还应在尽可能接近生产环境的条件下测试。
测试优先级应先覆盖高流量、高转化、高外链和高抓取频率 URL，再覆盖每条批量规则的正常样本、边界样本和例外样本。
上线后：利用日志与业务数据持续排查
立即重新请求全部旧 URL
生产环境上线后应再次执行全量验证。预发布环境通过并不代表生产环境一定正确，常见问题包括规则没有完整发布、匹配顺序改变、CDN 缓存旧响应、不同主机配置不一致，以及应用路由覆盖服务器规则。
持续监控旧域名的 404 与未命中路径
GOV.UK 的公开迁移实践体现了旧地址请求数据的价值。普通网站也可以按相同原则持续汇总旧域名上的 404，按请求量、搜索引擎访问和来源域名排序，再判断这些地址应补充重定向、恢复内容，还是继续返回 404 或 410。
修复时不能仅因某个 URL 有请求就创建重定向。扫描器、拼写错误和无效参数也会产生大量请求，应先确认地址是否曾真实存在，以及是否有相关的新内容。
结合搜索与业务指标判断影响
迁移后应同时观察 Search Console 的网页索引、抓取统计、点击和展示变化，以及分析平台中的自然流量、转化和落地页表现。排名或流量波动不能单独证明重定向错误，需要结合 URL 级请求、索引状态和目标页面质量进行定位。
可设置上线后 24 小时、7 天、30 天和 90 天检查节点。前期重点处理状态码、循环、主机和规则发布问题；中后期重点观察索引替换、长尾流量、外链访问及遗漏 URL。
从 GOV.UK 案例提炼的实践经验
经验一：多源 URL 清单比单次爬取可靠
爬虫反映当前站内链接结构，日志反映真实请求，搜索平台反映搜索曝光，外链工具反映站外引用，CMS 则可能保留已脱离导航的内容记录。只有合并这些来源，才能覆盖仍有价值的历史 URL。
经验二：映射质量比表面覆盖率重要
把所有旧地址跳转到首页虽然可以减少表面上的 404，却无法满足原始访问意图，大量不相关跳转还可能被搜索引擎视为软 404。更有意义的指标包括相关目标覆盖率、一步跳转率、有效落地率、规则命中率和高价值 URL 验证通过率。
经验三：规模化处理需要规则与人工审核结合
大型网站可能有数十万甚至更多历史 URL，逐条人工映射并不现实。可以按目录结构、内容 ID 或稳定路由批量生成规则，再通过自动测试和分层抽样验证。高流量、高转化、高外链页面以及规则例外仍应人工确认。
经验四：旧域名与关键重定向需要长期保留
旧链接可能长期存在于文档、书签、邮件和第三方网站中。只要成本、所有权和合规条件允许，就应继续控制旧域名并维护关键重定向。过早停止续费旧域名不仅会破坏历史链接，还可能带来品牌冒用和安全风险。
行业趋势：从一次性迁移转向持续治理
第一，重定向配置正在代码化。越来越多团队把规则和测试纳入版本控制，通过持续集成检查重复规则、循环、无效目标、规则冲突和意外的大范围匹配，使每次修改都有审核和回滚记录。
第二，边缘日志正在成为主要发现来源。随着网站规模扩大和前端架构复杂化，仅依靠页面爬取难以覆盖历史路径。CDN、负载均衡器和边缘平台记录的请求数据，可用于发现应用层之前发生的未命中和主机差异。
第三，语义匹配开始辅助 URL 映射。团队可以结合标题、正文主题、结构化数据和向量相似度生成候选目标，但语义接近不代表用户任务相同。高价值页面、交易页面和受监管内容仍需人工审核。
第四，重定向可观测性受到更多重视。迁移团队不再只统计配置了多少条 301，而会持续监控规则命中率、404 请求量、跳转链长度、目标页面健康度、索引替换和业务流量恢复情况。
第五，迁移验收正在从页面级扩展到用户任务级。除了检查旧地址能否打开，团队还会验证用户到达新页面后能否继续搜索、提交表单、购买产品或完成服务申请。这种验收方式更接近迁移的真实业务目标。
常见问题
只用爬虫采集旧 URL 可以吗？
不可以。爬虫通常只能发现当前通过站内链接可到达的页面，容易遗漏孤立页、历史活动页、参数地址和已从导航移除的页面。至少还应合并服务器或 CDN 日志、XML Sitemap、CMS、分析平台、Search Console 和外链数据。
网站迁移应该使用 301 还是 302？
永久迁移通常使用 301 或 308；302 和 307更适合临时跳转。具体选择还要结合服务器、CDN、请求方法和缓存策略，但永久迁移不应长期依赖临时重定向。
没有对应新页面的旧 URL 可以全部跳转到首页吗？
不建议。大量不相关的旧 URL 跳转到首页会损害用户体验，也可能被搜索引擎视为软 404。应优先选择能够承接原主题和用户任务的页面；确实没有替代内容时，返回 404 或 410 通常更合理。
如何判断旧 URL 重定向已经核对完成？
至少应确认旧 URL 返回预期的 301 或 308，能够一步到达正确目标，最终页面返回 200、允许索引且 Canonical 正确，同时不存在循环、长链、规则冲突、参数误处理和大规模不相关跳转。
重定向上线后需要监控多久？
可设置上线后 24 小时、7 天、30 天和 90 天的集中检查节点，但旧域名请求与 404 监控不应在 90 天后自动停止。只要历史链接仍可能被访问，关键重定向就应长期保留并定期验证。
URL 数量很多时必须逐条人工映射吗？
不必全部人工处理。可以按目录结构、内容 ID 或稳定路由批量生成映射，但高流量、高转化、高外链页面及规则例外需要人工审核。批量结果还应通过自动测试、边界样本和分层抽样进行验证。
404 和 410 在迁移中应该如何选择？
两者都表示页面不可用。404 可用于地址不存在或状态尚未明确的情况；410 更明确地表示资源已永久删除。实际选择应结合服务器能力和内容治理政策，重点是不要把没有替代内容的页面强行跳转到不相关地址。
总结
网站迁移中的旧 URL 重定向采集，是从爬虫、日志、Sitemap、CMS、搜索平台、分析平台和外链数据中找全历史地址；重定向核对，则是验证这些地址是否通过一次永久跳转到相关、可访问且可索引的新页面。GOV.UK 的公开案例说明，大规模迁移需要把映射、验证和旧地址请求监控作为持续治理流程。实践中应优先处理高价值 URL，自动检查状态码、目标、链路和索引配置，并对没有对应内容的页面采用归档、404 或 410，而不是统一跳转到首页。