WooCommerce 网店迁移清单，哪些要搬、哪些可以留下

新店上线后的那个周二。新网店看起来一切正常，每件商品都在该在的位置，然后邮件开始涌进来。一位顾客问，为什么要她重置一个从没改过的密码。另一位打来电话，说承诺给他的物流单号一直没收到，结果发现快递账户还连着旧网站。到了午饭时间，有人注意到那个原本在 Google 排第三的分类页，现在打开是 404。

这些都不是商品的问题。商品就是一个 CSV 文件，而 CSV 文件是早已解决的问题。真正让 WooCommerce 迁移翻车的，是那层从没人写下来的东西：插件时代搭起来的快递对接，指向一个没人看的邮箱的回复地址，以及 Google 花了六年才摸熟的五百个分类网址。

所以，这份 WooCommerce 迁移清单按网店实际出问题的方式来组织，按资产类别划分，而不是按日程划分。每一类都说明三件事：要带走什么，容易在哪里出错，以及该做的那一件事。在确定切换日期之前，把八类全部过一遍。

先定三条基本规则，因为如果不写下来，每一条都会在最糟糕的时刻引发争论。第一，明确冻结窗口，也就是从最后一次导出到修改 DNS 之间的这段时间，期间在旧店下的任何订单都不会出现在新店里；两小时比较从容，两天就意味着要手工对账。第二，旧店保留三十天，放在一个您仍然能登录的地方，因为头两周里有三分之一的问题，答案都要看旧店以前是怎么运作的。第三，确定快递、支付网关、邮件发送、域名注册商和 DNS 这些账户分别由谁负责，因为通常至少有一个是注册在已经离职的人名下。

不确定哪些项目适用于您的网店？通过申请表把域名和正在使用的插件清单发给我们，我们会在任何东西搬动之前，对照这份清单为您梳理迁移方案。这份梳理，正是大多数人最后花了两次钱才得到的那部分。

1. 商品、变体和分类树

WooCommerce 自带商品 CSV 导入导出工具，对于简单的商品目录，它够用。麻烦从可变商品开始。Woo 导出时是一行父商品加上每个变体各一行，而把它们绑定在一起的属性所在的列，对另一个平台来说毫无意义，必须经过映射这一步。四个尺码乘六种颜色就是二十四行，必须重新组装成一件商品，并且每个色块都对应正确的价格、库存数量和图片。

分类树是大家容易忘记的另一半，因为它在电子表格里是看不见的。对于技术性强的商品目录，分类层级承载着实实在在的商业逻辑。我们的 Intenze 案例中那家露营和房车帆布零售商，是我们手上最清楚的例子：遮阳篷、升顶帐篷帆布、罩布和支杆都有不同的适配规格，顾客要对照具体车型来选，因此分类树起的是搜索引擎的作用。凭记忆重建分类树，而不是把它原样带过去，迁移就会在不知不觉中丧失卖货的能力。

还有 CSV 不包含的东西：原始分辨率的图片（而不是 Woo 缩放过的副本）、属性集和色块排序、很少能完整导出的捆绑商品和组合商品、可下载附件，以及每件商品的运费类别和重量。后两者会影响第七项，如果跳过，它们会悄无声息地变成零。

• 要带走的：含变体的商品 CSV、原始图片文件、带排序的分类树，以及属性和运费类别的定义。
• 容易出错的：变体组装错误，以及捆绑商品到了新店只剩空壳，在列表视图里看起来却一切正常。
• 该做的：先手工核对五件最复杂的商品的每个变体、价格、图片和库存数，再去相信其余的数据。

2. 订单历史，以及把大部分留下的实在理由

直觉告诉您要全部搬过去。但对大多数网店来说，正确的做法是只搬很少一部分，其余的存放在可以查阅、而不必在系统里检索的地方。

订单记录是 WooCommerce 数据库里最乱的部分。老版本的安装把订单作为一种文章类型，分散存放在 posts 和 postmeta 表中；新版本则使用随高性能订单存储（HPOS）推出的专用数据表。无论哪种，每笔订单都冻结保存了当时的税务规则、配送方式、折扣码，以及指向您即将移除的插件的支付网关标识。把这些数据灌进另一套数据结构，得到的记录看起来像订单，却无法退款、无法重新发货，也无法对账。

