International E-commerce SEO: Hreflang, Geotargeting, Currency, and Stock

International e-commerce SEO is where technical debt accumulates fastest and costs the most. A misconfigured hreflang attribute on 50,000 product pages doesn't generate an error message — it silently routes German-speaking users to your US store, UK shoppers see USD prices in Google results, and your French catalog competes against itself in search. The damage is invisible until you look at the geo-segmented performance data and realize markets that should be your fastest-growing are plateauing.

This guide is for practitioners managing cross-border e-commerce SEO. It covers hreflang implementation at scale, geotargeting configuration, currency and pricing signals, inventory-aware international architecture, and the real operational complexity that platform documentation consistently underplays.

Architecture Decision: Subdomain, Subdirectory, or ccTLD?

This is the first and most consequential decision in international e-commerce SEO, and it's mostly irreversible once your catalog and links have accumulated. The debate has been running for over a decade; here's the unvarnished practitioner position.

The subdirectory approach wins for most operations: it accumulates all link equity on one domain while communicating locale targeting clearly. ccTLD is only justified when you have budget for separate link-building per market — in-market content teams, not just translated catalogs.

Hreflang: Implementation, Validation, and Scale

The Hreflang Spec and Where Everyone Gets It Wrong

Hreflang is implemented as an HTML link element, an HTTP header, or an XML sitemap attribute. At e-commerce scale (50,000+ product pages × 10+ locales = 500,000+ hreflang annotations), the sitemap implementation is the only operationally viable option. In-page link elements at that scale create massive page weight and render-blocking concerns. HTTP headers require server-level configuration for every URL.

The spec requires bidirectional annotation — if page A declares page B as its German equivalent, page B must declare page A as its English equivalent. This is where most implementations break. Here is a correctly formed cluster in XML sitemap format:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/en-gb/shoes/running/acme-carbon-x3/</loc>
    <xhtml:link rel="alternate" hreflang="en-gb"
      href="https://example.com/en-gb/shoes/running/acme-carbon-x3/"/>
    <xhtml:link rel="alternate" hreflang="en-us"
      href="https://example.com/en-us/shoes/running/acme-carbon-x3/"/>
    <xhtml:link rel="alternate" hreflang="de"
      href="https://example.com/de/schuhe/laufen/acme-carbon-x3/"/>
    <xhtml:link rel="alternate" hreflang="fr"
      href="https://example.com/fr/chaussures/course/acme-carbon-x3/"/>
    <xhtml:link rel="alternate" hreflang="x-default"
      href="https://example.com/shoes/running/acme-carbon-x3/"/>
  </url>
  <url>
    <loc>https://example.com/de/schuhe/laufen/acme-carbon-x3/</loc>
    <xhtml:link rel="alternate" hreflang="en-gb"
      href="https://example.com/en-gb/shoes/running/acme-carbon-x3/"/>
    <xhtml:link rel="alternate" hreflang="en-us"
      href="https://example.com/en-us/shoes/running/acme-carbon-x3/"/>
    <xhtml:link rel="alternate" hreflang="de"
      href="https://example.com/de/schuhe/laufen/acme-carbon-x3/"/>
    <xhtml:link rel="alternate" hreflang="fr"
      href="https://example.com/fr/chaussures/course/acme-carbon-x3/"/>
    <xhtml:link rel="alternate" hreflang="x-default"
      href="https://example.com/shoes/running/acme-carbon-x3/"/>
  </url>
</urlset>

The x-default Attribute

x-default is a fallback for users where no locale-specific version exists — not a catch-all for "all other languages." Point it to your global or English-international URL. Do not set it to en-us if you have a separate en-gb version.

Common Hreflang Failure Modes

In order of audit frequency: (1) missing return links — unidirectional implementation; (2) pointing to redirects — all hreflang values must point to 200-status canonical URLs; (3) invalid language codes — en-EN instead of en, or zh-TW instead of zh-Hant; (4) partial implementation — product pages without hreflang when category pages have it; (5) sitemap-only hreflang that Google hasn't processed — verify via GSC sitemap errors.

Validation at Scale

