企业官网改版如何做旧 URL 去向表？先确认每个旧页面的处理责任

官网改版时，团队容易先讨论首页、视觉稿和新栏目，直到上线前才发现旧文章、下载页或产品说明的网址已经变化。旧地址可能还出现在销售邮件、合同附件、外部文章、客户收藏和搜索结果中。去向表的目的不是估算流量，而是确认每个仍会被访问的入口下一步应该到哪里。

先导出旧站能够公开访问的 URL，再把来源记录下来：来自网站地图、栏目页、站内链接、业务团队常用资料，还是其他已知外部引用。来源没有查清的地址标成“待核验”，不要因为它不在导航里就直接当作无用页。旧站的抓取清单、CMS 导出和业务材料可以相互补充，但它们都不必然覆盖所有外部链接。

给每条地址建立一行记录，至少包括旧 URL、旧页主题、主要读者任务、事实是否仍有效、拟采取动作、新页面 URL、处理理由、业务负责人、技术负责人、计划切换时间、验证方式、实测结果和复查日期。还可以记录页面原有附件、表单或下载功能，以免迁移后正文保留了，真正的工作入口却消失。

这张表不要混成一列“旧地址→新地址”。如果目标页面尚未准备好、业务事实仍待确认或目标 URL 还没定，就留下明确状态和责任人。空白表示未知，不是自动等于退役。将计划与完成状态分开，有助于区分“编辑已决定”与“生产系统已实现”。

每条旧 URL 先经过四类判断。判断依据是页面是否还解决明确问题，以及新站是否有能实质承接它的内容，不是只比较网址是否相似。

保留：原问题仍成立，事实有效，页面仍有独立价值。将内容迁入新结构后，尽量保持稳定地址；若因为技术原因必须更换路径，记录精确的新旧对应关系。

更新：读者任务仍成立，但页面里的参数、服务条件、流程或入口已改变。先由事实负责人确认新信息，再更新内容。内容负责人应标出哪些是事实变化，哪些是表达调整，以便审核者看清更新范围。

合并：多个页面持续解决相同问题，正文重复，且一个页面能够保留对读者仍有用的信息。合并时先标记原页面中不可遗漏的条件、证据和附件，再明确哪个页面承接。如果两个页面虽然关键词相近，但服务对象、决策阶段或证据不同，就不能只为缩短清单而合并。

退役：页面事实已经失效，没有合适的新内容承接，也没有合理的替代入口。写明退役原因和对仍在使用旧链接的人会发生什么。不要把所有退役地址一律送到首页、联系页或某个关键词相似但答非所问的页面。

如果上述判断缺少数据或责任人，不要先编造确定结论。可先以“待产品确认”“待销售确认”“待查技术访问记录”标记，并将要问的问题写清楚。比如“该型号是否还有可售配置？”比“内容过时”更容易交给具体的人答复。

页面名称相似不等于页面用途相同。旧页写的是某个型号的尺寸，新的栏目首页即使包含型号导航，也未必是合适的直接落点；旧文解释的是比较条件，新文若只列产品特点，也不一定能接住读者原来的问题。为每一对新旧地址写一句验证说明：新页哪一段回应了旧页核心任务？还有什么信息没有承接？

当多个旧页面指向一个新页面时，在表格中写清它们为什么可以共用该目标。过度合并会让读者落到过宽泛的内容，技术上有跳转也不代表语义上迁移成功。若没有等价替代页，可以保留旧页说明、更新后继续服务，或按实际业务决定退役；不应仅为了把表格填满就指定一个不相关的新地址。

Google Search Central 关于网站搬迁的文档区分了带 URL 变化和不带 URL 变化的站点迁移，并建议预先规划和核验 URL 对应关系。这里的表格是团队协作方法，不是 Google 强制字段清单，也不能保证排名或流量保持不变。具体应采用何种状态码、跳转方式和持续时间，要由开发人员依据服务器、平台和实际页面关系核对。Google Search Central：网站搬迁及更改网址

同一条迁移通常同时包含内容与技术工作。内容负责人确认旧页的信息、读者任务、合并决定和新页正文；开发或站点维护者确认旧 URL 如何响应、新页面 canonical 是否正确、站内链接是否同步、站点地图生成是否符合当前规则。不要让内容编辑直接承诺某个跳转已经配置，也不要只凭开发的“路由通了”来确认内容已迁移。

在切换表中拆分状态：

工作项	谁确认	可记录的验收证据
旧页内容处置	内容/业务负责人	保留、更新、合并或退役决定及事实依据
新页承接	内容负责人	新旧任务对照与未承接信息说明
URL 实施	网站维护者	从生产环境访问旧 URL 的实际响应和最终落点
页面声明	网站维护者	新页最终 HTML 中的 canonical 与索引设置
内部引用	内容/网站维护者	导航、栏目、文章、下载资料中已更新的链接
搜索发现	网站维护者	站点地图与可用的站长工具检查记录

切换前先冻结去向表的版本，给每条改动加负责人和确认时间。多人并行修改时，可在表中增加“变更依据”和“最近更新人”，防止业务临时改了页面，而开发仍按旧目标配置。未决项目要能筛选出来并有下一步，而不是埋在备注文本中。

上线前，从不同来源抽样访问旧地址：手工复制的旧网址、历史邮件里的链接、站内文章链接、附件下载页和栏目入口。每次记录访问环境、旧 URL、预期处理、实际状态、最终落点、页面是否可读和复核人。检查目标内容是否真的出现，而不是只确认浏览器没有报错。

上线后在生产域名重做检查。预览域名成功不能替代生产验收；服务器缓存或 CDN 状态也可能与预览不同。旧网址如果需要跳转，应检查路径中是否包含参数、是否意外跳到其他语言或首页、是否形成重复跳转。新地址也要检查是否返回预期正文、声明正确的 canonical，并能从相关公开页面找到。

Google 的站点迁移指南建议在迁移期间监测流量和抓取情况、更新站点地图，并在新旧站处理完成后检查结果。不同站点技术栈和迁移范围会影响具体执行方式，因此把它当作核验来源，而不是照抄一套不适合当前环境的命令。把需要登录权限的 Search Console 验收项交给站点所有者；没有权限时应标“未核验”，不能写成已通过。

抽样通过不代表所有 URL 都已处理。表格可按动作和状态分别筛选：尚未有新址的保留页、指向同一目标的合并页、责任人未确认的条目，以及生产环境尚未测试的映射。若项目规模不允许逐页人工点击，技术团队可以设计自动化检查，再人工复核失败项；工具的覆盖范围和例外也应记录。

发布后继续保存一份迁移记录，包括生效时间、最终 URL 映射、已验证入口、仍待处理项目和下次复查时间。业务人员发现旧资料仍指向过期地址时，应能提交 URL 和材料位置，而不是只描述“客户打不开了”。迁移表可以作为后续内容维护的输入，但不能替代访问日志、搜索数据或真实业务反馈。

若改版后出现页面访问异常，先根据实际症状定位：访问失败时查生产路由和发布状态；跳错页面时查映射规则；内容不匹配时重新判断承接关系；站内仍有旧链接时更新来源页；搜索工具显示的状态则由有权限的人复核。不要把每种问题都归因于“还没收录”。

将 URL 去向表做成上线验收的一部分，团队可以把“页面已经改版”拆成可确认的决定：旧内容去哪里、由谁确认、具体怎样验证、问题由谁处理。它不能保证搜索系统何时处理变更，也不能替代技术实施；它能让遗漏和未决事项可见，避免发布会结束后找不到某条旧入口的负责人。