从 Elementor/Divi 迁移到 Bricks：完整分步指南

为什么要迁移到 Bricks

站点迁向 Bricks，通常出于三个理由。

性能：Bricks 输出干净 HTML/CSS，几乎无内联冗余，PageSpeed 与核心网页指标（Core Web Vitals）通常大幅抬升——Elementor 移动端 CWV 通过率约 25–35%，Bricks 达 55–65%。

代码质量与可维护性：语义化输出、设计令牌、全局类，后续维护与交接更轻松。

成本：一次性授权，优于 Elementor Pro / Divi 的年度订阅。

迁移的真正成本在于设计重建工时——内容会自动迁走，但 Elementor/Divi 布局要在 Bricks 里重搭。对多数被性能拖垮的站点，这笔投入划算。

迁移策略：一次性 vs 分阶段

两条路线。

一次性（Big Bang）：在暂存站一次性迁完再切换。适合约 30 页以内的小站，或上线前能承受整站重建。

分阶段（推荐）：逐段迁移。1. 从模板入手（页眉、页脚、单篇文章、归档）2. 先重建高流量页面 3. 其余保留旧编辑器 4. 重建完一页就用模板条件切到 Bricks。

分阶段把风险压到最低：站点始终在线、排名不受影响。

第一步：全站备份

全站备份（文件+数据库）——UpdraftPlus 或主机备份
导出内容——WordPress 工具 → 导出（全部内容）
导出旧编辑器数据——Elementor/Divi 各自的导出
记录当前 URL——每个 URL 必须保持一致（SEO）

备份没有商量余地——你要留好回滚路径。

第二步：在暂存站安装 Bricks

绝不在生产环境迁移。 多数主机提供一键暂存：1. 克隆到暂存 2. 安装并启用 Bricks（成为当前主题）3. 在那儿重建并测完。线上站点照常服务——零停机迁移。

第三步：内容与设计分离

关键心智模型：WordPress 把内容与设计分开存储。

✅ 内容自动迁移——文章、页面、图片、分类、自定义字段（ACF/Meta Box）、WooCommerce 商品，都在数据库里，切换编辑器毫发无损
❌ 设计不迁移——Elementor/Divi 的区块与内联样式不会带过去

所以重建只涉及设计，内容早已就位。

第四步：重建设计系统

先做地基，别先碰页面：

调色板——还原品牌色
排版——字体、字号、字重（全局设置）
全局类——按钮、徽章、容器、卡片
设计令牌——间距、圆角、阴影
断点——对齐布局需求

这就是“设计系统优先”：重建一次，每页继承。

第五步：重建模板

Bricks 模板掌控全局布局：页眉（吸顶/透明/巨型菜单）、页脚、单篇文章（特色图/元信息/正文/作者框）、单页、归档/博客（查询循环+卡片）、404/搜索。通过模板条件指派（如“X 分类用 Y 布局”），生效后内容页自动套用。

第六步：全局导入导出

维护多个 Bricks 站点时，用全局导入导出——一个 ZIP 带走主题样式、全局类、变量、调色板、断点、组件、模板、字体、图标集、全局查询及受支持的设置。

完美工作流：设计系统搭一次 → 导出 ZIP → 导入每个新客户站，几分钟转移一套地基。

第七步：WooCommerce 迁移

商品、订单、客户——都在 WooCommerce 表里，自动迁移
重建商品模板（单品/归档/购物车/结算）于 WooCommerce 构建器
v2 模块化结算——多步骤重建，当作升级而非单纯移植
跑通漏斗——购物车→结算→支付→感谢页→订单回执
保留 WooCommerce 及扩展启用；只有设计在变

第八步：SEO 与 URL

关键：URL 必须保持一致。 Bricks 是主题，固定链接不变。为稳妥：1. 迁移前导出站点地图作基线 2. 上线后重提交 Search Console对比覆盖率 3. 保留元标题/描述（Yoast/RankMath/SEOPress 数据都在）4. 检查重定向——URL 不变本不需要，但仍核实 5. 上线后监控排名 2–4 周。

第九步：停用旧编辑器

重建并测完之后：1. 模板条件全切到 Bricks 2. 停用（别删除）旧编辑器，数据留库当回滚保险 3. 彻底测试所有页面/表单/弹窗/脚本 4. 一两周后再删旧数据（先备份）。

绝不在同一天删除旧编辑器，至少留一个月回滚路径。

第十步：上线检查清单

所有页面经 Bricks 渲染（无旧编辑器残留）
页眉/页脚跨页一致
移动端+桌面端均测过
表单、弹窗、菜单、搜索正常
WooCommerce 漏斗完整（若有电商）
重跑 PageSpeed——前后对比（应有显著提升）
站点地图已重提，排名在监控
旧编辑器停用，备份安全

相关阅读：

小结

多数站点迁移后 PageSpeed 提升 10–30 分，代码更干净、维护更轻、成本一次性付清且优于年订阅。这次迁移重建的只是设计——内容、SEO 与商品都原封不动继承。前期把内容/设计分离想清楚、用分阶段策略、留足回滚路径，整件事就可控得多。

常见误区

迁移最危险的误区是直接在线上站装 Bricks 开干——一旦样式崩了没退路，务必先在暂存站（staging）或本地克隆上重建设计，确认无误再切。第二个坑是忘了 301 重定向：旧编辑器生成的 URL 结构可能变化，不重定向会丢 SEO 权重，上线前把旧路径映射到新路径。第三是插件兼容：某些依赖旧编辑器特性的插件在 Bricks 下要替换或重配。最后记住迁移只重建「设计」，内容和商品尽量原样继承，别手滑重填。

常见问题（FAQ）

Q：一定要一次性全站迁移吗？ A：不必，建议分阶段：先暂存站重建设计系统，再逐模板替换，留足回滚路径。

Q：迁移会影响 SEO 吗？ A：内容和 URL 尽量保持不变影响就小；URL 结构若变化必须做 301 重定向保权重。

Q：WooCommerce 商品要重录吗？ A：不用，商品数据在数据库里，迁移只重建前端展示，商品和订单原样继承。

Q：迁移后性能会提升多少？ A：具体提升随站点和主题复杂度变动，以官方文档和实际 PageSpeed 测分为准；本文给的是经验区间。