从 WordPress 迁移到定制网站：何时值得做，需要准备什么

工作需要时再迁移

如果现有网站总是妨碍企业完成必要工作，定制网站可能值得投资。也许编辑得在多个地方重复输入同一信息；也许咨询要按规则分给不同团队，而规则已越来越难维护；也许产品目录不断扩大，现有页面结构已容纳不下。

遇到这些情况，可以围绕人们实际要完成的工作设计内容、编辑界面和系统连接。例如，编辑可以只录入一次活动，日期便在全站一致显示；员工收到咨询时，也可能同时看到相关客户资料。你还能商定下一步真正重要的改动，而不用把每项需求都硬塞进现成插件。

这些改进需要设计、开发和测试。仅仅替换 WordPress 并不会自动实现。规划不周的定制系统，可能让编辑工具更难用，维护费用却更高。

先用业务语言说清问题：人们做什么事困难、发生多频繁、耗费多少时间或错过多少工作，以及怎样才算解决。然后比较实现途径。选能满足需求、有人能持续运营、负担最小的方案。

你需要的是哪一种改动？

“做一个新网站”可能指几种完全不同的项目。比较报价前，先弄清自己要买什么。

如果网站本身合适，只是运营方式出了问题，更换服务商也许就够了。我们另有一篇关于不重建网站而更换服务商的指南，专门讨论这项决定。

无头 WordPress 确实是一种选择：WordPress REST API 允许独立应用在权限范围内处理内容。但这不表示每个插件的数据或行为都能通过该 API 获取。新前端仍可能依赖旧的内容结构和插件规则。要问清它解决什么、哪些部分留在 WordPress，以及由谁维护两者的连接。

什么时候保留 WordPress 更合适

如果团队发布内容顺手，所需功能运行良好，改动也比较容易，继续使用可能是明智选择。普通的发布需求，并不足以成为重建网站的理由。

即使网站难用，问题也可能修得好。页面慢，可能要检查图片、托管、数据库操作或某个功能。编辑界面难用，也许通过更清楚的内容结构或更好的 WordPress 开发就能改善。应看问题及其后果，而不能只数插件数量就下结论。

也要比较合适的标准平台。如果现成平台已能妥善处理预约、商店或内容发布，配置它并谨慎迁移，后续工作可能少于定制系统。

企业自身的投入也重要。需要有人决定定制系统该做什么、检查是否做到了，并支付维护费用。技术维护可以外包，但企业仍需要能做决定、验收工作的人。如果缺少这种能力，容易管理的现有平台可能更合适。

查清网站实际在做什么

页面数量是起点。迁移范围还取决于页面背后的内容、关联和工作。

和使用、运营网站的人一起梳理，也要包括访客看不到的部分：

• 内容：页面、文章和其他内容类型；分类与标签；作者与发布日期；译文及其相互关系。
• 媒体：原始图片和其他文件、说明文字、替代文字、附件，以及每项素材用在何处。
• 查找内容：菜单、搜索、筛选、网址格式、现有重定向、SEO 标题与描述，以及哪些页面应被搜索引擎收录的规则。
• 访客操作：表单、确认消息、邮件发送、登录、账户访问和权限。
• 连接的工作：客户或财务系统、邮件工具、分析、导入导出、定时任务及其他后台工作。

逐项决定保留、替换还是停用。记下谁有权决定，以及如何确认结果可用。废弃的插件或许可删掉；另一个插件可能一直在悄悄把销售团队依赖的咨询发给他们。

如果你销售商品、会员资格或接受预约，应为这些工作单独确定范围。商品、订单、客户访问权限、续费、可用名额和连接的服务商都需要明确决定。迁移内容并不能解决正在进行的订阅或现有预约如何延续。调查实际系统和服务商后，才能承诺哪些数据可以迁移。

像设计公开页面一样认真设计编辑工具

离开 WordPress 后仍然可以保留后台管理系统。要具体规定它应让团队完成什么。定制开发不会自动带上编辑习惯使用的每一项功能。

决定每种内容包含什么。活动可能有日期、地点、预订链接和相关文章。给每部分独立字段，便于复用和校验，但也要商定例外怎么处理：跨越几天的活动、地点未定，或日后才添加预订链接。

