改版上线不是收尾，真正危险的是“看着没问题”

新首页打开正常、导航能点、手机端也没有明显错位，很多团队到这里就会把项目交给运营。问题往往也从这里开始。搜索引擎访问的是一批具体网址，广告和邮件带来的访客会经过表单、感谢页和统计代码，海外客户还可能进入不同语言、不同地区的页面。页面能打开，只证明浏览器收到了内容；旧网址的权重有没有传到新网址、询盘有没有记进分析系统，是另外两回事。

所以，上线后的第一件事不是继续改文案，而是把迁移当天的状态固定下来。旧网址、新网址、重定向状态、规范网址、语言版本、是否允许索引、上线前的自然搜索点击、历史询盘和主要外链，都应留一份可追溯的记录。以后某个国家的流量突然下降，或者一类产品页迟迟没有恢复，这份记录能让人很快分清：是季节波动、页面内容变化，还是迁移本身断了链路。

外贸站改版上线后的成品视觉

上线前三天，先把链接和询盘跑通

有网址变更的页面，应从旧网址直接跳到最对应的新页面，通常使用服务端永久重定向。能一跳到达，就不要让旧网址先跳一次、再经过另一个地址。也不要把已经删除的产品页一股脑导向首页；找不到真正对应的内容时，保留清楚的下架说明、提供合理替代，或者返回正确的不存在状态，往往比制造“假正常”更稳妥。

这时要用爬虫把新站完整走一遍，但不能只看有没有 404。还要看站内链接是否已经换成新网址，站点地图里是否只保留可索引、返回 200 的规范页面，页面有没有误带 noindex，robots.txt 是否挡住了需要抓取的目录，canonical 是否指向自己真正希望收录的版本。更换域名时，新旧域名都应在 Search Console 中验证；符合条件的迁移可以使用地址变更工具，并提交新站点地图。Google 目前仍建议永久重定向至少保留一年；考虑到外链、收藏夹和旧邮件长期存在，业务允许时保留更久通常更省事。

技术检查做完，当天还要走一次真实询盘。分别从电脑和手机进入主要落地页，提交英文及重点语种表单，检查成功提示、通知邮件、CRM 入库、来源渠道和感谢页事件是否齐全。只在后台看到一次测试事件还不够，销售实际收到的线索里，也要能看见页面、国家、来源和时间。站点迁移后最不该发生的情况，就是流量还在，询盘却因为表单、邮件或统计代码的小问题悄悄丢掉。

外贸站迁移后的链接核查

内容维护要慢一步，但不能停

刚上线就把所有产品页重写一遍，很难判断后面的波动到底来自迁移还是内容变化。比较稳的做法，是先让关键页面保持一段可观察的稳定期。产品参数、认证状态、交期、适用市场、下载文件等确有错误的内容立即修；纯粹为了“焕新”而大改标题、正文和页面意图，可以等抓取、索引和主要询盘确认正常后再分批进行。

更新顺序也不必按栏目平均分配。先看带来询盘的落地页，再看有稳定搜索点击或外链的页面，随后处理重点产品、重点国家和销售经常发给客户的资料页。一个长期没有流量、没有外链、也没有业务用途的旧页面，不值得因为“保持更新”反复换词。相反，产品规格已经变了、证书过期了、下载文件还是旧版本，即使页面流量不大，也应尽快处理，因为这会直接影响客户判断。

内容更新需要留得下依据。产品数据从哪里来、由谁确认、哪一天复核，最好写进内部内容台账；页面上可以自然呈现更新时间、作者或审核人、适用条件和原始资料链接。不是每篇文章都要挂一串头衔，也不要只改日期制造“新内容”。真正有用的是让客户和搜索系统都能看清：这项参数是否仍然有效，这个判断依据什么，在什么情况下不适用。

这对 AI 搜索同样重要。Google 对 AI 搜索功能给出的公开说明，并没有要求网站增加一套专门的 AI 标记；页面仍要先满足可抓取、可索引、内容有用和预览控制等基础条件。红数科技在维护这类站点时，更看重企业名称、产品型号、规格、认证、应用场景等关键事实是否前后一致，页面上的结构化数据是否与客户实际看见的文字一致。信息写得清楚、来源能核验，比堆一批所谓“AI 关键词”可靠得多。

