You've created a Tilda website, added a catalog, and set up checkout. Now you need to launch English and German versions. It seems like simply translating the text is enough.
According to CSA Research, 76% of buyers prefer to purchase in their native language, and 40% will not buy in another language at all. But adding a language version and making it functional are different tasks.
In practice, a multilingual store is more complex than a regular multilingual website. It includes a dynamic catalog, shopping cart, checkout, payment notifications, and error messages. Each of these elements requires separate attention. If something is overlooked, a customer from Germany might see a catalog in German with a Russian-language shopping cart.
What exactly needs to be translated in a store
An online store on Tilda has several categories of content that behave differently. Static page text is the lesser part of the problem.
Static Content
Store description, company texts, delivery terms, static blocks on the homepage. This is translated standardly; any proxy translator can handle it.
Product Catalog
Tilda loads product cards dynamically via JavaScript. Names, descriptions, characteristics, and price tags are generated after the page loads. Most translators only see the HTML structure, not what is loaded afterwards.
Result: the product in the catalog is called “Leather wallet”, but when you go to the product card, the name is in Russian. Or the entire catalog remains untranslated.
Cart and Checkout
Tilda Store is a separate module with its own logic. The cart, checkout page, delivery address fields, payment method selection, and “Pay” button are all separate components. Most services do not translate them.
System Messages
"Item added to cart", "insufficient stock", error notifications — all of this is generated dynamically. Often it remains in the language of the original site, even when everything else is translated.
Emails and Notifications
Order confirmation emails are a separate story. Tilda sends emails through its own mechanism, and Multify does not affect this process. This is not a bug or a limitation of a specific service: emails live outside the proxy's area of responsibility.
Technically, this can be solved through external automation. Multify passes form data fields with language, country, and domain from which the application was sent. If you connect n8n, Make, or an analog, you can set up logic: if an application comes from the German version, send an email using the German template. But this is a separate integration that needs to be configured independently.
Why Standard Solutions Don't Work
Weglot and Linguise translate static HTML. Dynamic content (catalog, cart, messages) they either don't see or translate unstably.
Specific problem: when a user adds an item to the cart, Tilda accesses its servers and receives real-time data. By this point, the client-side translator has already finished processing the page. It does not see the new data.
Solution — server-side translation. When all requests to Tilda go through a proxy, every response (including catalog data and cart status) is translated on the server, and the browser receives the ready result. The user always sees translated content, regardless of how they arrived on the page.
Currencies: Three Approaches and Their Consequences
A multilingual store almost always requires multi-currency. For a German buyer, prices should be in euros; for a British buyer, in pounds. There are three approaches, each with different SEO implications.
JavaScript Conversion
The most common method: a script on the page takes the ruble price and converts it to the desired currency directly in the browser. The user sees euros, but the HTML still shows rubles.
This is bad for SEO. Googlebot scans the page and sees prices in rubles. If your site is for the German market, it registers a discrepancy between what it indexes and what the user sees. This affects ranking for German queries.
Manual maintenance of multiple catalogs
A separate catalog with prices in euros for the German version. It works, but requires manual updates every time prices change. Acceptable for a small catalog, but not for 200+ products.
Server-side conversion
Prices are recalculated on the server, and the user receives a ready-made page with the desired currency. Googlebot sees exactly what a German buyer sees: prices in euros, correct SEO, up-to-date data.
You can choose the source of exchange rates: live currency exchange rate for the ruble market, ECB for the European market, or a manually specified rate – if you don't want prices to change daily with the exchange rate.
SEO: what needs to be configured for each language version
A multilingual store without a proper SEO foundation will be invisible to search engines in target markets.
Hreflang
Hreflang tags tell Google that you have multiple language versions of a single page. Without them, the search engine doesn't know which version to show users from each country and may consider language versions as duplicate content.
This is especially important for a store: every product, every category, and every checkout page must have correct hreflang. Official Google documentation describes the implementation rules in detail.
Sitemap for Each Language
The sitemap must contain all language versions of all pages. 300 products and three languages means 900 pages in the sitemap, each indicating its language.
Meta tags for each version
Title and description in search results should be in the user's language. A German buyer sees a German product description, a French buyer sees a French one.
URL structure
There are 3 possible models:
- subdomains (de.yourshop.com) — the simplest method, suitable for most online stores
- folders (yourshop.com/de/)
- different domains (yourshop.com/yourshop.de/)
Localization: what goes beyond translation
Technically, translation can be set up in a day. But for the store to work for buyers from a specific country, several additional things need to be considered.
Date and number formats. In Germany, the price is written as "19.99 €", in the USA - "$19.99". Thousands separator, currency sign position, date format. Small details that are immediately noticeable to a local buyer.
Payment methods. A Russian buyer is used to YuKassa or SBP. A European expects Stripe, PayPal, or SEPA transfer. Showing all payment methods to all users makes no sense, it creates confusion. It is better to show only those that work in a specific region.
Delivery terms. Each market has its own terms, its own carriers, its own delivery cost. This is configured separately for different regions.
Legal requirements. For the European market, a cookie banner is needed in accordance with GDPR, a privacy policy in the user's language, and sometimes mandatory seller information (Impressum for Germany).
Checklist for Launching a Multilingual Tilda Store
Use this list before launching a language version and opening it to traffic.
Content Translation
- All website pages are translated, including home, about us, contacts
- Product catalog: names, descriptions, characteristics in the target language
- Product cards, including extended descriptions and tabs
- Cart: all interface elements translated
- Checkout page: fields, buttons, tooltips
- Error messages when filling out forms
- Order confirmation on screen
- Order confirmation email (localization requires separate integration via n8n / Make)
Prices and Currencies
- Prices are displayed in the target market's currency
- Conversion happens server-side (not via JS)
- Exchange rate source selected: live currency exchange rate / ECB / manually specified rate
- Price format matches country standard (separator, currency symbol)
- Prices in search (Google Shopping, if used) match prices on the website
SEO
- hreflang tags are set on all pages, including product cards
- Sitemap contains all language versions of all pages
- Title and description of each page in the language version
- URL structure of language versions is consistent (subdomains or folders)
- Canonical tags are configured correctly, no duplication
Functionality
- Language switcher works on all pages, including checkout pages
- Adding an item to the cart does not change the interface language
- Language is preserved when returning to the site
- Automatic language detection by geolocation is configured (if needed)
- Catalog search works in the target language
Payment Methods
- Available payment methods correspond to the region
- Test order successfully completed on each language version
- Confirmation email is sent in the buyer's language
Legal Requirements
- Privacy Policy translated
- Terms of Use translated
- Cookie banner configured (mandatory for the European market)
- Age or other restrictions considered for the specific market
Final Check
- Full purchase path tested: from storefront to order confirmation
- Mobile view checked on the language version
- Loading speed of the language version is acceptable
- Traffic to the language version is tracked separately in analytics
Typical Launch Mistakes
Launched translation without checking the cart. The most common situation: the storefront is translated, the catalog looks good, but the cart and checkout remain in Russian. The customer reached the order placement stage and saw an untranslated interface. Always go through the full purchase path before launching.
Prices are translated via JS. Visually, everything looks correct, but Googlebot sees ruble prices on a German-language page. This affects ranking in German search and how product cards appear in Google Shopping.
No hreflang on product pages. It was set up on the main page, and on category pages too, but forgotten on product cards. Google doesn't understand that /de/product/leather-wallet is the German version of /product/leather-wallet, and may show the Russian version to German users.
Forgot about emails. A customer placed an order in German, but the confirmation email arrived in Russian. Tilda sends emails through its own mechanism, and this is not resolved automatically. If you want translated emails, you need a separate integration via n8n or Make — Multify transmits the language and domain from which the order came in the form data, and you can build the template selection logic on this.
FAQ
Do I need a separate domain for each language version of the store?
No. A single domain with folders (yourshop.com/de/) is the standard solution for most stores. A separate domain or subdomain only makes sense if you are creating a fully localized product for a specific country with separate branding. For launching multiple languages without a radical overhaul, folders are simpler.
How does Multify handle the catalog if products are loaded dynamically?
Multify works as a server-level proxy. All requests to Tilda, including catalog data requests, pass through it. The response with products is translated on the server, and the translated content is then sent to the browser. This works for both standard Tilda Store blocks and Zero Blocks.
Is it possible to show different prices for different countries, not just different currencies?
Yes. In addition to currency conversion, you can set fixed prices for specific language versions. For example, for the German version, you can set a price of 29 €, not tied to the ruble exchange rate. This is convenient if you have different pricing policies in different markets.
How do I update translations when store content changes?
When new products are added or descriptions are changed, translations are automatically updated on the next request. There's no need to manually update translations in the interface every time: the proxy layer processes new content just like the original.
Do I need to configure anything in Tilda itself for a multilingual store?
Usually, no additional settings are needed on the Tilda side. You work in the editor as usual: add products, change descriptions, update prices. Multify handles everything else at the proxy level.
Launching a multilingual store on Tilda is not just about adding a translation. You need to ensure that every step of the purchase journey works in your customer's language: from the product card to the confirmation email. The checklist above will help you not miss anything before launch.