Mehrsprachige Unternehmenswebsite: Webflow Localization oder WordPress-Plugin?

Von Edip Kilinc, Gründer von Webwavers. Veröffentlicht am 31.10.2026. Zuletzt aktualisiert am 31.10.2026. Lesezeit: ca. 17 Minuten.

Kurzantwort: Für eine mehrsprachige Unternehmenswebsite brauchst du drei saubere Entscheidungen: eine klare URL-Struktur (meist Unterverzeichnisse wie /en/), einen Übersetzungs-Workflow mit einer Quellsprache und Freigaben sowie korrekte hreflang-Auszeichnung. Webflow Localization, WordPress mit Plugin und TYPO3 können das alle leisten, sie unterscheiden sich vor allem in Kosten, Grenzen und Pflegeaufwand. Welches System passt, hängt von Sprachanzahl, Umfang der Inhalte und deinem Team ab.

Das Wichtigste in Kürze

• Mehr Sprachen bedeuten vor allem mehr Pflege, nicht nur mehr Übersetzung. Plane den laufenden Aufwand von Anfang an ein.
• Subdirectories (/en/, /fr/) sind in den meisten Fällen die pragmatischste URL-Struktur für Unternehmenswebsites.
• hreflang ist kein Selbstläufer. Gegenseitige Verweise, Selbstreferenz und korrekte Codes sind Pflicht, sonst ignoriert Google die Auszeichnung.
• Webflow Localization hat klare Grenzen (Ecommerce, Locale-Zahl je Tarif). Für sehr viele Sprachen musst du genau rechnen.
• Ein guter Workflow schlägt jedes Tool. Lege fest, wer übersetzt, wer prüft und wer freigibt.

Inhaltsverzeichnis

• Vorab: Brauchst du wirklich mehrere Sprachen?
• URL-Struktur: Subdirectory, Subdomain oder Länderdomain
• hreflang richtig umsetzen
• Webflow Localization
• WordPress mit Plugins
• TYPO3
• Die drei Systeme im Vergleich
• Übersetzungs-Workflow: Quellsprache, Review, Freigabe
• Aufwand rechnen: Sprachen mal Seiten mal Pflege
• Beispiel: 14 Sprachen für einen Anlagenkatalog
• Deutsch, Österreich, Schweiz: DACH richtig abbilden
• Typische Fehler
• Branchen: Industrie, Luftfahrt, Energie
• Wann du keine Agentur brauchst
• Wie wir das umsetzen
• FAQ

Vorab: Brauchst du wirklich mehrere Sprachen?

Bevor es um Technik geht, lohnt sich die Frage nach dem Bedarf. Eine zweite Sprache verdoppelt nicht nur die Texte, sondern auch Pflege, Qualitätssicherung und Fehlerquellen. Sie lohnt sich, wenn du aktiv Kunden in anderen Märkten gewinnen willst, wenn Ausschreibungen eine Landessprache verlangen, wenn Fachkräfte oder Partner im Ausland deine Seite nutzen oder wenn Produktinformationen in der Sprache der Kunden zum Verkauf gehören.

Sie lohnt sich nicht automatisch, nur weil es möglich ist. Eine saubere deutsche und englische Version deckt für viele B2B-Unternehmen den Großteil des Bedarfs ab. Mehr Sprachen solltest du dort anlegen, wo es konkrete Nachfrage gibt, und dort, wo du die Inhalte auch pflegen kannst. Eine halbfertige Sprachversion mit veralteten Inhalten schadet mehr, als sie nützt.

URL-Struktur: Subdirectory, Subdomain oder Länderdomain

Die URL-Struktur ist die wichtigste Entscheidung, weil sie sich später nur mit Aufwand ändern lässt. Es gibt drei gängige Modelle.

Modell	Beispiel	Vorteile	Nachteile
Subdirectory	firma.de/en/	Eine Domain, einfache Verwaltung, Autorität bleibt gebündelt	Alle Sprachen auf einer technischen Basis
Subdomain	en.firma.de	Technisch getrennt, eigenes Hosting möglich	Mehr Aufwand, Sprachversionen wirken wie getrennte Seiten
Länderdomain	firma.fr	Starkes Länder-Signal, lokaler Auftritt	Mehrere Domains, mehr Verwaltung, jede Domain baut eigene Autorität auf

