WordPress zweisprachig machen – Polylang DE/EN Schritt-für-Schritt Anleitung

Deine Website spricht nur Deutsch. Deine Besucher vielleicht nicht.

Das ist kein Problem – es ist ein lösbares Problem. Mit Polylang, einem kostenlosen WordPress-Plugin, bekommt deine Seite eine zweite Sprache. Kein teures Upgrade, keine Agentur, kein Neustart. Nur ein Plugin, ein paar Einstellungen – und am Ende ein kleiner DE | EN Schalter im Header, der die aktive Sprache fett und in deiner Akzentfarbe hervorhebt.

Dieser Guide dokumentiert die Live-Einrichtung auf foundic.org im März 2026 – mit allem, was dabei schiefgegangen ist, wie es repariert wurde, und was du daraus nicht selbst lernen musst.

Um diese Anleitung verständlicher zu machen, begleiten dich drei Personen:
Die typischen Büro-Charaktere: Die kompetente IT-Kollegin, der selbsternannte Experte und der ehrliche Anfänger. Diese drei Perspektiven helfen dir, typische Stolperfallen zu erkennen.
Tanja ist die IT-Expertin. Sie weiß, wie es funktioniert, erklärt geduldig und strukturiert – und lässt sich von schlechten Ratschlägen nicht aus der Ruhe bringen. Wenn du eine Frage hast, hat Tanja die Antwort.
Bernd ist der selbsternannte „Experte“, der alles besser weiß – und meistens falsch liegt. Seine Abkürzungen und sein Halbwissen führen regelmäßig zu Problemen. Er steht für alle gefährlichen Mythen und schlechten Praktiken, die du vermeiden solltest.
Ulf ist der Lernende, genau wie du. Er stellt die Fragen, die dir im Kopf herumschwirren, und braucht manchmal einen Vergleich aus dem Alltag, um IT zu verstehen. Wenn Ulf etwas nicht versteht, ist das völlig in Ordnung, dafür ist Tanja da. 

„Und… Action!“

Es ist Montagmorgen. Bernd steht am Whiteboard. Auf dem Board steht in großen Buchstaben: „ZWEISPRACHIG – easy peasy.“

Bernd: „Ich hab das am Wochenende einfach gemacht. Zwei Sprachen, zehn Minuten, fertig. Was soll da groß schiefgehen?“
Ulf: „Und? Hat’s geklappt?“
Bernd: „Naja… die Seite war kurz offline. Aber das war der Server.“
Tanja: „Das war nicht der Server, Bernd. Das war functions.php. Aber fangen wir von vorne an.“

Welchen Weg nimmst du?

Aufbau dieses Guides: Teil 1–3 beschreiben die universelle Polylang-Standardeinrichtung – das funktioniert auf jeder WordPress-Installation. Ab Teil 4 folgt eine projektspezifische Lösung für das Astra-Free-Theme. Wähle vorab, welche Variante zu deinem Setup passt:

Variante	Für wen	Aufwand
A – Standard (Teil 1–3)	Alle WordPress-Setups; Switcher erscheint im Menü rechts	Gering, wartungsarm
B – Astra Free zentriert (Teil 1–4)	Astra Free, DE|EN dauerhaft sichtbar und zentriert	Mittel, manueller HTML-Block
C – Entwicklerlösung	Dynamischer Switcher per Theme-Hook oder Shortcode	Hoch, kein statischer HTML-Block

Empfehlung: Für die meisten Leser ist Variante A der richtige Einstieg, wartungsarm, dynamisch, funktioniert auf jedem Theme. Variante B ist sinnvoll, wenn du Astra Free verwendest und DE|EN dauerhaft sichtbar im Header-Zentrum haben möchtest. Variante C empfiehlt sich für produktive Sites mit Entwicklerzugriff und langfristiger Wartung.
Dieser Guide dokumentiert Variante B vollständig. Variante A ist nach Teil 3 abgeschlossen. Variante C wird am Ende kurz skizziert.

Ausgangssituation

Stell dir vor, deine Website ist ein gut eingerichtetes Büro – alles auf Deutsch beschriftet, alle Ordner, alle Schilder, alle Dokumente. Jetzt kommen internationale Gäste, und du möchtest, dass sie sich genauso gut zurechtfinden wie die deutschen Besucher.

Genau das macht Polylang: Es gibt deiner Website eine zweite Etage – auf Englisch. Gleiche Struktur, gleiche Navigation, aber alles übersetzt. Und ein kleiner Aufzugsknopf im Header – DE | EN – bringt Besucher in die richtige Etage.

In diesem Guide arbeiten wir mit foundic.org als Beispiel. Die Seite läuft auf WordPress 6.9.4 mit dem Astra-Theme und ist bisher komplett auf Deutsch. 53 Beiträge, 4 Seiten – und kein einziges englisches Wort in der Navigation.

Das ändert sich jetzt.

Was du am Ende haben wirst

• Einen funktionierenden DE | EN Sprachumschalter im Header
• Getrennte Navigationsmenüs für Deutsch und Englisch
• Korrekte URL-Struktur: foundic.org/ für Deutsch, foundic.org/en/ für Englisch
• Automatische Browsersprache-Erkennung für neue Besucher
• Ein solides Fundament, auf dem du Schritt für Schritt englische Inhalte ergänzen kannst

Voraussetzungen

Bevor es losgeht: Hast du das alles?

• WordPress-Installation mit Admin-Zugang
• Ein Theme, das Menüpositionen unterstützt (z.B. Astra)
• Zugriff auf den WordPress Customizer
• Optional, aber dringend empfohlen: Ein Hosting-Backup – dazu mehr im Fehlerbehebungs-Kapitel

Ulf: „Backup? Wofür? Ich mach das einfach rückgängig wenn was schiefgeht.“
Tanja: „Ulf, WordPress hat keinen Rückgängig-Knopf für kaputte PHP-Dateien.“
Bernd: „Ich brauch keine Backups. Ich mach keine Fehler.“
Tanja: „Bernd, du hast letzten Monat die halbe Datenbank überschrieben.“
Bernd: „Das war ein Experiment.“

Mach das Backup. Es dauert zwei Minuten und rettet dich möglicherweise vor einer sehr unschönen Stunde.

Teil 1: Polylang installieren

Ulf: „Polylang – klingt nach nem Fußballverein aus Polen.“
Tanja: „Es ist das meistgenutzte Mehrsprachigkeits-Plugin für WordPress. 800.000 aktive Installationen, 4,5 Sterne. Kostenlos.“
Bernd: „Ich hätte einfach die Texte auf der Seite manuell auf Englisch geändert. Viel simpler.“
Tanja: „Dann hättest du keine deutschen Texte mehr.“
Bernd: „Stimmt. Schlechte Idee.“

Polylang ist wie ein Dolmetscher, der dauerhaft im Hintergrund sitzt. Du schreibst deine Inhalte einmal auf Deutsch, einmal auf Englisch – und Polylang sorgt dafür, dass der richtige Besucher die richtige Version sieht. Es verwaltet separate URLs, getrennte Menüs und die SEO-Tags, die Google braucht, um die Versionen auseinanderzuhalten.

So installierst du es:
Im WordPress-Backend: Plugins → Plugin hinzufügen → Suchfeld: „polylang“
Polylang erscheint als erstes Ergebnis. Auf „Jetzt installieren“ klicken, danach auf „Aktivieren“.

Nach dem Klick auf „Aktivieren“ startet Polylang automatisch den Einrichtungsassistenten. Nicht wegklicken – der führt dich durch die ersten wichtigen Einstellungen.

Teil 2: Einrichtungsassistent durchlaufen

