76% of people are more likely to buy a product if the description is in their native language — this is according to CSA Research. So translation is not just a “courtesy,” but direct work with conversion.
The client asks for an English version of the website. You open Tilda and realize: there is no built-in way to make a multilingual website. There are only a few workarounds, and most of them create problems at the start or later.
Option 1: Separate project in Tilda
The most obvious solution: you duplicate the project, translate everything manually, and publish it on another domain or subdomain.
As soon as the client changes something on the main site, you go to the copy and do the same. If the client actively maintains a blog or updates a catalog, this turns into endless manual synchronization. At the same time, the content still needs to be translated and re-laid out in the Tilda editor, as elements may shift.
Another problem: SEO. Tilda does not have a built-in mechanism for hreflang between two separate projects. Without hreflang, Google does not understand that the two sites are linked and may perceive the English version as duplicated content.
Suitable for: single-page landing pages with infrequent updates that are not planned for search promotion.
Option 2: Zero Block with language switcher
Found in agencies that want to do everything within one Tilda project. Logic: one block in Russian is hidden via CSS, another is shown. The language is switched by a button.
It looks like a solution, but search engines don't understand such a page. Google sees mixed content of both languages at once: it doesn't know that the Russian text is for some users and the English for others. No hreflang, no language separation. For SEO, this can be even worse than two separate websites.
In addition, forms and dynamic content are not translated with this approach: catalog buttons, form fields, error messages — all of this remains in the original language.
Option 3: Translation services with JS script
Weglot, Linguise, and similar solutions work with Tilda via a JS script on the page: the browser loads the original content, and the script replaces it with the translated version.
Visually, this approach works: the user sees the translated text, although not immediately after the page loads, but after some time. However, there is no benefit for SEO: search engine bots only index the original version of the site, as they see the content before the JS script has a chance to replace it.
Search engine bots index what they see during the initial rendering. They may not see JS content or may see it with a delay. This means that your English version in search will be indexed worse than desired, or not indexed at all.
Option 4: Proxy with server-side translation
It works like this: a proxy server stands between the user and your site, translating all content on the server side. The browser then receives the ready-translated HTML.
What this gives:
- Search engines see fully translated content, not a JS placeholder
- hreflang is generated automatically (in the meta tags of each page and in sitemaps)
- All dynamic content is translated: catalog, forms, buttons, error messages
- Content management only on the source site, the number of languages does not increase labor costs
This is how Multify works. You connect the English version via a subdomain (for example, en.yourwebsite.ru) or a separate domain, everything else happens at the server level.
What to Consider When Creating an English Version
Domain Structure
Two options: a subdomain (en.site.ru) or a separate domain (site.com). For most projects, a subdomain is easier to set up and works fine from an SEO perspective. A separate domain makes sense if you plan to build a separate brand for the Western market.
Folders (site.ru/en/) are not natively supported by Tilda. This cannot be implemented without a proxy, although this option is more advantageous: the reputation of one domain grows, and there is no need to spread efforts across promoting several sites.
Content that needs to be adapted
Mechanical text translation is only half the job. For an English-speaking audience, you often need to:
- Replace examples and cases with those understandable to a Western reader
- Change payment methods: some payment systems that work in Russia may not work abroad
- Adjust calls to action: what works for a Russian-speaking audience might sound strange in English
- Check images: do they contain text that also needs to be translated
hreflang and sitemap
Without properly configured hreflang, Google may show the English version to Russian-speaking users, and vice versa. Manually configuring hreflang in Tilda is non-trivial: the platform suggests inserting code manually into the HEAD of each page — there is no automatic interface.
When using a proxy solution, hreflang is typically generated automatically for each page. The sitemap is also updated automatically.
Forms on the English version
This is a separate story. A form on Tilda, translated mechanically, still sends data to the notification system in Russian, unless configured separately. Fields, hints within fields, messages after submission, error texts during validation — all of this needs to be translated separately.
Typical mistakes when launching an English version on Tilda
Publish without hreflang. Search engines will see two sites without a connection between them. Traffic may not go where it should.
Translate only text, ignore dynamics. English catalog, "Add to cart" buttons in Russian. Conversion will be appropriate.
Create a separate project and don't think about synchronization. The first couple of months are fine. Then the client starts making edits, and one of the sites "falls behind".
Ignore payment systems. YuKassa and Robokassa do not accept foreign cards. If the English version is for a Western audience, you need Stripe or PayPal.
How to make a decision
If the site is simple (landing page, business card) and the English version is needed once and for all without updates — a separate project in Tilda is the easiest. If the site is live, with regular updates, a catalog, or forms, a proxy solution is needed. Everything else creates debt that will have to be paid later.