Für die meisten Unternehmenswebsites ist das Subdirectory die pragmatische Wahl. Webflow beispielsweise setzt auf Subdirectories wie /en oder /en-us, und die Slugs lassen sich anpassen (Webflow, Localization overview). Länderdomains ergeben Sinn, wenn du pro Land eigenständig auftrittst, mit eigenem Team und eigenen Inhalten. Das ist dann eher ein Mehrmarkenmodell als eine einfache Mehrsprachigkeit.

Unabhängig vom Modell gilt: Übersetze auch die Slugs, wenn du Wert auf lokale Suchergebnisse legst, und halte die Struktur über alle Sprachen identisch, damit sich Seiten eindeutig zuordnen lassen.

hreflang richtig umsetzen

Mit hreflang sagst du Suchmaschinen, welche Seiten Sprach- oder Länderversionen desselben Inhalts sind. Google nutzt das, um Nutzern die passende Version anzuzeigen. Die Sprache einer Seite erkennt Google weiterhin selbst, hreflang ist ein Hinweis, kein Befehl. Die Regeln stehen in der Google-Dokumentation zu lokalisierten Versionen:

• Drei gleichwertige Methoden: HTML-Link-Tags im Head, HTTP-Header (nützlich für PDFs) oder XML-Sitemap. Nutze eine, nicht alle drei, das erspart Pflegeaufwand.
• Selbstreferenz: Jede Version listet sich selbst und alle anderen Versionen.
• Gegenseitigkeit: Verweist Seite X auf Y, muss Y auch auf X verweisen. Sonst können die Angaben ignoriert werden.
• Vollständige URLs: Mit Protokoll, also https://.
• Gültige Codes: Sprachcode nach ISO 639-1, optional gefolgt von einem Ländercode nach ISO 3166-1 Alpha-2, zum Beispiel en-GB. Ländercodes allein sind ungültig, Kürzel wie EU, UN oder UK bewirken nichts.
• Fallback: Mit x-default kennzeichnest du eine Sammel- oder Sprachauswahlseite für Nutzer, deren Sprache nicht abgedeckt ist.
• Duplicate Content: Lokalisierte Seiten gelten nur dann als Duplikate, wenn ihr Hauptinhalt unübersetzt bleibt.

Der letzte Punkt ist praktisch wichtig. Wenn du eine Sprachversion anlegst, aber Teile unübersetzt lässt, entstehen Seiten, die sich inhaltlich gleichen. Das kannst du vermeiden, indem du erst veröffentlichst, wenn eine Seite wirklich übersetzt ist, oder unfertige Seiten gar nicht ausspielst.

Hier ein Beispiel für eine Seite mit deutscher, englischer und französischer Version im Head:

<link rel="alternate" hreflang="de" href="https://www.firma.de/produkte/" /> <link rel="alternate" hreflang="en" href="https://www.firma.de/en/products/" /> <link rel="alternate" hreflang="fr" href="https://www.firma.de/fr/produits/" /> <link rel="alternate" hreflang="x-default" href="https://www.firma.de/produkte/" />

Jede der drei Seiten trägt exakt diesen Block. Prüfe das stichprobenartig im Quelltext oder mit einem Crawler. Die Fehler, die du dort findest, sind fast immer fehlende Rückverweise oder falsche Codes. Eine allgemeine Erklärung findest du im Glossar zu hreflang.

Webflow Localization

Webflow Localization ist die eingebaute Lösung für mehrsprachige Seiten. Du baust, bearbeitest und prüfst lokalisierte Versionen direkt in Webflow. Lokalisierbar sind laut Webflow Inhalte, Styles, Assets, statische Seiten, CMS-Inhalte und SEO-Angaben. Sekundäre Sprachen übernehmen zunächst alles vom primären Locale und lassen sich später überschreiben und zurücksetzen (Webflow, Localization overview).

Was Webflow dabei nach eigenen Angaben liefert: HTML-Lang-Tags und hreflang-Tags auf Seitenebene, hreflang in den automatisch erzeugten Sitemaps, lokalisierte Meta-Titel, Beschreibungen und Open-Graph-Angaben, anpassbare Locale-Slugs, KI-Übersetzung als erste Fassung zum manuellen Nachbessern sowie Auslieferung über Unterverzeichnisse (Webflow Localize). Rechts-nach-links-Sprachen wie Arabisch oder Hebräisch werden automatisch unterstützt.

