Multilingual SEO is not a reason to publish every language. Start with a market where delivery, returns, product restrictions and customer support are workable. Choose a small set of useful product, collection and support pages, and have a competent reviewer check the actual buying experience. Do not use a language selector as evidence that a market is ready.
1. Make a market acceptance sheet
For each proposed market, record language, destination countries, currency, available catalog, shipping conditions, returns, support owner and source of product facts. Compare the terms people use locally with the product you actually sell. Translate units and explain local compatibility rather than only translating a title. If a required fact or support capability is missing, keep that market out of the launch scope.
Example, not a customer result: a lamp sold in two countries needs verified plug, voltage, shipping and return information for each destination. Two translated descriptions are not enough. The buyer must see the right item and conditions after choosing a variant and again at checkout. Resolve contradictions with the merchant before publication.
2. Choose a URL structure for operational reasons
Shopify supports international domain configurations using domains, subdomains or subfolders. Check the current Shopify international domain documentation against your store's configuration. Subfolders can be a practical starting point for one managed store; separate domains may suit genuinely separate businesses, but require additional ownership and maintenance. A subdomain is not automatically an SEO failure, and moving to a subfolder does not guarantee improvement.
- Shared store and team: compare a subfolder setup against maintaining separate hosts; check language and market suffix requirements in the actual admin.
- Independent regional operation: document domain ownership, local support, analytics, catalog and release responsibilities before choosing separate domains.
- Existing working URLs: retain them unless a concrete benefit justifies migration cost. Inventory links and one-to-one redirects before any change.
Do not force every visitor away from a requested URL based only on IP. Provide understandable market selection and test a direct visit to each localized page. Check DNS, certificates and response time for the deployed route. A market that cannot be reliably reached is not ready regardless of its translated word count.
3. Validate hreflang against real equivalents
Use hreflang to describe language or regional alternatives of the same page, not unrelated homepages. For every candidate cluster, list the actual URL and language/region code. Verify that each page references itself and its true alternatives, and that destinations are reachable. Canonicalization and language alternatives have different roles; do not make every translation canonical to an English homepage.
Illustrative cluster: an English product at https://example.com/products/lamp and its genuinely equivalent French version at https://example.com/fr/products/lamp. Each would identify both alternatives using the appropriate language codes. These example URLs are not instructions to create those paths in your own store. Include x-default only when its destination serves the intended fallback choice.
Inspect the rendered head or sitemap annotations actually emitted by the theme/platform. One owner should manage each implementation; do not add another app's conflicting set. Check a published product, collection and article rather than assuming a homepage test covers all templates. Record missing return links, redirects and mismatched equivalents. Consult Google's localized-page documentation for the exact annotation rules.
4. Review the complete local purchase journey
Give a fluent reviewer the page without explaining the original copy. Ask what the product does, who it fits, what it costs and how delivery and returns work. Their unanswered questions identify content gaps. Check title, description, headings, image text, alt text, policy links, error messages and the checkout handoff. Mark unsupported claims for removal, not creative translation.
Do not assume the same questions or seasonal demand apply in every country. Compare the local customer's task and existing support questions, then adapt the examples and selection criteria. A page for a different market needs a maintained business purpose. Machine translation can assist drafting but is not a release check. Avoid fabricated local testimonials, offices or customer results.
5. Decide whether a separate CMS is worth operating
Keep Shopify's native content workflow when it meets publishing needs. A separate CMS is an option for structured editorial content, review roles or integration needs—not a ranking requirement. Before separating it, assign owners for content publishing, routes, preview access, redirects, caching, analytics and security. Estimate ongoing operations as well as initial build effort.
For a main-domain content route, document which component handles a blog request and which handles product/cart requests. Preserve status codes, canonical URLs, language alternatives and asset access. Do not cache personalized cart or account responses as public content. Test the failure path: if the content origin is unavailable, return an honest error and keep the storefront usable. Verify a rollback in a test environment before changing production routes. Our architecture overview describes the separation; it is not proof that a separate CMS will outperform a native blog.
6. Release and monitor one market at a time
Before launch, save the URL inventory, ownership sheet and representative test evidence. Check normal navigation, language switching, response codes, canonical signals and a labelled test conversion. Remove test data from business totals. Add only eligible canonical pages to the sitemap. Inspect Google status separately after publication; neither hreflang nor a sitemap guarantees indexing.
After deployment, compare equal reporting periods by country and landing page, noting data delay, stock changes and campaigns. Monitor broken local links and template changes. Do not call a low-volume market a failure after one day, or treat crawler visits as customer interest. Use the technical checklist and measurement steps to investigate a concrete issue.
How Shopify creates international URLs and hreflang
On Shopify, international SEO usually starts in Markets. A market groups countries and decides which languages, currency and domain or subfolder its visitors use. When you publish a language and assign it a subfolder or domain, Shopify serves localized URLs such as /fr/ for a language or /en-ca/ for a language in a specific country. Translations can come from Shopify's Translate & Adapt app or a third-party translation app; the URL and the tags depend on which of them owns the storefront languages.
For languages and markets configured this way, Shopify adds hreflang annotations to the storefront itself, so most stores do not need to write them by hand. Confirm this in your own store rather than assuming it: open a product in each published language, view the page source and look for the <link rel="alternate" hreflang="…"> lines. Each localized URL should list itself and its real equivalents. Also check whether your sitemap.xml lists the localized URLs you expect Google to find. Shopify's international domain documentation describes the current options.
- Language only: one market, several languages, subfolders such as
/de/ or /fr/. Simplest to operate when prices and catalogue are the same. - Language and country: separate markets with their own subfolder or domain, such as
/en-gb/ and /en-au/. Use this when price, currency, shipping or catalogue really differ. - Unpublished languages: a language that is not published for a market has no storefront URL there and should not appear in hreflang.
Common Shopify hreflang errors and how to find them
Most Shopify hreflang problems come from two systems describing the same page, or from localized pages that are not true equivalents. Check a product, a collection, a blog article and the homepage in every published language; a homepage test alone does not cover the other templates.
- Duplicate sets of tags. A theme or older app writes its own hreflang lines into
theme.liquid while Shopify also outputs them. Search the page source for hreflang: if the same language code appears twice with different URLs, remove the hand-written set. - A translation app and Shopify both manage languages. Some apps serve translations on their own subdomains or paths. Decide which system owns localized URLs, then make sure only that system emits hreflang and the other paths redirect or are removed.
- Automatic redirects by location. Forcing visitors to a country version based on IP can stop crawlers and travellers from reaching other versions. Google mainly crawls from the United States. Offer a country or language selector instead, and test a direct visit to each localized URL.
- Invalid codes. Language codes follow ISO 639-1 and optional regions ISO 3166-1 alpha-2.
en-UK is not valid; the United Kingdom is en-GB. A region code without a language, such as gb, is also invalid. - Canonical tags pointing to the primary language. Each localized page should normally be canonical to itself. If every translation is canonical to the English URL, Google treats the translations as duplicates and the hreflang set loses its purpose.
- Alternates that redirect or return errors. Every URL in the set should return 200. Alternates pointing to redirected, noindexed or deleted pages are ignored.
- Untranslated pages published as a language. A French URL that still shows English text is a thin duplicate. Translate the page or leave that language unpublished until it is ready.
Search Console's International Targeting report was retired in 2022, so it can no longer be used to check hreflang. Instead, use URL Inspection on a localized URL to see which canonical Google selected, and review the Page indexing report: Alternate page with proper canonical tag is expected for true duplicates, while Duplicate, Google chose different canonical than user on a translated page usually means the versions are not different enough or the tags conflict. A crawler with an hreflang report can check return links and status codes across many URLs at once.
Questions before a multilingual release
Do English-speaking countries always need separate pages? No. Separate regional pages only when the offer or task warrants maintained differences; language alone does not establish a new business need.
Will hreflang prevent every duplicate or indexing issue? No. It describes alternatives, not a quality pass or an indexing request. Verify canonicals and actual content independently.
Should every article have every language version? No. Publish an alternative only when it is useful, reviewed and maintainable. Do not invent an equivalent URL just to complete a language matrix.
Reviewed September 25, 2026. Examples are illustrative; this guide does not claim measured customer growth or guaranteed search visibility.
