Blog

English version of a Tilda website: how to create and what to consider

In this article: options for creating an English version on Tilda, why a separate project is a bad idea, what will break without a proper proxy, how to make an English version with correct SEO and not rebuild the site from scratch.
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 matter of "politeness", but a direct way to improve conversion.
A client asks for an English version of the website. You open Tilda and realize: there is no built-in way to create 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 website, 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. Moreover, 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 websites are related and may perceive the English version as duplicated content.
Suitable for: one-page landing pages with infrequent updates that are not planned for search engine promotion.

Option 2: Zero Block with a language switcher

This is common among agencies that want to do everything within a single Tilda project. The logic: one block in Russian is hidden via CSS, another is shown. The language is switched by a button.
This 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.
Plus, 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 translated text, although not immediately after the page loads, but after some time. However, there is no SEO benefit: 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 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

This works as follows: a proxy server stands between the user and your website, translating all content on the server side. The browser then receives the ready-made translated HTML.
What it gives:
  • Search engines see fully translated content, not a placeholder with JS
  • hreflang is generated automatically (in the meta tags of each page and in sitemaps)
  • All dynamic content is translated: catalog, forms, buttons, error texts
  • Content management only on the source website, 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.com) or a separate domain, everything else happens at the server level.
Do you need an English version of your Tilda website?
We will connect the English version with proper SEO, translation of forms and dynamic content.
Submit an application →

What to consider when creating an English version

Domain Structure

Two options: a subdomain (en.site.com) or a separate domain (site.com). For most projects, a subdomain is easier to set up and works well from an SEO perspective. A separate domain makes sense if you plan to build a separate brand for the Western market.
Folders (site.com/en/) are not natively supported by Tilda. This cannot be implemented without a proxy, although this option is more beneficial: the reputation of one domain grows, and you don't need to spread your efforts across promoting several sites.

Content to adapt

Mechanical text translation is half the job. For an English-speaking audience, it is often necessary 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 may sound strange in English
  • Check images: do they contain text that also needs to be translated

hreflang and sitemap

Without properly configured hreflang, Google might show the English version to Russian-speaking users, and vice versa. Manually configuring hreflang in Tilda is not 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

That's a separate story. A form on Tilda, mechanically translated, will still send 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

Publishing without hreflang. Search engines will see two unrelated websites. Traffic might not go where it's supposed to.
Translate only text, ignore dynamic elements. Catalog in English, "Add to Cart" buttons in Russian. The conversion will be accordingly low.
Create a separate project and don't think about synchronization. For the first couple of months, everything is 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, Stripe or PayPal is needed.

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.
Ready to launch an English version?
We will tell you how it works on your specific site and show a demo.
Try a free demo →
2026-04-02 23:58