Lerne den einfachsten Weg, Englisch und Spanisch zu deiner Website hinzuzufügen: richtige URL‑Struktur wählen, Sprachumschalter einrichten, SEO beachten und einen reibungslosen Launch durchführen.
Spanisch (oder Englisch) hinzuzufügen ist meist dann sinnvoll, wenn du klare Signale siehst: ein wachsender Anteil an Besuchern, die diese Sprache nutzen, wiederholte Verkaufsanfragen aus einem bestimmten Markt oder Support‑Tickets, die sich wegen Hin‑ und Her-Verkehr in die Länge ziehen. Gut gemacht kann Lokalisierung außerdem die Support‑Last reduzieren—wenn Kunden sich in ihrer bevorzugten Sprache selbst bedienen können, entstehen weniger „kurze Frage“‑Tickets.
Eine mehrsprachige Website ist nicht nur, dass deine Seiten durch Übersetzung laufen. Sie umfasst:
Wenn du nur den Fließtext übersetzt, stoßen Nutzer immer noch auf englische Menüs, kaputte Suche oder Formulare, denen sie nicht vertrauen. Das wirkt unfertig.
Beginne mit den Seiten, die direkt Umsatz und Support beeinflussen. Ein solides erstes Release umfasst oft:
Nice‑to‑have‑Elemente (Blogarchive, ältere Pressemeldungen) können später kommen, sobald das Fundament konsistent ist.
Bilinguale Sites scheitern, wenn eine Sprache nicht mehr aktualisiert wird. Weise klare Verantwortlichkeiten zu:
Treffe eine einfache Regel: wenn Englisch sich ändert, wird Spanisch innerhalb eines festgelegten Fensters aktualisiert (z. B. 3–5 Arbeitstage). Diese eine Entscheidung verhindert das Problem „zwei Sites driften auseinander“.
Deine URL‑Struktur ist das „Adresssystem“ für deine beiden Sprachen. Wähle sie früh und bleib dabei—eine Änderung später kann Redirects, verlorene Rankings und kaputte geteilte Links bedeuten.
1) Subfolders (empfohlen für die meisten Sites):
/ oder /en//es/2) Subdomains:
www.example.comes.example.com3) Separate Domains:
example.comexample.esFür SEO und Wartung sind Subfolders oft am wenigsten kompliziert:
/es/ vs. non‑/es/‑Traffic ohne komplizierte Zusammenführung.Subdomains und separate Domains sind nicht falsch—sie bedeuten nur zusätzlichen Aufwand. Wenn dein Ziel eine unkomplizierte Englisch/Spanisch‑Übersetzung der Website ist, sind Subfolders meist die praktischste Wahl.
/es/..../es/ beginnen). Deine URL‑Struktur bestimmt, wie einfach das ist.Entscheide, ob spanische URLs übersetzt werden oder nicht, und wende das überall an:
/es/precios, /es/contacto/es/pricing, /es/contactBeides ist in Ordnung—wichtig ist Konsistenz. Vermischte Ansätze verwirren Nutzer, Redakteure und Reports und machen die mehrsprachige Website schwerer wartbar.
Eine zweisprachige Seite wirkt nur „einfach“, wenn Besucher die Sprache ohne Nachdenken wechseln können. Dein Sprachumschalter ist ein kleines UI‑Element, das Vertrauen, Conversions und Support‑Anfragen beeinflusst.
Platziere einen klaren Sprachselector an einem konsistenten Ort—typischerweise im Header (am besten für Entdeckung) oder im Footer (akzeptabel, wenn der Header voll ist). Wenn er im Menü ist, halte ihn in der Nähe der Navigation, damit Nutzer nicht suchen müssen.
Verwende klare Bezeichnungen: English und Español. Vermeide Abkürzungen wie EN/ES, es sei denn, der Platz ist wirklich knapp.
Ländersymbole sind verführerisch, aber Sprache ist nicht gleich Land. Ein spanischsprachiger Nutzer kann in den USA sein, und Englisch wird in vielen Ländern genutzt. Wenn du Flaggen nutzt, kombiniere sie mit Text („English“, „Español“), damit die Bedeutung eindeutig ist.
Sobald jemand zu Español wechselt, zwinge ihn nicht, das auf jeder Seite erneut zu tun.
Das ist wichtig, wenn du Nutzer über Ads, E‑Mail oder Social Links auf beide Sprachen leitest.
Automatische Redirects basierend auf Browser‑Sprache oder IP können nach hinten losgehen: Zweisprachige Nutzer, Reisende und VPN‑Nutzer bekommen oft die „falsche“ Sprache. Wenn du eine Sprache vorschlägst, gestalte das leichtgewichtig (ein wegklickbares Banner) und biete immer einen Ein‑Klick‑Weg zurück.
Zuletzt: mache den Umschalter zugänglich—er muss per Tastatur erreichbar, auf Mobil lesbar und klar beschriftet sein (z. B. „Language").
Wenn du nur den sichtbaren Seitentext übersetzt, können Suchmaschinen verwirrt sein, welche Version gerankt werden soll—insbesondere wenn Englisch‑ und Spanischseiten ähnlich aussehen. Ein paar SEO‑Basics helfen enorm, und sie sind meistens „einmal setzen, fortlaufend pflegen.“
Füge hreflang hinzu, damit Google versteht, welche englische Seite zu welcher spanischen Seite gehört (und die passende Version nach Sprache/Region ausliefert).
Mindestens sollte jedes Paar gegenseitig referenzieren:
/en/pricing sollte auf /es/precios verweisen/es/precios sollte zurück auf /en/pricing verweisenWenn du generische Sprachversionen hast (keine länderspezifischen), nutze en und es. Wenn du Länderzielgruppen hast, kannst du en-US, es-ES, es-MX etc. verwenden. Viele Sites fügen auch eine x-default‑Version hinzu (oft Englisch) für Nutzer ohne klaren Sprachmatch.
Canonical‑Tags verhindern Duplicate‑Content‑Probleme, sind aber auf mehrsprachigen Sites leicht falsch konfiguriert.
Faustregel: Jede Sprachseite sollte auf sich selbst kanonisch verweisen.
Vermeide es, spanische Seiten auf englische Canonicals zu verweisen „weil Englisch das Original ist“. Das signalisiert Google, dass die spanische Seite nicht die bevorzugte Version ist und kann die Sichtbarkeit der spanischen Seite schädigen.
Such‑Snippets und Social‑Previews werden oft von Metadaten getrieben, nicht von Seitenüberschriften.
Stelle sicher, dass du übersetzt und lokalisiert:
og:title, og:description) und Twitter‑Card‑FelderTipp: Halte den Markennamen konsistent, passe aber die Formulierungen an das, wonach spanischsprachige Nutzer tatsächlich suchen.
Hilf Suchmaschinen, jede Version zu entdecken:
/en/ als auch /es/ URLs in dieselbe Sitemap auf, oderStell in jedem Fall sicher, dass neue Seiten im Laufe der Zeit in beiden Sprachen auftauchen—fehlende oder veraltete spanische URLs sind ein häufiger Grund, warum mehrsprachige SEO unterperformt.
Textabsätze zu übersetzen ist der offensichtliche Teil. Die „Erfahrung“ ist alles drumherum—Navigation, Buttons, Fehler, Formatierung und sogar Assets. Wenn diese Bestandteile in einer Sprache bleiben, fühlt sich deine Seite unfertig an und Nutzer verlieren Vertrauen.
Beginne mit Navigationslabels, CTAs und wiederkehrenden Interface‑Elementen (Header, Footer, Cookie‑Banner, Suche, Account‑Menüs). Dann zu Systemmeldungen: Validierungsfehler, leere Zustände, Erfolgsmeldungen und „Laden“‑Texte.
Das ist besonders bei Formularen wichtig. Eine spanische Seite mit englischen Feldfehlern ("Please enter a valid email") zerstört Vertrauen und führt zu Abbrüchen. Achte darauf, dass Platzhalter, Hilfetexte und automatisierte E‑Mails (wie „Danke für deine Anfrage“) zur Seiten‑Sprache passen.
Screenshots, Banner, Infografiken und „Text im Bild“ verbergen oft unübersetzten Inhalt. Du hast zwei Optionen:
Wenn du ein Bild kurzfristig nicht neu machen kannst, vermeide es, wichtige Informationen (Preise, Fristen, Anleitungen) ins Bild zu packen.
Spanisch benötigt vollständige Zeichensatzunterstützung: Akzente (á, é, í, ó, ú), ñ sowie umgekehrte Satzzeichen (¿ ¡). Prüfe, ob deine Schriften diese sauber bei allen Größen rendern—besonders in Buttons und Menüs, wo enge Abstände Zeichen abschneiden können.
Wähle Formate passend zu deiner Zielgruppe und nutze sie konsistent. Beispiele:
Wenn diese Details übereinstimmen, wirkt deine Englisch/Spanisch‑Website wirklich bilingual—nicht nur übersetzt.
Eine zweisprachige Site bleibt „einfach“, wenn du sie ohne Chaos aktualisieren kannst. Das Ziel ist kein perfekter Prozess—sondern ein wiederholbarer Weg von neuem Text zur veröffentlichten Seite in beiden Sprachen.
Erstelle ein lebendes Glossar, das alle nutzen—Schreiber, Übersetzer und Reviewer. Enthalten sein sollten:
So vermeidest du das klassische Problem, dass derselbe Button als „Empezar“, „Comenzar“ und „Iniciar“ auftaucht.
Wähle eine Herangehensweise und dokumentiere sie, damit sie konsistent ist:
Eine einfache Regel: Alles, was Conversion oder Vertrauen beeinflusst, bekommt die meiste menschliche Aufmerksamkeit.
Vermeide „alle reviewen alles“. Nutze eine kleine Pipeline:
Draft → Review → Publish
Lege fest, wer absegnet:
Die meisten bilingualen Sites scheitern leise: Englisch wird aktualisiert, Spanisch nicht. Verhindere Drift, indem du festhältst, was sich geändert hat:
Wenn du das von Anfang an machst, verwandelt sich das Hinzufügen neuer Seiten später nicht in eine Panikaktion.
Es gibt drei übliche Wege, eine Englisch/Spanisch‑Site zu liefern: ein CMS, ein codebasiertes Build (oft ein Static Site Generator) oder ein Plugin über dem Bestehenden. Die „beste“ Wahl ist meist die, die Übersetzungen organisiert und Updates einfach macht.
Wenn du regelmäßig Inhalte veröffentlichst (Blogposts, Landingpages, Hilfebereiche), ist ein CMS mit Multi‑Locale‑Support oft der glatteste Weg. Achte auf Features wie per‑Language URLs, per‑Language SEO‑Felder (Title/Description) und einen sauberen Redaktionsworkflow.
Worauf zu achten ist: Ob das CMS nicht nur Seitentexte, sondern auch Navigationslabels, Buttons und wiederverwendbare Komponenten handhaben kann.
Wenn deine Seite hauptsächlich Marketingseiten sind und du Geschwindigkeit + Kontrolle willst, kann ein SSG oder Framework‑Setup gut funktionieren—vorausgesetzt, es hat erstklassigen i18n‑Support.
Wichtige Regel: Hard‑code keine englischen Strings in Templates. Zentralisiere Texte in Übersetzungsdateien (z. B. JSON/YAML), damit dieselbe Komponente in Spanisch gerendert werden kann, ohne Layouts zu duplizieren.
Plugins sind ein schneller Weg, Spanisch zu einer bestehenden Seite hinzuzufügen, besonders bei populären Site‑Buildern und CMS‑Plattformen. Sie helfen, wenn du schnell etwas brauchst.
Tradeoffs: Prüfe, ob das Plugin saubere URLs erzeugt, Übersetzungen manuell editierbar lässt (nicht nur maschinell) und SEO‑Basics (Metadaten, Sprachsignale) unterstützt.
Unabhängig vom Ansatz: Speicher Übersetzungen strukturiert:
Wenn du die Site baust (oder neu aufsetzt), hilft es oft, Routing, wiederverwendbare UI‑Strings und SEO‑Felder sprachbewusst zu scaffolden, bevor du übersetzt. Tools wie Koder.ai können diese Basis beschleunigen: Du beschreibst die gewünschte URL‑Struktur (z. B. /en/ und /es/), das Verhalten des Sprachumschalters und das Layout der i18n‑Dateien in einem chatgestützten Planungsfluss und iterierst dann schnell mit Snapshots/Rollbacks, während UX und SEO validiert werden.
Selbst wenn du jetzt nur Englisch und Spanisch brauchst, setze Konventionen, die skalieren: Locale‑Codes (en, es), wiederholbare URL‑Regeln und eine Single Source of Truth für gemeinsame UI‑Texte. So ist das Hinzufügen von Französisch später eine Erweiterung—kein Neubau.
Eine mehrsprachige Site ist nicht nur Homepage und Preis‑Seite. Sobald sich jemand anmeldet, ein Passwort vergisst oder eine Fehlermeldung erhält, ist er nicht mehr „am Browsen“—sondern versucht, ein Problem zu lösen. Wenn diese Touchpoints nur auf Englisch sind, brechen spanischsprachige Nutzer oft ab.
Beginne mit Materialien, die Support‑Tickets reduzieren und Kunden schnell weiterhelfen:
Wenn du bereits einen Hilfebereich hast, verlinke ihn von beiden Sprachen aus mit relativen Pfaden wie /help. Gleiches gilt für Kontakt unter /contact.
Formulare sind die Stelle, an der mehrsprachige Sites oft brechen. Es reicht nicht, „Name“ und „Email“ zu übersetzen. Lokalisieren musst du:
Teste dann die gesamte Journey in beiden Sprachen: Sende jedes Formular ab, löse typische Fehler aus und bestätige, was der Nutzer auf dem Bestätigungsbildschirm sieht.
Wenn du Kunden auf Spanisch supporten kannst, sag das deutlich und biete eine spanische Kontaktoption (spanisches Postfach, Chat‑Routing oder spanische Sprechzeiten). Wenn du es noch nicht kannst, verheimliche es nicht—setze Erwartungen auf /contact und in automatischen Antworten.
Ein einfacher Ansatz: Biete zuerst spanische Self‑Serve‑Inhalte an und ergänze menschlichen Support, wenn das Volumen wächst.
Eine zweisprachige Site kann „fertig“ aussehen und dennoch kleine Probleme haben, die Nutzer verwirren oder SEO schaden. Eine kurze Pre‑Launch‑Checkliste hilft, die Probleme zu fangen, die später teuer werden—besonders sobald Seiten indexiert sind.
Spanisch ist oft länger als Englisch, was an Stellen brechen kann, die du im Desktop‑Preview übersehen würdest.
Teste wenn möglich auf einem kleinen Smartphone und zumindest einer großen Desktop‑Breite.
Nutzer sollten nie „in die falsche Sprache fallen“, wenn sie herumklicken.
Prüfe auch Footer, Breadcrumbs und Module wie „verwandte Artikel“ oder „empfohlene Services".
Vor dem Launch bestätige, dass Suchmaschinen die Sprachbeziehung zwischen Seiten verstehen.
Praktische Prüfungen:
/sitemap.xml (oder sprachspezifische Sitemaps) enthält beide SprachenWenn du eine Staging‑Umgebung hast, stell sicher, dass sie vom Index ausgeschlossen ist, während Production indexierbar ist.
Automatische Übersetzung kann ein Anfang sein, aber ein menschlicher Durchgang verhindert Glaubwürdigkeitskiller.
Konzentriere dich auf Seiten mit hoher Sichtbarkeit: Homepage, Preise, Top‑Landingpages und Checkout/Contact‑Flows. Achte besonders auf rechtlich relevante Aussagen, Preisangaben, Daten und Formularhinweise.
Wenn du ein finales Sicherheitsnetz willst, mache einen „5‑Minuten‑Task‑Test": Bitte jemanden, eine wichtige Seite auf Spanisch zu finden, auf Englisch zu wechseln und ein Formular abzusenden—ohne Hilfe.
Eine zweisprachige Site muss nicht auf einmal launchen. Ein gestaffelter Rollout lässt dich schnell echtes Nutzerfeedback sammeln und hält die Arbeit überschaubar.
Beginne mit Seiten, die den meisten Wert bringen—typischerweise Homepage, Top‑Produkt‑/Service‑Seiten, Preise und Kontakt. Wenn dein Blog groß ist, übersetze zuerst die meistbesuchten Beiträge.
Ein praktischer Fahrplan:
Lass den Traffic die Reihenfolge bestimmen, nicht Vermutungen. Wenn spanische Besucher auf einer bestimmten Service‑Seite landen, schiebe diese Seite nach oben auf der Liste.
Richte Reporting so ein, dass du Englisch vs. Spanisch nebeneinander vergleichen kannst. Mindestens tracke:
Wenn Spanisch‑Traffic steigt, Conversions aber nicht, prüfe, ob die spanischen Seiten dieselben CTAs, Vertrauenssignale, Preistransparenz und Formularverhalten haben wie die englischen Seiten.
Nach dem Launch nutze die Google Search Console, um zu achten auf:
Frühes Erkennen verhindert Wochen der Verwirrung „Warum rankt Spanisch nicht?".
Der schnellste Weg, Vertrauen zu verlieren, ist, wenn englische Seiten aktuell sind und spanische veraltet wirken.
Erstelle einen einfachen Wartungsplan:
Eine kleine Gewohnheit—z. B. eine geteilte „Translation Update“‑Checkliste—verhindert, dass deine Englisch/Spanisch‑Website langsam aus dem Takt gerät.
Auch gut gemeinte mehrsprachige Websites können Nutzer frustrieren (und Google verwirren), wenn ein paar Details fehlen. Hier die häufigsten Probleme auf Englisch/Spanisch‑Sites und wie du sie schnell behebst.
Fehler: Du erkennst den Standort eines Nutzers und leitest ihn sofort zu /es oder /en—ohne Weg zurück. Reisende, zweisprachige Nutzer, VPN‑Nutzer und Leute, die in einer anderen Sprache recherchieren, bleiben hängen.
Schnelle Lösung: Behandle Geolocation als Vorschlag, nicht als erzwungenen Redirect.
Fehler: Flaggen stehen statt Spracheindikatoren (Spanisch wird in vielen Ländern gesprochen; Englisch auch). Eine alleinstehende Flagge ist außerdem nicht zugänglich für Screenreader.
Schnelle Lösung: Nutze Textlabels: English / Español (optional mit Flaggen als Dekoration).
Fehler: Der Fließtext ist übersetzt, aber Title‑Tags, Meta‑Descriptions, URL‑Struktur, Formularvalidierungen, 404‑Seiten und E‑Mail‑Bestätigungen bleiben in der Originalsprache.
Schnelle Lösung: Erstelle eine Checkliste für „alles, was spricht“. Füge hinzu:
Fehler: Englisch‑ und Spanischseiten sind publiziert, aber Suchmaschinen können nicht zuverlässig erkennen, dass sie Alternativen sind. Das kann dazu führen, dass die falsche Sprache rankt oder Seiten als Duplikate gesehen werden.
Schnelle Lösung: Implementiere hreflang zwischen den Sprachversionen und setze Canonical korrekt (in der Regel selbstreferenzierend auf jeder Sprachseite).
x-default hinzu, wo es Sinn macht (z. B. eine Sprachwahlseite).Diese Fixes erfordern selten einen kompletten Neubau—vielmehr eine klarere Struktur und einen vollständigeren Übersetzungsprozess.
Übersetze, wenn es klare Nachfragesignale gibt, z. B.:
Wenn du unsicher bist, starte mit einer kleinen „Version 1“ (Startseite + Preise/Kontakt) und messe Conversion- und Support-Effekte, bevor du alles übersetzt.
„Übersetzt“ bedeutet oft, dass nur der Fließtext konvertiert wurde. „Mehrsprachig“ heißt, die gesamte Erfahrung funktioniert in beiden Sprachen, einschließlich:
Wenn Nutzer weiterhin englische UI oder Formulare sehen, wirkt die Seite unfertig und das Vertrauen sinkt.
Eine starke V1 konzentriert sich zuerst auf Umsatz und Support:
/contact, /demo, Bestimme Verantwortlichkeiten und eine einfache SLA, bevor du übersetzt:
Stelle dann eine Regel auf wie: „Wenn Englisch sich ändert, wird Spanisch innerhalb von 3–5 Arbeitstagen aktualisiert.“ Das verhindert, dass sich die Sprachen auseinanderentwickeln.
Für die meisten Seiten sind Subfolders die beste Wahl:
/ oder /en//es/Subfolders bündeln SEO‑Signale auf einer Domain, vereinfachen CMS/Deployments und machen die Segmentierung in Analytics (z. B. Pfade, die mit /es/ beginnen) leichter. Subdomains und separate Domains funktionieren auch, verursachen aber mehr Aufwand.
Beide Ansätze sind möglich – wähle einen und bleib dabei:
/es/precios, /es/contacto/es/pricing, /es/contactKonsistenz ist wichtiger als die konkrete Entscheidung. Ein Mischmasch erschwert Navigation, Reporting und Wartung.
Mach den Umschalter sichtbar und vorhersehbar:
Vermeide erzwungene Redirects per IP/Browser; zeige stattdessen ein wegklickbares Vorschlagsbanner und ermögliche immer einen Klick zurück.
Implementiere die Grundlagen, damit Suchmaschinen Sprachäquivalente verstehen:
Lokalisieren geht über Fließtext hinaus – sorge dafür, dass alles, worauf Nutzer klicken oder was sie brauchen, angepasst ist:
Prüfe außerdem Bilder mit Text (Screenshots/Banner). Ersetze sie durch lokalisierte Assets oder verschiebe den Text in echtes HTML.
Führe vor dem Indexieren eine kurze Checkliste durch, um teure Nachbesserungen zu vermeiden:
Mache einen End‑to‑End‑Test: Sprache wechseln, Formulare absenden, typische Fehler auslösen und bestätigen, dass Bestätigungen und E‑Mails zur Seite passen.
/signupNice-to-haves (alte Blogarchive, ältere Presseartikel) kommen später, sobald das Kernangebot konsistent ist.
/en/‑ als auch /es/‑URLs auf (in einer Sitemap oder in separaten)Das sind meist „einmal setzen, fortlaufend pflegen“-Aufgaben.