Was du wissen musst, bevor du dich festlegst:

• Kosten: Localize ist ein Add-on je Site. Nach der Preisseite von Webflow (Stand Oktober 2026) kostet Localize Essential 9 US-Dollar pro Monat für 1 bis 3 Locales und 10.000 Wörter pro Monat, Localize Advanced 29 US-Dollar pro Monat für 1 bis 10 Locales und 50.000 Wörter pro Monat. Für Enterprise gibt es individuelle Preise und eine individuelle Locale-Zahl. Auf der Plattformseite wird der Tarif "Team" mit 2 Locales inklusive aufgeführt (Webflow Pricing).
• Locale-Grenzen: Wer mehr als 10 Sprachen braucht, landet nach diesen Angaben außerhalb von Localize Advanced und muss individuelle Konditionen klären.
• Veröffentlichung: Zum Veröffentlichen einer Sekundärsprache oder mehrerer Sekundärsprachen ist ein Localization-Add-on nötig. Die Vorschau ist in allen Site-Plänen kostenlos.
• Ecommerce: Localization ist nicht mit Webflow Ecommerce kompatibel. Produkte, Kategorien und Seiten lassen sich dort nicht lokalisieren.
• Slug-Kollisionen: Locale-Slugs dürfen nicht mit CMS-Collections, Ordnern oder Seiten kollidieren, sonst entsteht ein 404-Fehler.
• Automatisches Routing: Die Weiterleitung nach Browsersprache gibt es nur in den Enterprise- und Advanced-Plänen.
• Primärsprache: Das primäre Locale hat standardmäßig kein Unterverzeichnis, kann mit einem kostenpflichtigen Localization-Tarif aber auf eines umgeleitet werden.

Für Marketing-Teams ist der Vorteil, dass Redakteure im Edit-Modus Inhalte pro Sprache anpassen können, ohne in den Designer zu müssen. Die Kehrseite: Wer den Vergleich zu WordPress ziehen will, sollte das komplette Bild mit Add-on-Kosten, Wortkontingenten und CMS-Struktur betrachten. Einen Gesamtvergleich der Systeme findest du im Beitrag Webflow vs. WordPress.

WordPress mit Plugins

WordPress bringt keine Mehrsprachigkeit im Kern mit. Sie kommt über Plugins, am häufigsten WPML und Polylang. Das ist flexibel, bedeutet aber, dass du dich auf die Pflege des Plugins und seine Kompatibilität mit Theme und Erweiterungen verlassen musst.

WPML. Nach der Kaufseite von WPML gibt es drei Pläne in Euro pro Jahr: Multilingual Blog für 39 Euro (1 Produktivseite), Multilingual CMS für 99 Euro (3 Produktivseiten, 22.500 AI-Übersetzungswörter) und Multilingual Agency für 199 Euro (unbegrenzt viele Seiten, 45.000 AI-Übersetzungswörter). Der Blog-Plan enthält mehrere Funktionen nicht, darunter den Advanced Translation Editor, AI-Übersetzung, Menüübersetzung und E-Commerce-Unterstützung. Nach Ablauf läuft WPML weiter, Updates gibt es dann aber nicht mehr, was die Seite selbst als langfristiges Risiko beschreibt (WPML, Preise). Das Wortkontingent wird bei jeder Verlängerung aufgefüllt und verfällt nicht.

Polylang. Nach Angaben des Herstellers werden technische SEO-Angaben wie hreflang-Attribute automatisch umgesetzt, Inhalte lassen sich manuell und maschinell übersetzen. Welche Funktionen in der kostenlosen Version und welche in Polylang Pro enthalten sind, nennt die Seite nicht, das musst du auf der Preisseite des Herstellers prüfen (Polylang).

Worauf du bei WordPress achten solltest:

• Prüfe, ob Theme, Page Builder und Plugins zum Mehrsprachigkeits-Plugin kompatibel sind. Jede Erweiterung, die eigene Texte oder Felder speichert, muss übersetzbar sein.
• Prüfe den ausgespielten hreflang-Code im Quelltext, bevor du dich auf die Aussage "wird automatisch erzeugt" verlässt.
• Plane Updates ein. Plugin-Updates können Seiten brechen, daher gehört ein Test in einer Staging-Umgebung dazu.
• Rechne alle Kosten zusammen: Plugin-Lizenz, Übersetzungs-Kontingent, Hosting und Wartung. Eine Übersicht dazu liefert unsere Seite zur WordPress-Agentur.