Der Assistent führt durch vier Schritte: Sprachen → Medien → Inhalt → Bereit!
Stell dir das vor wie das Ausfüllen eines Einstellungsformulars beim neuen Job – vier Seiten, und dann kannst du loslegen. Die Fragen sind einfacher als bei der Steuer.

Schritt 1: Sprachen hinzufügen

Im Dropdown zuerst „de_DE – Deutsch“ auswählen, auf „+ Neue Sprache hinzufügen“ klicken. Dann „en_US – English“ auswählen, wieder auf „+ Neue Sprache hinzufügen“ klicken. Beide Sprachen erscheinen in der Liste. Auf „Fortfahren“ klicken.

Ulf: „Warum de_DE und nicht einfach nur Deutsch?“
Tanja: „Weil es verschiedene Varianten gibt – Deutsch aus Deutschland, aus Österreich, aus der Schweiz. Das Kürzel sagt dem System genau, welches gemeint ist. So wie beim Fußball: FC Bayern ist nicht dasselbe wie FC Bayern Amateure.“
Ulf: „Ah. Okay. Das ergibt Sinn.“

Schritt 2: Medien-Einstellungen

Polylang fragt, ob Bilder und Dateien ebenfalls übersetzt werden sollen. Klingt nett, ist aber für die meisten Websites unnötig.

Toggle deaktiviert lassen. Auf „Fortfahren“ klicken.

Was bedeutet das konkret? Deine Bilder bleiben wie sie sind – ein Bild in der Mediathek, das in beiden Sprachversionen verwendet wird. Du müsstest nur dann aktivieren, wenn du für EN andere Bilder mit englischem Text einblenden möchtest.

Schritt 3: Bestehende Inhalte als Deutsch markieren

Polylang entdeckt jetzt, dass du bereits 53 Beiträge und 4 Seiten hast – und keiner davon ist bisher einer Sprache zugeordnet. Das ist wie ein Büro voller unbeschrifteter Ordner: Es gibt sie, aber niemand weiß, in welche Abteilung sie gehören.

„Deutsch – de_DE“ auswählen (bereits vorausgewählt) und auf „Fortfahren“ klicken. Polylang weist allen bestehenden Beiträgen und Seiten automatisch Deutsch zu – die Grundlage dafür, dass du später englische Übersetzungen anlegen und mit den deutschen Originalen verknüpfen kannst.

Bernd: „Kann ich da auch einfach alle auf Englisch setzen? Dann muss ich nichts übersetzen.“
Tanja: „Dann würden deine deutschen Artikel als englische Inhalte geführt. Google würde das bemerken und du bekommst SEO-Probleme.“
Bernd: „Ach so.“
Tanja: „Immer Deutsch. Du kannst danach englische Versionen anlegen.“

Schritt 4: Assistent abschließen

Der Assistent ist fertig. Polylang zeigt eine Bestätigungsseite und schlägt die nächsten Schritte vor.

Polylang ist jetzt aktiv. Was noch fehlt: Der Sprachumschalter, den Besucher tatsächlich sehen und klicken können. Den bauen wir in Teil 3.

Teil 3: Sprachumschalter im Menü einrichten

Jetzt wird es sichtbar. Bis hier hat Polylang still im Hintergrund gearbeitet. Jetzt bekommt deine Website ihren ersten öffentlichen Hinweis: „Hey, hier gibt’s zwei Sprachen.“
Der Sprachumschalter ist wie das Schildchen neben dem Aufzugsknopf. Klein, unscheinbar – aber ohne ihn findet niemand in die zweite Etage.

Schritt 5: Menü-Editor öffnen

Im Backend: Design → Menüs
Der Menü-Editor öffnet sich. Links sieht man jetzt einen neuen Block „Sprachumschalter“ – den hat Polylang automatisch hinzugefügt.

Schritt 6: Sprachumschalter zum Menü hinzufügen

Links unter „Sprachumschalter“ das Häkchen bei „Sprachen“ setzen und auf „Zum Menü hinzufügen“ klicken.
Im Menü erscheint ein neuer Eintrag „Sprachen“ als letzter Punkt.

Schritt 7: Sprachumschalter konfigurieren

Den Eintrag „Sprachen“ aufklappen (Pfeil rechts klicken). Polylang zeigt dir mehrere Einstellungsoptionen. Lass sie alle deaktiviert:

Option	Einstellung	Begründung
Als Auswahlbox darstellen	☐ aus	Links statt Dropdown
Darstellung der Sprach-Namen	☐ aus	Kein „Deutsch“/„English“ – Kürzel reicht
Flaggen anzeigen	☐ aus	Keine Flaggen, nur Text
Erzwingt einen Link zur Startseite	☐ aus	Switcher soll auf den gleichen Artikel zeigen
Versteckt die aktuelle Sprache	☐ aus	Beide Sprachen immer sichtbar
Sprachen ohne Übersetzung ausblenden	☐ aus	Verhindert zusätzliches Ausblenden verfügbarer Sprachoptionen

Ulf: „Warum keine Flaggen? Flaggen sind doch cool. Beim Stadion gibt’s auch Flaggen.“
Tanja: „Weil Flaggen für Länder stehen, nicht für Sprachen. Englisch ist nicht nur UK. Österreicher sprechen Deutsch und mögen vielleicht kein deutsches Flaggchen.“
Bernd: „Ich hätte einfach Flaggen genommen und geschaut, ob sich jemand beschwert.“
Tanja: „Das ist kein Ansatz, Bernd.“

Auf „Menü speichern“ klicken.

Wichtig: WordPress bestätigt mit „Hauptmenü wurde aktualisiert.“ im grünen Banner oben auf der Seite.

Schritt 8: CSS für den Sprachumschalter einrichten

Jetzt kommt die Kosmetik. Polylang zeigt den Sprachumschalter standardmäßig mit dem vollen Sprachnamen – „Deutsch“ und „English“. Das ist zu lang und zu unelegant. Wir wollen: DE | EN. Kompakt, klar, modern.

Das geht über CSS – die Gestaltungssprache des Webs. Keine Angst: Du musst hier nichts erfinden. Kopiere einfach den fertigen Code.

Im Backend: Design → Customizer → Zusätzliches CSS

Der Customizer öffnet sich mit dem CSS-Editor links und einer Live-Vorschau rechts. Folgenden Code ans Ende des bestehenden CSS anfügen:

/* ===== Sprachumschalter DE | EN ===== */

/* Originaltext ausblenden */
.lang-item a {
    font-size: 0 !important;
    color: #666;
    text-decoration: none;
    padding: 0 3px;
}

/* Sprachkürzel per Pseudo-Element einblenden */
.lang-item.lang-item-de a::after { content: "DE"; font-size: 13px; }
.lang-item.lang-item-en a::after { content: "EN"; font-size: 13px; }

/* Trennstrich | zwischen den Sprachen */
.lang-item + .lang-item::before {
    content: "|";
    color: #ccc;
    font-size: 13px;
    margin-right: 2px;
}

/* Aktive Sprache: fett + Akzentfarbe */
.lang-item.current-lang a::after {
    font-weight: bold;
    color: #e8691e;
}

Was macht das genau? Der Code blendet zunächst den Originaltext komplett aus (font-size: 0) und blendet dann per ::after die Kürzel „DE“ und „EN“ wieder ein. Der aktiven Sprache gibt er fette Schrift und die Akzentfarbe. Der senkrechte Strich | erscheint automatisch zwischen den beiden Einträgen – kein extra HTML nötig.

Auf „Veröffentlichen“ klicken.

