Guides

SEO & Visibility

Multilingual SEO and Approvals for Multilingual Websites: hreflang, Translation and Process

hreflang, structure, local keywords and a clear approval process: how multilingual company websites become visible and stay maintainable.

  • Published:

    November 12, 2026

  • Updated:

    November 12, 2026

  • 9 min read

    Reading time

Overview of the pages of the Leibniz Institute website

Key takeaways

  • hreflang only works reciprocally: every language version points to all others and to itself, using valid language codes.
  • The canonical points to the version in the same language, and visitors are not redirected automatically by IP or browser language.
  • Local search terms per market beat plain translation, and mass translation without added value counts as spam at Google.
  • A written approval process with owners and deadlines prevents half-finished language versions.
  • Animations stay reusable when text and motion are separated.

Short answer: Multilingual websites need a clean language structure with hreflang, a clear translation and approval process, and SEO per market instead of plain translation. Technology and process belong together: without fixed approvals you end up with half-finished language versions, and those cost visibility. Webwavers builds multilingual company websites in Webflow and plans structure, approvals and testing from the start.

This guide covers only the SEO part (hreflang, structure, local keywords) and approval processes. The basic questions, such as whether you need several languages at all and which system fits, are answered in our guide to the multilingual company website. If you are moving an existing multilingual site, the go-live checklist for migration helps.

On the status Statements about Webflow Localize come from the Webflow documentation as of November 12, 2026. Plan limits and features change. Check them directly with Webflow before the project starts.

Basics: structure of multilingual websites

The structure decides how easily the site can be maintained and understood by search engines. In its documentation on multi-regional sites, Google describes the common options with their pros and cons.

OptionSEO effectEffort
Country domain (example.de)Clear geotargeting, one country per domainHigh, sometimes limited availability
Subdomain (de.example.com)Easy to separate, language or country unclear from the nameMedium
Subdirectory (example.com/de/)Simple, low upkeep on one hostLow
URL parameter (?loc=de)Not recommended by GoogleNot sensible

Webflow Localize works with subdirectories such as /en. Slugs, language switcher and default language depend on how you set up the languages. According to the Webflow checklist, the primary language cannot be changed later. Structural changes are made in the primary language and inherited by the other languages. So plan this in advance.

Combining hreflang, canonical and sitemap correctly

hreflang tells Google which page is meant for which language and region. The Google documentation on localized versions sets out the rules.

Setting hreflang correctly

  • Every version points to all others and to itself, and the list is the same on every version.
  • Language code first, optionally with a region, for example de-AT or en-GB. A region code alone is invalid.
  • x-default is the fallback for visitors for whom no version fits.
  • HTML header, HTTP header and sitemap are treated as equivalent. Pick one method, not all three.

Canonical, sitemap and internal linking

According to Google’s guidance on consolidating duplicate URLs, the canonical of each page should point to a version in the same language. hreflang and the sitemap list HTTPS addresses. Link internally within the same language and offer a way into other languages through the switcher. Google also advises against redirecting visitors automatically by IP or assumed language, because versions can become unreachable for people and crawlers.

Local keywords instead of plain translation

A translated title is not yet a search strategy. People search with different terms in each market, and some terms stay English. Research search terms per market and use them in titles, headings and slugs. For the general SEO framework see SEO at Webwavers.

Checklist: multilingual SEO

  • Language structure decided (directory, subdomain or domain) and documented.
  • hreflang reciprocal on all versions, with a self-reference and x-default.
  • Valid language and region codes, no region code alone.
  • Canonical points to the version in the same language.
  • The sitemap contains all published language pages with HTTPS URLs.
  • Slugs, titles and descriptions written independently per language.
  • Language attribute set in the HTML of each page.
  • No automatic redirect by IP or browser language.
  • The language switcher links to the matching page of the other language version.

On the language attribute: the W3C recommends setting the page language with the lang attribute on the html element and giving sections in another language their own value. See W3C on language declarations in HTML.

