In this article: what needs to be translated in a Tilda online store besides page text, why the catalog and shopping cart require a special approach, how to set up currencies for different markets, what is important for multilingual store SEO, and a complete checklist for review before launch.
You've created a website on Tilda, added a catalog, and set up checkout. Now you need to launch English and German versions. It seems simple enough to just translate the text.
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 has a dynamic catalog, cart, checkout, payment notifications, and error messages. Each of these elements requires separate attention. If something is missed, a customer from Germany will see a catalog in German with a Russian-language cart.
What Exactly Needs to Be Translated in the Store
A Tilda online store 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 dynamically loads product cards via JavaScript. Names, descriptions, characteristics, and prices are generated after the page loads. Most translators only see the HTML structure, not what is loaded afterward.
Result: a 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, shipping address fields, payment method selection, "Pay" button — all of these are separate components. Most services do not translate them.
System Messages
"Product added to cart", "insufficient stock", error notifications — all of this is generated dynamically. It often 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 exist 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.
The solution is server-side translation. When all requests to Tilda go through a proxy, each 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 at 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, and each has different consequences for SEO.
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 contains rubles.
This is bad for SEO. Googlebot scans the page and sees prices in rubles. If your site is for the German market, it records 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: a live currency exchange rate, 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 in the search engines of target markets.
Hreflang
Hreflang tags tell Google that you have multiple language versions of one page. Without them, the search engine doesn't understand 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 include all language versions of all pages. 300 products and three languages mean 900 pages in the sitemap, each specifying 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).
Are you launching a store in multiple markets?
We will show you how your catalog and cart will look in the necessary languages, with the correct prices for each market.
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 remained in Russian. The buyer reached the checkout and saw an untranslated interface. Always go through the full purchase path before launching.
Prices are translated via JS. Outwardly, everything looks correct, but Googlebot sees ruble prices on the 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. The 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, a separate integration via n8n or Make is needed — Multify passes the language and domain from which the order came in the form data, and you can build the template selection logic based 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 drastic rework, 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 updated automatically with 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 make sure 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.
Ready to launch your store in new markets?
We will connect Multify, check the catalog, cart, and checkout, and show you how it looks in the desired languages.