Google is showing your Shopify prices in the wrong currency

Short answer. Google reads the currency off your landing page, and on a Shopify store with local currencies that page serves a different currency per market. The same product URL can return one currency to you and another to a crawler that resolves somewhere else. Google documents two separate Merchant Center issues here, one word apart, and they need opposite fixes.

A merchant sees it in one of two places. Either a product in Google's results carries a price in a currency the store does not sell in, or Merchant Center sends a warning about currency and the products stop showing. In both cases the merchant opens their own storefront, sees the correct currency, and concludes that Google is wrong.

Google is not usually wrong. It is usually looking at a different version of the same page, and the reason is structural rather than accidental.

Two Google issues, one word apart

Before anything else, read the issue name in full, because Merchant Center documents two different problems whose names differ by a few words and whose fixes point in opposite directions.

The first is Inconsistent currencies. Google describes the cause as "One or more of your products are using different currencies across applicable attributes within your product data", and its own example is a price submitted in one currency with shipping rates in another. This one is entirely internal to the feed: nothing outside your product data is involved. Google is explicit about the stakes, saying that failing to fix it "will cause your products to get disapproved", and its instruction is to "Ensure the same currency is being used across each product attribute that requires a currency for this product".

The second is Inconsistent currency between your product data and your website. Here Google is comparing two systems rather than one: the cause is that "the currency you provided in your product data doesn't match the landing pages", and the fix it offers is a choice between "update the currency in the price" attribute or "update the landing pages to match the currency in your product data".

That second sentence is the one worth sitting with. Google is offering to let you change your storefront to agree with your feed, which tells you how seriously it treats the landing page as evidence. It also tells you that no amount of work inside the feed can close this one on its own.

The distinction matters because the two are easy to conflate, and the one thread I read end to end opens on exactly that ambiguity. A merchant opening a Shopify Community thread on 25 December 2023 wrote only that "I have recently received warning for one of the countries from GMC for inconsistent currency", which is ambiguous between the two. The same merchant later identified the landing-page version and said so, in a reply dated November 2024: "Inconsitent currency issue comes when your feed and online url currency is mismatched."

What Google requires of the currency on the page

Google's requirements are not subtle, and they are worth quoting rather than summarising, because the whole failure mode lives in the gap between them and how a Shopify store actually behaves.

The price attribute specification asks you to "Submit an amount and currency that match the price on your landing page and the checkout pages", and to "Show the price in the currency of your target country prominently on your landing page and checkout pages". The currency itself has to be "represented in the currency of your target country according to ISO 4217". And it closes the obvious escape route: "If you use currency conversion, the prices on your landing page, checkout pages, and in your product data must still match."

The currency and language requirements page says the same thing from the other direction, asking you to "Show the product price on your landing page and checkout pages in the currency you submitted in the product data" and, in the localised case, to "Show all cost information in the target country currency on your landing pages and website".

Read as a single instruction, Google is asking for something that sounds trivial: the page and the feed should say the same currency. The trouble is that "the page" is not one thing on a Shopify store that sells internationally.

Why a crawler resolves into a different market than you do

Shopify's local currencies feature exists so that "your customers can view prices in your store, pay for their orders at checkout, and receive refunds in their local currency", and "By default, prices are converted automatically using the current market exchange rate." That is a good feature and a correct one. It also means the price a visitor sees is a function of which market the visitor lands in.

Google, meanwhile, publishes where its crawler comes from. The page on locale-adaptive pages states that "the default IP addresses of the Googlebot crawler appear to be based in the USA" and that "the crawler sends HTTP requests without setting Accept-Language in the request header". It adds that "Googlebot crawls with IP addresses based outside the USA, in addition to the US-based IP addresses", which makes the behaviour variable rather than fixed. And it states the consequence plainly for any site that changes its content by locale: "Google might not crawl, index, or rank all your content for different locales."

Put those two facts beside each other and the failure mode writes itself. A store in Canada, Denmark or Australia with local currencies enabled submits a feed in its home currency. The URL in that feed is a single address. A crawler requesting that address from a US location resolves into the store's US market and is served US dollars, in the visible price and in the markup alike. Merchant Center then compares a feed that says one currency against a landing page that said another, and raises exactly the issue it documents. The same crawl-side asymmetry is what makes a landing page Google cannot reach the way you can so hard to reproduce from the admin.

