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.