Manual hreflang validation is impossible above 1,000 URLs. Use Screaming Frog's hreflang validation module (it checks bidirectionality, valid language codes, and 200 status of all referenced URLs) combined with a custom Ahrefs Site Audit export. For sites with 100,000+ internationalized URLs, build a dedicated validation script that parses your sitemap XML, constructs the expected bidirectional graph, and flags any missing or malformed edges. Aleyda Solis's hreflang validation guide remains the definitive reference. See our hreflang audit template for a ready-to-use implementation checklist.

Geotargeting: GSC, CDN, and Server-Side Signals

Google Search Console Geotargeting Settings

For subdirectory implementations, configure geotargeting per-directory in GSC's Legacy tools: International Targeting → Country, one property per locale path (e.g., example.com/de/ → Germany). For subdomains, create separate GSC properties per subdomain and configure geotargeting on each. For ccTLDs, geotargeting is inherent to the TLD — no GSC configuration needed, though create separate properties per ccTLD for performance data segmentation.

CDN and IP-Based Geotargeting

A common mistake: configuring your CDN to redirect users to locale-specific URLs based on IP geolocation without serving the correct locale to Googlebot. Googlebot crawls from US IP addresses by default (and from various other locations for Googlebot rendering). If your CDN redirects US IPs to your en-us version, Googlebot will only ever see your en-us version — all other locale versions become invisible to Google unless you explicitly allow Googlebot to access them.

Correct CDN configuration for international e-commerce: do not redirect Googlebot based on IP — use JavaScript-based locale suggestions that don't affect server-rendered content. Set Vary: Accept-Language if your server serves different content by language header, and Cache-Control: private for any IP-geotargeted responses to prevent CDNs serving cached locale content to wrong users.

Currency, Pricing, and Structured Data

Currency handling is where international e-commerce structured data gets genuinely complex. Google's Product schema supports a single priceCurrency value per Offer. For a product available in multiple markets at different prices, you need separate Offer entities — one per market — within a single Product schema, or per-locale structured data on per-locale pages.

For per-locale pages (the recommended architecture), each locale page should have its own Product schema with the correct currency for that market:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Acme Pro Carbon X3",
  "sku": "ACME-CX3-BLK-42",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/de/schuhe/laufen/acme-carbon-x3/",
    "priceCurrency": "EUR",
    "price": "199.99",
    "availability": "https://schema.org/InStock",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": {
        "@type": "MonetaryAmount",
        "value": "4.99",
        "currency": "EUR"
      },
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "DE"
      },
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "handlingTime": {
          "@type": "QuantitativeValue",
          "minValue": 0,
          "maxValue": 1,
          "unitCode": "DAY"
        },
        "transitTime": {
          "@type": "QuantitativeValue",
          "minValue": 2,
          "maxValue": 5,
          "unitCode": "DAY"
        }
      }
    }
  }
}

Note the shippingDetails field with shippingDestination specifying the country code. This is required for Google Shopping eligibility in the respective market, and it's frequently missing from international implementations. Google can show country-specific shipping information in product results — this structured data is what enables that feature.

International Stock and Availability Signals

International e-commerce introduces a layer of complexity that domestic sites never face: a product may be in stock in one market and out of stock in another. Your structured data availability must reflect per-market stock, not global stock.

Your product data pipeline must feed market-specific availability to locale-specific pages. A /de/ product page must query German warehouse stock — not global stock. I've audited sites where all locale versions showed "InStock" because structured data was generated from a global "any warehouse has stock" query. Generate structured data server-side with market-aware inventory queries: Shopify Markets' Storefront API, Magento per-store inventory scopes, WooCommerce shipping zones combined with stock management.

When a product is available in some markets but not others, use the hasMerchantReturnPolicy and shippingDetails with explicit shippingDestination to restrict offers to specific countries:

"offers": [
  {
    "@type": "Offer",
    "priceCurrency": "EUR",
    "price": "199.99",
    "availability": "https://schema.org/InStock",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": ["DE", "AT", "CH"]
      }
    }
  },
  {
    "@type": "Offer",
    "priceCurrency": "GBP",
    "price": "179.99",
    "availability": "https://schema.org/OutOfStock",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "GB"
      }
    }
  }
]

Platform Specifics

Shopify Markets