还要商定谁能创建、批准和发布内容。按团队需要，考虑草稿、定时发布、预览、修订历史、媒体管理、菜单、搜索和重定向编辑。明确编辑如何改错，以及能否撤销修改。

验收编辑工具前，让真实用户用它完成代表性的工作。请人准备文章、加入图片和替代文字、在手机上预览页面、安排发布时间、修正错误，再找出一篇旧文章。观察他们在哪些地方需要帮助。让自己的团队完成日常工作，比观看一场漂亮的演示更能说明问题。

哪些能迁移，哪些必须重建？

WordPress 有导出工具。其 WXR 导出格式包含文章、页面、自定义内容类型、评论、字段、分类和标签等有记录的内容。这些是有价值的源数据，但不是整个网站的可运行副本。

负责迁移的团队要检查你的网站实际上保存了什么：数据库、上传文件、导出文件、API 响应及插件专用记录。转换之前先安全保存原件。找出每个必需字段的位置，以及记录之间如何关联。

字段映射，就是决定每个旧值在新系统里放哪里。作者仍须对应正确的文章；分类可能变成主题；相关文章链接须指向该文章的新版本。缺失值和重复内容要按事先商定的方法处理，不能悄悄丢弃。

图片需要单独迁移和检查。确认文件存在于新位置，仍关联正确内容，并能以合适尺寸加载。必要时更新文章内嵌图片和下载链接。迁移后的页面能显示图片还不够，因为图片可能仍由计划关闭的旧网站提供。

内容版式也要检查。WordPress 解释过，内容块可以保存标记和属性，动态块则可能只保存占位符，稍后才生成显示结果。因此复制过来的文章可能含有新系统不认识的指令。页面构建器也有自己的结构，需单独检查。

解决办法可能是把内容转换成新系统支持的组件、重建部分版式，或经编辑同意后简化旧页面。复制可见的 HTML 有时能保留外观，但不能证明编辑今后能正确修改。公开呈现和编辑行为都要约定。

一个小型出版社的例子

想象一家出版社要迁移 WordPress 网站。这是假设例子，不是客户成果。测试文章包含作者、主图、两篇相关文章，以及一个广告咨询表单。

标题和正文导入成功后，团队还要检查作者和发布日期是否保留、相关文章是否指向正确页面，以及图片、说明文字和替代文字是否都已迁移。编辑打开文章、修改导语并预览结果。这样同时测试内容和编辑方式。

表单是单独一项工作。替代品必须收集约定的信息，保存或发送到指定位置，并给访客有用的确认。有人提交测试信息，再检查是否真的收到。旧页面上有表单，不表示其行为会随文章一起迁移。

此时出版社对四件事已有证据：文章、图片、编辑的一项工作和访客的一次咨询。对网站其他不同结构重复这种检查，比一句“文章可以导入”更能为项目范围提供依据。

保留有用的网址，审慎规划变更

替换内容系统时，通常可以保留域名和现有页面路径。对仍有用的网址，要明确提出保留要求。更换 CMS 不需要同时换域名或网址格式。

必须改网址时，把旧地址对应到合适的新页面，并测试重定向。不要把所有旧页面都转到首页。停用文章、合并主题和迁移产品，应按照访客原本想找的内容分别决定。

Google 关于网址变更迁移的指南讨论网址映射、永久重定向，以及规范网址、内部链接、图片、语言版本关联和站点地图的检查。规范网址告诉搜索引擎你希望以哪个页面版本为准；要确认它指向正在使用的新页面，而不是测试站或旧地址。

检查全文的标题和描述、收录规则、各语言路径及链接。上线时正确处理测试环境的限制：需要保密的测试站继续保持私密，计划公开的页面则必须可访问、可被收录。

Google 的地址变更工具用于迁移域名或子域名。仅在原网址上替换 WordPress，本身不需要使用该工具。

重大改动之后，搜索排名可能波动。约定监测什么、由谁调查缺失页面或异常流量变化，以及如何修正。不能负责任地把迁移计划说成零排名损失或自动增长的保证。

约定上线前必须能正常完成的工作

围绕网站必须完成的工作制定验收检查。比较内容、图片和链接，再测试实际行为。表单应把消息送到正确位置，搜索应找得到代表性内容，有权限的用户应能登录，无权限者应被拒绝。编辑应能完成约定的任务。

