Hreflang on a multi-language Webflow site: what it is, and what StoreLingo does not do

When a site has the same product in English and in German, search engines need a way to tell the two pages apart and to know which one to show to which reader. Hreflang is the standard way to describe that relationship.

What hreflang is

Hreflang is an annotation that says: "this page also exists in German at this address, in Dutch at that address, and the English original is here." Each language version lists every other version, including itself. An optional default entry names the page to use when none of the listed languages matches the reader.

The annotation can be delivered in more than one place: in the head of each page, in the site's sitemap, or in the HTTP response headers. Which of these is open to you depends on your platform and tools.

Why it matters on a multi-language site

Without it, a search engine has to work out on its own which pages are language versions of each other. Hreflang gives it that information directly; its purpose is to help the right language version reach the right reader. It does not translate anything, does not improve a translation, and is not a ranking boost in itself.

How StoreLingo's translated pages are laid out

When you publish a language, StoreLingo creates one translated copy of each product (and of each CMS item in the collections you chose) in your Webflow site. Each copy has its own page under Webflow's normal template for that collection. The copy's slug is the language prefix followed by the source name, for example de-blue-mug next to the English blue-mug. The slug is not translated.

Each copy also carries a plain text field named Locale, set to its language code (de, fr and so on). Your own source products and CMS items are not tagged, so in the source language they are the items where Locale is not set. You can use that field to build per-language listing pages in Webflow.

Your options, in words

Because StoreLingo leaves this part to you, these are the broad choices a site owner has. StoreLingo does not set up any of them for you.

• Publish without hreflang. Each language page is still an ordinary page of your site; what you give up is the explicit statement of which pages belong together.
• Use what your platform provides. Check Webflow's own documentation for what it generates for the pages and features you use. Webflow's Localization feature manages language versions for the pages it localizes. It is a separate product from StoreLingo, and according to Webflow's Help Center (the "Webflow Localize overview" article, checked 30 October 2026) it does not localize Ecommerce products, categories or Ecommerce pages on sites that use Ecommerce.
• Ask a developer or SEO specialist. Adding annotations to pages or to a sitemap is site customisation. If you want it, have someone who knows your site plan it, so it matches how your language pages are actually organised.

Things to check whichever you choose

• Each language version should have its own stable address. With StoreLingo, that is the translated copy's own page.
• If a translated page declares the English page as its canonical address, search engines are told the English page is the one that counts. Check your page settings so each language page points at itself.
• Translated pages need to be published and linked from somewhere visitors can reach, for example a per-language listing page whose Collection List is filtered by the Locale field.
• Language codes have a standard form: de, nl, or a regional code such as en-GB.

More on how StoreLingo publishes: SEO and hreflang in the docs. Questions go to hello@storelingo.com; we reply within one business day (Monday to Friday, CET).