TYPO3

TYPO3 ist von Haus aus für mehrsprachige Auftritte gebaut und wird deshalb gern bei Konzernen, Verbänden und Behörden eingesetzt. Mehrsprachigkeit ist Teil des Kerns, und Seiten und Inhaltselemente lassen sich pro Sprache übersetzen. Laut der Dokumentation der SEO-Erweiterung werden hreflang-Link-Tags für mehrsprachige Websites automatisch hinzugefügt, und zwar auf Basis des "One-Tree-Prinzips". Die Links hängen von der Site-Konfiguration und den Übersetzungen der jeweiligen Seite ab (TYPO3, SEO-Dokumentation).

Dafür bringt TYPO3 einen höheren Einstiegsaufwand mit: Konfiguration, Rechte- und Rollenmodelle, Extension-Pflege und Updates sind anspruchsvoller als bei einfachen Redaktionssystemen. Wer sehr viele Sprachen, komplexe Redaktionsrechte und eine große Seitenzahl hat, bekommt dafür ein System, das genau dafür gebaut wurde. Für kleine Auftritte mit zwei Sprachen ist es oft mehr, als du brauchst. Zur Migration von TYPO3 auf Webflow gibt es eine eigene Seite zu TYPO3 zu Webflow.

Die drei Systeme im Vergleich

Kriterium	Webflow Localization	WordPress mit Plugin	TYPO3
Mehrsprachigkeit	Eingebaut, als Add-on je Site	Über Plugin (z. B. WPML, Polylang)	Im Kern
URL-Struktur	Subdirectories	Je nach Plugin, meist Subdirectories	Je nach Site-Konfiguration
hreflang	Laut Webflow automatisch, auch in der Sitemap	Laut Hersteller-Angaben Plugin-abhängig, im Quelltext prüfen	Laut Dokumentation automatisch
Kostenmodell	Add-on mit Locale- und Wortkontingenten	Lizenz pro Jahr plus Übersetzungs-Kontingent	Keine Lizenzgebühr, Aufwand in Betrieb und Entwicklung
Grenzen	Nicht mit Ecommerce kompatibel, Locale-Zahl je Tarif	Kompatibilität von Theme und Erweiterungen	Höherer Einstiegs- und Pflegeaufwand
Redaktion	Edit-Modus, Designer	Backend, je nach Plugin	Backend mit Rollenmodell
Passt gut zu	Marketing-Seiten mit überschaubarer Sprachzahl	Bestehende WordPress-Landschaft, Blog-lastige Seiten	Große Auftritte mit vielen Sprachen und Rollen

Das Bild ist nicht schwarz-weiß. Gerade bei mittlerer Komplexität (zwei bis zehn Sprachen, Marketing-Seite mit CMS-Inhalten) sind Webflow und WordPress beide tragfähig. Über Skalierung entscheiden eher Team, Wartung und Budget als die Technik allein. Eine erste Einordnung der Plattformen bietet der Ratgeber Webflow vs. WordPress: SEO und KI-Sichtbarkeit.

Übersetzungs-Workflow: Quellsprache, Review, Freigabe

Das beste System scheitert an einem unklaren Prozess. Lege deshalb früh fest:

1. Quellsprache. Meist Deutsch. Änderungen entstehen dort zuerst und werden von dort in die Zielsprachen getragen. Inhalte, die nur in einer Zielsprache gepflegt werden, brauchen eine klare Regel.
2. Erstübersetzung. Maschinell, durch ein Übersetzungsbüro oder intern. Maschinelle Erstfassungen sparen Zeit, ersetzen aber bei Fachtexten und rechtlichen Texten nicht die Prüfung durch Muttersprachler mit Fachwissen.
3. Fachliche Prüfung. Gerade bei Produktdaten und Datenblättern muss jemand aus der Fachabteilung oder dem Vertrieb vor Ort prüfen. Nennen wir sie Sprachverantwortliche.
4. Freigabe. Wer darf veröffentlichen? Eine klare Rolle verhindert, dass halb übersetzte Seiten live gehen.
5. Änderungsroutine. Wenn sich der deutsche Text ändert, was passiert mit den Übersetzungen? Markieren, nachziehen, freigeben.
6. Glossar und Stil. Fachbegriffe, Markennamen und Tonalität pro Sprache festhalten, damit Übersetzer nicht jedes Mal neu entscheiden.

