接入后自动抓取全站内容,首次翻译在几分钟内完成。后续页面更新会自动触发增量翻译——只翻译新增和修改的段落,不会重复翻译没有变化的内容。支持发布前预览,译文字数实时显示。
翻译后的页面生成独立 URL(子目录或子域名),配有正确的 hreflang 标签、本地化的 meta 描述和 OG 标签。Google 会把这些页面视为独立的多语言版本,不会判为重复内容。我们的客户平均在翻译上线 4-6 周后就能在目标语言的搜索结果中看到排名。
你更新了产品描述、改了定价、发了一篇新博客——翻译引擎通过 Webhook 感知变化,自动抓取并翻译有差异的段落。翻译完成后通过 API 推送回你的 CMS,全流程不需要手动操作。从内容更新到多语言页面刷新,一般在 5 分钟内完成。
不只是把文字翻译对——我们为每个语言版本生成独立的 sitemap,配置正确的 hreflang 标签,处理 Canonical URL 指向,并且自动将翻译后的图片 alt 文本、URL slug 和结构化数据一并本地化。Google Search Console 里能看到每个语种的独立点击和排名数据。
官方插件,支持 WPML/Polylang 联动
原生插件产品页、结账流程全链路翻译
原生插件通过 Custom Code 嵌入,与 CMS Collection 联动
代码嵌入Next.js / Nuxt / Gatsby / Hugo 全系支持
API 接入多语种子域名自动配置,Dashboard 管理
应用市场代码注入 + URL Mapping 方式集成
代码注入| 对比维度 | JS 代码片段 | REST API 集成 | 代理部署 |
|---|---|---|---|
| 实现难度 | 最低 —— 一行 script 标签即可 | 中等 —— 需要后端开发配合 | 较高 —— 需配置 DNS/反向代理 |
| SEO | 不生成独立 URL,Google 看不到翻译内容 | 生成独立 URL,hreflang 可由你完全控制 | 独立 URL + 服务器端渲染,SEO 最优 |
| 翻译质量管控 | 有限 —— 无法做译后编辑 | 强 —— 可在入库前人工审校 | 强 —— 内置审校工作流 |
| 维护成本 | 零维护,但翻译结果不可控 | 需维护翻译同步逻辑 | 需维护代理服务器配置 |
| 适用场景 | 内容少、对 SEO 无要求的网站 | 内容驱动、需要高质量 SEO 的网站 | 大型站点,要求最高级别的本地化体验 |
| 上线速度 | 5 分钟 | 1-3 天 | 3-7 天 |
一家工业传感器制造商的官网,120 个页面,技术参数表密集。选了 REST API 方案,翻译后在本地数据库存储,通过 WordPress 多站点架构分发。技术术语表的定制用了三周——"感应距离"译成 "sensing distance" 还是 "detection range" 这类问题逐一校准。上线六个月后,英文站的自然搜索流量从零增长到月均 2300 次访问,三个日本客户明确表示"是因为看了日文官网才发来的询价"。
一个定位中高端的鲜花电商,从中文站扩展至四个语种。用 Shopify 插件直接对接了产品标题、描述、变体选项和结账邮件模板的翻译。最意外的是德文站的表现——转化率在第三个月达到了中文站的 80%,客单价甚至高了 12%。团队后来分析,德国消费者对"每周订阅"模式接受度高,而德国本地鲜花电商恰好在这块做得不够好,等于翻译帮他们打开了一个蓝海市场。
一个面向中文开发者的技术文档社区,决定反向出海——把 800 篇中文技术文章翻译成英文。采用了基于 Next.js 的 Jamstack 架构,翻译 API 通过 CI/CD 流水线调用,每篇新文章在合并 PR 的 5 分钟内自动生成英文版本并部署。翻译质量方面,技术类内容的 BLEU 达到了 45+,但人工审校仍然必要——中文技术写作的省略主语习惯,英文读者常常感到困惑。他们为此建了一个双语审校清单,现在已经是社区 Wiki 的固定栏目。
拖拽滑块,看看你的网站规模大概对应多少翻译成本。实际报价会根据语种对和内容复杂度浮动。