所以，把大家想要订单历史的三个理由分开来看。财务需要的是总额和税款，CSV 导出已经足够。客服需要回答“我三月份那笔订单在哪里”，保留旧后台的查看权限就能解决。只有第三个理由，也就是让顾客看到自己过去的订单，才真正需要导入，而这主要对销售消耗品的网店才重要。

• 要带走的：未完成和未发货的订单、最近九十天的订单，以及此前所有订单的完整 CSV 存档。
• 容易出错的：花钱导入六年的订单，却没有可用的支付凭证，最后发现根本没人打开。
• 该做的：问一问负责退款的人，上个季度他们实际往回查了多久，就把导入时间范围设成那个数字。

3. 顾客账户和密码问题

顾客记录很好搬，密码却搬不过去，而这两句话之间的落差，会影响到您的每一位顾客。

WordPress 用加盐的单向哈希存储密码，所以没有什么可以转换的。您的新平台要么能通过兼容层导入这些哈希，要么不能；如果不能，每一位老顾客都要设置新密码。这不是一个技术脚注，而是一封要发给您全部顾客名单的邮件，如果事先不打招呼，它读起来就像钓鱼邮件，结果就是客服工单，以及悄悄不再下单的顾客。解决办法在于顺序：提前一天，用顾客已经熟悉的地址发一条简短通知，就能把一次安全惊吓变成一次产品更新公告。

记录的其余部分比较宽容，但很容易低估工作量。要带上已保存的账单地址和收货地址，因为一个已存的地址就是实打实地减少了结账阻力；同时要把同意标记原样带上，因为同意是不能想当然地转移的。已保存的支付方式留在原处，因为那些令牌属于创建它们的支付网关账户。商店积分和会员积分余额是您账上的负债，要手工对账，而且对两遍。

• 要带走的：顾客记录，包括已保存的账单地址和收货地址，以及原样记录的同意标记。
• 容易出错的：一封事先没有通知的强制重置密码邮件涌进成千上万个收件箱，读起来像钓鱼邮件。
• 该做的：现在就写好预告邮件，定在切换前一天发送，并且用您现有的地址发出。

4. SEO 资产，包括网址结构、301 映射、meta 和结构化数据

这是唯一一项可能让您损失一整年、而不只是一个周末的项目。其他所有问题都能在一个下午内补救；丢掉的排名，运气好也要两个季度才能找回来。

从您现有的结构出发。WooCommerce 把商品放在 product 路径下，把分类放在 product-category 路径下，前面往往还有一个商店基础路径，而 Google 收录的正是这些确切的字符串。如果新平台偏好不同的路径，您面临一个真正的选择：沿用旧结构，或者修改结构再做重定向。沿用几乎总是更省钱，而人们说服自己放弃它的理由，往往是审美上的，而不是商业上的。

如果您确实要修改路径，重定向映射就不是项目收尾时才做的事。从 Search Console 和 sitemap 导出所有已收录的网址，去重，然后把每一个都映射为永久 301 重定向。接着去找那些不是商品的网址：分页的分类页、被意外收录的筛选网址、旧的博客文章。Google 关于更改网址的网站迁移的指南值得通读：重定向必须是永久的、一对一的，并且第一天就要生效。

有两件事每次都会被漏掉。第一，SEO 插件写的 meta 标题和描述存放在该插件自己的数据表里，而不在商品记录中，所以标准导出会把它们落下；在停用任何插件之前，先把它们导出来。第二，结构化数据需要做一个决定，因为 Woo 会输出商品标记，大多数 SEO 插件也会输出自己的一份，于是很多网店多年来一直在输出两份重叠的标记。只保留一个输出源，并用富媒体搜索结果测试检查。

• 要带走的：已收录网址清单、插件中存储的 meta 标题和描述，以及一份关于由谁输出结构化数据的书面决定。
• 容易出错的：只给商品做重定向，漏掉分类、分页和旧博客网址，而流量正是从这些地方慢慢流失的。
• 该做的：在开发开始之前，用一张两列的电子表格做好 301 映射，并在测试环境里测试五十个重定向。

5. 商品评价

评价是最容易彻底丢失的资产，因为它们不在大家会去看的地方。WooCommerce 原生评价其实是评论，存放在评论表里，带有评价类型标记，评分放在元数据中，而不在商品导出文件里。如果只用商品 CSV 迁移，评价就直接消失了，通常要一周后有人问“星级怎么没了”才被发现。

如果您用的是第三方评价插件，评价存放在该服务商的系统里，而不在您的数据库中，导出要提交支持请求。尽早提，因为有些服务商要两周才处理，还有几家会把它当成挽留客户的谈话。