Farbe anpassen: #e8691e ist die Akzentfarbe von foundic.org. Ersetze diesen Wert durch den Hex-Code deiner Website-Farbe. Den findest du meistens in den Theme-Einstellungen unter „Primärfarbe“.

Schritt 9: Ergebnis im Frontend prüfen

Website aufrufen: https://deine-domain.de

Im Header ist jetzt der Sprachumschalter sichtbar – DE erscheint rechts im Menü, in Orange und fett. EN ist noch grau und inaktiv, weil noch keine englischen Inhalte vorhanden sind.

Das ist der erste funktionierende Zwischenstand. Variante-A-Nutzer sind hier fertig – herzlichen Glückwunsch. In Teil 4 gehen wir für Variante B weiter: Der Umschalter wandert in die Mitte des Headers, und EN ist dauerhaft sichtbar.

Bis hierhin: Standard-Polylang-Einrichtung abgeschlossen.
Was du jetzt hast: einen funktionierenden Sprachumschalter im Menü (rechts in der Navigation), der EN automatisch einblendet, sobald eine englische Übersetzung für die aktuelle Seite vorhanden ist. Das ist der offizielle Polylang-Weg – und für viele Websites ausreichend.

Wann reicht das?

• Du willst nur einen funktionierenden Sprachumschalter: → fertig, Teil 4 überspringen
• Du willst EN immer sichtbar, auch ohne Übersetzungen: → Teil 4 nötig
• Du willst den Umschalter exakt in der Header-Mitte bei Astra Free: → Teil 4 nötig
  Die folgenden Schritte sind projektspezifisch für das Ziel: DE | EN dauerhaft sichtbar und zentriert im Astra-Free-Header.

Teil 4: Sprachumschalter dauerhaft sichtbar und zentriert (Astra Free)

Variante B löst ein konkretes Layout-Problem elegant: DE | EN ist dauerhaft im Header sichtbar – unabhängig davon, ob für die aktuelle Seite schon eine Übersetzung existiert. Das gibt der Website von Anfang an ein zweisprachiges Erscheinungsbild, auch wenn die Inhalte noch im Aufbau sind.

Für wen passt Variante B am besten? Für Corporate- oder Marken-Websites, bei denen das visuelle Erscheinungsbild Priorität hat und der Sprachumschalter von Tag 1 sichtbar sein soll. Für redaktionelle Websites mit vielen Artikeln, bei denen Leser per Klick direkt zur übersetzten Version des aktuellen Artikels gelangen sollen, ist Variante A oder C die robustere Wahl.

Bernd betritt den Raum mit einem frischen Kaffee und dem Gesicht eines Mannes, der gerade eine Idee gehabt hat.

Bernd: „Ich würde jetzt einfach das Menü umbauen. Drag and Drop. Fünf Minuten.“
Tanja: „Astra Free hat kein freies Drag-and-Drop im Header Builder. Die Mittelspalte existiert zwar, ist aber standardmäßig null Pixel breit.“
Ulf: „Null Pixel? Das ist wie eine Auswechselbank ohne Spieler.“
Tanja: „Genau. Wir bauen die Bank trotzdem auf – per CSS.“

Problem 1: EN-Link fehlt im Sprachumschalter

Im Menü erscheint zunächst nur „Deutsch“ – der EN-Link fehlt komplett.

Das ist kein Fehler, sondern korrektes Polylang-Verhalten. Polylang zeigt eine Sprache im Switcher nur an, wenn für die aktuell angezeigte Seite eine Übersetzung in dieser Sprache existiert. Da bisher noch keine englischen Inhalte angelegt wurden, bleibt EN unsichtbar.

Die Lösung: Den Polylang-Menü-Switcher durch ein eigenes HTML-Widget im Astra Header Builder ersetzen, das DE und EN immer zeigt – unabhängig davon, ob Übersetzungen vorhanden sind.

Abwägung: Polylang-Switcher vs. eigenes HTML-Widget

Variante	Vorteil	Nachteil
Polylang-Menü-Switcher	Dynamisch, wartungsarm, funktioniert automatisch	Blendet EN aus, wenn keine Übersetzung vorhanden
Eigenes HTML im Header	DE|EN immer sichtbar, volle Kontrolle	Links sind fest eingetragen – bei Domainwechsel, Staging oder Subdirectory-Installation müssen sie manuell angepasst werden

Wir entscheiden uns hier für das HTML-Widget, weil DE|EN dauerhaft sichtbar sein soll. Denk daran: Bei einem Domainwechsel oder beim Einrichten einer Staging-Umgebung musst du die Links im Widget manuell aktualisieren.

Problem 2: Sprachumschalter soll in der Header-Mitte stehen

Der Polylang-Menüeintrag erscheint ganz rechts in der Navigation. Gewünscht ist eine Platzierung in der Mitte des Headers – zwischen Logo links und Menü rechts.

Stell dir den Header vor wie ein Fußballfeld: Links steht der Torwart (Logo), rechts stürmt die Mannschaft (Menü). Der Sprachumschalter soll der Libero in der Mitte sein – immer präsent, elegant positioniert.

Da Astra Free keine freie Positionierung im Header Builder erlaubt, greifen wir zu einem CSS-Trick: position: absolute. Das klingt gefährlicher als es ist.

Schritt 10: Astra Header Builder öffnen

Im Backend: Design → Customizer → Header → Header Builder

Der Header Builder zeigt den visuellen Aufbau mit drei Zonen: Links (Logo), Mitte (leer), Rechts (Primäres Menü).

Hinweis bei Astra Free: Das HTML-2-Widget kann nur in die linke Zone gezogen werden – die Mittelzone ist in der kostenlosen Version gesperrt. Die visuelle Zentrierung erreichen wir über CSS.

Schritt 11: HTML 2 Widget einfügen

Im Header Builder das „HTML 2″-Element aus dem Bereich „Verfügbare Widgets“ in den Header ziehen (linke Zone). Durch Klick auf das Widget öffnet sich ein WYSIWYG-Editor – ein einfaches Textfeld mit Formatierungsknöpfen.

Schritt 12: Sprachumschalter-HTML einfügen

Im Editor folgenden Code eingeben:

<nav class="pll-switcher-center">
  <a href="https://www.deine-domain.de/" class="pll-link-de" hreflang="de">DE</a>
  <span class="pll-sep">|</span>
  <a href="https://www.deine-domain.de/en/" class="pll-link-en" hreflang="en">EN</a>
</nav>

URLs anpassen: Ersetze deine-domain.de durch deine echte Domain.

Technische Besonderheit: Der WYSIWYG-Editor fügt nach jedem Element automatisch <br>-Tags ein. Das sieht zunächst seltsam aus – ist aber kein Problem. Das CSS im nächsten Schritt unterdrückt diese Zeilenumbrüche wieder.

Wichtig – Verhalten auf Unterseiten: Dieser HTML-Switcher ist ein statisches Widget. Die Links zeigen immer auf die Startseiten (/ bzw. /en/) – unabhängig davon, auf welchem Artikel der Besucher gerade ist. Das bedeutet: Wer auf einem deutschen Artikel auf EN klickt, landet zunächst auf der englischen Startseite, nicht auf der englischen Übersetzung des Artikels.

Für die Startseite und einfache Navigationszwecke ist das ausreichend. Wer artikelgenaues Umschalten benötigt (Klick auf EN → direkt zur englischen Version des gleichen Artikels), sollte stattdessen den nativen Polylang-Menü-Switcher verwenden (Variante A) oder eine dynamische Lösung per Theme-Hook einsetzen (Variante C). Der native Polylang-Switcher ist wartungsärmer und löst diesen Fall automatisch.

Auf „Veröffentlichen“ klicken.

Schritt 13: CSS vollständig überarbeiten

