Warum die zweite Sprache kein zweites Website-Projekt sein darf
Der Anlass ist fast immer derselbe: Dein SaaS wächst über den DACH-Raum hinaus. Die ersten Trials kommen aus den Niederlanden, ein Partner fragt nach der englischen Produktseite, der Beirat nach der internationalen Roadmap. Und sofort steht die Sorge im Raum: Müssen wir ab jetzt jede Seite, jeden Artikel, jede Preisänderung doppelt pflegen?
Die kurze Antwort: nein. Doppelpflege ist kein Naturgesetz, sondern ein Architekturfehler. Ob deine mehrsprachige Website zum Wachstumshebel oder zum Wartungsgrab wird, entscheidet sich an drei Stellen: bei der URL-Struktur, bei der hreflang-Auszeichnung und bei der Frage, wie dein CMS die Sprachversionen verwaltet.
Dass sich der Schritt lohnen kann, ist gut belegt: Laut der CSA-Studie «Can't Read, Won't Buy» (2020, 8.709 Befragte in 29 Ländern) bevorzugen 76 Prozent der Online-Käufer Produktinformationen in ihrer Muttersprache; 40 Prozent kaufen grundsätzlich nicht auf fremdsprachigen Websites. Wer nur eine Sprache anbietet, verzichtet messbar auf Nachfrage.
Dieser Artikel gehört zu unserem Guide über die Anatomie einer B2B-SaaS-Website. Ich gehe die Entscheidungen in der Reihenfolge durch, in der sie anstehen: Lohnt sich die zweite Sprache überhaupt? Welche Architektur trägt sie? Und wie bleiben die Inhalte synchron, ohne dass du sie kopierst?
Wann sich die zweite Sprache lohnt und wann sie nur Pflegeaufwand ist
Vorab eine unbequeme Wahrheit: Die Übersetzung selbst ist der kleinste Posten. Teuer wird das Weiterpflegen — jede neue Funktion, jeder Blogartikel, jede Preisanpassung stellt ab sofort die Frage «und auf Englisch?». Deshalb hängt die Entscheidung nicht am Sprachwunsch, sondern an deinem Geschäft. Drei Signale sprechen dafür:
- Trials aus dem Ausland: In deinen Analytics tauchen Registrierungen aus Märkten auf, die du nie beworben hast. Der Markt zieht, bevor du drückst.
- Englischsprachige Buying-Center: Auch DACH-Konzerne prüfen Software zunehmend in englischsprachigen Teams. Ohne englische Produkt- und Security-Seiten fällst du in der Shortlist-Phase durch.
- Produkt und Support können es schon: App-Oberfläche und Support arbeiten bereits auf Englisch. Dann ist die Website der letzte fehlende Baustein, nicht der erste.
Für die meisten SaaS-Firmen aus dem DACH-Raum heißt die zweite Sprache schlicht Englisch: 49,5 Prozent aller Websites sind englischsprachig (W3Techs, Stand 22. September 2026), und Englisch trägt dich durch Benelux, Skandinavien und Osteuropa, bevor du in weitere Landessprachen investierst.
Umgekehrt gilt: Ist dein Produkt an den deutschen Markt gebunden, etwa durch eine DATEV-Schnittstelle oder deutsches Steuerrecht, kauft dir niemand die internationale Website ab. Und kann niemand im Team englische Support-Tickets beantworten, erzeugst du Nachfrage, die du enttäuschen musst. Dann ist die zweite Sprache reiner Pflegeaufwand.
Die ehrlichste Testfrage lautet: Wer beantwortet in deinem Team nächsten Dienstag ein englisches Support-Ticket, und wer redigiert nächsten Monat die englische Fassung des neuen Features? Hast du zwei Namen, lohnt sich die Sprache. Hast du keine, ist sie Dekoration.
Eine Sprachversion, die niemand pflegt, ist kein Marktzugang. Sie ist ein Schaufenster voller Staub.
Subdirectory, Subdomain oder eigene Domain: die Architektur-Entscheidung
Zum Technischen: Google beschreibt in seiner Dokumentation für mehrsprachige Websites vier URL-Strukturen. Von URL-Parametern wie ?lang=en rät Google ausdrücklich ab. Bleiben drei Kandidaten, die sich so vergleichen lassen:
| Struktur | Beispiel | Stärke | Schwäche |
|---|---|---|---|
| Unterverzeichnis | example.com/en/ | eine Domain, eine Infrastruktur, gebündelte Autorität | Länderbezug in der URL wenig sichtbar |
| Subdomain | en.example.com | getrennte Systeme je Sprache möglich | Autorität und Pflege verteilen sich |
| Länderdomain (ccTLD) | example.co.uk | klarstes Signal für einen Ländermarkt | teuer, eigene Infrastruktur, ein Land je Domain |
Für SaaS-Websites ist das Unterverzeichnis fast immer die richtige Wahl: eine Codebasis, eine Domain, und jeder Backlink zahlt auf alle Sprachen ein. Eine neue Sprache ist dann ein Ordner, kein Projekt. Länderdomains lohnen sich erst, wenn du je Markt eine eigene Organisation mit eigenem Marketing aufbaust — also deutlich später.
hreflang: sag Suchmaschinen, welche Versionen zusammengehören
hreflang ist die Auszeichnung, mit der du Google mitteilst, welche Sprachversionen einer Seite einander entsprechen. Ohne sie rankt womöglich deine deutsche Preisseite in London. Die hreflang-Dokumentation von Google Search Central nennt drei Wege: Link-Tags im HTML-Head, HTTP-Header oder Einträge in der Sitemap.
Die Regeln sind streng, und an ihnen scheitern die meisten Umsetzungen: Jede Sprachversion muss alle anderen Versionen und sich selbst auflisten. Verweist Seite X auf Y, muss Y auf X zurückverweisen, sonst ignoriert Google die Auszeichnung. Die Codes folgen ISO 639-1 für die Sprache, optional ergänzt um ISO 3166-1 Alpha 2 für die Region, etwa de-CH.
Dazu kommt x-default als Auffangversion für alle Sprachen, die du nicht bedienst. Ein Klassiker der Fehlerliste: Regionscodes ohne Sprache («UK» oder «EU» allein) sind ungültig. hreflang ist Fleißarbeit nach klaren Regeln — genau deshalb sollte dein Framework die Tags generieren, nicht deine Redaktion.
Konkret stehen dafür im Head unserer Startseite drei Einträge: einer für de, einer für en, einer für x-default, jeweils mit vollqualifizierter URL samt https. Bei hunderten Seiten wandert diese Liste besser in die Sitemap, sonst schleppt jede Seite unnötige Kilobytes im Head mit.
Was du übersetzt und was besser nicht
Nicht jede Seite verdient eine zweite Sprache. Meine Faustregel: Übersetze, was verkauft, und lass weg, was nur beschäftigt.
- Immer übersetzen: Startseite, Produkt- und Feature-Seiten, Pricing, Trust-Center, Onboarding-Mails. Alles, was im Kaufprozess liegt.
- Selektiv übersetzen: Blog und Ressourcen. Übersetze die fünf Artikel, die nachweislich Trials bringen, nicht das Archiv.
- Meist nur auf Englisch: technische Doku, API-Referenz, Changelog. Entwickler erwarten Englisch; eine deutsche API-Doku pflegt erfahrungsgemäß niemand nach. Wie Doku und Website aus einer Quelle kommen, zeigt der Schwesterartikel Doku und Website aus einem CMS.
- Je Markt prüfen statt übersetzen: Impressum, AGB, Datenschutz, Preisangaben. Hier geht es nicht um Sprache, sondern um Recht; dazu unten mehr.
Content-Pflege ohne Drift: verknüpfen statt kopieren
Jetzt zum Kern des Use Cases: Wie pflegst du zwei Sprachen, ohne alles doppelt zu machen? Der häufigste Fehler ist schnell beschrieben: Die englische Site entsteht als Kopie der deutschen. Sechs Monate später weiß niemand mehr, welche Version welche Änderung verpasst hat. Dieses stille Auseinanderlaufen nenne ich Drift.
Das Gegenmittel ist ein Muster aus der Headless-Welt: ein Dokument je Sprache, verbunden über eine Übersetzungs-Referenz. Die deutsche und die englische Preisseite sind zwei eigenständige Dokumente, aber das CMS weiß, dass sie zusammengehören. Das bringt dir drei Dinge:
- Sichtbare Lücken: Du kannst abfragen, welche deutschen Dokumente noch keine englische Entsprechung haben. Aus «irgendwo fehlt was» wird eine Arbeitsliste.
- Unabhängige Inhalte: Die englische Version darf kürzer sein, andere Referenzen nennen oder einen Abschnitt weglassen. Du übersetzt die Aussage, nicht die Silben.
- Generiertes hreflang: Aus der Verknüpfung baut das Frontend die hreflang-Tags automatisch. Niemand pflegt Listen von Sprach-URLs von Hand.
Wir machen das auf happycoding.agency genau so, mit Sanity als CMS und Next.js als Frontend: Deutsch und Englisch liegen als Unterverzeichnisse /de/ und /en/ auf einer Domain, je Inhalt existiert ein Dokument pro Sprache, und ein Verknüpfungs-Dokument hält die Paare zusammen. Die hreflang-Tags entstehen aus dieser Verknüpfung. Ein hreflang-Tag von Hand geschrieben hat hier noch niemand.
So sieht das im Alltag aus: Du änderst den Preisabschnitt im deutschen Dokument. Die Verknüpfung zeigt dir die englische Entsprechung, du überträgst die Änderung in einer Viertelstunde, und beide Versionen sind wieder deckungsgleich. Ohne Verknüpfung beginnt stattdessen die Suche: Welche Seiten gab es noch mal auf Englisch?
Wichtig ist die Führungsfrage: Bei uns ist Deutsch die führende Sprache, jede Änderung startet dort und wandert dann nach Englisch. Lege diese Richtung explizit fest. Zwei gleichberechtigte Quellen driften garantiert.
Maschinell übersetzen, menschlich redigieren: der Workflow 2026
Zur Übersetzung selbst: Für den Rohtext musst du 2026 niemanden mehr beauftragen. Maschinelle Übersetzung, ob DeepL oder ein Sprachmodell, liefert bei Marketing-Texten eine Qualität, die vor wenigen Jahren Agenturniveau war. Der Engpass ist gewandert: von der Übersetzung zur Redaktion. Unser Workflow hat drei Schritte:
- Glossar zuerst: Lege fest, welche Begriffe unübersetzt bleiben (Produktname, Feature-Namen) und wie Kernbegriffe übersetzt werden. Ohne Glossar heißt dasselbe Feature auf drei Seiten drei verschiedene Dinge.
- Maschinelle Erstfassung: Die Maschine übersetzt das ganze Dokument, samt Meta-Title, Meta-Description und Bild-Alternativtexten. Das kostet Minuten, nicht Wochen.
- Menschliche Redaktion: Ein Mensch mit Marktkenntnis prüft Positionierung, Tonalität, Claims und alles mit Rechtsbezug. Nach unserer Projekterfahrung ist das je Marketing-Seite eher eine halbe Stunde als ein halber Tag — eine Einschätzung, kein Branchenwert.
Den Redaktionsschritt solltest du auch aus SEO-Sicht ernst nehmen: Google führt in seinen Spam-Richtlinien automatisiertes Übersetzen unter den Techniken auf, mit denen massenhaft Seiten ohne Mehrwert entstehen. Eine redigierte Übersetzung mit Marktbezug ist davon weit entfernt; tausend ungeprüfte KI-Seiten sind genau das.
Wichtig noch: Übersetzung ist kein Projekt, sondern ein Prozess. Plane den Redaktionsschritt fest in deinen Veröffentlichungs-Ablauf ein: Ein neuer Blogartikel gilt erst als fertig, wenn entschieden ist, ob er übersetzt wird — ein bewusstes Nein ist dabei ein völlig legitimes Ergebnis.
Für dein Budget heißt das: Nach meiner Einschätzung kostet die zweite Sprache grob 20 bis 30 Prozent Aufschlag auf die laufende Content-Pflege — ein Erfahrungswert aus unseren Projekten, keine erhobene Branchenzahl. Mit kopierten statt verknüpften Seiten liegst du dauerhaft deutlich darüber.
Fünf Fehler, die ich immer wieder sehe
Zum Abschluss die Fehlerliste aus Audits und Projektübernahmen. Prüfe deine Website gegen jede Position:
- Die halb übersetzte Site: Startseite Englisch, Blog Deutsch, Cookie-Banner gemischt. Das wirkt nicht international, sondern unfertig. Übersetze lieber zehn Seiten vollständig als vierzig zur Hälfte.
- Vergessene Meta-Texte: Meta-Title, Meta-Description, Open-Graph-Texte, 404-Seite, Formular-Fehlermeldungen, Bestätigungs-Mails. Ausgerechnet die Texte, die kein Redakteur im Alltag sieht, sieht der Interessent zuerst.
- Zwangs-Redirect nach IP: Wer aus Zürich kommt, landet automatisch auf Deutsch, auch als englischsprachiger Nutzer. Google rät von automatischen Sprach-Redirects ab und empfiehlt sichtbare Links zwischen den Versionen; IP-Ortung gilt in derselben Dokumentation als generell unzuverlässig.
- hreflang ohne Rückverweis: Die neue englische Seite verweist auf die deutsche, aber auf der deutschen fehlt der Rückverweis. Ergebnis: Google ignoriert beide Auszeichnungen.
- Preise und Rechtstexte ungeprüft übernommen: netto oder brutto, Währung, Impressumspflicht, anwendbares Recht. Was für Deutschland stimmt, ist in UK oder den USA falsch. Diese Seiten brauchen keine Übersetzung, sondern eine Prüfung je Markt.
Nächste Schritte
Steht die zweite Sprache bei dir an, beginne mit der Architektur, nicht mit der Übersetzung: Unterverzeichnis-Struktur, ein verknüpftes Dokument je Sprache, generiertes hreflang. Das kostet zu Beginn wenige Tage und erspart dir Jahre an Doppelpflege.
Als Website-Agentur für B2B-Unternehmen bauen wir mehrsprachige Websites mit Next.js und Sanity — nach demselben Muster, mit dem unsere eigene Site auf Deutsch und Englisch läuft. Wenn du wissen willst, wie der Weg für deine Website aussieht, buch dir ein kostenloses Erstgespräch: Wir schauen uns dein Setup an und skizzieren die Schritte zur zweiten Sprache.
