Wie man ein mehrsprachiges Informationsportal erstellt

Beginnen Sie mit Zielen, Zielgruppen und Sprachprioritäten

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.

Definieren Sie das Portalziel

Mehrsprachige Informationsportale folgen meist einigen Mustern:

• News und Updates (Zeitnähe ist wichtig; ältere Inhalte müssen nicht immer komplett übersetzt werden)
• Leitfäden und Ressourcen (evergreen-Seiten, die am meisten von Lokalisierung profitieren)
• FAQs und Support (weniger Tickets ist ein messbares Ergebnis)
• Verzeichnisse (Listen mit Diensten, Kontakten oder Organisationen; Genauigkeit und regionale Unterschiede sind wichtig)

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.

Listen Sie Zielgruppen und Regionen auf (und was sie wirklich brauchen)

Sprachen sind keine Checklisten. Identifizieren Sie:

• Ihre primären Nutzergruppen (Bewohner, Besucher, Fachkräfte, Studierende, Partner)
• Die Regionen, die Sie bedienen (eine Sprache kann nur in bestimmten Städten oder Ländern nötig sein)
• Die Absicht hinter Besuchen (schnelle Antworten, tiefgehende Recherche, Formulare, Kontaktdaten)

Wenn Sie Analytics oder Support-Logs haben, nutzen Sie sie, um zu bestätigen, welche Sprachen und Themen die meiste Nachfrage erzeugen.

Entscheiden Sie, was übersetzt werden muss vs. was einsprachig bleiben kann

Nicht alle Inhalte haben denselben Wert. Ein praktischer Ansatz ist, jeden Inhaltstyp zu kennzeichnen als:

• Must translate: kritische Journeys (wie man sich bewirbt, Anspruchsvoraussetzungen, Notfallinfos, zentrale Richtlinien)
• Should translate: reichweitenstarke Leitfäden, Top-FAQs, Onboarding-Seiten
• Can stay single-language: interne Ankündigungen, Nischen-Updates, technische Dokumentation

Entscheiden Sie auch, welche Inhalte voll lokalisiert werden (für Verständlichkeit umgeschrieben) und welche eine einfache Übersetzung erhalten.

Legen Sie Erfolgskennzahlen frühzeitig fest

Wählen Sie eine kleine Menge messbarer Ergebnisse, z. B.:

• Such-Traffic zu lokalisierten Seiten
• Anmeldungen oder Ressourcen-Downloads nach Sprache
• Verweildauer / Scrolltiefe auf Schlüssel-Leitfäden
• Weniger Supportanfragen aufgrund von Missverständnissen

Diese Metriken helfen Ihnen, Sprachen zu priorisieren und nach dem Start zu beweisen, dass das Portal funktioniert.

Planen Sie die Informationsarchitektur für mehrere Sprachen

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.

Beginnen Sie mit einem Inventar (was Sie tatsächlich veröffentlichen)

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).

Erstellen Sie eine Sitemap, die überall funktioniert

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.

Standardisieren Sie Taxonomien: Kategorien und Tags

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.

Entscheiden Sie sich für Content-Parität vs. sprachspezifische Abschnitte

Wählen Sie früh eines dieser Modelle:

• Gleiche Struktur + gleicher Inhalt in jeder Sprache (am besten für Support-Portale und Dokumentation)
• Gleiche Struktur + teilweise übersetzte Inhalte (üblich bei Blogs und Resource Centern)
• Sprachspezifische Abschnitte (nützlich, wenn Gesetze, Dienste oder Nutzerbedürfnisse unterschiedlich sind)

Wenn Sie sprachspezifische Abschnitte zulassen, dokumentieren Sie sie klar, damit das Portal nicht im Laufe der Zeit in drei verschiedene Websites zerfällt.

Wählen Sie eine Sprache‑URL‑Struktur, die skaliert

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.

Die wichtigsten URL‑Optionen (und was sie bedeuten)

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.

Eine Standardempfehlung

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.

Halten Sie URLs lesbar und konsistent

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.

Redirects und Canonical-Regeln

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).

Gestalten Sie den Sprachumschalter und die Nutzererfahrung

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.

Wo der Umschalter hin gehört (und wie er beschriftet wird)

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).

Auto‑Detection: hilfreich, aber nie zwingend

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.

Merken Sie sich die Wahl des Nutzers

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.

Fallbacks, wenn Inhalte nicht übersetzt sind

Planen Sie für fehlende Seiten. Wenn eine Seite in einer Sprache fehlt:

• Bleiben Sie in der gewählten Oberfläche und zeigen Sie eine freundliche Nachricht, dass die Seite noch nicht übersetzt ist
• Bieten Sie einen Link zur Default‑Sprache (klar gekennzeichnet)
• Geben Sie Alternativen: die nächstgelegene Kategorie, Suchergebnisse oder die Portal-Startseite

Das vermeidet Sackgassen, erhält Vertrauen und verhindert, dass der Umschalter „gebrochen“ wirkt, solange Übersetzungen noch ausstehen.

Wählen Sie das richtige CMS und Tools für ein mehrsprachiges Portal

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.

Beginnen Sie mit den multilingualen Grundlagen

„Mehrsprachige Website“ bedeutet nicht nur übersetzten Fließtext. Prüfen Sie, ob die Plattform pro Sprache verwalten kann:

• Seiten und wiederverwendbare Blöcke (Header, Footer, Banner)
• Menüs und Navigationslabels
• SEO‑Metadaten (Titel, Beschreibungen, Social‑Sharing‑Texte)
• Medienfelder (Bildunterschriften, Alt‑Text)

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?

CMS‑Optionen: worauf Sie achten sollten

Ob klassisches CMS (WordPress, Drupal), ein gehosteter Builder oder ein Headless‑CMS — bewerten Sie dieselben Fähigkeiten:

• Klare Content‑Modellierung: Übersetzungen sollten mit der Originalseite verknüpfbar sein und der Status auf einen Blick sichtbar
• Flexible Workflows: Entwurf → Prüfung → Freigabe → Veröffentlichung sollte pro Sprache einfach durchsetzbar sein
• Skalierbare URL‑Unterstützung: Das CMS sollte Ihre gewählte Sprach‑URL‑Struktur ohne Hacks unterstützen

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.