Jetzt kommt der entscheidende Schritt: Das CSS aus Schritt 13 muss vollständig ersetzt werden. Das bisherige CSS hat den Polylang-Switcher im Menü gestylt – der ist jetzt nicht mehr zuständig. Das neue CSS stylt das HTML-Widget und positioniert es in der Mitte des Headers.

Im Backend: Design → Customizer → Zusätzliches CSS

Das bisherige CSS für .lang-item vollständig durch folgenden Code ersetzen:

/* ===== Sprachumschalter DE | EN (zentriert) ===== */

/* DE|EN als flex-Zeile, br-Tags unterdrücken */
.pll-switcher-center {
    display: flex !important;
    flex-direction: row !important;
    align-items: center;
    gap: 6px;
    margin: 0; padding: 0;
}
.pll-switcher-center br { display: none !important; }

/* Sprachlinks */
.pll-switcher-center a,
.pll-switcher-center .pll-sep {
    font-size: 13px;
    font-weight: normal;
    color: #888;
    text-decoration: none;
    line-height: 1;
}

/* Aktive Sprache fett + orange */
html[lang="de-DE"] .pll-link-de,
html[lang="de"] .pll-link-de { font-weight: bold; color: #e8691e !important; }
html[lang="en-US"] .pll-link-en,
html[lang="en"] .pll-link-en { font-weight: bold; color: #e8691e !important; }

/* HTML 2 Widget absolut zentriert im Header */
.ast-header-html-2 {
    position: absolute !important;
    left: 50% !important;
    top: 50% !important;
    transform: translate(-50%, -50%) !important;
    z-index: 5;
    white-space: nowrap;
}
.site-primary-header-wrap { position: relative !important; }

/* Polylang-Menüeintrag ausblenden (ersetzt durch HTML 2) */
.lang-item { display: none !important; }

Was diese CSS-Regeln bewirken – im Klartext:

• .pll-switcher-center { display: flex } – verhindert, dass die br-Tags DE und EN untereinander stapeln. Flex macht aus einer vertikalen Stapel eine horizontale Zeile.
• html[lang="de-DE"] .pll-link-de – erkennt die aktive Sprache anhand des lang-Attributs, das WordPress automatisch in den <html>-Tag schreibt. Kein JavaScript nötig.
• .ast-header-html-2 { position: absolute } – entnimmt das Widget seinem normalen Platz in der linken Zone und positioniert es exakt in der horizontalen und vertikalen Mitte des Headers. translate(-50%, -50%) korrigiert den Versatz durch den eigenen Elementabstand.
• .lang-item { display: none } – blendet den alten Polylang-Menüeintrag aus, der sonst noch „Deutsch“ im rechten Menü anzeigen würde.

Bernd: „Position absolute? Das ist doch Hacks. Richtige Entwickler machen das nicht so.“
Tanja: „Richtige Entwickler nehmen die Lösung, die funktioniert. Bei Astra Free ist das die einzige Option ohne kostenpflichtiges Upgrade.“
Ulf: „Ist das wie wenn der Trainer taktisch improvisiert, weil der Mittelstürmer verletzt ist?“
Tanja: „Perfekter Vergleich.“

Auf „Veröffentlichen“ klicken.

Schritt 14: Ergebnis prüfen

Website aufrufen. Im Header sind jetzt drei Bereiche sichtbar:

• Links: Logo
• Mitte: DE | EN (zentriert)
• Rechts: Hauptnavigation

Das ist Variante B – dauerhaft sichtbar, sauber zentriert, optisch klar.

Responsive prüfen – vollständige Lösung: Die absolute Positionierung funktioniert auf Desktop sehr gut, kann aber auf schmalen Viewports zu Überlappungen mit Logo oder Menü führen. Die empfohlene Lösung für Mobile:

Desktop: HTML-Widget zentriert im Header (wie eingerichtet)
Mobile: HTML-Widget ausblenden, nativen Polylang-Switcher im Off-Canvas-Menü verwenden

Dazu den Polylang-Menü-Switcher im Hauptmenü nicht entfernen, sondern nur auf Desktop ausblenden. CSS anpassen:

/* Desktop: Polylang-Menüeintrag ausblenden, HTML-Widget sichtbar */
.lang-item { display: none !important; }

/* Mobile: HTML-Widget ausblenden, Polylang-Menüeintrag wieder sichtbar */
@media (max-width: 768px) {
    .ast-header-html-2 { display: none !important; }
    /* Theme-Standarddarstellung des Menüeintrags wiederherstellen –
       je nach Theme kann hier list-item, block oder inherit passender sein */
    .lang-item { display: list-item !important; }
}

So hat der Nutzer auf jedem Gerät einen funktionierenden Sprachumschalter – auf Desktop zentriert und immer sichtbar, auf Mobile im Burger-Menü integriert. Die konkrete display-Eigenschaft kann je nach Theme-Menüstruktur variieren; im Zweifel mit den Browser-Entwicklertools prüfen, welcher Wert der Theme-Standard ist.

Teil 5: Englisches Menü einrichten

Der Sprachumschalter ist da. Aber wenn jemand auf EN klickt und zur englischen Startseite wechselt, sieht er noch immer „KI-News“, „Themen“, „Projekte“, „Schulungen“. Das ist wie ein internationales Hotel, das englische Gäste empfängt – und ihnen dann die Speisekarte auf Deutsch gibt.

Das ändern wir jetzt.

Ulf: „Warte, muss ich jetzt alle meine Artikel auf Englisch schreiben?“
Tanja: „Nein. Erst kommt die technische Struktur – Kategorien, Menüs. Die Artikel kommen danach Schritt für Schritt.“
Bernd: „Ich würde Google Translate drüber laufen lassen. Fertig.“
Tanja: „Bernd, das hat Stiftung Warentest schon für Websites gemacht. Das Ergebnis war erschreckend.“

Schritt 15: Kategorien übersetzen

Im Backend: Beiträge → Kategorien
Polylang hat jetzt neben jeder Kategorie ein kleines Flaggen-Symbol hinzugefügt. Für jede Kategorie die englische Übersetzung anlegen:

Deutsch	Englisch
KI-News	AI News
Themen	Topics
Projekte	Projects
Schulungen	Training

Auf das 🇺🇸-Symbol neben einer Kategorie klicken → Editor öffnet sich → englischen Namen eingeben → speichern.

Schritt 16: Permalinks neu speichern

Das ist einer der Schritte, die aussehen als würden sie nichts tun – und trotzdem unverzichtbar sind.

Wichtig: Nach der Kategorien-Übersetzung müssen die Permalinks neu gespeichert werden, damit Polylang die Rewrite-Regeln für /en/ korrekt registriert.

Im Backend: Einstellungen → Permalinks → „Änderungen speichern“ klicken.

Kein Wert muss geändert werden – der Klick alleine reicht. Was passiert im Hintergrund? WordPress schreibt die URL-Muster neu – jetzt weiß der Server, dass Anfragen auf /en/ zu Polylang weitergeleitet werden sollen und nicht als 404-Fehler enden.

Nach dem Speichern ist die englische Startseite unter deine-domain.de/en/ erreichbar. Der Inhalt ist zunächst leer – das ist normal, da noch keine englischen Beiträge vorhanden sind:

Schritt 17: Englisches Menü „Main Menu“ erstellen

Im Backend: Design → Menüs → Link „erstelle ein neues Menü“ klicken.

• Name: Main Menu
• Position im Theme: ☑ Primäres Menü English, ☑ Off-Canvas-Menü English
• Gleichzeitig diese Positionen beim deutschen Hauptmenü abhaken – sonst erscheint das englische Menü auch auf der deutschen Seite
  Auf „Menü erstellen“ klicken.

Schritt 23: Englische Kategorien zum Main Menu hinzufügen

Im Bereich „Menüeinträge hinzufügen“ → Kategorien → Tab „Alle anzeigen“.

Folgende vier englischen Kategorien anhaken:

• ☑ AI News
• ☑ Projects
• ☑ Topics
• ☑ Training

Auf „Zum Menü hinzufügen“ → „Menü speichern“ klicken.

Schritt 24: Ergebnis – beide Sprachen mit eigenen Menüs

Jetzt hat die Website zwei vollständig getrennte Navigationsbereiche.
Englische Seite (deine-domain.de/en/): DE | EN · AI News · Projects · Topics · Training

Sprache	URL	Menüpunkte
Deutsch	deine-domain.de/	KI-News · Themen · Projekte · Schulungen
Englisch	deine-domain.de/en/	AI News · Projects · Topics · Training

Teil 6: Browsersprache-Erkennung einrichten

Bisher muss der Besucher selbst auf DE oder EN klicken. Das ist okay. Aber noch besser wäre es, wenn die Website schon beim ersten Besuch automatisch die richtige Sprache zeigt – basierend auf der Browsersprache des Nutzers.

Ulf: „Wie weiß die Website, welche Sprache mein Browser hat?“
Tanja: „Jeder Browser schickt beim Seitenaufruf einen sogenannten Header mit – darin steht die bevorzugte Sprache. Polylang liest das aus und leitet entsprechend weiter.“
Bernd: „Ich hab das einfach über JavaScript gemacht. Hat nicht funktioniert.“
Tanja: „Weil du dann einen gecachten Redirect hattest. Das ist ein Klassiker.“

Schritt 18: Polylang-Einstellung aktivieren

Im Backend: Polylang → Einstellungen → Funktion „Browsersprache erkennen“ aktivieren.
Was passiert: Polylang liest beim ersten Besuch der Startseite den Accept-Language-Header des Browsers und leitet auf die passende Sprachversion weiter. Nur beim ersten Besuch – danach merkt sich ein Cookie die Wahl des Nutzers.

Schritt 19: WP Fastest Cache – Startseite ausschließen

Hier lauert eine unsichtbare Falle – Bernd ist direkt reingetappt.
Problem: WP Fastest Cache speichert die Startseite als statische HTML-Datei. Wird diese gecachte Datei direkt ausgeliefert, läuft kein PHP mehr. Die Polylang-Umleitung ist aber PHP-Code – sie wird also nie ausgeführt. Alle Besucher sehen immer die Standardsprache.
Lösung: Im Plugin WP Fastest Cache → Tab „Ausschließen“ eine Regel für die Startseite anlegen:

• Regel: „Homepage“ → „The homepage has been excluded“
  Anschließend alle Caches leeren: WP Fastest Cache → Alle Caches löschen.
  Gilt auch für andere Caching-Plugins: Jedes Caching-Plugin, das statische HTML-Dateien erzeugt, muss für die Startseite deaktiviert werden. Andernfalls funktioniert die Browsersprache-Erkennung nicht.

Schritt 20: Fallback für nicht-deutsche Sprachen (PHP-Snippet)

Noch ein Feinschliff: Polylang leitet standardmäßig nur dann weiter, wenn die Browser-Sprache exakt einer Website-Sprache entspricht. Ein Besucher mit französischem Browser würde daher auf Deutsch (= Standardsprache) landen – nicht auf Englisch.
Für die meisten internationalen Websites ist Englisch aber der sinnvolle Fallback für alle Nicht-DE-Sprachen. Dafür gibt es ein kleines PHP-Snippet.
Einrichtung über das Plugin „Code Snippets“ (sicherer als functions.php – dazu mehr in Teil 8):

1. Plugin installieren: Plugins → Plugin hinzufügen → „Code Snippets“ suchen und installieren
2. Im Backend: Snippets → Neu hinzufügen
3. Einstellungen:
   • Titel: Polylang: Nicht erkannte Browsersprachen auf Englisch umleiten
   • Typ: PHP
   • Location: Nur im Frontend ausführen
4. Folgenden Code einfügen:

add_filter( 'pll_preferred_language', 'foundic_language_fallback' );
function foundic_language_fallback( $slug ) {
    if ( false === $slug ) {
        return 'en';
    }
    return $slug;
}

5. Snippet aktivieren und speichern

Was macht dieser Code? Polylang übergibt der Filterfunktion die erkannte Browsersprache. Wenn keine passende Sprache gefunden wurde, liefert Polylang false. Das Snippet fängt genau diesen Fall ab und gibt stattdessen 'en' zurück – Englisch also.
Ergebnis:

Browser-Sprache	Verhalten
de, de-DE, de-AT	→ Startseite Deutsch ✅
en, en-US, en-GB	→ Startseite Englisch ✅
fr, es, it, zh, …	→ Startseite Englisch (Fallback) ✅

Hinweis: Gilt nur für Erstbesucher ohne gesetztes pll_language-Cookie. Rückkehrer behalten ihre zuletzt gewählte Sprache. Eingeloggte Admins werden nie umgeleitet.

Das solltest du bedenken: Der Fallback auf Englisch für alle Nicht-DE-Sprachen ist eine Produktentscheidung, keine technische Notwendigkeit. Überleg dir, ob das für deine Zielgruppe sinnvoll ist – für eine deutschsprachige Community-Seite z.B. könnte Deutsch als Fallback besser passen. Außerdem: Browser-Sprache und Nutzerpräferenz sind nicht immer gleich. Wer einen deutschen Browser hat, aber Englisch bevorzugt, landet trotzdem auf Deutsch. Und bei aggressiven Redirect-Setups können Suchmaschinen-Crawler und CDN-Systeme unerwartetes Verhalten zeigen – prüfe nach der Aktivierung, ob Google Search Console keine Crawling-Fehler meldet.

Empfehlung: Für den Anfang lieber ohne Browsersprache-Redirect live gehen. Baue erst Inhalte in beiden Sprachen auf, teste den Switcher manuell und aktiviere die automatische Erkennung erst danach. Für kleine Blogs oder Community-Seiten mit klarer deutschsprachiger Zielgruppe ist die Browserweiterleitung oft gar nicht nötig. Für internationale SEO-Setups mit Google-Traffic aus mehreren Ländern kann sie sinnvoll sein – dann aber unbedingt mit curl-Test und Search-Console-Monitoring einrichten.

Teil 7: Inhalte auf Englisch übersetzen

Die technische Einrichtung ist jetzt vollständig abgeschlossen. Tanja lehnt sich zurück. Ulf sieht aus als hätte er gerade ein Tor geschossen. Bernd hat still seinen Kaffee getrunken.

Ulf: „Und jetzt?“
Tanja: „Jetzt kommt die Arbeit.“
Bernd: „Kann man das nicht automatisch übersetzen lassen?“
Tanja: „Kann man. Sollte man bei Fachtexten nicht. Aber das ist deine Entscheidung.“

Artikel übersetzen

1. Einen Beitrag im Backend öffnen: Beiträge → Alle Beiträge
2. Rechts in der Sidebar erscheint das Polylang-Feld „Sprachen“
3. Neben dem 🇺🇸-Symbol auf „+“ klicken
4. Es öffnet sich ein neuer Editor für die englische Version
5. Den Artikel auf Englisch verfassen und veröffentlichen

Polylang verknüpft beide Versionen automatisch und setzt die korrekten hreflang-Tags für Google – das sind Hinweise im Seitenquelltext, die Google sagen: „Diese Seite existiert auch auf Englisch, und hier ist der Link.“ Wichtig für internationale SEO.

Seiten übersetzen

Für Seiten (Impressum, Datenschutz, etc.) funktioniert es genauso: Seiten → Alle Seiten → gewünschte Seite öffnen → 🇺🇸 → „+“.

Tipp: Übersetze zuerst die rechtlich relevanten Seiten (Impressum, Datenschutz, Cookie-Richtlinie), bevor du die eigentlichen Artikel angehst.

Rechtlicher Hinweis: Eine sprachliche Übersetzung dieser Seiten ersetzt keine rechtliche Prüfung für andere Zielmärkte. Je nach Land können abweichende Anforderungen gelten – etwa andere Pflichtangaben im Impressum oder zusätzliche Datenschutzregelungen. Im Zweifel rechtlichen Rat einholen.

Teil 8: Fehlerbehebung

Tanja stellt eine Tasse Kaffee auf den Tisch. „Jetzt kommen die Dinge, die ich schon erlebt habe. Und Bernd auch.“

In diesem Kapitel sind die häufigsten Probleme bei der Polylang-Einrichtung und ihre Lösungen dokumentiert. Die Fehler sind nach Häufigkeit und Schwere gegliedert.

Häufige Fehler

Fehler 1: EN-Link im Sprachumschalter fehlt

Symptom: Im Menü erscheint nur Deutsch, der EN-Link ist unsichtbar.
Ursache: Polylang-Standardverhalten – EN wird nur angezeigt, wenn für die aktuelle Seite eine englische Übersetzung existiert.
Lösung: HTML-2-Widget im Astra Header Builder verwenden (→ Schritt 15–18).

Fehler 2: 404-Fehler auf /en/

Symptom: Die englische Startseite deine-domain.de/en/ zeigt eine 404-Fehlerseite.
Ursache: Polylang hat die Rewrite-Regeln noch nicht registriert.
Lösung: Im Backend Einstellungen → Permalinks → „Änderungen speichern“ klicken. Kein Inhalt muss geändert werden – der Klick alleine reicht, um die Rewrite-Regeln neu zu schreiben.

Fehler 3: Englische Seite hat kein Menü

Symptom: Auf der /en/-Startseite fehlt die Navigationsleiste komplett.
Ursache: Das englische Menü wurde noch nicht den richtigen Theme-Positionen zugewiesen.
Lösung: Im Backend Design → Menüs → Tab „Positionen verwalten“:

• Primäres Menü English → Main Menu zuweisen
• Off-Canvas-Menü English → Main Menu zuweisen

Layout-Fehler

Fehler 4: Sprachumschalter im Header nicht sichtbar (Astra Grid-Problem)

Symptom: Der Sprachumschalter ist im Header-Builder eingebaut, aber im Frontend unsichtbar.
Ursache: Astra berechnet die Spaltenbreiten dynamisch. Die Mittelspalte kann dabei 0px Breite bekommen – alles darin ist unsichtbar. Das passiert, wenn Astra erkennt, dass die Mittelspalte leer ist, und ihr schlicht keinen Platz zuweist.
Diagnose: In der Browser-Konsole (F12) prüfen:

const header = document.querySelector('.ast-primary-header-bar .ast-builder-grid-row-has-sides');
getComputedStyle(header).gridTemplateColumns;
// Falls Ergebnis: "639.5px 0px 639.5px" → Problem bestätigt

Lösung: CSS-Override im Customizer → Zusätzliches CSS hinzufügen:

/* Sprachumschalter: Center-Spalte sichtbar machen */
.ast-primary-header-bar .ast-builder-grid-row-has-sides.ast-grid-center-col-layout {
  grid-template-columns: 1fr auto 1fr !important;
}
.ast-primary-header-bar .site-header-primary-section-center {
  min-width: 80px !important;
  overflow: visible !important;
}

Fehler 5: Polylang blendet Sprachumschalter per CSS aus

Symptom: Der Sprachumschalter ist im Quellcode vorhanden, aber im Browser nicht sichtbar.
Ursache: Polylang fügt standardmäßig die CSS-Regel .lang-item { display: none } ein und macht die Items normalerweise per JavaScript wieder sichtbar. In manchen Theme-Setups greift dieses JavaScript nicht – und alles bleibt ausgeblendet.
Diagnose: In der Browser-Konsole prüfen:

// Sucht nach der problematischen Regel in allen Stylesheets
[...document.styleSheets].forEach(s => {
  try { [...s.cssRules].forEach(r => {
    if (r.selectorText && r.selectorText.includes('lang-item')) console.log(r.cssText);
  }); } catch(e) {}
});

Lösung: Das CSS im Customizer (Schritt 18) setzt .lang-item { display: none !important; } und verwendet stattdessen das eigene HTML-2-Widget, das nicht von Polylang-CSS beeinflusst wird.

Kritische Fehler

Fehler 6: PHP-Syntaxfehler / Website offline

Das ist Bernds Spezialität.

Bernd: „Ich hab mal schnell was in die functions.php geschrieben. Dann war die Seite weg.“
Tanja: „Wie lange?“
Bernd: „…eine Stunde.“
Ulf: „Eine Stunde! Das ist ein kompletter Halbzeitausfall.“

Symptom: Nach einer Änderung in functions.php zeigt die Website nur einen weißen Bildschirm oder einen HTTP 500-Fehler. Das WordPress-Backend ist nicht mehr erreichbar.
Ursache: Ein PHP-Syntaxfehler in functions.php bringt WordPress komplett zum Absturz. WordPress prüft den Code nicht vor dem Speichern – es speichert einfach, auch wenn der Code kaputt ist.
Lösung A: Über das Hosting-Backup wiederherstellen (empfohlen)

Die meisten Hosting-Anbieter haben eine Backup-Funktion. Bei Strato z.B.:

1. Strato Kundencenter → BackupControl
2. Letztes Backup vor der Änderung auswählen
3. Zu /wp-content/themes/dein-theme/ navigieren
4. functions.php mit dem Symbol ≠ (= Unterschied zum Backup) markieren
5. „Auswahl wiederherstellen“ → Bestätigen
   Nach der Wiederherstellung ist die Website sofort wieder online:

Und die functions.php ist wieder im sauberen Ausgangszustand:

Lösung B: Über FTP/SFTP manuell wiederherstellen

1. Mit einem FTP-Programm (z.B. FileZilla) verbinden
2. Datei /wp-content/themes/dein-theme/functions.php herunterladen
3. In einem Text-Editor öffnen und den fehlerhaften Code entfernen
4. Datei wieder hochladen und überschreiben
   Prävention: Niemals functions.php direkt im WordPress-Theme-Editor bearbeiten. Stattdessen das Plugin „Code Snippets“ verwenden (→ Schritt 27) – es validiert Code vor der Aktivierung und kann einzelne Snippets deaktivieren, ohne die gesamte Website zu zerstören.

Fehler 7: Änderungen im Frontend nicht sichtbar (Cache-Problem)

Symptom: CSS-Änderungen oder Menü-Updates sind im Frontend nicht sichtbar, obwohl sie im Backend gespeichert wurden.
Ursache: Ein Caching-Plugin liefert noch die alte, gecachte Version aus. Das Caching-Plugin weiß nicht, dass du etwas geändert hast – es serviert einfach die gespeicherte Version.
Lösung: Nach jeder Änderung an CSS, Menüs oder Theme-Einstellungen den Cache leeren:

• In der WordPress-Adminleiste auf „WP Fastest Cache“ klicken
• „Alle Caches löschen“ auswählen
  Tipp: Wenn du Änderungen direkt im Customizer machst, immer zuerst auf „Veröffentlichen“ klicken und erst dann den Cache leeren. Die Reihenfolge ist wichtig.

Fehler 8: Browsersprache-Erkennung funktioniert nicht

Symptom: Englischsprachige Besucher landen trotz aktivierter Browsersprache-Erkennung immer auf der deutschen Seite.
Häufige Ursachen und Lösungen:

Ursache	Lösung
Startseite ist gecacht	Startseite im Caching-Plugin ausschließen (→ Schritt 26)
Eingeloggter Admin	Admins werden von Polylang nie umgeleitet – normales Verhalten
Cookie bereits gesetzt	pll_language-Cookie löschen und erneut testen
Polylang-Einstellung deaktiviert	Polylang → Einstellungen → „Browsersprache erkennen“ prüfen

Test-Tipp: Ein echter Test ist nur mit einem Browser möglich, der auf en eingestellt ist, oder via Terminal:

curl -H "Accept-Language: en" https://deine-domain.de/ -I

Du solltest einen Redirect auf /en/ sehen.

Endergebnis: Funktionstest DE ↔ EN

Der folgende Test zeigt das Ergebnis mit dem nativen Polylang-Menü-Switcher (Variante A), der artikelgenau auf die jeweilige Übersetzung verlinkt:

Auf dem deutschen Artikel: DE | EN – Klick auf EN führt direkt zur englischen Version

Nach dem Wechsel auf EN: Englisches Menü, EN fett/orange, zurück zu DE funktioniert ebenfalls

Hinweis für Variante B (HTML-Widget): Der statische HTML-Switcher im Header zeigt auf Unterseiten immer auf die jeweilige Sprach-Startseite, nicht auf den übersetzten Artikel. Artikelgenaues Umschalten ist mit Variante B nur möglich, wenn zusätzlich der native Polylang-Switcher im Menü aktiv bleibt.

Teil 9: Wartung und spätere Änderungen

Tanja schaut in die Runde. „Ihr denkt, das war’s?“

Es ist nie wirklich fertig. Websites wachsen, Themes ändern sich, neue Sprachen kommen hinzu. Hier sind die häufigsten Wartungsszenarien – damit du nicht wieder von vorne anfangen musst.

Dritte Sprache hinzufügen: In Polylang → Sprachen eine neue Sprache anlegen, ein neues Menü für diese Sprache erstellen und das HTML-Widget im Header um einen dritten Link ergänzen. CSS für .pll-link-xx entsprechend erweitern.

Theme-Wechsel: Das HTML-Widget und das zusätzliche CSS bleiben erhalten (sie liegen im Customizer, nicht im Theme). Prüfe nach dem Theme-Wechsel, ob die CSS-Selektoren .ast-header-html-2 und .site-primary-header-wrap noch greifen – diese sind Astra-spezifisch und müssen für andere Themes angepasst werden.

Wechsel von Astra Free zu Astra Pro: Astra Pro bietet einen echten Header Builder mit freier Positionierung. Das HTML-Widget und die absolute CSS-Positionierung können dann entfernt werden – stattdessen den nativen Polylang-Switcher direkt im Header-Builder platzieren.

Wechsel des Caching-Plugins: Die Ausnahme für die Startseite (→ Schritt 26) muss im neuen Plugin neu eingerichtet werden. Andernfalls funktioniert die Browsersprache-Erkennung nicht.

Migration auf Staging und zurück: Die Domain-URLs im HTML-Widget müssen auf der Staging-Umgebung angepasst werden. Am einfachsten: Widget auf Staging temporär deaktivieren und nur den nativen Polylang-Switcher nutzen.

Teil 10: Rückbau / Deaktivierung

Manchmal will man einen Schritt zurückgehen. Kein Problem – hier ist der saubere Rückweg.

HTML-Widget entfernen: Design → Customizer → Header Builder → HTML-2-Widget aus dem Header ziehen oder löschen.

Nativen Polylang-Switcher reaktivieren: Design → Menüs → Hauptmenü → Sprachumschalter-Eintrag aufklappen → gewünschte Einstellungen setzen. Im CSS den Block .lang-item { display: none !important; } entfernen.

CSS aufräumen: Im Customizer → Zusätzliches CSS den gesamten Block zwischen /* ===== Sprachumschalter DE | EN ===== */ und dem letzten } löschen. Der restliche CSS-Code der Website bleibt unberührt.

Menüs zurücksetzen: Design → Menüs → Tab „Positionen verwalten“ → Primäres Menü English und Off-Canvas-Menü English auf „kein Menü“ setzen, falls gewünscht.

Polylang deaktivieren: Plugins → Polylang → Deaktivieren. Bestehende Übersetzungsverknüpfungen bleiben in der Datenbank erhalten, sind aber ohne Polylang inaktiv. Alle Beiträge bleiben zugänglich – sie verlieren nur ihre Sprachzuordnung.

Teil 11: Hinweis für Entwickler – Variante C

Der HTML-Widget-Ansatz in Variante B ist ein pragmatischer Workaround für Astra Free. Für produktive Websites mit längerfristiger Wartung ist eine dynamische Lösung robuster.

Tanja: „Für Entwickler gibt es eine elegantere Lösung.“
Bernd: „Ich bin quasi auch Entwickler.“
Tanja: „Bernd, du hast functions.php mit Notepad bearbeitet.“
Bernd: „Das ist ein valider Editor.“
Tanja: „Ich rede weiter.“

Eine technisch robustere Alternative ist ein dynamischer Sprachumschalter, der über einen passenden Theme-Hook, einen Template-Part oder einen Shortcode eingebunden wird.

Beispiel: Shortcode

// In einem Child-Theme oder per Code-Snippets-Plugin:
add_shortcode( 'sprachumschalter', function() {
    if ( ! function_exists( 'pll_the_languages' ) ) return '';
    ob_start();
    pll_the_languages( array(
        'show_flags'          => 0,
        'show_names'          => 0,
        'display_names_as'    => 'slug',
        'hide_current'        => 0,
        'hide_if_no_translation' => 0,
    ) );
    return ob_get_clean();
} );

Der Shortcode [sprachumschalter] kann dann in einem Widget, einem Template-Part oder direkt im Header-Markup platziert werden. Polylang rendert dabei dynamisch die korrekten URLs – auf Artikelseiten zeigt der Switcher direkt auf die verknüpfte Übersetzung, nicht auf die Startseite.
Ausgabeformat: pll_the_languages() rendert standardmäßig eine HTML-Liste:

<ul class="ast-nav-menu">
  <li class="lang-item lang-item-de current-lang"><a href="/">DE</a></li>
  <li class="lang-item lang-item-en"><a href="/en/">EN</a></li>
</ul>

Das resultierende Markup muss je nach Theme per CSS an das Header-Layout angepasst werden – insbesondere Darstellung, Abstände und Hervorhebung der aktiven Sprache.

Vorteile gegenüber Variante B:

• Keine statischen URLs – funktioniert bei Domainwechsel und Staging ohne Anpassung
• Artikelgenaue Umschaltung automatisch
• Neue Sprachen werden automatisch eingebunden

Für produktive Nutzung empfohlen:

• In einem Child-Theme umsetzen, damit Theme-Updates den Code nicht überschreiben
• CSS für aktive Sprache, Kontrast und Fokus-Stil ergänzen (→ Accessibility, siehe unten)
• Nach jedem Theme-Update prüfen, ob Hook-Positionen noch stimmen
  Hinweis: pll_the_languages() gibt eine HTML-Liste aus und sollte in einem sichtbaren Frontend-Bereich eingebunden werden – nicht im <head> der Seite.

Go-live-Checkliste

Bevor du die zweisprachige Website offiziell in Betrieb nimmst, diese Punkte abhaken.
🔴 Pflicht · 🟡 Optional · 🔵 Nur Variante B · 🟢 Nur bei aktivem Redirect

Grundfunktion:

• 🔴 DE-Startseite lädt korrekt (deine-domain.de/)
• 🔴 EN-Startseite lädt korrekt (deine-domain.de/en/) – kein 404
• 🔴 Permalinks wurden neu gespeichert
• 🔴 Cache nach allen Änderungen geleert

Navigation:

• 🔴 Deutsches Menü zeigt korrekte Kategorien
• 🔴 Englisches Menü zeigt korrekte Kategorien
• 🔴 Sprachumschalter sichtbar
• 🔴 Aktive Sprache wird fett und farbig hervorgehoben

Sprachumschaltung:

• 🔴 Variante A / C: Klick auf EN von DE-Artikel → landet direkt auf englischer Übersetzung
• 🔴 Variante A / C: Klick auf DE von EN-Artikel → landet direkt auf deutschem Original
• 🔵 Variante B: Header-Switcher zeigt korrekt auf / (DE) und /en/ (EN)
• 🔵 Variante B: Verhalten auf Unterseiten bewusst getestet und dokumentiert

Inhalte:

• 🔴 Mindestens ein DE/EN-Beitrag testweise übersetzt und verknüpft
• 🔴 Rechtliche Seiten in beiden Sprachen vorhanden

Browser-Redirect:

• 🟢 Browser-Redirect in Inkognito-Tab getestet (kein Admin-Cookie)
• 🟢 Google Search Console: keine neuen Crawling-Fehler nach Aktivierung

Technik:

• 🔴 Desktop, Tablet und Mobile geprüft
• 🟡 Accessibility: Sprachumschalter per Tastatur erreichbar, ausreichender Kontrast
• 🟡 XML-Sitemap: EN-URLs erscheinen in der Sitemap (SEO-Plugin ggf. neu generieren)

Zusammenfassung: Was wurde eingerichtet?

Gemeinsame Grundlage (alle Varianten):

Was	Ergebnis
Plugin	Polylang (kostenlos)
Sprachen	Deutsch (de_DE) + Englisch (en_US)
URL-Struktur	DE: deine-domain.de/ · EN: deine-domain.de/en/
Bestehende Inhalte	Alle als „Deutsch“ markiert
Englisches Menü	Separate Navigation mit übersetzten Kategorienamen

Variante A – Standard:

Was	Ergebnis
Sprachumschalter	Nativer Polylang-Switcher im Menü, dynamisch, artikelgenau
Wartungsaufwand	Gering

Variante B – Astra Free zentriert (dieser Guide):

Was	Ergebnis
Sprachumschalter	Statisches HTML-Widget, zentriert im Header
Styling	Aktive Sprache fett + Akzentfarbe per html[lang]-Selektor
Artikelgenaue Umschaltung	Nur mit zusätzlichem nativen Polylang-Switcher
Wartungsaufwand	Mittel – URLs bei Domainwechsel manuell anpassen

Optional (unabhängig von Variante):

Was	Ergebnis
Browsersprache-Erkennung	Automatische Weiterleitung für neue Besucher
EN-Fallback	Alle Nicht-DE-Sprachen → Englisch (Produktentscheidung)
Cache-Ausnahme	Startseite vom Cache ausgeschlossen (nur bei aktivem Redirect nötig)
PHP-Snippets	Über „Code Snippets“-Plugin, nicht direkt in functions.php

Accessibility-Hinweise

Beim eigenen HTML-Widget (Variante B) ist Barrierefreiheit nicht automatisch gewährleistet. Das klingt nach Bürokratie – ist aber für Tastaturnutzer und Screenreader-Nutzer ein echter Unterschied. Diese Punkte solltest du prüfen und ergänzen:
aria-label am Nav-Element:

<nav class="pll-switcher-center" aria-label="Sprache wechseln">
  <a href="..." class="pll-link-de" hreflang="de" lang="de">DE</a>
  <span class="pll-sep" aria-hidden="true">|</span>
  <a href="..." class="pll-link-en" hreflang="en" lang="en">EN</a>
</nav>

Aktive Sprache nicht nur über Farbe kennzeichnen – ergänze aria-current="true" auf dem aktiven Link oder stelle sicher, dass die Fettung allein als visueller Unterschied ausreicht. Farbe allein ist laut WCAG kein ausreichendes Unterscheidungsmerkmal.
Kontrast prüfen: Die inaktive Farbe (#888 im Beispiel-CSS) hat gegen einen weißen Header möglicherweise zu wenig Kontrast. Ziel: mindestens 4,5:1 für normalen Text (WCAG AA).
Fokus-Stil: Stelle sicher, dass die Links per Tastatur erreichbar sind und einen sichtbaren Fokus-Rahmen haben. Viele Themes entfernen den Browser-Standard-Fokus per outline: none. Ergänze im Customizer CSS:

.pll-switcher-center a:focus-visible {
    outline: 2px solid currentColor;
    outline-offset: 2px;
}

Das sorgt für einen sichtbaren Fokusrahmen bei Tastaturnavigation, ohne das visuelle Design bei Mausnutzung zu beeinflussen.

SEO-Prüfung nach den ersten Übersetzungen

Sobald die ersten Beiträge in beiden Sprachen veröffentlicht sind, diese Punkte prüfen:
hreflang-Tags:

• Sind die hreflang-Tags paarweise korrekt? DE-Seite verweist auf EN, EN-Seite verweist auf DE.
• Im Seitenquelltext prüfen: <link rel="alternate" hreflang="de" href="..."/> und <link rel="alternate" hreflang="en" href="..."/>müssen beide vorhanden sein.
  Canonicals:
• Zeigt jede Seite auf sich selbst als Canonical? DE-Seite → DE-URL, EN-Seite → EN-URL. Keine Kreuz-Verlinkung.
  Indexierung:
• EN-Seiten indexierbar? In Google Search Console prüfen, ob /en/-URLs gecrawlt und indexiert werden.
• Leere EN-Entwürfe (ohne Inhalt) nicht indexieren – entweder auf noindex setzen oder erst veröffentlichen, wenn Inhalt vorhanden.
  Interne Links:
• Sind interne Links innerhalb eines Sprachbereichs konsistent? Deutsche Artikel verlinken auf deutsche Seiten, englische auf englische.
  XML-Sitemap:
• Tauchen EN-URLs in der Sitemap auf? Nach dem Veröffentlichen erster englischer Beiträge das SEO-Plugin (Rank Math, Yoast, o.ä.) öffnen und die Sitemap einmal neu generieren lassen.
• In der Google Search Console die Sitemap einreichen und prüfen, ob EN-Seiten ohne Fehler indexiert werden.

Nächste Schritte

Die technische Einrichtung ist vollständig. Tanja nickt zufrieden. Ulf schaut aus dem Fenster. Bernd öffnet gerade ein neues Browserfenster – man weiß nie.
Jetzt kannst du Schritt für Schritt Inhalte auf Englisch ergänzen:

1. Rechtlich relevante Seiten zuerst: Impressum → Legal Notice, Datenschutz → Privacy Policy
2. Dann die wichtigsten Artikel übersetzen
3. Jede übersetzte Seite erscheint automatisch im Sprachumschalter des entsprechenden DE-Artikels

Ulf: „Das war gar nicht so schlimm.“
Tanja: „Das sagen alle am Ende.“
Bernd: „Ich hätte das in zehn Minuten gemacht.“
Tanja: „Bernd, du bist immer noch nicht fertig mit deinem Backup von letztem Monat.“
Bernd: „Das ist ein laufendes Projekt.“