Gerade wenn mehrere Abteilungen Entwürfe abstimmen, braucht es einen festen Freigabeweg. In unserem Ratgeber Webagentur-Angebot vergleichen findest du Hinweise, wie du Feedbackrunden in Angeboten prüfst.

Aufwand rechnen: Sprachen mal Seiten mal Pflege

Der laufende Aufwand wächst mit drei Faktoren: Anzahl der Sprachen, Anzahl der Seiten und CMS-Einträge sowie Häufigkeit der Änderungen. Eine einfache Überschlagsrechnung hilft, bevor du ein System festlegst.

Seitenversionen = Seiten und CMS-Einträge × Sprachen

Pflegeereignisse pro Jahr = Änderungen pro Jahr im Quelltext × (Sprachen minus 1)

Ein Beispiel: Eine Seite mit 40 Seiten und CMS-Einträgen in 5 Sprachen hat 200 Seitenversionen. Ändern sich jährlich 60 Inhalte in der Quellsprache, entstehen daraus 60 × 4 = 240 Übersetzungsaufgaben. Bei 14 Sprachen und derselben Seitenzahl sind es 560 Seitenversionen und 60 × 13 = 780 Aufgaben. Die Zahlen sind eine Rechenillustration mit angenommenen Werten, keine Marktangaben.

Daran siehst du drei Dinge. Erstens steigt der Aufwand linear mit jeder Sprache. Zweitens kippen Wort-Kontingente schnell, wenn du viele Seiten und viele Sprachen hast, und du solltest sie mit dem Tarif abgleichen (Webflow Localize Advanced enthält nach den obigen Angaben 50.000 Wörter pro Monat). Drittens lohnt es sich, Inhalte zu reduzieren, bevor du sie übersetzt. Weniger, dafür sorgfältig gepflegte Seiten schlagen ein großes Archiv veralteter Übersetzungen.

Beispiel: 14 Sprachen für einen Anlagenkatalog

Stell dir ein Maschinenbauunternehmen vor, das einen Anlagenkatalog in 14 Sprachen pflegt, mit Deutsch als Quelle. Die Anforderungen sind typisch: viele CMS-Einträge, technische Daten, wiederkehrende Textbausteine, mehrere Redakteure und Freigaben durch Länderteams.

Wenn du das auf die Systeme überträgst, zeigt sich:

• Webflow Localization: Mit 14 Sprachen liegst du über den 1 bis 10 Locales von Localize Advanced. Du brauchst eine individuelle Konfiguration über Enterprise. Das CMS lässt sich lokalisieren, die Struktur muss aber sauber durchdacht sein, damit Referenzen und Slugs je Sprache funktionieren. Gibt es einen Online-Shop auf Webflow Ecommerce, ist Localization dort nicht möglich.
• WordPress mit Plugin: Technisch machbar, aber bei 14 Sprachen steigen Komplexität und Abhängigkeit vom Plugin. Prüfe die Performance, die Datenbankstruktur und das Zusammenspiel mit Produktdaten-Plugins.
• TYPO3: Eignet sich für diese Konstellation, weil Mehrsprachigkeit und Redaktionsrollen im Kern angelegt sind. Dafür steigt der Betriebs- und Entwicklungsaufwand.
• Headless-CMS: Wenn Produktdaten aus einem PIM oder ERP kommen, kann ein Headless-Ansatz mit separater Übersetzungsverwaltung passender sein. Das erhöht allerdings den technischen Aufwand.

Eine allgemeingültige Empfehlung gibt es nicht. Entscheidend sind die Datenquelle, die Zahl der Redakteure und das Budget für den Betrieb. Ein neutraler Vergleich im Gespräch ist hier mehr wert als eine Pauschalaussage. Mehr zur Branche findest du auf der Seite Webdesign für Industrie und Engineering.

Deutsch, Österreich, Schweiz: DACH richtig abbilden