The merchant checking this by hand sees nothing, and that is not carelessness. They are in their home country, so their browser resolves into the home market every time. The one view of the store guaranteed to look correct is the one the person responsible for fixing it is using. Shopify's own answer to this on the storefront side is social rather than technical: its currencies documentation notes that "you need to have a country selector so that customers can select their local country or region and your store displays their local currency", which helps shoppers and does nothing for a crawler, since a crawler does not use selectors.

What ten live Shopify product pages actually served

The standard advice for this symptom is to edit priceCurrency in the theme so the structured data stops reporting the wrong currency. We went looking for the defect that advice is aimed at, and did not find it.

On 21 October 2026 we took twenty candidate storefronts, kept the thirteen that answered with a Shopify powered-by response header, and fetched one product page from each store's own public catalogue using a Googlebot user agent from a US address. Two of the thirteen served no public catalogue endpoint at all, and both also reported Oxygen and Hydrogen in the same header, which is Shopify's headless stack rather than a conventional storefront. On one more, the product URL built from the store's own catalogue answered 404. That leaves ten pages fetched, and all ten returned HTTP 200.

Nine of the ten carried Product or ProductGroup structured data. On every one of those nine, three independent declarations of the currency agreed with each other: the priceCurrency inside the JSON-LD, the og:price:currency meta tag, and the presentment currency the theme exposes to its own scripts. Not one store in the sample carried the markup defect. The tenth page redirected to a US subdomain of the same brand and carried no product structured data whatsoever, which is a different problem and a worse one.

The currencies served to that single US address were six US dollars, two Australian dollars, one Canadian dollar and one Danish krone, and the currency tracked the market the store had resolved us into every time.

Then we asked the question that matters. Taking the same product URLs and varying only the market, three of the nine stores served a different priceCurrency in their structured data from the same address: Canadian dollars became US dollars, Danish kroner became US dollars, and on one store that had served us US dollars, those became Canadian dollars. All six of those requests returned HTTP 200. The remaining six served one currency regardless.

Two caveats, because they change what this does and does not prove. The market was varied with a country parameter we supplied, not by moving the request to another country, so this shows that the URL can serve more than one currency, not which one Googlebot specifically received. And ten large storefronts are not a prevalence measurement; they are a demonstration that the behaviour is live on ordinary stores.

What the nine-of-nine agreement does establish is sharper than a rate. On these stores the page is internally consistent, so a currency complaint about them is not a markup bug and editing the theme's priceCurrency would not have improved anything. What varies is not the quality of the markup but the market the request lands in, and the markup faithfully follows it. The received fix is aimed at a defect that was not present on a single page we looked at.

Where the currency on a Shopify page comes from

Shopify documents the split that produces this, though not in one place and not with Google in mind.

The shop object exposes shop.currency, which it defines only as "The currency of the store". The cart object exposes cart.currency, and here the documentation is specific: "If the store uses multi-currency, then this is the same as the customer's local (presentment) currency." So Shopify names two currencies, and only tells you which one moves with the shopper.

What it does not tell you is which of them lands in your structured data. The reference for the structured_data filter, the documented way to emit a product's schema from a theme, states no rule about currency at all. Its sample output simply shows "priceCurrency":"CAD" next to a price, with no explanation of where that value came from. A theme author reading only that page has nothing telling them that the choice between the store's currency and the shopper's currency is a choice at all, let alone one that Merchant Center will audit.

In practice, on the stores we measured, the markup followed the shopper. That is the right behaviour: it keeps the page honest, because the structured data describes the offer the visitor is actually being shown. It is also what makes the URL ambiguous from the feed's point of view, and those are two descriptions of the same fact rather than a trade-off you can escape by picking a side.

The same ambiguity shows up elsewhere in this cluster. A page can be internally consistent and still disagree with the feed about the price itself or about whether the product is in stock, and the markup can be correct today and stale tomorrow because a sale window expired. Currency is the version of this where the page is not wrong at all, which is why it survives so much checking.

