![[截图 2：浏览器 Network 中直接请求 translate.yandex.net]](https://media.shuijingwanwq.com/2026/07/2-16-1024x568.png)
最近我开始重新重视博客的英文流量。
我的博客目前是基于：
- WordPress
- Polylang
- AutoPoly – AI Translation For Polylang
- AutoPoly 免费版中的 Chrome Built-in AI
来实现中文文章自动翻译成英文。
一开始这个方案的优点很明显：成本低、流程简单、能快速生成英文版本。
但随着我最近申请了 Carbon Ads（BuySellAds），并且打算后续长期做英文海外流量，我越来越明显地感觉到一个问题：
Chrome Built-in AI 的翻译质量，只能解决“有没有英文版”的问题，不能很好解决“英文文章是否自然、可信、适合海外技术读者阅读”的问题。
尤其是我的博客内容里有大量技术文章、VPN、CDN、WordPress 优化、联盟营销、服务器运维、AI 工具学习等主题。如果英文表达太像机器翻译，不仅影响海外读者体验，也可能影响广告平台审核、英文 SEO 和联盟营销转化。
于是，我开始排查：在尽量少花钱的前提下，如何提升博客英文翻译质量。
一、当前翻译方案：Polylang + AutoPoly 免费版
我当前使用的是：
Polylang + AutoPoly – AI Translation For Polylang
AutoPoly 免费版里可以选择的 AI Translation Providers 包括：
- Chrome Built-in AI
- Yandex Translate
而 Pro 版本里，还可以看到更多 Provider，比如：
- DeepL
- Google Translate
- OpenAI
- Gemini 等
这里一开始很容易产生一个直觉：
既然 Chrome Built-in AI 翻译质量不够好，那是不是买 AutoPoly Pro，然后换 DeepL 就可以了？
但实际排查后发现，中国大陆用户想稳定使用 DeepL API，并没有这么简单。
二、先测试服务器能不能访问各类翻译 API
我的博客服务器在阿里云杭州 ECS 上。
因为 WordPress 插件后台调用翻译 API，一般是由服务器发起请求，所以我先在 ECS 上测试几个 Provider 的连通性。
我测试了以下接口：
curl -I --connect-timeout 10 https://api-free.deepl.com/v2/usage
curl -I --connect-timeout 10 https://api.deepl.com/v2/usage
curl -I --connect-timeout 10 https://translation.googleapis.com/language/translate/v2
curl -I --connect-timeout 10 https://api.openai.com/v1/models
curl -I --connect-timeout 10 https://generativelanguage.googleapis.com/
测试结果比较清楚：
- DeepL Free API：返回
HTTP/2 405 - DeepL Pro API：返回
HTTP/2 405 - Google Translate API：连接超时
- OpenAI API：连接超时
- Gemini API：连接超时
这里的 HTTP/2 405 不是坏结果。因为我使用的是 curl -I，也就是 HEAD 请求，而 DeepL 返回的信息里明确显示允许的是 GET、POST。
也就是说：
阿里云杭州 ECS 到 DeepL API 网络是通的，只是请求方法不对。
而 Google Translate、OpenAI、Gemini 在我的 ECS 上直接超时。因此，即使 AutoPoly Pro 支持这些 Provider，从服务器环境看，也不适合作为当前 WordPress 后台自动翻译方案。
当时得到的阶段性判断是：
如果只看服务器网络连通性，DeepL 是 AutoPoly Pro 里最现实的选择。
但问题很快出现在账号注册和付款环节。
三、DeepL API 最大的问题：不支持中国大陆主体直接注册
接下来，我进入 DeepL API 页面，准备尝试注册 Developer 计划。
一开始看起来还不错，因为 Developer 计划可以用于 API 测试，非常适合先确认能不能拿到 API Key。
但进入注册流程后发现，国家或地区选择列表里没有中国大陆。
这一步基本确认了：
DeepL API 对中国大陆用户并不是网络不可达，而是账号地区和付款体系不支持。
后续我又搜索了一些资料，发现很多人给出的解决方案是：
- 使用支持地区的代理节点
- 选择美国、欧洲、中国香港、新加坡等地区
- 准备当地或受支持地区发行的外币信用卡
- 或者使用第三方 API 中转服务
这些方法技术上可能可以绕过去，但对我来说并不理想。
因为我的目标不是折腾一个高风险账号，而是要为博客长期稳定地做翻译。如果账号地区、支付卡、账单地址、后续续费、风控都有不确定性，那么这套方案就不适合作为长期主流程。
四、为什么不建议强行用美国 VPN 注册 DeepL
当时我也想过：既然我现在 VPN 是美国节点，能不能直接选择美国注册？
但冷静想一下，这个方案风险很大。
因为 DeepL 账号后续很可能涉及：
- 账单地址
- 支付卡地区
- 信用卡验证
- 续费
- 发票
- API 使用风控
即使 Developer 计划看起来是免费注册，但一旦后续升级付费计划，付款信息和账号地区不一致，就可能出现各种麻烦。
最终我的判断是：
不建议为了 DeepL API，使用美国 VPN + 随便填写美国地区的方式强行注册。
这不是不能折腾，而是不值得。
我现在更需要的是低成本、低维护、长期稳定的博客翻译工作流，而不是再增加一个不确定的账号风险点。
五、Google AI 给出的替代方案，也需要筛选
在排查过程中，我也用 Google 搜索 AI 看了一些建议。
它提到了几类替代方案：
- TranslatePress + DeepL 或其他翻译服务
- WPML + 内置 AI 翻译云
- Weglot 云翻译
- 国内 DeepL API 中转
- DeepSeek、百度翻译、腾讯翻译、阿里翻译等国内 API
- 大语言模型翻译工作流
这些方案看起来很多，但真正适合我当前博客现状的不多。
因为我的博客已经有大量中文文章和英文文章，当前结构是 Polylang 体系。如果贸然换成 WPML、TranslatePress 或 Weglot，就不是简单换一个插件，而是整个多语言体系迁移。
可能涉及：
- 中文文章与英文文章的对应关系
- 英文 URL
- hreflang
- sitemap
- 分类
- 标签
- 系列
- 已收录页面
- 已有英文流量
- SEO 稳定性
所以我的结论是：
对一个已经用 Polylang 跑起来的老博客来说，不应该为了翻译质量，轻易迁移到另一套多语言插件。
六、为什么暂时不换 WPML / TranslatePress / Weglot
1. TranslatePress
TranslatePress 的前端可视化翻译体验很好，适合新站，也适合希望在页面上直接修改翻译的人。
但对我来说，它的问题是：
- 已有 Polylang 内容迁移成本高
- DeepL 自动翻译仍然可能需要 DeepL API
- 对上千篇文章来说，免费或低价额度不一定够
- 迁移后 SEO 结构需要重新验证
所以我不打算现在迁移到 TranslatePress。
2. WPML
WPML 是 WordPress 多语言插件里非常成熟的方案，自动翻译体系也比较完整。
但它的问题是：
- 插件本身是付费的
- 自动翻译积分后续也会产生费用
- 从 Polylang 迁移到 WPML 风险较大
- 对我这种已有大量文章、分类、标签、系列的站点来说，不适合轻易切换
3. Weglot
Weglot 的优点是快，安装后很快就能生成多语言版本。
但它是云端订阅模式，按词数和语言数量收费。我的博客文章数量很多，如果未来再做日语、韩语，成本会迅速增加。
更关键的是：
一旦停止订阅，翻译内容和多语言页面的持续性就会成为问题。
因此，Weglot 也不适合我现在“尽量少花钱”的目标。
七、最终结论：不要重构多语言系统，先保留 Polylang
经过这次排查，我认为现阶段最稳的策略是：
继续保留 Polylang，不迁移多语言插件。
原因很简单：
- Polylang 已经跑起来了
- 中文和英文文章关系已经建立
/en/路径已经被搜索引擎收录- 分类、标签、系列体系已经存在
- 迁移成本和 SEO 风险都太高
现在要解决的不是“换一个多语言插件”，而是：
在现有 Polylang 体系下，找到低成本提升翻译质量的方法。
八、现阶段最现实的翻译质量提升方案
最终我把方案分成三层。
第一层：普通文章继续自动翻译
普通文章不值得人工精修。
可以继续使用：
- AutoPoly 免费版
- Chrome Built-in AI
- Yandex Translate
下一步我会测试 Yandex Translate，看看它是否比 Chrome Built-in AI 更适合中文技术博客翻译成英文。
普通文章的目标不是完美，而是：
- 低成本
- 自动化
- 有英文版本
- 覆盖长尾搜索
- 不占用大量人工时间
第二层：重点英文文章使用 ChatGPT Plus 完整重译
真正有商业价值的文章，可以使用 ChatGPT Plus 进行完整重译。
比如：
- VPN 高流量文章
- Vultr / DMIT / ZgoCloud 相关内容
- Cloudflare / CDN / WordPress 性能优化文章
- AI / Codex 学习路线文章
- 联盟营销相关文章
- Carbon Ads 可能审核的代表文章
- About / Contact / Advertising 页面
这里我一开始想过只优化标题、首段、小标题、结尾 CTA。
但实际想了一下，这个流程并不省事。因为我要分别从 WordPress 里复制标题、首段、小标题、CTA，然后再分别复制回去。这样还不如整篇文章复制一次，让 ChatGPT 直接返回完整英文版。
所以最终确定的人工优化流程是：
直接复制中文文章代码编辑器全文，让 ChatGPT 按固定规则返回完整英文代码编辑器版本。
第三层：未来再考虑 DeepSeek / 国内大模型 API 工作流
如果后续英文站确实能带来广告收入、联盟营销收入，或者 Carbon Ads 通过审核，那么可以进一步考虑开发一个半自动翻译工作流。
比如：
- 从 WordPress REST API 读取中文文章
- 调用 DeepSeek、通义千问、腾讯混元、智谱等国内大模型 API
- 保留 Gutenberg 区块结构
- 保留 HTML、代码块、短代码、图片占位
- 生成英文草稿
- 人工审核后发布或更新 Polylang 英文文章
这条路线长期看可能比 DeepL、WPML、Weglot 更适合我。
因为我是技术开发者，可以自己控制流程，也可以逐步用 Codex 辅助实现。
九、以后发给 ChatGPT 的固定指令
为了避免每次都重新写 Prompt，我决定把下面这段固定指令保存在这篇博客中。
以后需要高质量英文翻译时，直接复制下面这段即可。
按博客英文完整重译规则处理。
请将下面的中文 WordPress 文章翻译并改写成自然、可信、适合海外技术读者阅读的英文版本。
要求：
1. 保留 WordPress 代码编辑器中的 Gutenberg 区块结构。
2. 保留 HTML 标签、短代码、图片占位、代码块、表格、链接。
3. 产品名、插件名、命令、路径、域名、URL 不要翻译。
4. 技术术语使用自然英文，不要机器翻译腔。
5. 不要过度营销，保持技术博客的可信度。
6. 如果文章中包含联盟链接，请保留链接，并自然加入 affiliate disclosure。
7. 返回可直接复制到 WordPress 英文文章代码编辑器中的完整内容。
8. 如果原文使用 wp:kevinbatdorf/code-block-pro 代码块，请完整保留该区块结构，包括 wp:kevinbatdorf/code-block-pro 注释、JSON 属性、div.wp-block-kevinbatdorf-code-block-pro、textarea、pre.shiki、code、span.line 等结构。
9. 代码块中的内容默认不要翻译、不要改写、不要替换，只保持原样；除非我明确说明代码块内容也需要翻译。
10. 不要将 wp:kevinbatdorf/code-block-pro 简化为普通 pre/code，也不要改成 wp:code。
请按以下格式返回：
英文标题：
英文别名建议：
英文 Meta Description：
英文摘要：
英文文章正文代码编辑器内容：
下面是中文文章信息：
中文标题：
中文摘要：
中文文章代码编辑器全文：
以后如果文章太长，可以分段发送。
第一段可以这样发送：
按博客英文完整重译规则处理。
这是第 1/3 段，先不要返回最终版本，等我发完。
最后一段可以这样发送：
这是第 3/3 段，已经发完。现在请返回完整英文版。
这样流程会简单很多。
十、关于日语、韩语：暂时不要全站扩张
这次排查过程中，我也想到一个问题：
如果以后我要把博客翻译成日语、韩语，工作量会更大。
现在中文文章已经很多，英文文章也已经很多。如果再加上日语、韩语，整个站点会变成：
- 中文
- 英文
- 日语
- 韩语
这会带来一系列问题：
- 翻译成本增加
- 人工审核成本增加
- 分类标签维护变复杂
- sitemap 变复杂
- SEO 监控变复杂
- 页面质量控制变难
- 多语言广告策略也会变复杂
所以现阶段不要急着做日语、韩语。
更合理的顺序是：
- 先把英文站跑通
- 优化 10 到 30 篇最有商业价值的英文文章
- 观察 Carbon Ads、Bing、Google、联盟营销是否有改善
- 如果英文站证明有效，再拿 5 篇文章测试日语
- 再拿 5 篇文章测试韩语
多语言不是越多越好。
如果每一种语言都只是机器翻译堆出来，但没有流量、没有收入、没有维护能力，反而会增加网站负担。
十一、这次排查后的最终决策
这次折腾下来，我的结论是：
在中国大陆环境下，想为 WordPress 博客接入一个高质量、稳定、低成本的自动翻译方案，真心不简单。
DeepL 翻译质量好，但中国大陆主体直接注册 API 不顺。
Google Translate、OpenAI、Gemini 理论上可选，但我的阿里云杭州 ECS 直接访问超时，不适合作为 WordPress 后台翻译 Provider。
WPML、TranslatePress、Weglot 都有成熟方案，但对一个已经使用 Polylang 的老博客来说，迁移成本和长期费用都需要谨慎评估。
所以最终最适合我的方案不是“换一个插件”，而是：
继续保留 Polylang
普通文章继续自动翻译
测试 AutoPoly 免费版 Yandex Translate
重点英文文章用 ChatGPT Plus 完整重译
未来再考虑 DeepSeek / 国内大模型 API 半自动翻译工作流
这不是最完美的方案，但它是现阶段成本、风险、质量之间比较平衡的方案。
十二、给后来的自己一句提醒
以后再遇到类似问题，不要一开始就陷入某个插件的 Provider 列表里。
真正应该先问的是：
我的目标是什么？
我的预算是多少？
我能接受多少人工工作量？
哪些页面真正值得高质量翻译？
哪些页面只需要自动翻译覆盖长尾流量？
对于我现在的博客来说，答案已经比较明确：
不追求全站完美翻译。
先让最可能产生英文流量、广告收入、联盟营销收入的页面变好。
普通文章自动化，重点文章人工精修。
不轻易迁移多语言系统。
这可能才是当前最现实的路线。
需要长期技术维护或远程问题排查？
我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。
如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：
- ✅ PHP / Laravel / Yii2 老项目无人维护
- ✅ Go / Gin 后端接口需要排查或优化
- ✅ WordPress 网站访问慢、报错或插件冲突
- ✅ Nginx / MySQL / Redis / Linux 服务器异常
- ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
- ✅ 需要长期远程技术支持或兼职维护
更多介绍请查看：关于我 & 合作
微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan
发表回复