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 a cross-border shopping study, 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 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 is 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 the 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, if the store is originally Russian — may appear in search results. 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, in the page code you can often find meta tags or JSON-LD markup like "price": "4500" and "priceCurrency": "RUB". Even if the JS script on the frontend replaces the display with "€45", the search robot, reading 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, we recommend checking the page using Google Rich Results Test. This tool will show exactly how Google interprets your microdata in real time.
The format for 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 this 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
When converting currency 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 as the buyer: the price in euros, correct micro-markup, correct snippet. Localization is complete — for the user and for the search engine simultaneously.
Within this approach, the exchange rate is taken from a reliable source (for example, ECB or another API) and applied on the proxy server side when the page is delivered. The cache is updated on a schedule. The user never sees a "flicker" during loading.
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 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 setup is required.
The difference with the JS approach is fundamental: with JS, you pretend that the site is localized, with server-side conversion, the site 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 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 prices in the desired currency and correct microdata are present there.
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 in a more complex way 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 robot may not get the correct content during the initial crawl.
How to check that the search engine sees the correct currency?
Via Google Search Console: “URL Inspection” → “View Indexed 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.