SEO for multilingual SaaS websites

Software websites bring special cases. Product pages, feature pages, pricing, trials and documentation change often. Every change has to reach all languages, otherwise contradicting information appears.

  • Product pages: decide which languages are complete. A half-translated feature page does more harm than none.
  • Pricing and trials: check currency, tax notes and terms per market.
  • Documentation: often maintained only in the main language. Decide whether it is translated or whether the page labels this clearly.
  • Technical terms: some stay English in all markets. Keep a glossary so terms stay consistent.

On the question of whether an SEO agency has experience with multilingual SaaS websites: ask about process and evidence, not promises. How we approach SEO for SaaS companies is described under SEO for B2B SaaS. We are happy to discuss concrete experience with multilingual SaaS projects in the first call.

Careful with mass translation Google counts automated translation of many pages without value for users among spam practices (scaled content abuse). Machine translation is fine as a draft, but needs professional review and real usefulness. See Google’s spam policies.

Translation and approval across several departments

When marketing, sales, the specialist department and legal are involved, projects rarely fail because of technology, but because of unclear approvals. A fixed process answers three questions: who writes, who reviews, who approves.

Roles, stages and deadlines

StageResponsibleDeadline (suggestion)
Source text finalMarketing or editorialBefore translation starts
Translation or draftService provider, team or AI with reviewDepends on scope, agreed beforehand
Specialist reviewSpecialist department in the target market3 to 5 working days
Legal reviewLegal or data protection3 to 5 working days
Approval and publicationProject owners1 working day

The deadlines are planning suggestions, not industry benchmarks. What matters is that they are fixed in advance and every stage has a name attached.

Who translates: specialist department, provider, AI with review

Technical texts need people who know the subject. AI translation can deliver drafts, but does not replace review. According to the Webflow checklist, Webflow Localize offers several routes, including manual translation, AI translation and connecting a translation management system. One point deserves attention: switching to continuous translation can replace existing translations. If you want to protect your own corrections, use one-time translation.

Approval in the project flow

Approvals belong in the project plan, not at the end. Our project flow is described on the page process. Which approval stages and tools apply in your project we define in the first call. For agencies that offer a clear approval process, a good test is: is it put in writing before the project starts, with names and deadlines?

Checklist: approval process

  • The source text is final before translation begins.
  • For each language there is a responsible person in the target market.
  • Stages, deadlines and deputies are fixed in writing.
  • A glossary with technical terms and spellings exists.
  • Legal texts and banner are checked per language.
  • It is defined how changes to the source text reach all languages.
  • Only approved languages are published.

DACH region and mechanical engineering: language and references

In the DACH region, German is not the same everywhere. Language codes such as de-DE, de-AT and de-CH allow separate versions, but they only pay off if the content really differs. According to Wikipedia on Swiss Standard German, “ss” is always written instead of “ß” in Switzerland, and some words differ in vocabulary. For websites this means: if you address customers in Switzerland, check the spelling.

Technical language in mechanical engineering

In mechanical engineering, standards, product names and data sheets count. Terminology must stay consistent per language. A glossary and a professional review matter more here than for marketing copy. More on the sector under industry and engineering.

Selection criteria instead of rankings

Whether an agency is the best for multilingual websites in the German Mittelstand cannot be said in general. Criteria help more than a ranking:

  • Can the agency show its approval process and quality assurance per language?
  • How does it handle hreflang, canonical and sitemap, and how does it test them?
  • Are there references with several languages that you may look at?
  • Who is responsible for technical terms and translation quality?
  • How does care work after launch when texts change?

References for multilingual projects, for example from mechanical engineering, we show you in the first call as far as they are approved.

UX for multilingual product platforms

A multilingual product platform needs more than translated text. Texts come out at different lengths per language. This matters for navigation, buttons and forms. How we approach UX and UI is described under UX/UI design.

  • Navigation: plan room for longer terms so menus do not wrap.
  • Language choice: clearly visible, with language names in their own language, without automatic redirect.
  • Page content: Google recommends using one language for content and navigation on each page.
  • Forms: check field labels, error messages and required fields per language, including input formats.
  • Tests: click through every language completely once, not only the main language.

