Google is serving the wrong country version of your Shopify product, and no Search Console report covers it

Short answer. Google picks which market's URL to show, using the hreflang set Shopify generates for you. If a market has no URL of its own, if an alternate points at a product that market does not sell, or if automatic redirection sends the crawler elsewhere, Google will show the wrong version or none. Search Console retired the report that used to flag this, so nothing in either admin tells you.

A shopper in Toronto searches for your product and lands on the British page, in pounds, with shipping you do not offer there. Or your German market has been live for three months and has never appeared in Google at all, while the English original ranks for everything. Inside Shopify admin every market is published, every translation is saved, and nothing is marked as a fault.

That gap is the whole problem. Which country and language version Google shows is decided by a set of tags Shopify writes into your theme for you, from settings in two different admin screens, and the one Search Console report that used to tell you when that set was broken no longer exists.

What Google is choosing between, and why nothing warned you

When you sell the same product in several markets, you have several URLs for one product. The tags that tell Google those URLs are versions of each other rather than duplicates are hreflang annotations, and on Shopify you do not write them. Shopify's developer documentation is direct about where they come from: "Shopify adds hreflang tags to your theme automatically through the content_for_header object", "which your theme renders in the <head> of layout/theme.liquid."

Google's side of the contract has three parts, and all three are stated in one page on localized versions. Every version has to include itself: "Each language version must list itself as well as all other language versions." Every pair has to be confirmed from both ends: "If page X links to page Y, page Y must link back to page X." And the penalty for failing that is not a warning, it is silence: "If two pages don't both point to each other, the tags will be ignored." There is also a fallback entry for everyone you have not named, where "The reserved x-default value is used when no other language/region matches the user's browser setting."

So the mechanism is a mutual declaration between pages, built by your platform, and judged by Google without a report. That last part is the recent change, and it is why this failure has become hard to see. Google's help centre states it without ceremony: "The International Targeting report has been deprecated." That report was where hreflang usage and hreflang errors were listed. Google is careful to add that the tags themselves did not go anywhere, "Google will continue to support and use hreflang tags on your pages.", while the site-wide country target that lived beside it "was determined to have little value for the ecosystem, and is no longer supported."

Read those two documents together and you get the shape of this incident. The signal still counts. The instrument that measured it is gone. Nothing in Shopify admin replaces it, because Shopify's role ends at generating the tags, and nothing in Search Console replaces it either, beyond inspecting one URL at a time. That is a different situation from the statuses in the Page indexing report, where the report at least names the problem once it fires.

Confirm it yourself in five minutes

You do not need a crawler for the first pass. Open the product page that is showing the wrong version, view source, and search the head for rel="alternate". What you get back is the list Google is choosing between, and five things in it are worth reading in order.

• Does one entry point at the page you are on? That is the self-reference Google requires. A set that lists every market except the page serving it fails the first rule above.
• Open three of the alternates. You are looking for anything that is not a working product page: a 404, a redirect to a home page or a collection, or a store password screen. Of the five checks here, this is the one our own probe below returned the most faults from.
• On one alternate that does load, look for the link back. View source there and search for your original URL in its own alternate list. If it is absent, the pair is unconfirmed, which is the case Google says it ignores.
• Run a site: query per market URL. Search site:example.com/en-ca/, or the market's own domain. A market with its own URL pattern and nothing indexed under it is a different diagnosis from one that is indexed and outranked, and the first case often turns out to be discovered and never fetched.
• Read the canonical on the same page. If it points at another language version rather than at the page itself, two signals on one page are now disagreeing about which URL this is.

Then check the two switches in your own admin, because between them they decide everything above. Both sit in Online Store → Preferences: "In the Social sharing and SEO section, turn off Automatic hreflang tags." describes the switch that decides whether the tags exist at all, and the Automatic redirection section on the same screen decides what a visitor, or a crawler, is actually served.

Cause 1: the market has no URL of its own

The market that has never appeared in Google at all, rather than appearing in the wrong place, usually ends up here. It is not a bug: it is documented behaviour that follows from how the market was published.

Shopify's International domains page ties the tags to the URL structure: "Hreflang tags and meta tags are automatically created for every international domain or subfolder that you set up." A market published on a domain, a subdomain or a subfolder therefore gets tags. A market that simply shares your primary domain has no separate address to tag, and the same page states the consequence without softening it: "Because region-specific URLs aren't created, this method won't help you acquire SEO traffic from secondary markets."

