A Tilda store, with an audience in several countries. It would seem that you connect a JS currency conversion widget, prices are recalculated in the user's browser — problem solved. But when you look at Search Console, you see that organic traffic for foreign queries is not growing. The reason is that the search engine sees something completely different from what the buyer sees.
根据 cross-border shopping research, 92% of buyers prefer to see prices in local currency, and one in three buyers abandons their cart if the price is shown only in foreign currency. This sounds obvious — but what's interesting is how most stores solve this problem, and why the solution turns into an SEO problem.
How JS Conversion Works
Most currency conversion widgets and scripts work according to one scheme: the page loads with prices in the original currency, then JS gets the exchange rate via API and recalculates the numbers directly in the user's browser.
For the buyer, this looks normal: they landed on the page, and a second later saw the price in euros. Sometimes there's a slight flicker during loading, sometimes not. Visually, it works.
The problem is not that the user doesn't see something. The problem is that the search robot sees the page completely differently.
What Googlebot Sees
Googlebot indexes pages during initial rendering. According to Google Search Central, JavaScript rendering may be delayed: first, the HTML version of the page is indexed, JS may be processed later or not at all.
This means that prices in the original currency — rubles — may appear in the search results if the store is originally Russian. A user from Germany enters a query, sees “4500 ₽” in the results, clicks, and only after the page loads is the price converted to euros.
This is two problems at once. First: the snippet in the search results shows an unlocalized price — this reduces clickability. Second: if you use micro-markup (schema.org/Product with a price field), it is written in HTML with the original currency. The search engine sees structured data with rubles and displays it exactly as such in rich results.
For example, if you use Tilda, you can often find meta tags or JSON-LD markup like "price": "4500" and "priceCurrency": "RUB" in the page code. Even if the JS script on the frontend replaces the display with “€45”, the search robot, which reads the original HTML, will record the ruble value, which will lead to errors in displaying the price in the search results.
To ensure that the search engine sees the currency you expect, I recommend checking the page via Google Rich Results Test检查页面。此工具将实时显示 Google 如何解释您的微数据。
The format of structured data for products, including fields for price and currency, is described in more detail in Google's official documentation on structured data for products。
Why This Is Worse Than It Seems
Suppose you are promoting a page for the German market. In Google Merchant Center or in organic search results, the buyer expects to see the price in euros. If your microdata says “4500 RUB”, it's not just unsightly — Google may not show your products in local shopping results.
An SEO strategy for a specific market assumes that the content on that page matches the audience: language, currency, context. JS conversion gives the illusion of localization, but the indexable content remains in its original form.
Server-side conversion: how it should work
With server-side conversion, the user's browser receives an already prepared page with prices in the desired currency. Everything is calculated on the server, the browser receives ready-made HTML with the correct numbers.
Googlebot 看到买家看到的内容：欧元价格、正确的微数据、正确的摘要。本地化是完整的——同时适用于用户和搜索引擎。
在这种方法中，汇率取自可靠来源（例如，ECB 或其他 API），并在代理服务器端交付页面时应用。缓存按计划更新。用户在加载时永远不会看到“闪烁”。
How Multify solves the problem
Multify works as a proxy layer between the site and the user. When a request comes from a user in Germany, the server returns the page with prices already recalculated in euros. The exchange rate is updated automatically.
This is important not only for SEO, but also for the URL structure. The language version of the site lives at /de/ or de.yourdomain.com, and at this same address Googlebot sees correct German-language content with prices in euros. hreflang is generated automatically — no separate configuration is needed.
The difference with the JS approach is fundamental: with JS, you pretend that the site is localized. With server-side conversion, it is truly localized — both for people and for search engines.
What to do if you already have JS conversion
If you are currently using a currency conversion widget, check in Google Search Console what Googlebot sees when indexing your product pages. The “URL Inspection” tool shows the HTML that the bot received — check if there are prices in the desired currency and correct microdata.
If you see the original currency, it's not a disaster, but it means that organic traffic from other countries is not working at full capacity.
常见问题
Googlebot 总是忽略 JavaScript 吗？
No, but it's more complicated than one would like. Google does render JavaScript, but this happens in a separate queue and can be delayed. For fresh pages or rapidly changing prices — indexing delay means that the current content will appear in the search results later. For dynamic data like prices, this is unacceptable.
What about Yandex?
Yandex also renders JavaScript, but with limitations. For CIS markets (Kazakhstan, Belarus, Armenia), this is also a relevant problem: the robot may not get the correct content during the initial crawl.
How to check if the search engine sees the correct currency?
Via Google Search Console: “URL Inspection” → “View Crawled Page” → “More Info”. This shows the HTML that Googlebot received. Look for your prices — in what currency they are specified in the priceCurrency tag of the microdata.