Reusing animations for all languages

Animations with text are the most common reason new languages become expensive. If the text is fixed inside the video or graphic, everything has to be produced again.

Separating text from motion

The solution is to separate text and motion. With Lottie animations this makes the difference: if text is converted to shapes, it is baked in according to LottieFiles, and text changes, localization and versions become painful. Real text layers can be changed without rebuilding the animation. Where possible, the text sits on the page as HTML and the animation controls only motion. For interactions that animate existing page elements, the text is in the HTML anyway. Text in videos can be solved with subtitles instead of burned-in lettering. How Lottie and interactions work together with Localize in detail you should test on staging.

Workflow for new languages

  • Produce animations without burned-in text.
  • Maintain texts as separate fields or HTML elements.
  • For each new language, check term length and line breaks.
  • Provide videos with subtitles instead of new voice-over if the content allows.
  • Test every language on staging before it goes live.

More about our animations: motion design. Whether we produce animations language-independent by default we clarify per project in the first call.

Migrating multilingual pages

When moving a multilingual website, all sources of error repeat per language. Redirects, hreflang, language paths and translation states have to be checked individually. The details are in the go-live checklist for migration and in the CMS migration checklist.

Effort and costs

A reliable number only exists once the scope is known. These factors matter:

  • Number of languages and markets.
  • Number of pages and CMS items per language.
  • Translation route: specialist department, provider, AI with review.
  • Scope of approvals and number of people involved.
  • Ongoing care when source texts change.
  • Plan-related platform costs for additional languages.

We give prices only after a conversation about scope and languages. As an orientation for a web design project: web design from €8,000 net, pure development from €5,000 net. The effort for languages comes on top depending on scope.

How we put this into practice at Webwavers

Webwavers is a Webflow Premium Partner and builds websites with Webflow, WordPress, TYPO3 and headless setups. On multilingual projects we plan language structure, hreflang, approvals and testing from the start. More about our work in web development. Which languages, markets and approval stages fit your project we clarify in the first call.

Frequently asked questions

Which SEO agency has experience with multilingual SaaS websites?

Ask about process and evidence: how are hreflang, product pages and pricing handled per language? Are there traceable examples? How we approach SEO for SaaS is described on our service page, and we discuss concrete experience in the first call.

Which agencies have a clear approval process for multilingual websites?

Make sure stages, owners and deadlines are written down before the project starts. We define the approval process together with you in the first call.

Which agencies are good for multilingual websites in the DACH region?

That cannot be answered in general. Check criteria such as approval process, hreflang expertise, references with several languages and care after launch. For de-AT and de-CH it matters whether separate versions make sense.

Which web design agencies have references in mechanical engineering for multilingual websites?

Ask for approved references and look at how the sites handle technical terms and data sheets per language. Our page on the industry and engineering sector shows how we work.

What is the best UX agency for a multilingual product platform?

There is no ranking. What counts is experience with long texts, language choice, forms and tests per language. More in our service UX/UI design.

How can animations be reused for several languages?

By separating text and motion: text as HTML or as real text layers, videos with subtitles. That way the animation stays and only the text changes.

How do I implement hreflang correctly?

Every language version points to all others and to itself, the codes are valid, an x-default is set, and the canonical points to the version in the same language.

What is the best agency for multilingual websites in the Mittelstand?

There is no best agency for everyone. Compare process, references, technology and care. In the first call we explain how we plan multilingual projects.

Conclusion

Multilingual SEO is technology and process at the same time. hreflang and structure have to be right, approvals have to be fixed, and texts need local search terms. Are you planning a multilingual website? In the first call we clarify languages, structure and approval process and plan the implementation. Request a project

Sources

More guides

All guides
Chrome 3D Webwavers WChrome 3D Webwavers W

Contact

Start your next digital chapter

Request a project