Hreflang tags: telling Google which language version to show

Reviewed June 2026, applies to PrestaShop 1.7, 8 and the Hummingbird-based default on 9.x, all of which emit a core hreflang block you should verify rather than assume.

You have done the expensive part: your store speaks German to German shoppers, French to French ones, Polish to Polish ones. The cheap part. Telling Google which version belongs to whom. Is the part most PrestaShop merchants get wrong, and it quietly undoes the translation work. Without correct hreflang signals, Google has to guess, and it guesses badly: it serves your English page to a German searcher, or it decides your five language versions are five near-duplicates fighting over the same keyword and ranks one while burying the rest. Hreflang is the small piece of plumbing that turns "we translated the store" into "the right shopper lands on the right language." This guide is about getting that plumbing right on PrestaShop specifically, what the platform already emits, where it falls short, and how to verify it instead of trusting that it "just works."

This is the hreflang-specific piece of a larger cluster. If you are still earlier in the journey. Deciding which languages to run, how URLs should be structured, or whether to use one store or several. Start with multi-language store setup and come back here once the languages exist.

What hreflang actually tells Google (and what it doesn't)

A hreflang annotation is a single line in the page head:

<link rel="alternate" hreflang="de" href="https://yourstore.com/de/produkt">

It says one thing: "there is a German-language equivalent of this page, and it lives here." Repeat it for every language and you have given Google a map of which URLs are translations of one another. Google uses that map for two jobs. First, language matching. A French-Canadian searcher gets your fr page, not your en page, even if the English one ranks better in raw terms. Second, and the one merchants underrate, cannibalization control: hreflang tells Google these pages are alternates, not competitors, so they don't split each other's ranking signals. That second job is why an SEO problem and a translation problem are really the same problem.

It is worth being honest about the boundary, because it's where false expectations start. Hreflang is a hint, not a directive. Google has said as much repeatedly. It does not force a ranking, it does not replace good translations, and it will not rescue pages that Google considers low quality. It also does nothing for your customers directly; nobody sees a hreflang tag in their browser. It is purely a signal to the crawler. So the "So what?" is narrow but real: correct hreflang stops you from losing rankings you already earned to a duplicate-content misread, and it stops the wrong-language bounce that burns ad and SEO spend alike.

What PrestaShop already does, and where the gaps are

Here is the thing the old "PrestaShop has no hreflang, install a module" advice gets wrong: modern PrestaShop already emits hreflang tags. The default themes (the classic theme on 1.7/8 and the Hummingbird-based default on 9.x) include an hreflang block in the page head that loops over your active languages and prints a rel="alternate" line for each, built from Link::getLanguageLink(). So a stock multilingual install on a single store usually has working hreflang out of the box. Before you buy anything, view the source of a product page and search for "hreflang". You may already have it.

What core does not reliably get right is everything around the edges, and the edges are where international stores actually live:

• x-default is frequently missing. Core's loop emits one tag per language but often omits the hreflang="x-default" entry that tells Google what to show when none of your languages match the searcher (a Dutch shopper on an EN/DE/FR store). Without it, Google picks for you.
• Same-language, multi-market targeting isn't solved for you. A PrestaShop language carries locale and language-code fields, so a regional value isn't impossible, but core won't automatically assemble the complex market-level clusters you need when you sell to both Austria and Germany in German, or the UK and US in English. Distinguishing de-AT from de-DE across those alternates is something you have to set up and verify, not something the stock hreflang loop figures out. Check the actual hreflang values emitted from each language's locale/code rather than assuming they target the market you intended.
• Multistore splits the set. If you run separate stores per country (see PrestaShop Multistore), each store only knows its own languages. Getting store-de.com and store-fr.com to cross-reference each other in one hreflang cluster is exactly the case core does not assemble for you.
• Custom and child themes drop it. Themes that override head.tpl or strip the hook can silently remove the hreflang block. A surprising number of "missing hreflang" cases are a theme that simply doesn't print the partial anymore.

So the real question on PrestaShop is rarely "do I have hreflang?" It's "is the set complete, reciprocal, and pointed at canonical URLs?", and that is a verification task, not a purchase.

Getting your URL structure right first

Hreflang points at URLs, so it can only ever be as clean as your multilingual URL structure underneath it. PrestaShop gives you a choice that you set under Shop Parameters → Traffic & SEO → SEO & URLs (and, for the per-language domain option, the Set shop URL / multistore URL settings). The three realistic shapes, and what each means for hreflang:

One PrestaShop-specific trap lives in the language's configuration (International → Localization → Languages), where two separate fields matter. The URL path prefix is built from the two-letter ISO code, so a language added with a sloppy ISO code produces a sloppy path. The hreflang value, by contrast, comes from the language's locale / language code, so a wrong-language-tag problem and a wrong-URL-prefix problem are fixed in different places. Check the ISO code if your paths look off, and check the locale/language code if your emitted hreflang values look off, and fix them on the language, not by hand-editing the tag. Currencies, tax and the broader EU-selling setup that sits alongside this live in selling across Europe from PrestaShop; this post stays on the hreflang lane.

The four mistakes that silently void your hreflang

Hreflang fails quietly. There is no error in your store, no broken page. Google just ignores the annotation and goes back to guessing. These four account for nearly every real-world failure:

• Missing return tags (non-reciprocal sets). If your EN page lists the DE page as its German alternate, the DE page must list the EN page back. Hreflang is a handshake; a one-way wave is dropped. This is the single most common failure, and it's the one that bites multistore setups, where each store naturally only knows half the handshake.
• Wrong language codes. The value must be a real ISO 639-1 language code, optionally plus an ISO 3166-1 country. en-GB is valid; en-UK is not (the country is GB). cs is Czech, not cz. PrestaShop will happily let you type a bad ISO code into the language config, and it propagates straight into the tag.
• Pointing at non-canonical URLs. If your canonical is https://store.com/de/ but your hreflang points to http://store.com/de (no SSL, trailing-slash mismatch, or a ? parameter), Google sees a different URL and discards the annotation. On PrestaShop this most often comes from mixed http/https config or the friendly-URL canonical not matching what the hreflang loop builds.
• Partial coverage. Hreflang on products but not on categories, CMS pages, or the homepage leaves Google confused about whole sections of the site. It has to be every page type, every language, or the inconsistency itself becomes a signal that something is off.

When core's hreflang isn't enough: the module route

If you have verified your setup and found real gaps, no x-default, a custom theme that dropped the tags, country-level targeting core can't express, or a multistore cluster that needs cross-domain reciprocity, that's the point where an SEO module earns its place. The job is narrow: emit a complete, reciprocal, canonical hreflang set on every page type, including the x-default, without you hand-editing templates.

Our SEO Revolution suite handles hreflang as part of its international SEO layer: it generates the alternate set across products, categories, CMS pages and the homepage from your active PrestaShop languages, adds the x-default entry that core tends to skip, and points every tag at the canonical URL so the http/https and parameter mismatches above don't sneak in. So what does that buy you? You stop auditing head tags by hand on a store that keeps adding pages, and a theme upgrade can't silently strip your hreflang, because the tags come from the module rather than a template you might override. It configures from the back office, no head.tpl surgery, no developer invoice for a one-line tag that has to be right on thousands of URLs. That's the honest boundary too: a module that emits perfect hreflang does not rank your store; it removes the technical reason Google would mis-rank or mis-serve the pages you already translated.

Verify it, don't assume it

Hreflang is uniquely punishing because a half-wrong implementation can be worse than none: a broken reciprocal set can make Google distrust the whole cluster. So verification isn't optional polish, it's the job. Three checks, in order:

• View source first. Open a product page, search the HTML for "hreflang", and count. You should see one rel="alternate" line per active language, plus one x-default. If you see zero, your theme dropped the block. If you see the languages but no x-default, that's your first gap.
• Check reciprocity by hand on one cluster. Take a product, open each language version's source, and confirm every version lists the same full set, including itself. If the DE page doesn't point back to EN, you've found a return-tag failure before Google does.
• Then trust the crawler's view. Google Search Console no longer has the old International Targeting report, so use a crawler that audits hreflang (Screaming Frog, Sitebulb, or Ahrefs/Semrush site audit) to flag missing return tags, invalid codes, and non-canonical targets across the whole site at once. That's the only way to catch the partial-coverage problem, because it's spread across thousands of URLs.

Frequently asked questions

Does PrestaShop emit hreflang on its own, or do I need a module?

Modern PrestaShop already emits it. The default themes (classic on 1.7/8, the Hummingbird-based default on 9.x) include an hreflang block in the page head that loops over your active languages and prints a rel="alternate" line for each, built from Link::getLanguageLink(). So a stock multilingual single-store install usually has working hreflang out of the box, view source and search for "hreflang" before buying anything. You reach for a module when you find real gaps: a missing x-default, a custom theme that dropped the block, country-level targeting, or a multistore cluster that needs cross-domain reciprocity.

What does a complete hreflang set actually look like?

Every language version of a page should list the same full set, including itself, plus an x-default. For an EN/DE/FR product, every one of those three pages should carry an identical block in its <head>:

<link rel="alternate" hreflang="en" href="https://store.com/en/product" />
<link rel="alternate" hreflang="de" href="https://store.com/de/produkt" />
<link rel="alternate" hreflang="fr" href="https://store.com/fr/produit" />
<link rel="alternate" hreflang="x-default" href="https://store.com/en/product" />

The x-default tells Google what to serve when none of your languages match the searcher (a Dutch shopper on an EN/DE/FR store). Point each tag at the canonical URL, same protocol, same trailing-slash, no stray ? parameter, or Google discards the annotation.

What's the most common way hreflang silently fails?

Missing return tags. Hreflang is a handshake: if your EN page lists the DE page as its German alternate, the DE page must list the EN page back. A one-way wave gets dropped. This is the failure that bites multistore setups hardest, because each store naturally only knows half the handshake. Getting store-de.com and store-fr.com to cross-reference each other is exactly the case core does not assemble for you.

My hreflang values are wrong. Where do I fix them, the tag or the language?

The language, never the tag by hand. The URL path prefix comes from the language's two-letter ISO code, while the hreflang value comes from the language's locale / language code (International → Localization → Languages). So a wrong-path problem and a wrong-tag problem are fixed in different fields. Use a real ISO 639-1 code optionally plus an ISO 3166-1 country: en-GB is valid, en-UK is not; cs is Czech, not cz.

How do I verify hreflang across thousands of URLs?

View source on one page first to confirm the tags exist and include x-default, then check reciprocity by hand on one product cluster. After that, trust a crawler. Google Search Console no longer has the old International Targeting report, so use Screaming Frog, Sitebulb, or an Ahrefs/Semrush site audit to flag missing return tags, invalid codes and non-canonical targets site-wide. That's the only practical way to catch partial coverage, since it's spread across the whole catalogue.

Related reading

• Multi-Language Store Setup. Get the translated store and per-language URLs right before you worry about hreflang.
• PrestaShop Multistore, where cross-domain hreflang reciprocity becomes the hard part.
• Currency Selector and Language Flags, the human-facing switcher that hreflang complements but can't replace.

The principle underneath all of it is the same one that runs through the rest of this cluster: a store that sells across borders is a set of small, exact signals, the right currency, the right language flag, the right tax line, and the right hreflang, each cheap on its own, each capable of leaking value when it's slightly wrong. Get the language and currency UX right so visitors stay (currency selector and language flags), price and charge correctly per market (multi-currency and international selling), and let hreflang make sure the search engine sends each shopper to the version you built for them. On PrestaShop that means knowing core already does most of the work, and spending your effort on the x-default, the reciprocity, and the canonical match that decide whether it actually counts.