无论来源是什么，都要坚持导出文件包含那些让评价有价值的字段：评分、正文、评价人姓名、原始日期、已验证购买标记和照片。打上本月日期的评价看起来像是伪造的，会打乱顾客浏览时依赖的时间顺序；如果您还同时输出评价结构化标记，那就等于在发布不真实的日期。最后一个坑：评价是通过一个内部标识与商品关联的，这个标识在迁移后不会保留，所以必须按 SKU 重新关联。

• 要带走的：评分、正文、评价人姓名、原始日期、已验证购买标记和照片，并按 SKU 关联。
• 容易出错的：评价存放在评论表或服务商的平台里，商品导出会把它们全部落下。
• 该做的：第一天就把评价单独导出成一个文件，并确认原始日期也一并导出了。

6. 交易邮件，以及没人负责的回复地址

订单确认、发货通知、密码重置和退款通知，是顾客真正会打开的邮件。在 WooCommerce 网店上，它们通常同时由三方产生：Woo 核心负责订单邮件，一个插件负责发送基础设施，有时还有一个营销工具接管了邮件模板。

切换之前，先盘点两件事。第一，会发出哪些邮件，各自由什么触发；这份清单比老板预想的要长，而一封停止发送的邮件在顾客投诉没收到物流单号之前是没人察觉的。第二，也是最容易出问题的一点，发件地址是什么，回复实际会落到哪里。在老网店上，这两者常常各走各的：网店用一个不接收回复的地址发信，顾客照样回复，回复就石沉大海。把这一点管起来，是 Intenze 迁移中一项实实在在的收获：回复地址不再是藏在某个插件设置页里的一个字段，而是变成了同一个后台里的一项设置，看邮件的人自己就能修改。

发件人认证也不会随内容一起迁移。SPF、DKIM 和 DMARC 是 DNS 记录，指向的是您之前用来发信的服务，所以新的发信服务需要新的记录，并且要在第一封确认邮件发出之前完成验证。在最忙的那一天用未经认证的身份发信，确认邮件就会在顾客正等着它的时候掉进垃圾箱。

• 要带走的：每一封由事件触发的邮件、发件地址、真实的回复目的地，以及您当前的 SPF、DKIM 和 DMARC 记录。
• 容易出错的：用不接收回复的地址发信，回复全部消失；发件人记录未经验证，导致上线当天确认邮件进了垃圾箱。
• 该做的：在测试环境里下一笔真实的测试订单，回复确认邮件，确认回复能到达一个有人查看的邮箱。

7. 配送和履约对接

到了配送这一步，迁移就不再只是一个网站项目了。这里没有任何东西是作为数据迁移过去的，全部都是需要有意识地重新搭建的配置。它之所以会出问题，是因为在第一笔真实订单到来之前，它看起来简单得不值一提。

先看运费规则：配送区域、重量和价格区间、免运费门槛、偏远地区附加费、每件商品的运费类别、超大件处理。对于运营多年的网店，这些规则凝结着来之不易的商业经验，而且常常分散在两三个插件里，以没人记录过的方式相互作用。在停用任何东西之前，把每一个配置页面都截图保存。

然后是快递对接，它有自己的凭据，需要针对新网店重新授权。随之而来的是真正节省时间的部分：已付款的订单直接进入履约系统，不用任何人重新输入地址；物流单号自动返回给顾客，不用任何人复制粘贴。这种自动化就是对接的全部价值所在。在 Intenze 网店上，这部分从一个需要有人维护的插件变成了平台自带的能力，详见我们的配送应用页面。到店自提、线上下单门店取货和本地配送需要各自单独测试一轮；如果运费和商品的计税方式不同，税务也要单独测试。

• 要带走的：每一条运费和区域规则的截图、每件商品的运费类别，以及指定了负责人的快递账户凭据。
• 容易出错的：把配送当作一项设置而不是一项对接，等切换之后才去重新授权快递对接。
• 该做的：在测试环境里下三笔测试订单，一笔普通件、一笔超大件、一笔偏远地区件，并为每一笔打印一张真实的面单。

8. 可以删掉的插件清单

最后反过来看。前面每一项问的都是您要带走什么，这一项问的是您刻意不带走什么，而正是这一项，让整个项目物有所值。

