Mehrsprachige Websites für kleine Webagenturen
Praxisleitfaden zur Architektur mehrsprachiger Websites für kleine Agenturen - URL-Strategie, Inhaltsmodellierung, hreflang und die Werkzeuge, die Mehrsprachigkeit editierbar machen.
Dies ist der praktische Leitfaden unserer Agentur für den nachhaltigen Umgang mit mehrsprachigen Websites.
TL;DR. Eine nachhaltige Mehrsprachigkeit für KMU-Sites ruht auf vier Entscheidungen: Unterverzeichnis-URLs (example.com/de/, example.com/en/), lokalisierte Slugs pro Seitenschlüssel, eine explizite Standard- und Fallback-Regel sowie ein Übersetzungs-Workflow, der zu einem kleinen Team passt. Ergänzt um Feld-Ebenen-Flags und automatisches hreflang in Kopf und Sitemap, nimmt das CMS dem Redakteur den Großteil der wiederkehrenden Mehrsprachigkeitsarbeit ab.
TL;DR (zum Überfliegen)
- Unterverzeichnis-URL-Strukturen (z. B.
/en/) sind in der Regel die nachhaltigste Wahl für KMU. - Hreflang-Tags sind für SEO entscheidend und sollten vom CMS automatisiert werden.
- Die Lokalisierung auf Feldebene spart Zeit, da vollständige Seitenübersetzungen bei kleinen Änderungen entfallen.
In Deutschland, Österreich, der Schweiz und weiten Teilen der EU ist “Unterstützen Sie mehrere Sprachen?” keine besondere Anforderung - es ist eine Grunderwartung. Eine Hotel-Website ohne englische Version verliert Gäste. Eine Praxis ohne türkische oder arabische Seite lässt Patienten außen vor. Ein Kleinkanzlei-Portfolio, das Mehrsprachigkeit nicht sauber handhabt, arbeitet unter seinen Möglichkeiten. Gerade deshalb ist ein mandantenfähiges CMS für Agenturen in diesen Märkten besonders sinnvoll.
Die vier grundlegenden Entscheidungen
Erfolgreiche mehrsprachige Websites erfordern Vorabentscheidungen zu URL-Routing, Slug-Lokalisierung, Fallback-Verhalten und Übersetzungs-Workflows.
URL-Strategie. Drei Optionen. Unterverzeichnis (example.com/de/, example.com/en/) empfiehlt sich für fast jeden Fall. Eine Domain, ein SSL-Zertifikat, eine Analytics-Property, einfaches hreflang. Subdomain (de.example.com) ist akzeptabel, aber mit mehr Einrichtungsaufwand verbunden. ccTLD (example.de, example.fr) ist nur sinnvoll, wenn man auf landesspezifische Märkte getrennt abzielt. Für mehrsprachige KMU-Sites: standardmäßig Unterverzeichnisse.
Lokalisierte Slugs. example.com/de/funktionen/ liest sich für einen deutschen Besucher selbstverständlich. example.com/de/features/ klingt übernommen. Lokalisierte Slugs sind besser für die native Nutzererfahrung, besser für die sprachspezifische SEO - und signalisieren Suchmaschinen, dass jede Sprachversion eigenständig gepflegt wird. Der Implementierungsaufwand ist eine Slug-Zuordnungstabelle pro Seitenschlüssel pro Sprachvariante - überschaubarer Aufwand, erheblicher UX-Gewinn.
Standardsprache und Fallback. Eine Standardsprache festlegen - meist der Heimatmarkt der Agentur oder Englisch für ein EU-weites Produkt. Dann entscheiden, was passiert, wenn eine lokalisierte Version einer Seite nicht existiert. Harter 404, wenn jede Seite in jeder Sprache vorhanden sein sollte. Fallback auf die Standardsprache ist akzeptabel, wenn man eine neue Sprachvariante einführt, die noch nicht vollständig ist - mit sichtbarem Hinweis. Weiterleitung ist für SEO am saubersten, kann aber befremdlich wirken.
Übersetzungsworkflow. Für KMU-Sites mit kleiner Agentur funktionieren drei Muster. Vorab übersetzen, dann je Sprache separat bearbeiten (am häufigsten). Nur in der Standardsprache bearbeiten, maschinelle Übersetzung beim Rendern (günstig, Qualität schwankend). Eigenes Redaktionsteam pro Sprache (für betreute KMU-Websites selten).
hreflang in der Praxis
Das hreflang-Attribut ist der Standardmechanismus (dokumentiert von Google Search Central), um Suchmaschinen mitzuteilen, welche Sprachversion einer Seite welchen Nutzern angezeigt werden soll.
Suchmaschinen müssen wissen, welche Seite in welcher Sprache die kanonische Version desselben Inhalts ist. Der Mechanismus ist das hreflang-Attribut, das im Seitenkopf als link rel="alternate" hreflang für jede Sprachversion gesetzt wird - plus hreflang="x-default" für den Fallback. Außerdem in der Sitemap mit xhtml:link rel="alternate" hreflang pro URL-Eintrag. Ein modernes mehrsprachiges CMS übernimmt beides automatisch.
Lokalisierungsgranularität
Nicht jedes Feld muss übersetzt werden. Ein typisiertes Inhaltsmodell lässt die Agentur je Feld entscheiden. Immer lokalisiert: Überschriften, Fließtext, FAQ-Einträge, Bild-Alternativtexte, SEO-Meta-Titel und -Beschreibungen. Manchmal lokalisiert: Produktnamen, Team-Mitglied-Titel. Nie lokalisiert: Layout-Entscheidungen, Ausrichtung, Datumsangaben (werden bei der Anzeige sprachabhängig formatiert), Blockstruktur, Bildreferenzen.
Ein CMS, das der Agentur erlaubt, jedes Feld als lokalisiert oder nicht lokalisiert zu markieren, nimmt einem einen großen Teil der Mehrsprachigkeitsarbeit ab. Feldebene-Locale-Flags sind der Unterschied zwischen “die Website übersetzen” und “den Inhalt übersetzen”.
Besonderheiten für den deutschen Markt
Einige Muster sind für deutschsprachige Sites besonders relevant. Formelles Sie durchgehend in deutschem B2B-Inhalt, stets groß geschrieben - die Formulierungen unterscheiden sich vom informellen du, es geht nicht nur um den Austausch eines Pronomens. Deutsch erlaubt lange Komposita - das Layout muss 30 Zeichen lange Einzelwörter ohne Überlauf aufnehmen können. Datumsformat: 9. Mai 2026, nicht May 9, 2026. Zahlenformat: 1.000,50 (Punkt als Tausendertrennzeichen, Komma als Dezimaltrennzeichen). Impressum, Datenschutzerklärung und Cookie-Richtlinie sind Pflichtangaben - pro Sprachvariante eigene Seiten, keine übersetzten Kopien einer gemeinsamen Seite.
Was man vermeiden sollte
Eine CMS-Installation pro Sprache - ein Muster aus der Vergangenheit, das zur Wartungs-Tretmühle wird. Automatische Übersetzung nur zur Renderzeit - für wenig wichtige Inhalte tolerierbar, für SEO problematisch. Freier HTML-Körper, der als Ganzes übersetzt wird - jede Inhalteänderung löst eine vollständige Übersetzungsprüfung des gesamten Körpers aus.
Die Tooling-Grundlage
Ein kleines Agentur-Setup für mehrsprachige Websites braucht typischerweise ein CMS, das lokalisierte Felder auf Schema-Ebene handhabt, lokalisierte URL-Slugs ohne manuelle Abstimmung ermöglicht, automatisches hreflang in Kopf und Sitemap liefert, eine sprachabhängige Vorschau bietet, Pro-Sprache-Entwurf- und Veröffentlichungsstatus kennt und Übersetzungs-API-Hooks unterstützt, wenn man KI-gestützte Übersetzung einsetzen möchte. Nach unserer Erfahrung bringt Kernset all das effektiv mit. Den vollständigen Funktionsumfang finden Sie auf der Funktionsseite.
Für eine typische KMU-Site ist mit 30 bis 50 Prozent zusätzlichem Content-Einpflegeaufwand pro hinzugefügter Sprache beim Launch zu rechnen. Laufende Anpassungen sind geringfügig aufwendiger, weil der Kunde an zwei Stellen bearbeitet. Der Gewinn ist eine Website, die ihr Publikum wirklich in dessen Sprache anspricht - was in den meisten europäischen Märkten der entscheidende Faktor ist.
Häufige Fragen
Sollte ich Subdomains oder Unterverzeichnisse für eine mehrsprachige Website verwenden?
Für die überwiegende Mehrheit der KMU-Kundenwebsites sind Unterverzeichnisse (wie example.com/en/) die bessere Wahl. Sie bündeln die Domain-Autorität, erfordern nur ein SSL-Zertifikat und vereinfachen das Analytics-Tracking im Vergleich zu Subdomains.
Gegen Ihr Portfolio testen
Wenn Ihr Portfolio Hotels, Praxen oder Dienstleister umfasst, die in zwei oder drei Sprachen muttersprachlich klingen müssen, ist der schnellste Weg zur Entscheidung, ob Kernset passt, ein Vergleich mit Ihrer aktuell unübersichtlichsten mehrsprachigen Site. Frühzugang anfragen - jede Nachricht liest ein Mensch.