企业官网改版前，哪些历史数据和页面必须先盘点？

企业官网改版最容易被低估的一步，不是设计，也不是开发，而是改版前的资产盘点。很多项目一上来就讨论新首页、视觉风格和栏目结构，直到准备上线才发现：旧站还有持续带来搜索流量的 URL、客户长期收藏的产品页、被外部网站引用的 PDF、正在工作的表单通知、统计代码和第三方接口。

这时再补盘点，项目通常会变得被动。更稳妥的做法，是把旧站当成一套正在运行的业务资产，而不是一批“准备被新页面替换的旧文件”。

改版前不要只导出页面。至少要把下面几类资产放进同一个盘点范围里：

这一步的目的，是先回答“旧站有哪些东西不能无声消失”。只有这个问题清楚，新站才有资格开始做迁移决策。

• URL：所有仍可访问的栏目页、产品页、服务页、案例、文章、下载页和历史落地页。
• 搜索入口：有曝光、点击、排名或品牌查询的具体页面，而不是只记全站流量。
• 内容资产：产品参数、服务说明、案例、FAQ、下载资料、图片和视频。
• 外部引用：第三方网站、客户资料、社交账号、广告或邮件里仍然指向的旧地址。
• 转化链路：表单、电话、邮件、WhatsApp、下载、预约、CRM 入库和通知动作。
• 技术依赖：统计代码、验证文件、接口、Webhook、Cookie、定时任务和第三方脚本。

一份真正有用的 URL 清单，至少要让后续开发、SEO 和内容人员直接做决定。只有旧地址，没有页面类型、价值判断和新地址，到了上线阶段仍然要重新调查。

建议每个 URL 至少补齐这些信息：

如果 URL 数量很多，可以把 Sitemap、站内抓取、数据库内容和 Search Console 页面数据合并去重，再人工分类。不要只依赖菜单，因为最容易遗漏的恰恰是已经退出导航、但仍然被搜索引擎和老客户访问的历史页面。

• 旧 URL：当前真实可访问地址，不要只抄导航菜单里的链接。
• 页面类型：首页、产品、服务、案例、文章、下载、活动页或其他类型。
• 当前状态：200、跳转、404、软 404、异常或无法访问。
• Canonical：当前页面实际声明的规范地址。
• 搜索价值：是否有自然搜索曝光、点击、排名或稳定查询。
• 业务价值：是否被销售、客户、售后、广告或外部资料长期使用。
• 外链情况：是否有第三方网站或合作伙伴仍在引用。
• 新 URL：改版后准备承接它的正式地址。
• 处理动作：保留、重定向、合并、归档、下线或待判断。

改版前只记“网站每月有多少流量”帮助不大。上线后即使总访问量差不多，也可能是核心业务页下降、无关内容页上升。需要保护的是具体入口和具体搜索意图。

建议至少保存：

业务有明显淡旺季时，最好保留能够覆盖完整业务周期的数据。否则上线后的正常季节波动，很容易被误判为改版损失。

• 自然搜索曝光：按页面、查询、国家和设备拆分，识别真正有搜索资产的入口。
• 自然搜索点击：重点看业务页、产品页和长期稳定获得点击的文章。
• Landing Page 访问：确认哪些页面是客户第一次进入网站的入口。
• 转化页面：哪些页面真实产生过表单、电话、邮件、下载或其他有效动作。
• 品牌词与业务词：区分“找公司名称的人”和“找业务解决方案的人”。
• 时间范围：保存足够长的正常周期，避免只拿上线前几天作为基线。

很多网站改版的验收只看“页面能打开”。真正影响业务的往往是那些页面背后的链路。

需要逐项验证：

如果企业当前没有完善的 CRM，也至少要保存一份真实提交后的去向和通知链路。否则新站上线后最危险的不是“少一个动画”，而是客户提交了需求却没人收到。

• 表单字段是否与旧站一致，哪些字段新增、删除或改名。
• 提交成功后是否仍会通知正确负责人，而不是只显示“提交成功”。
• 线索是否继续写入 CRM、邮箱、企业微信或其他系统。
• 电话、邮件、即时通讯按钮是否仍然指向正确联系人。
• 文件下载链接是否迁移，旧 PDF 或规格书是否仍能访问。
• 广告转化、分析事件和埋点是否随着新模板一起恢复。
• 隐私同意、Cookie 或地区规则是否因为新前端被漏掉。

旧站里的媒体资产经常被低估，因为它们不一定出现在导航里，但可能被搜索引擎、客户文档、外部文章或销售长期引用。

盘点时建议特别关注：

不是所有旧文件都必须永久保留，但每个高价值附件都应该有明确处理结果：保留原 URL、迁移到新 URL、做文件级重定向，或者确认无价值后下线。

• 产品规格书、说明书、检测报告、白皮书等 PDF。
• 被文章、案例和产品页长期使用的图片路径。
• 外部网站直接引用的媒体 URL。
• 文件名虽然旧，但已经被客户收藏或搜索引擎收录的附件。
• 新站准备重新压缩或改格式的图片，是否仍保留原引用关系。

视觉和栏目盘点完成后，还需要单独做一次技术依赖检查。很多“新站看起来完全正常”的事故，都是这里漏掉的。

重点检查：

从项目实施角度，我们更建议把这些依赖写成清单并指定负责人，而不是靠某个开发人员“记得旧站还有这个东西”。

• 域名 DNS、HTTPS、证书续期和强制跳转规则。
• robots.txt、XML Sitemap、Canonical、noindex 等搜索控制。
• Search Console、分析平台和第三方验证文件。
• API、Webhook、邮件 SMTP、短信、地图、客服和支付等外部服务。
• 定时任务、缓存清理、图片处理、备份与同步脚本。
• 旧后台字段与新系统字段是否存在兼容和映射关系。
• 测试环境的限制是否可能被带到正式环境。

页面和依赖一多，所有事情都标成“重要”就等于没有优先级。一个实用做法，是按失败后的业务损失来分层。

这种分层能帮助团队在上线窗口里先守住真正不能出错的部分，也方便验收脚本把 P0/P1 作为强制 Gate。

• P0：一旦丢失就会直接造成客户无法访问、无法提交需求、核心业务页 404、关键接口中断。
• P1：不会立刻中断业务，但会造成搜索入口、外链、重要附件或高价值内容损失。
• P2：可以在上线后短期补齐，例如低流量历史内容、次要图片或非核心样式细节。
• 待判断：现阶段无法确认价值的资产，不要直接删除，先进入人工复核。

盘点不是为了制造文档。它必须转化成后续设计、开发、SEO 和验收都能直接使用的实施依据。

建议最终至少形成：

这五类输出完成以后，下一篇《网站改版怎样减少对原有SEO资产的影响？》才真正有实施基础。没有旧 URL 和页面价值的前像，301、Canonical、Sitemap 都只能临时猜。

• URL Mapping：旧 URL、新 URL、处理动作、优先级、负责人。
• 内容迁移清单：保留、重写、合并、删除，以及每项内容的责任人。
• 媒体与附件清单：图片、PDF、下载文件、公开路径和使用页面。
• 转化链路清单：入口、字段、通知对象、CRM 去向、统计事件和实际测试结果。
• 技术依赖与上线基线：接口、脚本、验证文件、核心页面状态、搜索数据、流量和转化前像。