# 不用插件翻译 WordPress 网站：哪些做法真的可行

> 了解如何在不用插件的情况下翻译 WordPress 网站、把各语言页面关联起来，并选择一套你能长期维护的方案。

- URL: https://www.lingowp.com/zh/blog/fanyi-wordpress-wangzhan-wuxu-chajian/
- Author: Amine Sayagh
- Category: 指南
- Published: 2026-09-20
- Language: zh

你想让网站以另一种语言呈现。在再装一个插件之前，先问问能否用手头已有的 WordPress 工具完成这件事，是合理的。

**是的，你可以不用插件翻译 WordPress 网站。**你可以把现有内容替换成新语言，也可以发布翻译好的页面并手动关联它们，或者为每种语言维护独立站点。WordPress 原生没有提供的，是一套用来关联和管理这些译文的完整工作流。[WordPress 多语言文档](https://developer.wordpress.org/advanced-administration/wordpress/multilingual/)

对小型网站来说，手动方式也许够用。关键问题是发布之后会怎样：当某项服务变更、新页面上线，或访客浏览到一半切换语言时。

本指南讲清各种可行方案，并给出一套不依赖多语言插件、添加翻译页面的简单步骤。

## 先判断你需要一种语言还是多种语言

这是两个不同的项目。

**替换网站语言**意味着重写现有内容。例如，一个英文网站变成只有法语。如果你不再打算同时提供两种语言，就不需要把英文版和法语版关联起来。

**新增一种语言**意味着两个版本都保留。访客需要找到对应内容、在语言之间切换，并在浏览过程中不会突然被带回原始语言。

这两者都不等同于修改**设置 → 常规 → 站点语言**。该设置控制的是 WordPress 的默认语言，而不是一条翻译页面的命令。可用的语言包也会影响主题和插件的内置标签，但你自己写的文字仍然需要翻译。[WordPress 常规设置](https://wordpress.org/documentation/article/settings-general-screen/)

在本指南中，"不用插件"指的是不新增多语言插件。你仍然可以使用现有的编辑器、主题和其他站点工具。

## 选择与你网站相匹配的方案

| 你的目标 | 合适的方案 | 主要责任 |
|---|---|---|
| 把现有网站变成另一种单一语言的网站 | 就地翻译当前内容 | 上线前检查完整的访客体验 |
| 让几个重要页面提供两种语言 | 发布译文页面并手动关联 | 保持链接、共享导航和更新的一致性 |
| 运营各自独立的区域网站 | 独立安装或 WordPress 多站点 | 维护每个站点并协调共用信息 |
| 打造高度定制的多语言体验 | 定制开发方案 | 为开发、测试和长期支持预留预算 |

浏览器翻译是访客阅读你网站的另一种方式，但它不会替你发布翻译后的内容。下面会说明这一区别。

## 方案一：替换网站当前的语言

如果你的网站只服务一种语言，可以直接翻译其现有内容。

假设你用英文搭建了一个小企业网站，但现在希望它完全是法语。你未必需要多语言架构，你需要的是一次细致的内容转换。

开始编辑之前，先做备份，并尽可能在私有的测试环境中操作，以免访客看到翻译了一半的网站。

然后按以下顺序处理整个网站：

1. 翻译首页和主要服务页。
2. 酌情更新导航、页头、页脚、按钮和联系方式。
3. 使用管理这些内容的工具，翻译表单、确认提示和其他面向访客的文字。
4. 检查图片说明、替代文本和可下载文档。
5. 更新页面标题以及你能控制的搜索描述。
6. 设置站点默认语言，并测试完成后的网站。

并不是因为翻译了文字就必须更改每个 URL。如果你确实更改了现有地址，请规划重定向，让使用旧链接的访客仍能抵达正确页面。

转换完成后，你维护的是一种语言，而不是一个原始版本加一套译文。当你确实不再需要旧语言时，这是完全合理的选择。

## 方案二：在现有网站中添加译文页面

对于小型展示型网站，你可以为每个重要页面创建译文版本，并把对应的页面互相关联。

这种方式无需再搭一套 WordPress 就能让译文上线。但它本身并不会把 WordPress 的其余部分变成一个"懂语言"的系统。

下面是一个英文网站添加法语的实际例子。

### 第 1 步：从一条小而完整的访客路径开始

挑出别人理解你的业务并联系你所需要的页面。对服务类网站来说，可能是首页、服务、关于和联系。

先翻译这条路径，再去处理旧文章的归档。一个能看懂你的服务却无法使用联系表单的访客，并没有获得完整体验。

用一张简单的跟踪表记录四列：原页面、译文页面、审校状态、最后检查日期。

### 第 2 步：创建译文页面

在 WordPress 中进入**页面 → 新建**，填入翻译后的标题和内容，并用你惯用的编辑器排版。

如果你使用 Elementor，道理相同：先翻译页面内容，再检查排版中更长的标题、不同的换行以及移动端的间距。

选择清晰的页面地址。例如，英文的服务页可以用 `/services/`，法语对应页面用 `/services-fr/`。

你也可以把普通的 WordPress 页面放在一个别名为 `fr` 的父页面之下，生成 `/fr/services/` 这样的地址。WordPress 通过页面设置支持页面层级和可编辑的别名。这只是组织页面，并不会自动生成按语言区分的博客归档、商品或搜索结果。[WordPress 页面设置](https://wordpress.org/documentation/article/page-post-settings-sidebar/)

### 第 3 步：关联对应的页面

在英文服务页上，添加一个标注清晰的 **Français** 链接，指向法语服务页。在法语页面上，添加一个返回的 **English** 链接。

你可以先用页面内普通的文字链接或按钮。把这些链接放在固定、容易找到的位置。

有用的细节在于目标地址：在服务页上切换语言，应该把访客带到同一项服务，而不是让他们从首页重新找起。

如果某个译文尚未提供，就明确说明，而不要链接到一个不相关的页面。

### 第 4 步：检查导航和共享区块

这正是简单的页面翻译可能演变成大工程的地方。

翻译后的页面可能仍使用与英文站相同的页头、页脚和导航。编辑共享菜单会影响所有使用它的页面。

WordPress 的导航区块可以添加和编辑导航链接。但添加一个法语菜单，并不会让 WordPress 自动为法语页面选用它。这一行为取决于你的主题、模板配置或额外开发。[WordPress 导航区块文档](https://wordpress.org/documentation/article/navigation-block/)

如果你的主题支持合适的模板，也许可以为译文页面指定单独的导航布局。否则，请判断页面级别的链接是否够用，还是需要技术支持。

### 第 5 步：测试范围要超出页面文字

以访客身份打开法语版本，走完整条路径：

- 你能在译文页面之间移动而不被带回英文吗？
- 移动端菜单的表现符合预期吗？
- 表单标签、错误提示和确认信息是否易懂？
- 语言链接是否指向对应页面？
- 共享横幅和页脚链接是否合适？

还要检查页面的语言声明是否与内容一致。这有助于屏幕阅读器采用正确的发音规则。仅有一个法语 URL 并不能完成这项配置；对于多语言混排的站点，可能需要开发者处理。[W3C 关于页面语言的指南](https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html)

**最适合：**页面数量有限、语言不多、更新不频繁的情况。请把它当作人工维护的方案，而不是完整的多语言系统。

## 方案三：为每种语言维护独立站点

当每类受众确实需要不同内容时，独立站点是有意义的。法国区域团队可能有自己的服务、促销和发布节奏。

你可以使用独立的 WordPress 安装，也可以使用 WordPress 多站点——它用一套共享的安装运行一个站点网络。多站点可以共享主题和插件，同时让各站点内容彼此独立。启用它会改动你的安装环境，需要规划和备份；请让主机商或开发者按官方指南操作。[WordPress 多站点搭建指南](https://developer.wordpress.org/advanced-administration/multisite/create-network/)

之后的发布流程大致如下：

1. 准备该语言的站点及其导航。
2. 添加并审校其内容。
3. 在站点之间关联对应页面。
4. 明确每个站点的更新责任人。

多站点不会翻译你的内容，也不会自动关联对应页面。它提供的是网络，语言之间的关系仍由你管理。

对相互独立的区域业务来说，这是合理的结构。但对一家只想让同一个网站有两种语言的小企业来说，它可能带来超出必要的管理成本。

## 方案四：定制开发多语言方案

开发者可以围绕你网站的具体需求，构建语言选择、翻译字段、导航规则和搜索行为。

对于定制应用或拥有开发团队的机构，这是正当的选择。但对一个只想避免再多一笔订阅费的新手来说，这很少是一件可以自己动手的小事。

上线之后工作仍在继续。必须有人测试新的内容类型、主题变更、表单以及网站依赖的各种集成。

如果选择这条路，记得要求对方演示**编辑体验**，而不只是成品网站。你应该能看到哪些译文缺失、哪些需要审校，以及如何安全地发布更新。

不用现成插件并不能消除软件维护的需要，它只是改变了由谁来负责。

## 谷歌翻译或浏览器翻译够用吗？

Chrome 等浏览器可以为单个访客翻译页面。当有人打开一个自己读不懂的语言的网站时，这确实有帮助。[Chrome 翻译帮助](https://support.google.com/chrome/answer/173424?hl=en)

但这发生在访客的浏览过程中。它不会在你的 WordPress 后台生成一个可供你审校、发布和维护的法语页面。

把浏览器翻译当作一种便利，而不是你自己多语言发布策略的替代品。你无法指望每位访客都启用它，也无法控制他们看到的每一处措辞。

用外部翻译工具准备草稿则是另一回事：你可以审校这份草稿，再用上文的某种手动方式自行发布。

## 不用插件的多语言网站能出现在搜索结果里吗？

可以。翻译插件并不是译文页面出现在谷歌中的前提条件。

谷歌建议为每个语言版本使用不同的 URL、提供清晰的语言专属内容和导航，并提供让访客选择其他语言的链接。它还建议使用 `hreflang` 标注来标识对应的语言版本。仅依赖浏览器设置或按语言自动跳转，可能会让各版本更难被发现。[谷歌的多语言网站指南](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)

对于你的手动方案，请检查：

- 每个译文页面都有可用且可公开访问的 URL。
- 其正文内容和导航使用的是预期语言。
- 页面标题和搜索描述与译文内容一致。
- 语言链接连接的是对应页面。
- 技术性的语言标注已正确实现并持续维护。

你不需要掌握每一个技术细节才能安排这项工作。但发布翻译好的段落，并不等于完成了 SEO 配置，而且没有任何配置能保证排名。

## 长期工作：让每种语言都保持准确

设想你为服务页添加了法语版本。上线当天一切完美。

两个月后，你改了服务套餐、调整了交付周期，并在英文页面上新增了一个咨询按钮。

法语译文依然通顺。问题在于，它描述的已经是一项你不再提供的服务。

这就是选择方案之前要回答的维护问题：**你将如何察觉另一种语言需要更新？**

对小网站来说，一张跟踪表加一份发布清单可能就够了。每次修改页面时，在标记完成之前先检查它的其他语言版本。

对于不断成长的网站，任务不止于页面段落。菜单、表单、可下载文档、推广横幅和商品信息都可能各自发生变化。

WooCommerce 商店还要多考虑一层：翻译商品描述并不会自动带来多语言的购物车、结账流程和客户邮件。请测试完整的购买路径，并确认你所选方案支持哪些环节。

并不存在一个通用的页面数量阈值，超过它手动管理就失效了。更新频率、语言数量和团队责任分工同样重要。

## 什么时候需要一个翻译工作区

对于小而稳定的网站，手动管理依然合适。如果你花在跟踪翻译进度上的时间，超过了审校译文本身的时间，那就值得考虑一套专门的工作流。

LingoWP 是其中一个选择。它把翻译工作集中到一个 WordPress 工作区里，你可以在其中手动翻译、审校译文，并在源内容更新后识别出需要关注的受支持内容。

AI 翻译是可选的：工作流可以采用手动翻译、托管 AI，或你自己的受支持服务商密钥。若使用自有密钥，服务商仍可能收取使用费用。

实际好处在于可见性。你不必再去回忆检查过哪些语言的哪些页面，而是有一个地方来组织工作、查看还剩什么。

LingoWP 本身仍是插件，所以它不属于"不用插件"的方法。它是为那些更看重长期易管理性的读者准备的另一种选择。你可以在 [LingoWP 网站](https://lingowp.com/)了解其工作流，并在选用前确认它与你网站的当前兼容性。

## 常见问题

### 不用插件能免费翻译 WordPress 网站吗？

你可以使用 WordPress 现有的编辑工具手动翻译并发布内容，而无需购买多语言插件。但翻译服务、额外的主机资源或开发协助仍可能产生费用。你自己的时间同样是决策的一部分。

### 不用插件能添加 WordPress 语言切换器吗？

可以。你可以用文字、按钮或导航链接在各语言版本之间添加链接。但一份基础的链接列表既不会翻译内容，也不会自动选中对应页面。这些对应关系需要你自己维护。

### 更改站点语言会翻译我的页面吗？

不会。它改变的是 WordPress 的默认语言，而不是你写的内容。你的页面、文章和自定义的访客可见文字仍需翻译。

### 做双语网站需要 WordPress 多站点吗？

不需要。小型网站可以在一套安装中发布并关联译文页面。当维护独立站点更符合你的组织方式时，多站点才是一个选项；它并不是提供两种语言的必要条件。

### 可以手动翻译 Elementor 网站吗？

可以。你可以用 Elementor 创建译文页面并把它们关联起来。共享模板、导航、表单和移动端布局需要单独检查。添加译文文字并不会自动为每种语言配置这些部分。

## 选一套你能持续维护的方案

如果你是用一种语言替换另一种，就翻译现有网站并仔细通读检查。如果你只需要少数几个双语页面，手动关联的译文也许就够了。如果你的区域网站各自独立运营，那么独立站点可能更合适。

当更新变得频繁时，请选择一套能让翻译状态一目了然、便于维护的工作流。

目标不是把另一种语言发布一次就算完成，而是让访客每次回来，都能在该语言中读到准确的信息。