Case study: 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 does not see the same thing that the buyer sees.
According to cross-border shopping research, 92% of buyers prefer to see prices in local currency, and one in three buyers abandon 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 issue.
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 visit the page, and within a second, they see the price in euros. Sometimes there's a slight flicker during loading, sometimes not. Visually, it works.
The problem isn't that the user doesn't see something. The problem is that the search bot sees the page completely differently.
What Googlebot sees
Googlebot indexes pages during initial rendering. According to Google Search Central, JavaScript rendering can 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 — can appear in 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.
These are two problems at once. First: the snippet in the search results shows an unlocalized price — this reduces clickability. Second: if you use microdata (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 them exactly as such in rich results.
For example, if you use Tilda, you often find meta tags or JSON-LD markup like "price": "4500" and "priceCurrency": "RUB" in the page code. Even if a JS script on the frontend replaces the display with "€45", the search robot reading the original HTML will record the ruble price, which will lead to errors in the price display in search results.
To ensure that the search engine sees the currency you expect, we recommend checking the page using Google Rich Results Test. This tool will show exactly how Google interprets your micro-markup in real time.
More details on the structured data format for products, including fields for price and currency, are described 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, a 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 this page matches the audience: language, currency, context. JS conversion gives the illusion of localization, but the indexed content remains in its original form.
Server-side conversion: how it should work
When currency is converted on the server, the user's browser receives a ready-made page with prices in the desired currency. Everything is calculated in advance; the browser receives ready HTML with the correct numbers.
Googlebot sees the same thing the customer sees: prices in euros, correct micro-markup, correct snippet. Full localization — for the user and for the search engine simultaneously.
Within this approach, the exchange rate is taken from a reliable source (e.g., ECB or another API) and applied on the proxy server side when serving the page. The cache is updated on a schedule. The user never sees any "flickering" during loading.
How Multify solves the problem
Multify works as a proxy layer between the website and the user. When a request comes from a user in Germany, the server delivers the page with prices already converted to 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 the site is localized; with server-side conversion, the site is truly localized — for both people and search engines.
What to do if you already have JS conversion
If you are currently using a currency conversion widget, check Google Search Console: what does Googlebot see 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 if the microdata is correct.
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.
FAQ
Does Googlebot always ignore JavaScript?
No, but it works more complex than desired. Google does render JavaScript, but it happens in a separate queue and can be delayed. For fresh pages or rapidly changing prices, indexing delays mean that relevant content will appear in 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 bot 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 microdata tag.