Multilingual Online Store on Tilda: Launch Checklist
In this article: what needs to be translated in a Tilda online store besides page text, why the catalog and cart require a special approach, how to set up currencies for different markets, what is important for SEO of a multilingual store, and a complete checklist for checking before launch.
You've created a Tilda website, added a catalog, and set up order processing. 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 buy 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, shopping cart, checkout, payment notifications, and error messages. Each of these elements requires separate attention. If something is missed, a buyer from Germany might see a German storefront with a Russian-language cart.
What exactly needs to be translated in the 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 prices are generated after the page loads. Most translators only see the HTML structure, not what is loaded afterwards.
Result: the product is called "Leather wallet" on the storefront, but when you go to the product card, it's back in Russian. Or the entire catalog remains untranslated, while the storefront is already in English.
Cart and Checkout
Tilda Store is a separate module with its own logic. Cart, checkout page, shipping address fields, payment method selection, "Pay" button — all these are separate components. Most services do not translate them.
System Messages
"Item added to cart," "insufficient stock," error notifications — all of these are generated dynamically. They often remain in the original site's language, 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 fields with language, country, and domain from which the application was sent in the form data. If you connect n8n, Make, or an analogue, 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 Fail
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 data in real time. By this point, the client-side translator has already finished processing the page. It does not see new data.
The solution is server-side translation. When all requests to Tilda pass 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 it appeared 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, and each has different consequences for SEO.
Conversion in JavaScript
The most common method: a script on the page takes the ruble price and recalculates it into 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.
Manually Maintaining 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 the German buyer sees: prices in euros. SEO is correct, data is up-to-date.
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 in the search engines of target markets.
hreflang
Hreflang tags tell Google that you have multiple language versions of the same 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 a 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
Two main models: subdomains (de.yourshop.com) and folders (yourshop.com/de/). For most Tilda online stores, folders are easier to implement and do not require additional DNS settings.
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's 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 not translated automatically; the content needs to be adapted for each market.
Legal requirements. For the European market, a cookie banner is required in accordance with GDPR, privacy policy in the user's language, sometimes mandatory seller information (Impressum for Germany).
Launching a store in multiple markets?
We will show you how your catalog and cart will look in the desired 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
When returning to the site, the language is preserved
Automatic language detection by geolocation is configured (if needed)
Catalog search works in the target language
Payment Methods
Available payment methods correspond to the market
Test order successfully completed on each language version
Confirmation email arrives in the customer's language
Legal requirements
Privacy policy translated
Terms of use translated
Cookie banner configured (mandatory for the European market)
Age or other restrictions taken into account 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 Errors During Launch
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 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 prices in rubles on the German-language page. This affects ranking in German search and how product cards appear in Google Shopping.
No hreflang on product pages. You set it up on the homepage, and on category pages, but forgot about product cards. Google doesn't understand that /de/product/leather-wallet is the German version of /product/leather-wallet, and may show German users the Russian version.
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 automatically resolved. If you want translated emails, you need a separate integration via n8n or Make — Multify passes the language and domain from which the order came in the form data, and you can build template selection logic based on this.
FAQ
Do I need a separate domain for each language version of the store?
No. One 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 major 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 requests for catalog data, 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 Block.
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, 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 to 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?
No additional settings are usually required from Tilda's side. You work in the editor as usual: add products, change descriptions, update prices. Multify takes care of everything else at the proxy level.
Launching a multilingual store on Tilda is not just about adding a translation. You need to make sure that every step of the purchase path 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 required languages.