Shopify's page on automatic storefront redirection puts the same fact in harder terms: "For markets that use shared domains, content isn't indexed by search engines." That is a vendor stating that a live, selling, correctly configured part of your store is not in the index. Shopify announced the behaviour change behind it in its own changelog on 23 August 2023, when automatic redirection was extended to markets using the primary domain.

There is a related trap for markets that do have their own URL but nothing else of their own. Google's condition for treating localized URLs as duplicates is about the words on the page, not the price on it: "Localized versions of a page are only considered duplicates if the main content of the page remains untranslated." A market that changes the currency and the shipping table while leaving the product description in the original language sits inside that sentence.

Cause 2: the alternate is built from the handle, not the catalogue

Our probe returned more faults here than anywhere else in the set, so it is worth setting out how it was measured before saying what it means.

On 28 October 2026 we took 26 candidate storefronts and kept the 22 that answered, identified themselves as Shopify-served in the response header, and exposed a readable public catalogue; the other four dropped out at one of those three steps. On each of the 22 we found one product through the store's own catalogue endpoint, skipping handles that read as test or duplicate products, and fetched that product page with a Googlebot user agent. Thirteen of the 22 carried an hreflang set on the product page we fetched, and nine carried none at all. The sets ranged from 2 entries to 192.

Then we tested the alternates themselves, up to eight per store, sampled across each set: 75 declared alternates, of which 60 returned HTTP 200, 8 returned 404, and 7 could not be read at all. The seven unreadable ones are all one host, which answered 403 to two different fetchers, so they are a refusal to serve us rather than evidence of a dead page, and we are not counting them as faults.

The eight 404s came from two stores, and on one of them seven of the eight alternates we tested returned 404. That store's market host is not broken: we requested its home page with a second, independent fetcher and got a working storefront listing its own products at its own prices. The market is live. The product declared as that market's alternate simply does not exist there. The eighth and last alternate we tested on that store returned 200 and resolved to a page headed "Enter store using password", so an entire market was being offered to Google as a localized version of a product while sitting behind a password. Across all eight, not one was a working product page.

The shapes in those sets point the same way. Alongside the plausible combinations were entries pairing a language with a country that has little to do with it: Polish in Austria, Czech in Malta, French in San Marino. Those read as a cross-product of the languages and the countries a store has configured, rather than as a list of pages that exist.

What this does and does not establish. The reading covers 13 stores on one day, is reported as counts and not as a rate, and these are large international brands, which are the stores least likely to be running a careless setup. That makes it good evidence about what the pattern emits by default and weak evidence about how common the defect is across all merchants. The deduction that does survive is narrow: the alternate URL is built from the product handle and the market's URL pattern, independently of whether that product is published to that market. Google's return-link rule then applies without needing any interpretation, because a 404 and a password screen cannot link back to anything, so the pairs that include them cannot be confirmed from both ends.

Two honest limits. We are not claiming Google drops the whole set when some of its members are dead, because Google documents the pairing rule and not that conclusion, and the sentence says what it says. And this is a cause our own scan does not flag. What we read is the tag set itself, plus one same-domain alternate for its return link, which is cause 4 below. A cross-domain alternate that returns 404, a market published on your primary domain, and a redirect setting are all things the five-minute check above will find and we currently will not.

The other readings from the same 13 sets were cleaner than expected. Twelve of the 13 listed the fetched page itself, and on the thirteenth a second fetcher could not reproduce the reading at all, so we do not count it either way. Twelve of the 13 carried an x-default entry. None contained a language code outside the valid pattern, which matters because Google states that "If you use codes that are listed as reserved for something else, Google Search ignores that part of the annotation". And none declared the same code twice pointing at two different URLs. The generated part of the set was well formed. What failed was the assumption that the URLs it names are there.

Cause 3: automatic redirection, and what Shopify says it costs

Automatic redirection is the setting that makes your storefront feel local: "the storefront that matches the location preferences of your customers is automatically displayed", with a separate language toggle where "Language redirection detects a customer's browser language and automatically switches the storefront to match".