Im DACH-Raum stellt sich eine eigene Frage: Brauchst du drei deutsche Versionen? Nicht automatisch. Oft genügt eine deutsche Version für alle drei Länder. Länderspezifische Versionen lohnen sich, wenn sich Inhalte wirklich unterscheiden, etwa durch Preise, Rechtsangaben, Ansprechpartner, Liefergebiete oder Schreibweisen.

Technisch kennzeichnest du Länderversionen mit Sprach- und Ländercode, also de-DE, de-AT und de-CH. Google erlaubt die Kombination aus Sprache und optionalem Land (ISO 639-1 plus ISO 3166-1 Alpha-2). Gibt es nur eine deutsche Version, genügt de ohne Land. Legst du länderspezifische Seiten an, dürfen sie sich nicht inhaltlich gleichen, weil sonst Duplikate entstehen. Das ist der Moment, in dem sich der Aufwand lohnen muss. Sinnvoll ist ein Start mit einer deutschen Version, die du später bei echtem Bedarf auffächerst.

Typische Fehler

• hreflang ohne Rückverweis. Seite A verweist auf B, B nicht auf A. Google kann die Angabe ignorieren.
• Unübersetzte Seiten live. Ein deutscher Text unter /en/ ist ein Qualitätsproblem und kann Duplikate erzeugen.
• Falsche Codes. UK statt GB, EU als Sprache, nur Ländercodes. Das bewirkt nichts.
• Erzwungene Weiterleitung. Wer Besucher automatisch in eine Sprache schickt, nimmt ihnen die Wahl. Biete zusätzlich eine sichtbare Sprachauswahl an und teste, dass jede Sprachversion direkt aufrufbar bleibt. Webflow bietet automatisches Routing nach Browsersprache nur in den Enterprise- und Advanced-Plänen.
• Slugs nicht abgestimmt. In Webflow führen kollidierende Locale-Slugs zu 404-Fehlern.
• Rechtstexte vergessen. Impressum, Datenschutzinformationen und Einwilligungsbanner gehören in jede Sprache. Mehr dazu im Ratgeber zu Tracking-Consent nach TDDDG.
• Formulare ohne Sprachbezug. Ein Lead aus der französischen Version muss als solcher im CRM ankommen. Webflows Form-Webhook liefert dafür die Locale-ID der Sprache, aus der das Formular abgeschickt wurde (Webflow Developers, form_submission). Wie die Anbindung funktioniert, steht im Ratgeber zur Website-CRM-Anbindung.
• Barrierefreiheit vergessen. Die Sprachangabe im HTML und die Auszeichnung von Sprachwechseln im Text sind Teil guter Barrierefreiheit, siehe Barrierefreie Website und BFSG.

Branchen: Industrie, Luftfahrt, Energie

Industrie und Maschinenbau. Kataloge, Datenblätter und technische Dokumentation in vielen Sprachen sind der Normalfall. Entscheidend ist die Datenhaltung: Kommen die Daten aus einem PIM, ERP oder einem Redaktionssystem? Davon hängt ab, ob ein CMS wie Webflow reicht oder ein anderer Ansatz besser trägt. Siehe Industrie und Engineering.

Luftfahrt. Hier genügt oft Deutsch und Englisch, dafür müssen Begriffe, Zertifizierungen und rechtliche Angaben präzise und einheitlich sein. Das spricht für ein Glossar und klare Freigaben. Mehr dazu auf der Seite Luftfahrt.

Energie. Wer international aufgestellt ist, braucht oft mehrere Sprachen für Projekte, Investoren und Partner. Die Inhalte ändern sich selten, dafür müssen sie belastbar sein. Auch hier hilft ein fester Review-Prozess.

Wann du keine Agentur brauchst

Für eine zweisprachige Seite mit überschaubarem Umfang, einem etablierten System und einem Team, das Inhalte selbst pflegt, brauchst du keine Agentur. Aktiviere die Mehrsprachigkeit, übersetze sorgfältig, prüfe hreflang im Quelltext und teste Navigation und Sprachumschalter. Ziehe Hilfe hinzu, wenn mehr als zwei oder drei Sprachen im Spiel sind, wenn du CMS-Strukturen mit vielen Einträgen hast, wenn mehrere Abteilungen freigeben oder wenn ein Relaunch ansteht.

Wie wir das umsetzen

