从 WordPress 迁移至 Astro，并不会自动让网站变快。我把自己的 WordPress 网站迁移至 Astro 后，用来追踪 Core Web Vitals 的 PageSpeed 分数只提高了两分。日常使用时，我几乎感觉不到差别。网站确实有改善，但远不如那些常用来宣传静态网站的前后对比故事。
网站迁移后排名下降，大多也不是新平台造成的。更常见的情况是 CMS、设计、网址、托管和内容同时变更。一旦流量下滑，就没人知道是哪项改动导致问题。
WordPress 迁移至 Astro 应先作为基础架构项目处理。保留公开网站、替换交付层、测试所有功能，之后再考虑改善设计。
重点摘要
- 我的迁移只让 PageSpeed 提高两分，网站使用起来没有明显变快。
- 我迁移是为了简化公开网站架构，不是为了展示性能截图。
- 尽可能保留现有网址、内容、元数据和内部链接。
- 使用页面构建器的网站应以渲染后的 HTML 为参考，因为 REST API 可能没有可见布局。
PageSpeed 只提高两分，我为什么还是迁移？
Google 对实验室数据和现场数据的说明指出，受控测试和真实用户体验网页时的条件并不相同。两分不算明显提升。PageSpeed 也是一项测试，并非每位访客手持的秒表。如果有人把一个分数当作网站变快的证明，这项区别就很重要。
我仍然更喜欢 Astro 架构。提供普通页面时，公开网站不再需要 WordPress、PHP 和数据库来组装页面。网站可以预先构建、审查，再以文件形式部署。即使用户几乎感觉不到速度变化，维护方式仍然改变了。
两者的区别很简单：性能指访客的实际体验，架构指系统如何提供这种体验。改变架构可以让系统更容易管理，但不一定带来明显的视觉变化。
Astro 无法解决什么问题
Astro 不会自动压缩过大的主视觉图片，也不会移除配置不当的同意管理平台、缩小臃肿的网页字体，或阻止市场团队加入五个追踪脚本。如果这些资源拖慢加载速度，把 PHP 换成静态 HTML，用户可能仍然感觉不到区别。
Astro 也无法改善内容质量、混乱的导航或不具无障碍性的界面。这些是设计和编辑问题。更换框架无法替您作出相关决定。
因此，我不会把 WordPress 迁移至 Astro 包装成速度服务。先测量现有网站。如果延迟来自图片、JavaScript 或第三方代码，就先处理这些问题。为了不检查浏览器 waterfall 而重建整个平台，成本很高。
哪些情况下 WordPress 仍是更合适的工具
WordPress 的实用之处，在于没有技术背景的人也能操作。由开发人员主导迁移规划时，这项优势很容易被忽略。
如果网站依赖 WooCommerce、会员功能、学习管理系统、复杂的发布权限，或承载重要业务逻辑的插件，我会保留 WordPress。如果编辑人员需要自行创建和调整页面，而不必请开发人员部署网站，我也会保留 WordPress。
WordPress 可以继续作为 Headless CMS，由 Astro 负责公开前端。编辑人员可以继续使用 CMS，但团队需要管理两套系统。有时这样做合理，有时只是把工作量加倍，却没有带来实际好处。
迁移时必须保留的内容
新代码库不是迁移工作的起点，现有公开网站才是。
我会根据 sitemap、网站爬取结果、WordPress 记录和 Google Search Console 建立清单。Search Console 很重要，因为它经常能找出仍有曝光、却不在当前导航中的旧页面。
请为每个可编入索引的页面记录：
- 公开网址和响应状态码。
- 标题、meta 描述、canonical 网址和 robots 指令。
- H1、主要内容、结构化数据和内部链接。
- 页面使用的图片、文件、表单和其他功能。
这份清单也是验收测试。仅仅因为 Astro 路由已经存在，不代表页面已迁移。新路由必须保留用户过去依赖的信息和功能，才算完成迁移。
我会如何处理迁移
1. 固定公开网址对应表
如果 WordPress 文章的网址是 /example-article/，Astro 版本也应使用 /example-article/。仓库内部的文件夹结构无关紧要。不要只因为 /blog/ 看起来比较整齐，就额外加上这层路径。
只有公开网址确实改变时，才使用永久重定向。重定向应直接指向最接近的替代页面。已删除且没有适当替代内容的页面，应返回 404 或 410，而不是重定向到首页。
Google 网站迁移指南说明网址对应、重定向和监测方式。我们的网站迁移流程则分别列出上线前和上线后的检查。
2. 保存浏览器实际收到的内容
对于使用页面构建器的网站，普通 WordPress 导出并不足够。Bricks、Elementor 等构建器可能把重要布局资料存放在文章内容以外。REST API 响应即使有效，也可能只包含很少的可见页面内容。
我会保存渲染后的 HTML、载入的 CSS，以及每个模板在桌面和手机宽度下的截图。导出内容是参考资料，不是可以直接贴进 Astro 的代码。复制所有构建器包装层和 class，只会用另一个文件名把旧系统搬过来。
也可参考这篇关于小屏幕体验的手机优先设计指南。
3. 决定内容存放位置
Markdown 适合开发人员或独立技术编辑，但对于需要可视化编辑器的市场团队来说，并不是合适的答案。
Astro 可以读取本地文件，或从 CMS 获取内容。无论使用哪种来源，都要定义每篇文章所需字段：
- 标题和描述。
- 发布日期和更新日期。
- canonical 网址。
- 特色图片和替代文字。
缺少必要资料时，验证流程应中止构建。我偏好可以迁移到其他框架的内容模型。字段名称清楚的内容集合，比储存在 shortcode 或构建器 JSON 中的多年布局资料更容易迁移。
4. 移除 WordPress 前，列出每个插件的功能
插件实际承担的工作，往往比名称显示的更多。表单插件可能负责验证、防垃圾信息、邮件发送、数据库记录和 CRM 集成。换成静态表单元素，并不会取代这些工作。
请记录每个插件实际处理的功能。只重建网站仍然需要的功能，然后测试完整流程。
以联系表单为例，应从已部署的网站提交表单，并确认预定收件人收到信息。部署通过的绿色勾号不能证明邮件已送达。
5. 比较新旧网站的输出
我会爬取两个版本，并按网址比较结果。检查内容包括响应码、标题、描述、canonical 标签、标题层级、内部链接、图片路径、结构化数据和 robots 指令。
我也会在浏览器中检查页面。爬虫无法发现手机菜单被其他元素挡住，也无法判断表单的成功消息是否看得见。
迁移期间先保留手机布局。之后若有证据支持，再重新设计。
6. 保留回退方式
上线后，我会确保旧 WordPress 文件和数据库仍可恢复。Astro 版本也应保留已知可用、能快速恢复的部署版本。
不要为了证明有信心，就在上线当天删除旧系统。信心不是回退方案。
SEO 工作主要是保护现有表现
Astro 没有保留排名的设置。搜索引擎读取的是网址和 HTML，不会因为仓库用了较新的框架就给予额外分数。
尽可能保留现有网址，并沿用标题、描述、canonical 标签、标题结构、有用内容、内部链接和准确的结构化数据。
只把预期编入索引的路由加入 sitemap。上线前移除测试站的 noindex 规则。
上线后，监测 Search Console、服务器日志、自然搜索着陆页面和询问。短暂波动不一定代表失败；突然出现大量 404 错误或 canonical 标签缺失，就是应修复的问题。
这份迁移后 SEO 审查清单按顺序列出检查项目。
结语
我从 WordPress 迁移至 Astro 后，PageSpeed 分数提高了两分。网站并没有突然变快。我不会把这项结果包装成速度案例。
这次迁移仍然有价值，因为它改变了公开网站的构建、部署和维护方式。这是技术架构决策。只有当这些运营好处值得更改发布系统的成本时，迁移才有意义。
如果您也在考虑迁移，请先进行网站迁移与 SEO 审查，在开始重建前查明哪些内容必须保留。
常见问题
Astro 会让我的 WordPress 网站明显变快吗？
不一定。我自己的 PageSpeed 只提高了两分，日常使用时几乎感觉不到差别。不要先假设 WordPress 运行环境是主要原因，应先测量网站目前慢在哪里。
从 WordPress 迁移至 Astro 后，排名会下降吗？
Google 重新爬取有变动的页面时，排名可能会波动。保留原有网址和相当的搜索信号，可以避免不必要的风险。没人能保证排名完全不变。
可以保留现有的 WordPress 设计吗？
可以。保存渲染后的页面，再用 Astro 组件重建访客看到的效果。除非您准备同时诊断两种改动的影响，否则不要把平台迁移和改版合并进行。
一定要使用 Markdown 吗？
不需要。Astro 可以使用本地文件或 CMS 内容。编辑方式应符合实际发布人员的需要。
WordPress 表单会如何处理？
必须替换表单，或将它连接到其他 endpoint。在已部署的网站上测试输入验证、防垃圾信息、资料送达和失败消息。
上线后要立刻关闭 WordPress 吗？
不要。请保留安全且可恢复的副本，直到 Astro 网站通过上线后检查，并确认实际询问资料都能正确送达。
关于相关交付范围，请参阅 Ulement 的技术 SEO 服务。