如果范围包括购买、预订或系统集成，也要测试这些流程及其重要例外。若连接的系统还需接收记录，页面显示成功只是结果的一部分。

使用受保护的测试环境完成这些工作。限制私人信息访问，防止测试向真实客户发消息或触发意外的线上操作。约定可使用哪些数据，以及如何处理测试副本。

规划新网站准备期间发生的改动。可以短暂停止发布并迁移最后的修改，或安排把首次导入之后新增的记录再迁移一次。说明每个阶段由哪个系统保存权威记录。否则编辑可能在一处修正文章，访客却在另一处提交咨询。

我们的系统替换期间新旧系统并行运行指南，进一步讨论了这些责任归属和过渡决定。

也要商定现实可行的回退方案。WordPress 的备份指南区分恢复所需的数据库和文件。有副本只是起点；团队仍要证明所需服务能恢复。我们关于网站备份究竟应恢复什么的文章说明了检查方法。

新网站一旦收到咨询、订单或编辑内容，或向其他服务发送指令，切回旧网站就会复杂得多。必须核对这些记录和操作。不能认为恢复昨天的数据库就能保住今天的业务。上线前要定好回退条件和负责人。

成本和工期取决于什么？

内容数量很重要，内容的多样性也同样重要。结构统一的几千篇文章，可能比数量较少但各自有特殊行为的页面更容易预测工作量。

可比较的报价应解释工作背后的假设：

• 要调查并转换哪些内容结构、自定义块和插件记录？
• 包括哪些集成、账户、交易和语言？
• 计划调整多少设计、整理多少内容？
• 需要哪些编辑功能、权限和培训？
• 包含哪些测试、上线保障、连续运营安排和后续工作？

也要预留团队自己的时间。人们需要提供访问权限、回答问题、决定停用什么、整理内容、试用编辑工具并验收成果。如果决策人无法参与，即使开发准备好了，工作也可能停下来。

要求供应商区分已确定的工作和仍需调查的事项。先试迁移一页复杂内容或依赖插件的功能，能在投入整个项目之前消除昂贵的不确定性。只看未经检查的导出文件就报固定价，可能掩盖供应商之间截然不同的假设。

比较各方案的运营成本，也要比较建造费用。纳入托管、许可、外部服务、补丁更新、备份、监控、支持及后续改动。保留 WordPress 有成本，定制软件也有成本。真正有用的比较是：在计划使用的期间，每条路线交付什么，以及责任是否清楚。

定制系统以后由谁照看？

选择方案时就要谈好。定制网站仍依赖软件框架、程序库、托管和连接的服务，这些依赖都需要维护。安全也是持续工作：WordPress 自己的安全指南介绍风险降低和共同责任。换平台不会消除分配这些责任的必要。

把补丁更新、备份、监控和事故支持写进协议。说明谁收到警报、谁能处理、紧急问题如何报告，以及实际包含哪些支持。除了故障，也要安排日常改进的流程。

明确访问和交接事项：托管及部署账户、凭据、数据导出、文档、许可，以及适用时的代码仓库或源代码访问。仅有源代码访问权，并不等于著作权转让，也不能保证另一家供应商能够运营系统。有效交接还应说明如何部署、恢复，以及如何处理依赖。

Google 的 Acacio Cruz 和 Ashish Bhambhani 在服务就绪经验文章中谈到文档、培训和运营责任的转移。小企业不需要照搬 Google 的团队结构，但接手的人必须有知识和访问权限，才能完成工作。

LINK-V 提供网站和定制系统、迁移、集成、设计及持续维护。开发、权利、交接和后续维护需要按项目约定。你可以根据所需工作，了解定制开发或单项服务。

首次沟通要准备什么

不必带着技术规格来。准备足够的信息，让问题看得见：

• 现有网站，以及谁掌握其后台、托管、域名和连接服务的访问权限。
• 反复遇到的困难、一个具体例子，以及你希望人们今后能怎样处理。
• 必须保留的内容、功能和有用网址，以及打算停用的东西。
• 应参与测试替代网站的编辑和其他用户。
• 连接的服务、重要交易或发布日期，以及企业能承受多长中断。
• 关于成本、权利、访问、支持和未来改动的问题。

这样，下次沟通就有了实际目标：判断改进现有网站是否足够、找出未知事项，并约定在决定重建前必须证明什么。