打开插件页面，把所有插件都写下来，因为我们接手的大多数 Woo 网店都装着十五到四十个插件。把每一个分到三堆里。第一堆是新平台已经原生支持的：商品集合筛选、通知工作室停工一周的横幅、评价展示、Cookie 提示、图片优化、缓存、安全和备份。在现代技术栈上，这些根本就不是扩展，每去掉一个，就少一笔订阅费，也少一个兼容性风险。第二堆是确实与您的业务相关的，需要在切换前给出真正的解决方案。第三堆是没人说得清用途的插件，数量总是比预想的多。

第一堆能为您省下两笔开支。显而易见的是许可证续费。不那么显而易见的是维护税：总得有人去更新插件，当顾客反馈结账出问题时，总得有人去排查是三十家供应商中的哪一家搞坏的。如果正是这笔账让您读到了这里，完整的论述见我们的 WordPress 替代方案页面。

• 要带走的：列出所有在用的插件，并分为原生已有、业务专属和用途不明三类。
• 容易出错的：出于习惯去重建某个插件的功能，其实平台早已具备，只是没人去核对。
• 该做的：在切换前一周停用用途不明的那一堆，看看有没有人提出来。

9. 按顺序推进，不要一次性全切

第一步盘点：趁旧店还在正常运行，把第一到第八项全部以清单和截图的形式记录下来。第二步搭建和导入，放在项目组以外的人无法访问的测试环境里。第三步测试，用真实订单而不是点点按钮：下单、付款、退一笔款、发一笔货、回复确认邮件。只有完成这些之后，才去切换 DNS。切换之后，盯住 Search Console 的覆盖率和 404 报告，看重定向映射有没有漏洞；盯住每一笔已付款订单是否都进入了履约流程；还要盯住客服收件箱，它能兜住前两项漏掉的一切。

• 要带走的：一份分四个阶段的计划，每个阶段都有指定负责人和日期。
• 容易出错的：在测试环境里还没有完成真实下单、付款和退款之前，就切换了 DNS。
• 该做的：把切换安排在某个工作日的上午，并让旧店在三十天内保持可查阅。

常见问题

WooCommerce 迁移需要多长时间？
对于几百件商品、配送规则常规的网店，需要的是几周而不是几个月，而且大部分时间花在盘点和测试上，而不是搭建上。拉长周期的几乎从来不是商品数量，而是捆绑商品、特殊的配送逻辑，以及等待第三方。

离开 WooCommerce 会丢掉 Google 排名吗？
只要网址结构得到保留，或者第一天就用永久 301 完整重定向，并且 meta 数据也迁移过去了，就不会。排名损失几乎总能追溯到某个具体的失误：漏掉了分类重定向、meta 标题困在插件的数据表里，或者测试环境的 noindex 忘了关。Google 重新抓取期间，会有短暂的波动。

我应该迁移订单历史吗？
迁移未完成和近期的订单，其余的以 CSV 存档，并保留旧后台的查看权限。导入的历史订单没有可用的支付凭证，本来就无法退款或对账。例外是销售消耗品的网店，对它们来说，从历史订单中复购正是关键所在。

顾客需要重置密码吗？
通常需要，因为 WordPress 的密码哈希是单向的，很少能移植。把它当作一项沟通任务来处理：提前一天用顾客熟悉的地址宣布迁移，让重置邮件成为意料之中的事，而不是看起来像钓鱼邮件。

我的商品评价怎么办？
评价需要单独导出。Woo 原生评价存放在评论表里，不在商品 CSV 中；第三方评价存放在服务商的系统里，需要提交请求。坚持要求保留原始日期和已验证购买标记，并按 SKU 重新关联。

精简版

一共九项，而真正让人头疼的，并不是那些看起来难的。商品是一个文件。订单是一个关于哪些值得带走的决定。密码是一封提前一天发出的邮件。SEO 是唯一一项会造成长达十二个月损失的，所以它值得一张电子表格和五十个重定向的测试。评价是最常被彻底丢失的资产。邮件和配送是对接，不是设置，两者都需要一笔真实的测试订单来验证。

我们在真实的网店上执行过这份清单，其中包括为一家新西兰露营和房车帆布零售商完整迁移 WooCommerce 商品目录，我们如何界定这类工作的范围，详见我们如何处理网站救援和迁移。如果您想在做任何决定之前先拿到迁移梳理，请通过申请表发来您的域名和插件清单。无论您最终是否迁移，这份逐项资产评估都归您所有。