代理机构将 Weglot 连接到 Tilda 网站。插件安装成功，语言切换按钮也出现了。然后发现商品目录仍然是俄语，联系表单也是，部分内容根本没有加载。这不是安装错误。这是架构的根本限制：Weglot 只翻译静态内容，而 Tilda 中的静态内容很少，所有动态内容都未被翻译。
Weglot 不仅仅是一个 JS 脚本，它通过 DNS 作为反向代理工作。问题在于它没有考虑到 Tilda 架构的特殊性，这导致了内容翻译的困难。
Weglot 的整体工作原理
反向代理在具有简单 HTML 结构的静态网站上运行良好：普通博客、没有动态块的登录页面。Weglot 在 WordPress、Shopify、Webflow 上表现出色——那里的内容是可预测的，并且在加载时可立即供脚本使用。
Tilda 的结构不同：它具有特定的功能和许多需要特殊处理的动态内容。
为什么 Tilda 是一个不同的案例
Tilda 以区块形式生成页面。大部分内容以标准方式加载，但一些区块通过其自己的机制运行：AJAX 请求、独立的 API 请求。
这些区块包括：
- 商品目录 (Tilda Store) — 商品数据通过对 Tilda 服务器的单独请求加载，而不是存在于原始 HTML 中。Weglot 的 JS 脚本在这些数据出现在 DOM 之前运行。
- 表单 (Tilda Forms) — 字段名称、标签、错误消息和按钮文本部分是动态渲染的。Weglot 无法完全拦截所有内容。
- 小部件和第三方嵌入 — TravelLine、Calendly、预订小部件从另一个域加载到 iframe 中。Weglot 的 JS 脚本无法访问这些内容：这是浏览器限制，而非 Weglot 的问题。
总结：在一个典型的带有目录和表单的 Tilda 商业网站上，Weglot 大约翻译了一半的内容。其余的仍保留在原始语言中。
这对 SEO 意味着什么
这是一个独立的问题，而且比看起来更严重。
Weglot 通过 DNS 集成（反向代理）成功地在服务器端翻译静态内容。然而，对于通过 JS 加载的动态元素，此方法不起作用：Googlebot 可能会在脚本替换文本之前抓取页面，导致原始版本被索引。
对于动态块，Weglot 尝试在页面加载后翻译内容，这会导致延迟和视觉跳动。与此不同，Multify 直接集成到 Tilda API 中，并在响应到达浏览器之前翻译数据：对于用户来说，内容看起来是立即翻译的，就好像它最初来自 Tilda 服务器一样。
这直接影响了外语关键词的排名：页面存在，翻译也存在，但搜索引擎却无法将其识别为已翻译。 Weglot 自己也承认：JS 集成不提供 SEO 优势，因为翻译不会进入原始 HTML。
hreflang 的细微差别
Weglot 静态添加 hreflang 标签。虽然这允许搜索引擎发现语言版本，但存在一个技术细微差别：Weglot 不添加 x-default 标签。而 Multify 则根据 Google 的建议正确实现 x-default，这有助于搜索引擎更好地确定默认语言版本。
该怎么办
Weglot 是一款不错的产品，它适用于内容静态且可预测的场景。但在包含目录和表单的 Tilda 网站上，它只能部分工作。这不是设置或费率的问题，而是架构限制。Weglot 最初是为 WordPress 和 Shopify 量身定制的。
Multify 专为 Tilda 优化：它翻译动态内容、表单和目录，并在服务器端转换货币。正确的 SEO 元标签直接在 HTML 中生成。
代理方法根本不同：翻译在服务器上进行，浏览器接收到的已经是翻译好的页面。Google看到的内容与用户看到的内容相同。