A client asks for a website in three languages. You open the Tilda documentation, look at multilingual solutions, and realize: neither Weglot nor built-in tools can handle the catalog and forms. Multify works differently — not through a script on the page, but through DNS. Let's break down exactly how.
The Problem with Client-Side Translation
Most translation services work on one principle: they insert a JavaScript script into the <head> of the page. The script loads in the browser, intercepts the text on the page, and replaces it with the translation.
This creates several problems.
Search engines see the original. Googlebot requests the page, receives HTML without the script (or with an unexecuted script), and indexes the original language. Language versions are either not indexed at all or are indexed as duplicates. Google officially confirms that JavaScript rendering occurs with a delay and is not guaranteed.
Dynamic content is not translated. Tilda loads the product catalog via a separate API request. By the time the translation script has already “processed” the page, the products have not yet arrived. Result: the interface is translated, product names and prices are in the original language.
Forms break. Tilda forms send data through their own domain. The translation script runs on your domain and does not have access to Tilda requests. Field labels, error messages, and post-submission text remain untranslated.
How a Reverse Proxy Works
Multify connects at the DNS level. You change the records so that traffic to language versions goes through Multify servers, not directly to Tilda.
The scheme works like this:
- User opens de.yoursite.com (or yoursite.com/de)
- DNS sends a request to Multify servers
- Multify requests the original page from Tilda
- Receives HTML, translates all content on the server
- Returns the already translated page to the user
The user sees your domain. Tilda doesn't even know that there is a proxy layer between it and the user. From Tilda's point of view, it's just another request to the site.
Why Server-Side Translation is Important for SEO
When translation occurs on the server before HTML is delivered, the search engine receives an already translated page. This means:
- Googlebot indexes the German version as a separate URL with German content
- hreflang attributes in <head> point to the correct language versions
- The sitemap has separate URLs for each language
- No duplicate content — each version has its own semantics
Multify automatically generates all these tags. You don't need to manually specify hreflang for each page or maintain a separate sitemap. Implementation requirements are described in Google's documentation on localized versions.
What This Means for Dynamic Content
The proxy architecture intercepts not only the initial HTML but also all subsequent content requests. When Tilda loads a product catalog via API, Multify intercepts the server's response and translates it before delivering it to the browser.
In practice, this means:
- Product names and descriptions are fully translated
- Prices are converted to the desired currency (more on this below)
- Dynamically loaded blog articles switch to the desired language
- Content of widgets and third-party blocks is processed where technically possible
For an agency, this removes the most frequent question from clients with catalogs: "will the products also be translated?"