本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

5 WordPress Migration Mistakes That Can Cause Website Downtime

您的新托管环境已准备就绪。WordPress 文件已完成传输。主页加载完美。然而，当有人尝试下单时，结账功能却停止了工作。网站迁移往往在真正完成之前就显得非常成功。迁移 WordPress 网站不仅仅是在服务器之间传输文件。成功的迁移需要保护数据库、功能、电子邮件配置、安全设置以及网站用户的使用体验。以下是可能导致不必要停机的五个常见错误，以及如何避免它们。

1. Migrating Without a Tested Backup

Creating a backup is usually the first item on a migration checklist. But having a backup file doesn’t guarantee that you can restore your website successfully. A complete WordPress migration may involve several components: WordPress application files and themes, installed plugins and uploaded media, the WordPress database, important configuration files, and server-specific settings. Before starting, confirm that you have a recent backup and know how to restore it. For a busy WooCommerce store or membership website, consider how new orders, accounts and other database changes will be handled during the migration window. Practical advice: Test the restoration process in a separate environment before depending on that backup.

1. 在没有经过测试的备份的情况下进行迁移

创建备份通常是迁移清单上的第一项。但拥有备份文件并不能保证您可以成功恢复网站。完整的 WordPress 迁移可能涉及多个组件：WordPress 应用程序文件和主题、已安装的插件和上传的媒体、WordPress 数据库、重要的配置文件以及特定于服务器的设置。在开始之前，请确认您有最新的备份并知道如何恢复它。对于繁忙的 WooCommerce 商店或会员网站，请考虑在迁移窗口期间如何处理新订单、账户和其他数据库更改。实用建议：在依赖该备份之前，请在单独的环境中测试恢复过程。

2. Changing DNS Before Testing the New Website

This is one of the easiest ways to create a stressful migration. The new hosting account is configured, so someone updates the DNS records immediately. But what if the new server has an incompatible PHP version? What if the SSL certificate isn’t ready? What if the contact form depends on a missing server extension? Now visitors may be reaching a website that hasn’t been properly tested. A safer approach: Prepare the new environment first. Use a staging URL or an appropriate local hosts-file override to test the destination server before changing public DNS. Check the homepage, internal pages, WordPress administration, forms and any important customer journeys. Where appropriate, reduce DNS TTL ahead of the planned migration window. Remember that DNS caching behaviour varies, and a lower TTL does not guarantee an instant switch. Practical advice: Treat DNS cutover as one of the final steps—not the first.

2. 在测试新网站之前更改 DNS

这是导致迁移过程充满压力的最简单方法之一。新托管账户配置完成后，有人立即更新了 DNS 记录。但如果新服务器的 PHP 版本不兼容怎么办？如果 SSL 证书未准备好怎么办？如果联系表单依赖于缺失的服务器扩展怎么办？现在，访问者可能会进入一个未经妥善测试的网站。更安全的方法是：先准备好新环境。在更改公共 DNS 之前，使用暂存 URL 或适当的本地 hosts 文件覆盖来测试目标服务器。检查主页、内部页面、WordPress 管理后台、表单以及任何重要的客户流程。在适当的情况下，在计划的迁移窗口之前降低 DNS TTL。请记住，DNS 缓存行为各不相同，较低的 TTL 并不能保证立即切换。实用建议：将 DNS 切换视为最后步骤之一，而不是第一步。

3. Overlooking PHP, Plugins and Server Compatibility

A website can function perfectly on one server and behave differently on another. WordPress depends on more than its application files. PHP versions, database versions, server extensions, caching, rewrite rules and plugin requirements can all affect the result. For example, a WordPress website might rely on: A PHP extension available only on the original server, a caching plugin configured for the previous hosting environment, custom redirects or web-server rules, or scheduled background tasks and third-party API connections. Before migration, document the current environment and compare it with the destination. Check plugin compatibility, review server logs and test any critical features. Avoid combining a hosting migration with several major plugin and theme upgrades unless those changes have been tested together. Practical advice: Reduce the number of things changing at the same time.

3. 忽视 PHP、插件和服务器兼容性

一个网站在某台服务器上可能运行完美，但在另一台服务器上表现却截然不同。WordPress 的运行不仅仅依赖于其应用程序文件。PHP 版本、数据库版本、服务器扩展、缓存、重写规则和插件要求都会影响结果。例如，WordPress 网站可能依赖于：仅在原始服务器上可用的 PHP 扩展、为先前托管环境配置的缓存插件、自定义重定向或 Web 服务器规则，以及计划的后台任务和第三方 API 连接。在迁移之前，请记录当前环境并将其与目标环境进行比较。检查插件兼容性，查看服务器日志并测试任何关键功能。除非这些更改已一起测试过，否则请避免将托管迁移与多个主要的插件和主题升级结合在一起。实用建议：减少同时进行的更改数量。

