Multicurrency Online Store: Why JS Solutions Break SEO

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 sees something different from what the buyer sees.

According to a cross-border shopping study, 92% of buyers prefer to see prices in their local currency, and one in three buyers abandons their cart if the price is only shown in a 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.

Most currency conversion widgets and scripts work on the same principle: 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.

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, 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 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 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 detailed information on the format of structured data for products, including fields for price and currency, is described in Google's official documentation on structured data for products.

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 micro-markup 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.

When converting currency on the server, the user's browser receives an already prepared page with prices in the desired currency. Everything is calculated in advance; the browser receives ready HTML with correct numbers.

Googlebot sees the same thing the buyer sees: the price in euros, correct microdata, 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 (e.g., 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 "flickering" during loading.

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 the site is localized; with server-side conversion, the site is truly localized — for both people and search engines.

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 robot received — check if there are prices in the correct 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.

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.

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.

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.