Shopify Markets (launched 2022, significantly updated in 2023–24) is the native Shopify solution for international e-commerce. It uses a subdirectory structure by default (example.com/de/) and generates hreflang tags automatically for market-specific pages. The hreflang implementation is bidirectional and generally correct — but validate it, because there are known edge cases with custom domain markets where the sitemap hreflang entries don't match the in-page link elements.

Shopify Markets limitations from an SEO standpoint:

• The automatic URL translation for markets uses Shopify's built-in translation system — machine translation quality for product descriptions is often insufficient for competitive markets. Always layer human translation for high-value category and product pages.
• Market-specific sitemaps are generated at /sitemap.xml?market=[handle] — submit each market sitemap separately to GSC.
• Shopify's automatic canonical tag generation for Markets is generally correct, but verify that non-primary market URLs don't have self-referencing canonicals when they should be canonicalizing to the primary locale.

Magento Multi-Store

Magento's multi-store architecture (Store Views) is the most flexible but also the most complex international implementation. Each store view can have a distinct base URL, which enables both subdirectory and subdomain configurations. Magento does not generate hreflang tags natively — you need a third-party extension or custom implementation.

For hreflang in Magento, the recommended approach is sitemap-based: configure Magento's sitemap to generate a per-store-view sitemap, then build a sitemap index that references all store view sitemaps. Add hreflang annotations programmatically using a custom sitemap observer that reads your store view configuration and constructs the bidirectional annotation graph.

Magento Multi-Store geotargeting configuration also requires manual GSC setup for each store view URL prefix. Don't assume that setting the store view locale in Magento's admin panel is sufficient for Google to understand the geotargeting — GSC configuration is a separate requirement. See our Magento international SEO configuration checklist for the complete setup protocol.

WooCommerce with WPML or Polylang

WooCommerce's native internationalization is limited. Most production international WooCommerce stores use WPML (WooCommerce Multilingual) or Polylang Pro. Both generate hreflang tags — WPML's implementation is generally more reliable for e-commerce because it handles product-level hreflang across variable products and their variants, which Polylang can struggle with at scale.

The most frequently missed WooCommerce international configuration: ensure your currency switcher (WPML's or standalone CURCY) generates separate URLs per currency, not cookie-based or JavaScript switching on a single URL. Cookie-based switching means Google sees only your default currency — regardless of which locale is served. Google's structured data guidelines for international pricing clarify this requirement.

Tooling: Yext, BrightLocal, and International Citation Management

For international retailers with physical locations in multiple markets, local SEO tooling adds another layer to the international SEO stack. Google Business Profile management across markets requires either direct GBP management per location (feasible up to ~50 locations) or a platform like Yext or BrightLocal for larger location counts.

Yext for International Location Data

Yext's Knowledge Graph syndicates location data across 100+ country-specific directories including Germany's Das Örtliche and Gelbe Seiten, and France's PagesJaunes — markets that Whitespark and BrightLocal don't cover natively. Each location record in Yext must be tagged with the correct language and country code, or Yext pushes English-language data to local directories, suppressing local rankings. See our Yext international configuration guide for the language/country tagging protocol.

Structured Data for International LocalBusiness

{
  "@context": "https://schema.org",
  "@type": "Store",
  "name": "Example Store Berlin",
  "url": "https://example.com/de/stores/berlin/",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Kurfürstendamm 123",
    "addressLocality": "Berlin",
    "postalCode": "10711",
    "addressCountry": "DE"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 52.5066,
    "longitude": 13.3140
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "10:00",
      "closes": "20:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "10:00",
      "closes": "18:00"
    }
  ],
  "telephone": "+49-30-12345678",
  "priceRange": "€€",
  "currenciesAccepted": "EUR",
  "paymentAccepted": "Cash, Credit Card, Debit Card"
}

FAQ

Should I translate URL slugs for international pages?

Yes — translated URL slugs are a meaningful ranking signal in their target language markets and improve click-through rates from non-English SERPs. A German user searching for "Laufschuhe" is more likely to click on /de/schuhe/laufen/ than /de/shoes/running/. The operational cost of translated slugs is real (you need a human translation pipeline, not machine translation), but the SEO and UX benefit is worth it for your primary market categories. Product-level slug translation is higher effort and lower return — prioritize category and subcategory URLs first.

Does Google always honor hreflang for country targeting?

