Set up hreflang for multilingual & country WooCommerce sites

Implement hreflang so search engines can choose the right language or country page for shoppers. This guide explains the three supported methods, what to check on your live pages, and a short fictional example you can copy and test.

Editorial illustration of two off-white browser cards—one showing language tabs and a product image, the other a sitemap-style stack of URL cards—on a pale mint background with teal and navy accents.

If you sell the same product in more than one language or country, add hreflang annotations and verify them before expecting search engines to pick the correct variant for a shopper. A common approach is to have your multilingual plugin or sitemap tool emit hreflang alternates, but verify the vendor documentation and inspect the public HTML, sitemap, or response headers for each product page — tools vary and you must confirm they emit complete, bidirectional alternates.

Article contents and quick links

How hreflang works

Hreflang is a selection signal that helps Google and other search engines serve the language- or country-specific URL that best matches the user. Google documents three supported places to declare alternates: link elements in the <head>, xhtml:link entries in an XML sitemap, or HTTP Link response headers for resources that must use headers. Each set of alternates must include the page itself and all other variants; you can also include an x-default fallback where appropriate. See Google’s hreflang documentation for the authoritative rules and examples.

Choose a method for your shop

Pick the method you can maintain reliably across every language and product URL. Practical choices for a WooCommerce store:

  • Let your multilingual plugin or your theme add <link rel="alternate" hreflang=...> in the <head>. Many plugins do this automatically; check vendor docs and your generated HTML.
  • Use sitemap alternates if you prefer to declare alternates centrally in XML. The sitemap method works well if your sitemap generator supports xhtml:link children on each <loc> entry.
  • Use HTTP Link headers only for non-HTML resources or where your hosting stack requires headers instead of HTML edits.

For a WordPress/WooCommerce site you should confirm whether your plugin emits hreflang or whether a sitemap tool does. WordPress’ plugin handbook explains where translations live and why a plugin commonly manages translated content; WooCommerce’s localization documentation covers setting languages and translation files but does not document any built‑in hreflang feature, so implement hreflang using a multilingual plugin, sitemap alternates, or HTTP Link headers as appropriate and verify with vendor documentation or public HTML, sitemaps or response headers. See the WordPress and WooCommerce references for context: WordPress localization handbook and WooCommerce localization.

Practical verification checks

  1. Pick one product page that exists in all languages or countries. Implement hreflang for that one first.
  2. Open each variant’s public URL in a browser and view the page source (or use “Inspect”). Confirm the <head> contains a complete set of rel="alternate" hreflang="..." href="https://..." lines that: (a) include that page’s self-reference, (b) list every other variant, and (c) include hreflang="x-default" if you want a fallback. Google documents the required format and fully qualified URL rule: Google’s hreflang documentation.
  3. If you use sitemap alternates, fetch the sitemap XML and locate the product’s <loc> entry. Check that it contains xhtml:link child elements listing the same complete set of alternates. (Sitemaps are authoritative for the sitemap method.)
  4. If you rely on HTTP Link headers, fetch the response headers (for example with curl -I https://example.com/page) and confirm the Link: header lists the alternates in the documented format.
  5. Confirm bidirectional consistency: for every pair A and B, A must list B and B must list A. Implement and verify one product before rolling site-wide.
  6. Record the exact head/sitemap/header snippet you find for later troubleshooting; if something is missing, consult the plugin/vendor docs for how they emit hreflang (do not assume a particular plugin’s behaviour without checking its docs).

Canonical and conflicting signals

Rel=”canonical” is a separate signal from hreflang. Make sure canonical links don’t contradict hreflang (for example, a page canonicalising to a different-language URL can create confusion). Google explains canonicalisation behaviour and why the signals are distinct; check your canonical usage if you see unexpected results: Google’s canonicalisation guidance.

CDN, proxy and cache considerations

If your site sits behind a CDN, reverse proxy or HTML cache, verify the final public response after that layer. Some CDNs can strip or rewrite Link headers or serve cached HTML that lacks recent head changes. Fetch the page from the public URL (not from origin only) and confirm the alternates appear in the delivered HTML or response headers.

Rollout checklist — quick steps

  • Implement on one product (or a small set) first.
  • Verify head/sitemap/headers on the public URLs and confirm bidirectional alternates.
  • Check canonical links on each variant for consistency.
  • Test again after your CDN/cache layer; purge caches if needed and re-check.
  • When all checks pass, roll out to other products and monitor Search Console / indexing reports for any indexing issues.

Worked example: verify alternates for one product

Imagine a jacket that has three localized pages: /en/jacket, /fr/veste and /de/jacke. On each page the <head> contains identical rel-alternate lines:

<link rel="alternate" hreflang="en" href="https://example.com/en/jacket">
<link rel="alternate" hreflang="fr" href="https://example.com/fr/veste">
<link rel="alternate" hreflang="de" href="https://example.com/de/jacke">
<link rel="alternate" hreflang="x-default" href="https://example.com/en/jacket">

To verify, view the source of https://example.com/fr/veste and confirm it lists all three alternates and its own self-reference. Repeat for the other two URLs. This is a safe, local test you can run on any public multilingual product page; treat it as a validation step rather than a guarantee of immediate ranking change.

Next action: pick one product URL that exists in every language, run the head/sitemap/header checks above, record the alternates you find and fix any missing self-references or mismatches before rolling site-wide.