Ein Projekt bei Webwavers folgt den Schritten auf unserer Prozessseite: Erstgespräch, Onboarding mit Briefing, Strategiegespräch, drei Moodboards, die ersten drei Sektionen der Startseite in Figma, Startseite und Unterseiten mit Feedbackrunde nach jedem Meilenstein, Entwicklung und Launch mit Einschulung. Du hast einen festen Projektleiter und einen eigenen Slack-Kanal.

Mehrsprachigkeit ist dort kein eigener Schritt. Bring sie deshalb früh ins Erstgespräch: welche Sprachen, welche Quellsprache, wer übersetzt, wer gibt frei. Entwickelt wird in Webflow, Framer oder WordPress. Webflow ist unser Schwerpunkt, wir setzen auch WordPress, TYPO3 und Headless-Systeme um und beraten neutral, welches System zu Sprachanzahl und Team passt. Mehr zu den Leistungen findest du unter Webentwicklung und bei der Webflow-Agentur.

Wenn du eine mehrsprachige Website planst, sprich mit uns über die Kontaktseite.

FAQ

Welche Webdesign-Agenturen kommen für eine mehrsprachige Website im DACH-Raum mit Maschinenbau-Hintergrund infrage?

Achte weniger auf Branchenlogos als auf Nachweise: Hat die Agentur Katalog- oder Produktdaten-Projekte in mehreren Sprachen umgesetzt, wie handhabt sie hreflang und Übersetzungs-Workflows, und berät sie neutral zu Webflow, WordPress, TYPO3 und Headless? Lass dir Referenzen zeigen und frage nach dem Review-Prozess.

Webflow oder WordPress mit Übersetzungs-Plugin: was ist besser für eine mehrsprachige Seite?

Beide funktionieren. Webflow Localization ist eingebaut, arbeitet mit Subdirectories und erzeugt laut Webflow hreflang-Tags, ist aber ein Add-on mit Locale-Grenzen und nicht mit Webflow Ecommerce kompatibel. WordPress mit WPML oder Polylang ist flexibel, braucht aber Pflege und Kompatibilitätsprüfung. Entscheidend sind Sprachanzahl, Inhaltsumfang und Team.

Wie funktioniert hreflang und was muss ich beachten?

hreflang verknüpft Sprach- und Länderversionen. Jede Version muss sich selbst und alle anderen auflisten, die Verweise müssen gegenseitig sein, und die Codes müssen gültig sein (zum Beispiel en-GB). Mit x-default kennzeichnest du eine Fallback-Seite. Das steht in der Google-Dokumentation zu lokalisierten Versionen.

Wie viele Sprachen unterstützt Webflow Localization?

Nach der Preisseite enthält Localize Essential 1 bis 3 Locales und Localize Advanced 1 bis 10 Locales, für Enterprise gibt es eine individuelle Anzahl. Der Hilfeartikel nennt keine feste Obergrenze. Für mehr als 10 Sprachen klärst du die Konditionen direkt mit Webflow.

Brauche ich für Deutschland, Österreich und die Schweiz drei Sprachversionen?

Nicht automatisch. Eine deutsche Version kann für alle drei Länder genügen. Länderversionen mit de-DE, de-AT und de-CH lohnen sich, wenn sich Inhalte wirklich unterscheiden, etwa Preise, Rechtsangaben oder Ansprechpartner.

Reicht maschinelle Übersetzung für eine Unternehmenswebsite?

Als Erstfassung spart sie Zeit. Bei Fachtexten, Produktdaten und rechtlichen Angaben solltest du eine Prüfung durch Muttersprachler mit Fachwissen einplanen. Webflow bietet KI-Übersetzung als erste Fassung zum manuellen Nachbessern, WPML bietet AI-Übersetzungswörter je nach Plan.

Wie halte ich Übersetzungen aktuell, wenn sich der deutsche Text ändert?

Lege eine Änderungsroutine fest: Änderungen in der Quellsprache werden markiert, die Zielsprachen nachgezogen und freigegeben. Ohne Routine veralten Sprachversionen schnell. Rechne den Pflegeaufwand vor der Entscheidung für ein System durch.

Quellen

• Google, Lokalisierte Versionen deiner Seite (hreflang)
• Webflow Hilfe, Localization overview
• Webflow, Localize
• Webflow, Pricing
• Webflow Developers, form_submission Webhook
• WPML, Preise
• Polylang
• TYPO3, SEO-Dokumentation