关于

这个工具由 Leo 构建和维护，他是一名全栈开发者，拥有九年 WordPress 和 Elementor 使用经验——期间已将 189 个网站迁移到 Elementor。

为什么会有这个工具

每一次迁移都撞上了同一堵墙。一份设计稿、从其他构建器导出的内容，或者一个旧静态站点，最终都会变成一堆 HTML 和 CSS。要把它放进 Elementor，只有两个糟糕的选择：把整段内容粘贴进单个 HTML 组件里，从此再也无法编辑；或者逐块重建，每页浪费一整天。做了十几个站点之后，你就不会再接受这种取舍，而是开始把它自动化。这个工具就是那套自动化流程，经过整理后公开出来。

189 次迁移教会我的事

转换器里几乎每一条规则，都是对真实项目中某个出错问题的直接回应：

• 样式表会说谎，计算后的样式不会。层叠顺序、媒体查询、继承值和工具类意味着你在 CSS 文件里读到的规则，很少就是浏览器真正渲染出来的值。转换器会先渲染你的 HTML，再读取计算后的样式，所以它能扛住 Tailwind 风格的标记和框架 CSS，而不是被它们卡住——前提是编译后的 CSS 就放在页面内部。从外部 URL 加载的样式表会为了安全被剥离，所以请先把 CSS 内联进去。
• 如果一一映射，嵌套会爆炸。普通页面里到处都是没有任何视觉意义的包裹 div。原样复制它们，你会得到一个十层容器深的 Elementor 结构，谁都编辑不了。没有样式效果的包裹层会被折叠；真正承载内边距、背景或阴影的包裹层会保留——合并这些才是破坏布局的原因。
• 内联 SVG 无法变成可编辑的 Elementor 图标。这是 Elementor 的限制，不是转换 bug：它的图标控件只接受图标库条目或媒体库文件，其他都不行。Font Awesome 类可以干净地映射为可编辑图标；手写的 SVG 只能保留为原始 HTML。在生成 HTML 之前知道这一点，能省掉一次完整的重建。
• Base64 图片在你导入之前看起来没问题。一个页面有十几张内联图片，体积会膨胀到超过半兆，然后无法进入媒体库。它们会变成带标签的空位，这样你之后可以把真实文件放进去，并且知道哪张是哪张。
• 响应式不是一个单一设置。布局差异会在多个宽度下测量，并写入 Elementor 自己的响应式字段，而不是指望一个桌面布局在手机上自然降级。
• 有些事情确实无法转换。动画、脚本驱动的交互、伪元素，以及任何依赖你网站自身数据的东西——菜单、产品循环、查询——都无法从静态 HTML 中推断出来。工具遇到这些时会告诉你，而不是悄悄丢掉。

它不会做什么

它不会承诺像素级完美的输出。HTML 和 Elementor 的渲染并不完全相同，任何声称能做到的转换器，都只是转换的页面还不够多。它不会碰你的 WordPress 网站：工具只生成数据，导入过程由你在你自己的 Elementor 里完成。它也不会要求你注册。

它同样不会把风险带过去。脚本、危险链接、外部样式表和表单提交都会在到达你的编辑器之前被剥离，而保留下来的样式会被限定在导入内容范围内，不会泄漏到你主题的其他部分。

你的文件永远不会离开浏览器

解析、转换和预览全部在浏览器本地运行。你的 HTML、图片以及生成的 Elementor 数据，永远不会被发送到本站或任何其他地方。这是一开始就做好的设计决定，而不是以后可以拿来交换的功能。

适合谁用

• 使用 Elementor 为客户建站的自由职业者和小团队。
• 用 AI 生成 HTML，想要可编辑页面而不是一段死代码块的人。
• 任何正在把一批静态页面迁移到 WordPress 和 Elementor 的人。

联系我

问题、bug 报告和棘手的转换样本，都欢迎发送到 [email protected]。如果某些内容转换得很糟糕，把 HTML 片段发过来是得到修复最快的方式——上面有好几条规则，正是因为有人这样做了才存在。