4. Forgetting About Email and Dynamic Website Data

It’s possible to move a WordPress website successfully and still disrupt the business using it. Email is a common example. A domain’s DNS zone may contain MX, SPF, DKIM and DMARC records that support email delivery and authentication. If those records are accidentally omitted or replaced during a DNS migration, email service can be affected even while the website appears normal. Dynamic data needs similar attention. An online store may receive new orders while files and databases are being transferred. A booking website may receive appointments during the cutover. If the final database copy does not include those changes, valuable information can be lost. Practical advice: Plan how email DNS records and live database writes will be preserved. For transactional websites, coordinate a controlled final synchronisation or maintenance window when necessary.

4. 忘记电子邮件和动态网站数据

即使成功迁移了 WordPress 网站，仍有可能干扰其业务运营。电子邮件就是一个常见的例子。域名的 DNS 区域可能包含支持电子邮件发送和身份验证的 MX、SPF、DKIM 和 DMARC 记录。如果在 DNS 迁移过程中意外遗漏或替换了这些记录，即使网站看起来正常，电子邮件服务也可能受到影响。动态数据也需要同样的关注。在线商店在传输文件和数据库时可能会收到新订单。预订网站在切换期间可能会收到预约。如果最终的数据库副本不包含这些更改，宝贵的信息可能会丢失。实用建议：规划如何保留电子邮件 DNS 记录和实时数据库写入。对于交易型网站，必要时协调受控的最终同步或维护窗口。

5. Finishing the Migration Without Proper Verification

The DNS change is complete. The website loads. Everyone assumes the job is finished. But the homepage is only one part of the website. After the migration, verify the functionality that matters to your users. A useful post-migration checklist includes: Homepage and important internal pages load correctly, HTTPS and SSL certificates work as expected, contact forms and transactional emails work, WordPress administration is accessible, images, stylesheets and scripts load properly, login, checkout or booking workflows function, and redirects and important URLs remain correct. Backups, scheduled tasks and caching behave as intended. Keep the previous environment available for an agreed rollback period wherever technically and contractually possible. Monitor server logs and application errors after cutover. Practical advice: A migration is complete when the business-critical workflows have been verified—not simply when the homepage opens.

5. 在没有进行适当验证的情况下结束迁移

DNS 更改已完成。网站可以加载。每个人都认为工作已经结束。但主页只是网站的一部分。迁移后，请验证对用户至关重要的功能。有用的迁移后检查清单包括：主页和重要的内部页面加载正确，HTTPS 和 SSL 证书按预期工作，联系表单和交易电子邮件正常，WordPress 管理后台可访问，图像、样式表和脚本加载正常，登录、结账或预订流程功能正常，重定向和重要 URL 保持正确。备份、计划任务和缓存按预期运行。在技术和合同允许的情况下，请在商定的回滚期内保留先前的环境。切换后监控服务器日志和应用程序错误。实用建议：当业务关键工作流程得到验证时，迁移才算完成，而不仅仅是主页打开时。

A Better WordPress Migration Checklist

Before moving your next WordPress website, make sure you can answer five questions: Do we have a backup that we know how to restore? Have we tested the destination environment? Are the PHP, database and plugin requirements compatible? Have we accounted for email and changing customer data? Do we have post-migration checks and a rollback plan? A well-planned migration may involve more preparation, but it reduces the chances of discovering critical problems after visitors arrive. And that preparation matters whether you’re moving a small business website, an agency client’s WordPress installation or a busy online store.

更好的 WordPress 迁移清单

在迁移下一个 WordPress 网站之前，请确保您能回答五个问题：我们是否有知道如何恢复的备份？我们是否测试了目标环境？PHP、数据库和插件要求是否兼容？我们是否考虑了电子邮件和不断变化的客户数据？我们是否有迁移后的检查和回滚计划？精心策划的迁移可能需要更多的准备工作，但它减少了在访问者到达后发现严重问题的可能性。无论您是迁移小型企业网站、代理机构客户的 WordPress 安装还是繁忙的在线商店，这种准备工作都很重要。

Final Thoughts

Most WordPress migration problems are not caused by the act of transferring files. They happen because an important dependency was missed or the cutover was not properly managed.

结语

大多数 WordPress 迁移问题并非由传输文件这一行为引起。它们发生的原因是遗漏了重要的依赖项，或者切换过程管理不当。