外贸站内容与多语言页面维护

多语言站最容易在小地方掉流量

外贸站通常不是把中文页翻成英文就结束。英语面向哪些市场，西班牙语页面是给西班牙还是拉美客户，产品名称、计量单位、认证和交付说明是否适合当地，这些都会改变页面内容。每个语言或地区版本应有稳定、独立的网址，并通过 hreflang 互相标注；页面自己也要包含在这组标注中。canonical 一般应指向同语言中真正的规范页面，而不是把所有语言版本都指回英文首页。

不要只按 IP 或浏览器语言强制跳转。海外采购人员可能在中国办公室查看英文站，也可能通过 VPN 访问；搜索爬虫更不一定来自目标国家。保留清楚的语言或地区切换入口，让用户自己选择，通常更稳。页面下线、合并或改名后，对应的 hreflang、站点地图、站内链接和 canonical 要一起改，不能只处理页面正文。

数据维护不是看一条总流量曲线

迁移后只看“全站访问量下降了多少”，经常会得出错误结论。更有用的拆法，是按旧网址与新网址、目录、产品类别、国家、设备、搜索渠道和询盘结果来看。某个访问量很大的资讯目录下降，未必影响业务；一个流量不高但一直能带来询盘的产品页失去收录，反而需要马上处理。

上线日期、代码版本、重定向调整、表单修改和大批内容更新，都应记在同一份变更日志里。分析工具中的事件名称、参数和转化口径尽量保持连续；确需重命名时，要保存新旧字段的对应关系。跨域支付、第三方表单、Cookie 同意管理、UTM 参数和 CRM 线索字段，也要一起验证。否则报表里出现的“自然流量下降”或“直接访问上升”，可能只是来源参数在跳转中丢了。

Search Console 适合看搜索曝光、点击、索引和页面体验，分析工具负责站内行为，CRM 才能说明询盘有没有成为有效商机。三边不能靠一个总数硬拼。比较时至少保留上线前的基线，同时看环比和同比，避开节假日、展会、广告停投等业务变化。页面级数据量较小时，不必因为一天的波动马上改站；但表单提交突然归零、核心目录大量返回 5xx、重要页面被 noindex 或 canonical 到别处，这些不需要等周报，应当立即排查。

页面体验也要持续看真实用户数据。当前 Core Web Vitals 以 LCP、INP 和 CLS 为核心指标，Google 给出的“良好”参考线分别是 2.5 秒以内、200 毫秒以内和 0.1 以内，并以第 75 百分位评估。测速工具的一次高分不能代替真实数据，尤其是图片较多、第三方脚本较重的产品页，桌面端正常并不代表海外移动网络下也正常。

外贸站搜索与询盘数据看板

一个能长期执行的维护节奏

上线后的 0 至 72 小时，适合盯可访问性、重定向、索引控制、站点地图、关键表单和统计事件。前两周每天看核心页面有没有新的抓取、排除和服务器错误，确认旧网址的搜索点击正在转到对应新网址。这个阶段不要同时推进大规模内容重写。

接下来的一个月至三个月，可以改为每周复盘。把自然搜索点击、重点词曝光、落地页访问、有效询盘和页面异常放在一起看，按目录和国家找问题。需要更新内容时，每次处理一组有明确业务关系的页面，并在变更日志中记清范围。这样即便数据变化，也能知道是哪次改动造成的。

等收录、主要排名和询盘链路稳定后，再进入月度维护。此时应持续清理过期资料，补齐新产品和真实客户问题，复核多语言版本，检查重定向、外链落点、结构化数据和页面速度。半年或一年后，迁移台账仍然值得保留；它不仅用于复盘这次改版，也会成为下一次换域名、换系统或调整目录时最可靠的底稿。

外贸站迁移后的维护，归根结底不是“每天发多少篇文章”，而是让旧链接有去处、关键事实有人负责、询盘数据能追到来源。三件事接得住，改版才算真正上线。

资料核验