代理机构将Weglot连接到Tilda网站。插件安装成功，语言切换按钮也出现了。然后发现商品目录仍然是俄语，联系表单也是，部分内容根本没有加载。这不是安装错误。这是架构的根本限制：Weglot只翻译静态内容，而Tilda中的静态内容很少，所有动态内容都未被翻译。
Weglot不仅仅作为一个JS脚本工作，它通过DNS作为反向代理（reverse proxy）工作。问题在于它没有考虑到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看到的内容与用户看到的内容相同。
常见问题
Weglot在Tilda上完全不工作吗？
它工作，但只是部分工作。静态内容——标题、文本块、普通页面——Weglot会翻译。问题始于产品目录、表单以及所有动态加载的内容。
如果我有一个没有目录的简单着陆页——Weglot会适用吗？
对于没有动态块的着陆页，Weglot很可能可以处理。弹出窗口不会有问题，但表单会遇到困难：Tilda将无法接收请求，因为没有集成。对于带有商店的商业网站——不适用。
为什么Google可能看不到Weglot的翻译？
如果翻译是通过JavaScript连接的，Google可能看不到它。在这种模式下，搜索引擎爬虫（例如Googlebot）异步索引页面：它们可能会在脚本运行之前记录原始HTML。结果，索引中保留了原始语言，因为这是客户端JS翻译的工作方式的特点。
Weglot与Tilda有官方集成吗？
Weglot可以通过在网站设置中添加一个特殊脚本来连接到Tilda。这不是官方集成，而只是一种在页面中嵌入代码的方式。
