客户要求制作一个三种语言的网站。您打开Tilda文档，查看多语言解决方案，然后发现：无论是Weglot还是内置工具都无法处理目录和表单。Multify的工作方式不同——不是通过页面上的脚本，而是通过DNS。让我们来分析一下具体如何运作。
客户端翻译的问题
大多数翻译服务都遵循一个原则：将 JavaScript 脚本插入页面的 <head> 中。脚本在浏览器中加载，拦截页面上的文本并将其替换为翻译。
这会产生几个问题。
搜索引擎看到的是原文。 Googlebot 请求页面，接收没有脚本（或脚本未运行）的 HTML，并索引原始语言。语言版本要么根本不被索引，要么被索引为重复内容。Google 官方确认，JavaScript 渲染会延迟且不保证。
动态内容未翻译。 Tilda 通过单独的 API 请求加载产品目录。当翻译脚本“处理”页面时，产品尚未到达。结果：界面已翻译，但产品名称和价格仍为原始语言。
表单损坏。 Tilda 表单通过其自己的域发送数据。翻译脚本在您的域上运行，无权访问 Tilda 请求。字段标签、错误消息和提交后的文本未翻译。
反向代理如何工作
Multify 在 DNS 级别连接。您更改记录，以便语言版本的流量通过 Multify 服务器，而不是直接流向 Tilda。
该方案的工作原理如下：
- 用户打开 de.yoursite.com（或 yoursite.com/de）
- DNS 将请求发送到 Multify 服务器
- Multify 从 Tilda 请求原始页面
- 接收 HTML，在服务器上翻译所有内容
- 向用户提供已翻译的页面
用户看到您的域。Tilda 甚至不知道它和用户之间有一个代理层。从 Tilda 的角度来看，这只是对网站的另一个请求。
为什么服务器端翻译对 SEO 很重要
当翻译在 HTML 交付之前在服务器上进行时，搜索引擎会收到一个已经翻译好的页面。这意味着：
- Googlebot将德语版本作为具有德语内容的独立URL进行索引
- <head>中的hreflang属性指向正确的语言版本
- sitemap中每个语言都有单独的URL
- 没有重复内容——每个版本都有自己的语义
所有这些标签都是Multify自动生成的。您无需手动为每个页面编写hreflang或维护单独的sitemap。实施要求在Google关于本地化版本的文档中有所描述。
这对动态内容有什么帮助
代理架构不仅拦截初始HTML，还拦截所有后续的内容请求。当Tilda通过API加载产品目录时，Multify会在将其提供给浏览器之前拦截服务器响应并进行翻译。
实际上这意味着：
- 产品名称和描述被完整翻译
- 价格将转换为所需的货币（详情如下）
- 动态加载的博客文章将切换到所需的语言
- 小部件和第三方块的内容在技术上可行的情况下进行处理
对于代理机构来说，这解决了客户最常问的关于目录的问题：“产品也会被翻译吗？”