Fixing each cause

If the issue is attribute-level. This is the Inconsistent currencies case, and it is the straightforward one. Every attribute in the feed that carries a currency has to use the same one, and shipping is the attribute Google's own example singles out, which is worth knowing because shipping rates are often configured somewhere other than the price. Fix it in the feed; nothing on the storefront is involved.

If the issue is page-level and your markets have their own URLs. Submit the market URL rather than the address that resolves by location. A URL that pins the market serves one currency to everyone who requests it, which is what the feed is implicitly promising. This is the fix the merchant in the thread above reported in May 2024: "I solved it using feed rule in Google merchant center product feed where I replace my store URL with Shopify markets subfolder URL and the issue is solved." Treat that as one merchant's reported outcome rather than a documented guarantee, but note that it is the only fix in this article that addresses the actual mechanism instead of a symptom of it.

If the issue is page-level and your markets share one URL. Then the URL genuinely cannot identify a currency, and you have a decision rather than a repair. Either give the market its own URL so the feed can point at it, or narrow the feed to the market the shared URL resolves into for Google and accept that you are not submitting the others. What you should not do is hard-code a currency into the theme's markup to satisfy the feed, because that makes the structured data disagree with the price every shopper outside that one market is shown, which is a worse failure and one Google's price specification addresses directly when it asks that the landing page, the checkout and the product data all match.

If the structured data is genuinely wrong. It does happen, and it is worth ruling in rather than assuming. The currency has to be a "three-letter ISO 4217 format" code per Google's merchant listing documentation, which also makes priceCurrency required whenever a price is specified. A currency symbol, a currency name, or a blank where a code should be will all fail, and so will a page whose feed URL redirects somewhere else entirely, or markup that does not parse at all. If you have more than one kind of warning on these pages, the field-level warnings guide sorts the blocking ones from the noise, and which report the warning appears in tells you which of Google's two bars you are being measured against.

How to check your own store

Five minutes, no app, and the order matters because the first step decides which of the remaining ones apply.

1. Read the issue name in full in Merchant Center rather than the summary line in the email. Inconsistent currencies sends you to the feed. Inconsistent currency between your product data and your website sends you to the storefront.
2. Fetch the exact URL your feed submits from outside your home market, or with a country parameter for another market you sell to, and read the currency in the HTML that comes back. Do not use the browser you normally use, because that is the one view guaranteed to look right.
3. Compare the three declarations on that page: the priceCurrency in the product JSON-LD, the og:price:currency meta tag, and the price the shopper is shown. If all three agree, your markup is fine and a theme edit will not help you.
4. Request the same URL for a second market and compare the structured data again. If the currency changes, the URL does not identify a currency on its own, and that is the whole problem stated in one observation.
5. Check the feed's currency attributes against each other, separately from any of the above, so that an attribute-level mismatch is not hiding behind a page-level one.

Run it once and you will know which of the two issues you have. The harder question is the next one, because nothing here stays fixed on its own. Adding a market, enabling local currencies, changing the backup region, installing a currency switcher or a theme update that touches the schema block can each change which currency a given URL serves, and none of them raises a notification or leaves a record in the admin. The price in your admin stays correct throughout, which is precisely why nobody looks. If you want to understand how long the gap between a change and Google noticing it tends to run, the timing article covers the four separate clocks involved, and the full map places this failure among the other ways a Shopify product quietly stops showing.

Is this happening on your store right now?

Shopify admin has no report for this. Your product schema can be invalid, missing a price or stock value, or dropping review stars in the results, and nothing in the admin flags it. The only way to know is to check the markup the way Google parses it.

• 90+ checks, the way Google parses your product markup. Schema validity, price and stock fields, review markup.
• Read-only. No app to install, no admin access, nothing changes on your store.
• The exact fix for each page, in plain English, so you or your developer can act the same day.

Across full-catalog scans of more than 90,000 Shopify product pages, about 1 in 4 stores had at least one critical Google visibility issue.

Scan my store for free

Free scan: issue types, counts and first fixes. Full report on every product page, not a sample: $49 once, no subscription.