A crawler is not a customer, and it has no location preference you set. Google documents that its crawlers and fetchers are "distributed across many datacenters across the world" but that "Google egresses primarily from IP addresses in the United States.", with the possibility that "it may attempt to crawl from IP addresses located in other countries". So what a crawler receives is whatever your redirect rules decide for a request arriving mostly from one country and carrying no preference you set. If every request resolves to one market, that market is the one Google reads, and the others are offered as alternates to a crawler that keeps being sent somewhere else. That gives the symptom in the opening paragraph a second possible route, and the two are worth telling apart: either Google is holding the wrong market's URL for that shopper, or it is holding the right one and your own redirect rules move them off it after the click.

The trade is explicit in Shopify's own documentation rather than something to infer. Shopify's own page for the feature carries its cost for shared-domain markets, quoted in the previous section. Turning redirection on is how you stop a French shopper landing on dollars. Leaving it on, for markets without their own URL, is also how their content stays out of the index. Both halves are Shopify's statements, on the page that sells the feature, which is a more honest piece of documentation than it is usually given credit for.

If you need one sentence to take into a conversation with a developer: redirection decides what a visitor sees, URL structure decides what Google can keep, and only the second one is what a market ranks on.

Cause 4: the tags are present and wrong

When a market has its own URL, its pages are indexed, and Google still shows the wrong one, the fault is usually inside the set rather than around it. Four variants account for most of it, and three of the four are things we flag.

No self-reference. The page lists every market except itself. Google's first rule is that each version lists itself as well as the others, so the set is incomplete at the one point that identifies the page serving it.

The canonical points at another language. Both tags are individually valid here, and they are saying different things. The page declares itself as the German version in its hreflang set, and its canonical names the English URL. You have told Google the page is a localized sibling and that it is a copy of a different page, on the same page. That conflict is also invisible to an ordinary canonical check, because the handle and the /products/ path both look right. For the case where Google picks a URL you did not nominate at all, see user-declared canonical versus Google-selected on Shopify, which is the same family of disagreement without the language dimension.

The same code twice, pointing somewhere different. Two x-default entries, one of them aimed at the home page, is the shape our own scanner check was written around. Google cannot act on a declaration that gives one code two destinations.

Two sets at once, or none. The switch quoted in section two exists precisely because an app or a theme may add its own tags, in the same way that an app can add a noindex you never wrote. Turn automatic tags off while nothing replaces them and the cluster disappears; leave them on while an app adds a second set and the page ships two overlapping declarations. Shopify's own instruction for the first case is unambiguous: "To avoid impacts on your SEO, you need to add your own hreflang tags to your theme."

All four recur without telling you, which is what makes this worth a standing check rather than a one-off fix. Adding a market, removing one, publishing a language, changing a market's domain, installing a translation app, or changing theme all rewrite this set, and none of those actions reports on what it did to it.

The fix, in order

Work from the structure outwards, because a repair to the tags cannot help a market that has no address to tag.

• Give every market you want to rank its own URL. A domain, a subdomain or a subfolder. It is the one step the Shopify sentences quoted in section three tie directly to whether a market can be indexed, which is why it comes before any repair to the tags.
• Translate the main content, not just the money. Google's duplicate condition is about untranslated main content, so a market that differs only in currency and shipping has not yet been differentiated in the terms Google uses.
• Prune the alternates that do not exist. Where a product is not sold in a market, the set should not offer that market's URL for it. Check the dead ones with the three-request test in section two before assuming the generated list is accurate.
• Make the canonical point at the page itself on every localized URL, so it agrees with the self-reference instead of contradicting it.
• Decide who owns the tags, then let only them write. Either Shopify's automatic tags are on and no app duplicates them, or they are off and your theme carries a complete set. The failure is in having one and a half.
• Re-check after any market, language, domain or theme change, because that is when this set is rewritten and nothing announces it. The same discipline applies to the currency Google reads off the page, which is decided by the same market machinery and breaks on the same events.

The pattern underneath this is the one that runs through most of what we write: the product is live, the admin is green, and the failure is only visible from Google's side. For the full map of the ways that happens on a Shopify store, see the 11 silent failures.

Is this happening on your store right now?

Search Console will not page you when this happens. The product page loads fine in a browser, the sitemap looks clean, and Google quietly stops crawling or indexing it anyway. The only way to know is to check the pages the way Google sees them.

• 90+ checks, the way Google crawls and indexes your store. Noindex tags, canonicals, redirects, robots.txt, sitemap coverage.
• 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.