No. Google treats hreflang as a strong signal, not a directive. In practice, Google honors correct hreflang implementations reliably for language targeting (serving the French version to French-language users), but country-level targeting (serving the French-language version to users in France versus users in Belgium) is less reliable. Geographic user signals — IP, Search language settings, browser locale — can override hreflang. This is why the ccTLD structure provides stronger geotargeting than subdirectory hreflang for markets where geographic precision is critical.

How do I handle products that are only available in some markets?

Don't create placeholder pages in markets where the product isn't available — this generates thin, non-functional pages with incorrect availability signals. Instead, exclude market-unavailable products from locale-specific sitemaps, and do not create hreflang entries for them in those locales. If a user somehow reaches an unavailable product URL in a market where it doesn't ship, redirect them to the closest category page in their market, not the global product page.

What's the right approach for markets that share a language but have different tax/VAT requirements?

Language-only differentiation (e.g., en-gb vs en-us) with market-specific pricing requires separate page URLs (separate GSC properties, separate sitemaps, separate hreflang clusters). Tax-inclusive pricing (UK, EU) versus tax-exclusive pricing (US) means the displayed price differs — which means the structured data differs — which means the pages must be separate. This is a common reason why sites that started with language-only differentiation later need to add country-level URL separation.

How should I handle international canonical tags when the same product exists across multiple locales?

Self-referencing canonicals on each locale page — not cross-locale canonicals. The en-gb product page should canonical to itself; the de product page should canonical to itself. Cross-locale canonicals (the de page canonicalizing to the en-gb page) are wrong — they signal to Google that the German page is a duplicate of the English page, which defeats the purpose of internationalization. Let hreflang do the inter-locale relationship work; canonicals handle only within-locale duplication.

Can I use a single XML sitemap for all locales?

Technically yes — a single sitemap index can reference sitemaps for all locales. But operationally, separate sitemaps per locale are much easier to manage, submit to GSC, and debug. Google allows up to 50,000 URLs per sitemap and 50MB uncompressed — at e-commerce scale with multiple locales, you'll exceed these limits with a single sitemap. Use a sitemap index file that references separate sitemaps per locale.

How does Bing handle hreflang versus Google?

Bing supports hreflang but its implementation and compliance differ from Google's. Bing also supports the XML sitemap hreflang syntax and generally follows the same bidirectionality requirement. However, Bing's Webmaster Tools doesn't have the same geotargeting configuration options as GSC. For Bing, ccTLD architecture provides the most reliable geotargeting signal. Bing also places more weight on the HTML lang attribute on the page root element — ensure your <html lang="de"> attribute is set correctly on locale-specific pages.

Key Takeaways

• Subdirectory architecture wins for most international e-commerce operations — it consolidates domain authority while enabling locale-specific geotargeting through GSC settings and hreflang.
• Hreflang must be bidirectional, implemented for every page in a locale cluster, point only to 200-status canonical URLs, and use valid BCP 47 language codes. Validate this programmatically — manual validation doesn't scale.
• Never use IP-based redirects that hide locale versions from Googlebot. Use JavaScript locale suggestions or language selectors that don't affect server-rendered content.
• Product schema availability and pricing must be market-specific — a product's German page must query German warehouse stock and display EUR pricing, not global stock with USD pricing.
• Translated URL slugs are worth the operational cost for primary category URLs in high-value markets. Machine translation of product slugs is insufficient — use human translation for URLs that will carry search traffic.
• Shopify Markets generates adequate hreflang automatically; Magento requires custom implementation; WooCommerce requires WPML or Polylang with careful currency switcher configuration.
• For international retailers with physical locations, Yext provides the broadest international directory coverage — configure with explicit language and country codes per location record.

Conclusion

International e-commerce SEO rewards the practitioners who understand that it's not a single problem but an orchestration of interdependent systems: URL architecture, hreflang signal graphs, geotargeting configuration, market-specific structured data, inventory-aware availability signaling, and international citation management. The teams that treat these as separate initiatives — "we did hreflang last year, we'll do structured data this year" — leave systematic ranking losses on the table in every market they've not yet fully configured. The teams that build market-aware technical infrastructure once and maintain it as a system consistently outperform competitors in every local market they enter.