28. Mai 2025·4 Min
Wie man ein mehrsprachiges Informationsportal erstellt
Erfahren Sie, wie Sie ein mehrsprachiges Informationsportal planen, aufbauen und optimieren: Struktur, Übersetzungen, Navigation, SEO und laufende Pflege.
Erfahren Sie, wie Sie ein mehrsprachiges Informationsportal planen, aufbauen und optimieren: Struktur, Übersetzungen, Navigation, SEO und laufende Pflege.
Bevor Sie über Übersetzungstools oder einen Sprachumschalter nachdenken, klären Sie, wofür Ihr Portal da ist und wen es bedienen muss. Dieser Schritt spart später Geld, weil er verhindert, dass „alles übersetzen“-Entscheidungen getroffen werden, die nicht zu den tatsächlichen Nutzerbedürfnissen passen.
Mehrsprachige Informationsportale folgen meist einigen Mustern:
Formulieren Sie ein Ein-Satz-Ziel, z. B.: „Bewohnern helfen, verifizierte Dienste zu finden und Anspruchsvoraussetzungen zu verstehen.“ Dieses Ziel wird Ihr Filter dafür, was zuerst übersetzt wird.
Sprachen sind keine Checklisten. Identifizieren Sie:
Wenn Sie Analytics oder Support-Logs haben, nutzen Sie sie, um zu bestätigen, welche Sprachen und Themen die meiste Nachfrage erzeugen.
Nicht alle Inhalte haben denselben Wert. Ein praktischer Ansatz ist, jeden Inhaltstyp zu kennzeichnen als:
Entscheiden Sie auch, welche Inhalte voll lokalisiert werden (für Verständlichkeit umgeschrieben) und welche eine einfache Übersetzung erhalten.
Wählen Sie eine kleine Menge messbarer Ergebnisse, z. B.:
Diese Metriken helfen Ihnen, Sprachen zu priorisieren und nach dem Start zu beweisen, dass das Portal funktioniert.
Ein mehrsprachiges Informationsportal steht oder fällt mit der Struktur. Bevor Sie etwas übersetzen, stellen Sie sicher, dass die Form der Seite klar, konsistent und leicht in andere Sprachen übertragbar ist.
Listen Sie Ihre Inhaltstypen und ihre Beziehungen auf. Für die meisten Portale gehören dazu Artikel, Kategorien, Tags, Hilfe-Dokumente/FAQs und Formulare (Kontakt, Feedback, Newsletter, Einreichungen). Notieren Sie auch spezielle Elemente: rechtliche Seiten, Ankündigungen, herunterladbare Ressourcen oder standortbezogene Seiten.
Wenn Sie alles an einem Ort sehen, können Sie entscheiden, welche Typen in jeder Sprache existieren müssen (z. B. Kern-Hilfeseiten) und welche optional sein können (z. B. lokale Nachrichten).
Streben Sie eine Sitemap an, die auch in übersetzter Form Sinn macht. Eine einfache Struktur ist leichter zu pflegen und zu navigieren — besonders wenn Nutzer die Sprache während der Sitzung wechseln.
Halten Sie die Anzahl der Top-Level-Bereiche gering und vermeiden Sie „Verschiedenes“-Eimer, die später in Unordnung enden. Wenn Sie Platz für Wachstum brauchen, planen Sie ihn als zweite Ebene unter einem bestehenden Bereich statt neue Top-Level-Elemente hinzuzufügen.
Verwenden Sie konsistente Kategorienbedeutungen über Sprachen hinweg (auch wenn sich die Labels ändern, sollte das zugrunde liegende Konzept stabil bleiben). Das ist wichtig für Navigation, Suchfilter, Analytics und gemeinsame Templates.
Seien Sie vorsichtig mit Tags: sie vermehren sich schnell, sind schwer konsistent zu übersetzen und werden oft Duplikate (z. B. „how-to“ vs. „guide“). Wenn Sie Tags verwenden, definieren Sie Regeln: wer darf sie erstellen, wann zusammenführen und wie übersetzen.
Wählen Sie früh eines dieser Modelle:
Wenn Sie sprachspezifische Abschnitte zulassen, dokumentieren Sie sie klar, damit das Portal nicht im Laufe der Zeit in drei verschiedene Websites zerfällt.
Ihr URL‑Muster ist eine der schwierigsten multilingualen Entscheidungen, die sich später nur schwer ändern lässt. Wählen Sie eine Struktur, die beim Hinzufügen weiterer Sprachen, Bereiche und Contributor klar bleibt.
1) Subdirectories: /de/, /es/, /fr/
Das ist die gängigste Wahl für mehrsprachige Informationsportale, weil alles unter einer Domain liegt. Es ist einfacher zu pflegen, leichter in einer Analytics-Property zu verfolgen und in der Regel betriebswirtschaftlich günstiger.
2) Subdomains: de.example.com, es.example.com
Nützlich, wenn Teams, Infrastruktur oder Release-Zyklen nach Locale getrennt sind. Der Nachteil: Jede Subdomain kann sich wie eine eigenständige Seite anfühlen, was Aufwand für SEO, Analytics, Cookies und Governance erhöht.
3) Separate Domains: example.es, example.fr (oder völlig unterschiedliche Domains)
Am sinnvollsten, wenn starke Landesmarkenbildung, lokale rechtliche Anforderungen oder lokales Hosting nötig sind. Es ist auch der meiste Aufwand: mehrere Domains, separater Aufbau von Authority und komplexere Governance.
Für die meisten Portale empfehlen wir Subdirectories (z. B. /de/, /es/) und eine gleiche Inhaltsstruktur in allen Sprachen.
Wählen Sie Subdomains, wenn Sprachversionen effektiv als halbunabhängige Properties betrieben werden.
Wählen Sie separate Domains nur bei klaren geschäftlichen oder rechtlichen Gründen.
Verwenden Sie benutzerfreundliche Slugs, halten Sie sie stabil und spiegeln Sie die Hierarchie wider:
/de/hilfe/erste-schritte//es/ayuda/primeros-pasos/Entscheiden Sie, ob Slugs übersetzt werden (oft am besten für Nutzer) und dokumentieren Sie die Regel, damit Editoren nicht abdriften.
Legen Sie ein Standardverhalten fest (z. B. Weiterleitung von / auf /de/ oder Anzeige eines Sprachselectors) und seien Sie konsistent.
Vermeiden Sie doppelte Seiten, die sich nur durch Tracking-Parameter oder alternative Pfade unterscheiden. Nutzen Sie 301-Weiterleitungen für ausgemusterte URLs und Canonical-Tags, um auf die bevorzugte Version zu verweisen, wenn Duplikate unvermeidbar sind (z. B. Druckansichten oder gefilterte Listings).
Ein mehrsprachiges Portal wirkt nur „einfach“, wenn Menschen die Sprache ohne Nachdenken ändern können. Der Sprachumschalter ist kein Zierat — er ist ein zentrales Navigationselement, das auf der gesamten Seite konsistent sein sollte.
Platzieren Sie einen klaren Sprachumschalter in der Kopfzeile, sodass er auf jeder Seite sichtbar ist, auch auf Landingpages aus der Suche. Ergänzen Sie ihn im Footer als Backup für Nutzer, die scrollen (und für Seiten mit dichter Kopfzeile).
Bevorzugen Sie eindeutige Sprachnamen („Deutsch“, „Español“, „Français“) statt Flaggen. Flaggen stehen für Länder, nicht für Sprachen, und können verwirren (z. B. Spanisch vs. Mexiko vs. Spanien).
Erkennen Sie Sprache vorsichtig: Sie können eine Empfehlung basierend auf Browsereinstellungen oder Standort anzeigen, dürfen aber nie eine Weiterleitung erzwingen, die Nutzer einsperrt. Ein gängiges Muster ist ein dezenter Banner: „Bevorzugen Sie Español? Zur spanischen Version wechseln.“ Wird er weggeklickt, zeigen Sie ihn für eine Weile nicht erneut.
Wenn ein Nutzer eine Sprache wählt, merken Sie sich das über mehrere Sitzungen per Cookie (und speichern Sie es im Profil, falls vorhanden). Ziel: Nachdem jemand einmal eine Sprache gewählt hat, sollte die Seite so lange bleiben, bis er/sie sie ändert.
Planen Sie für fehlende Seiten. Wenn eine Seite in einer Sprache fehlt:
Das vermeidet Sackgassen, erhält Vertrauen und verhindert, dass der Umschalter „gebrochen“ wirkt, solange Übersetzungen noch ausstehen.
Ihre CMS‑Wahl macht mehrsprachiges Publizieren entweder routine‑tauglich — oder verwandelt jedes Update in ein Mini‑Projekt. Bevor Sie Plattformen vergleichen, schreiben Sie auf, was Sie veröffentlichen (News, Leitfäden, PDFs, Alerts), wie oft es sich ändert und wer jede Sprache verantwortet.
„Mehrsprachige Website“ bedeutet nicht nur übersetzten Fließtext. Prüfen Sie, ob die Plattform pro Sprache verwalten kann:
Prüfen Sie auch, wie das CMS mit „fehlenden Übersetzungen“ umgeht. Kann man z. B. englische Updates veröffentlichen, während die deutsche Version in Arbeit ist, ohne die deutsche Navigation zu zerstören?
Ob klassisches CMS (WordPress, Drupal), ein gehosteter Builder oder ein Headless‑CMS — bewerten Sie dieselben Fähigkeiten:
Wenn Sie ein Headless‑CMS in Erwägung ziehen, stellen Sie sicher, dass Sie im Team jemanden haben, der das Frontend pflegen kann. Andernfalls ist ein Managed‑CMS möglicherweise besser geeignet.
Wenn Sie ein Portal von Grund auf neu bauen, kann eine vibe‑coding Plattform wie Koder.ai eine praktische Option zum Prototypenbau und schnellen Ausliefern des Stacks sein: Sie können die mehrsprachige IA, URL‑Struktur (z. B. /de/, /es/) und Kern‑Templates im Chat beschreiben und dann mit Planungsmodus, Snapshots und Rollbacks iterieren. Besonders nützlich, wenn Sie ein React‑Frontend mit einem Go/PostgreSQL‑Backend wollen und schnell vorankommen möchten, aber die Möglichkeit behalten wollen, Quellcode zu exportieren.
Starten Sie, indem Sie ein einprägsames Portalziel in einem Satz formulieren und Ihre wichtigsten Nutzerwege auflisten (z. B. Anspruchsvoraussetzungen, Bewerbungsprozess, Notfallinformationen). Kennzeichnen Sie dann Inhaltstypen als:
Das verhindert ein „alles übersetzen“-Budget und stellt sicher, dass die Qualität dort hoch bleibt, wo sie am meisten zählt.
Nutzen Sie Metriken, die an konkrete Ziele gebunden sind, nicht nur Seitenaufrufe. Übliche Optionen sind:
Setzen Sie Ziele pro Sprache, damit Sie erkennen können, ob eine Region bei Auffindbarkeit oder Nutzbarkeit zurückfällt.
Beginnen Sie mit einem Inventar dessen, was Sie veröffentlichen (Artikel, Leitfäden, FAQs, Verzeichnisse, Formulare, rechtliche Seiten). Entwerfen Sie dann eine Sitemap, die in allen Sprachen konsistent bleibt:
Eine konsistente Struktur erleichtert Navigation, Suche, Analytics und Übersetzungs-Workflows erheblich.
Behandeln Sie Taxonomien als kontrollierten Wortschatz. Definieren Sie kanonische Konzepte (z. B. „Öffentliche Gesundheit“) und pflegen Sie genehmigte Übersetzungen für jede Sprache.
Praktische Tipps:
Das verhindert, dass ähnliche Bereiche in unterschiedliche, verwirrende Bezeichnungen ausarten.
Für die meisten Portale sind Subdirectories (z. B. /de/, /en/) die beste Wahl. Sie sind in der Regel einfacher für:
Verwenden Sie Subdomains nur, wenn einzelne Sprachversionen wie halbunabhängige Properties betrieben werden. Separate Domains sind nur bei klaren rechtlichen/geschäftlichen Gründen sinnvoll.
Legen Sie ein einheitliches Verhalten fest und wenden Sie es überall an:
/ macht (Weiterleitung auf eine Standardsprache oder Anzeige eines Selectors)Stellen Sie außerdem sicher, dass jede Seite auf ihr wirkliches Sprachequivalent verlinkt (nicht nur auf die Startseite), damit ein Sprachwechsel den Pfad des Nutzers nicht zerstört.
Platzieren Sie einen Sprachumschalter in der Kopfzeile auf jeder Seite (ggf. zusätzlich im Footer). Nutzen Sie Sprachnamen wie „Deutsch“, „English“, „Español“ statt Flaggen.
Bei Auto-Erkennung:
So bleibt das Verhalten vorhersehbar und vermeidet Frust.
Vermeiden Sie Sackgassen. Wenn eine Seite nicht übersetzt ist:
Das bewahrt Vertrauen, während Übersetzungen noch in Arbeit sind.
Stellen Sie sicher, dass Ihr CMS pro Sprache mindestens verwalten kann:
Suchen Sie außerdem nach Übersetzungs-Verknüpfung/status, per-Sprache Workflows (Entwurf → Prüfen → Veröffentlichen), Rollen & Berechtigungen sowie sauberer Unterstützung für Ihre gewählte URL-Struktur.
Priorisieren Sie Klarheit und Nützlichkeit in jeder Sprache:
Verwenden Sie regionalspezifische Codes (z. B. ) nur bei echten regionalen Anforderungen.
de-CH