Umlaute kaputt nach WordPress-Umzug? So entsteht Mojibake – und so reparierst du es

Eben lief deine Website noch einwandfrei – nach dem Umzug auf einen neuen Server steht plötzlich überall „Grüße“ statt „Grüße“. Umlaute, das ß und Sonderzeichen sind in seltsame Buchstabensalate verwandelt. Die gute Nachricht vorweg: Deine Texte sind nicht verloren. Das ist ein bekanntes, klar benanntes Problem mit einer zuverlässigen Lösung. In diesem Beitrag erklären wir verständlich, was technisch passiert, warum ausgerechnet der Umzug den Schaden anrichtet – und wie du ihn Schritt für Schritt vollständig behebst.

Das Symptom: Aus „Grüße“ wird „Grüße“

Das Schadensbild ist immer gleich und sehr wiedererkennbar. Überall dort, wo eigentlich ein deutscher Umlaut oder ein Sonderzeichen stehen müsste, erscheinen jetzt zwei oder mehr fremde Zeichen. Typische Beispiele aus echten Fällen:

Fachleute nennen diesen Zeichensalat Mojibake (japanisch für „Zeichen-Wandlung“). Das Muster ist verräterisch: Fast immer taucht ein großes Ã auf, gefolgt von einem zweiten Zeichen. Genau dieses Ã ist die Signatur des Problems – und gleichzeitig der Schlüssel zur Reparatur.

Keine Panik: Nichts ist verloren

Das ist der entscheidende Unterschied zu echtem Datenverlust: Hier sind die Buchstaben nicht weg, sondern nur „falsch übersetzt“. Wenn man die falsche Übersetzung kennt, kann man sie exakt umkehren. Und die kennen wir.

Wie WordPress Texte speichert (einfach erklärt)

Um zu verstehen, was schiefgeht, brauchst du nur eine Idee: Ein Computer speichert keine Buchstaben, sondern Zahlen (Bytes). Welche Zahl welcher Buchstabe ist, legt der sogenannte Zeichensatz fest – quasi das Wörterbuch zwischen Zahlen und Buchstaben. Für deutsche Websites sind drei Begriffe wichtig:

Der Knackpunkt: Ein „ü“ ist in UTF-8 zwei Bytes lang (technisch: die Zahlen C3 A4 für „ä“, C3 BC für „ü“). Wenn ein Programm diese zwei Bytes fälschlich mit dem alten latin1-Wörterbuch nachschlägt, liest es daraus zwei einzelne Zeichen – nämlich Ã und ¼. Genau hier beginnt der Salat.

Warum das Original funktioniert, der Klon aber kaputt ist

Das ist die Frage, die fast alle Betroffenen stellen: „Auf der alten Seite war doch alles richtig – warum jetzt nicht mehr?“ Die Antwort ist überraschend logisch.

Viele ältere Installationen – besonders die, die per 1-Klick-Installer im cPanel (Softaculous & Co.) entstanden sind – haben eine kleine Inkonsistenz eingebaut: Die Texte sind als modernes UTF-8 gespeichert, aber die Datenbank ist nach außen als latin1 deklariert. Das klingt nach einem Fehler – und ist es im Prinzip auch. Aber solange Speichern und Anzeigen auf demselben System mit denselben (falschen) Einstellungen passieren, heben sich die beiden Fehler gegenseitig auf. Die Seite sieht perfekt aus. Niemand merkt etwas.

Beim Umzug wird genau diese stille Übereinkunft zerstört. Das Umzugswerkzeug nimmt die „latin1“-Beschriftung der alten Datenbank wörtlich und „konvertiert“ die Daten brav nach UTF-8 – obwohl sie längst UTF-8 sind. Jedes Umlaut-Byte wird dabei ein zweites Mal verschlüsselt. So wird aus einem Zeichen plötzlich zwei. Auf dem neuen Server fehlt dann die ausgleichende Gegen-Inkonsistenz, und der Salat wird sichtbar.

Was „Doppel-Kodierung“ konkret bedeutet

Man kann es sich wie eine doppelte Übersetzung vorstellen: Ein deutscher Satz wird ins Englische übersetzt – und dann wird das englische Ergebnis noch einmal so behandelt, als wäre es Deutsch, und „übersetzt“. Heraus kommt Unsinn. Beim Mojibake ist es genauso, nur mit Bytes:

Richtig:        ü   =  Bytes  C3 BC          (UTF-8, ein Zeichen)
Eine Übersetzung
zu viel:        ü → „Ó + „¼“ → Bytes  C3 83 C2 BC   (= "ü", zwei Zeichen)

Dasselbe für ß:  ß  =  C3 9F   →   "ß"  =  C3 83 C2 9F

Weil dieser Vorgang nach einer festen Regel abläuft und die komplette Datenbank gleichmäßig betrifft, lässt er sich exakt umkehren: Man muss die überflüssige Übersetzung einfach genau einmal zurückrechnen. Danach steht wieder das saubere „ü“ da.

Die typische Falle: cPanel-Installer und Duplicator

Das Problem tritt fast immer in derselben Konstellation auf – deshalb lohnt es sich, sie zu kennen:

Reparatur Schritt für Schritt

Jetzt zur Lösung. Die Reparatur ist gut machbar, aber sie greift direkt in die Datenbank ein. Deshalb gilt eine eiserne Regel, bevor irgendetwas anderes passiert:

Schritt 1: Die Diagnose – welcher Fall liegt vor?

Es gibt zwei Spielarten des Problems, und sie brauchen unterschiedliche Lösungen. Schau dir dazu am besten einen betroffenen Text genau an:

• Fall A – Doppel-Kodierung: Du siehst Muster wie ü, ö, ä, ß (immer mit dem großen Ã). Das ist der häufigste Fall nach einem Duplicator-Umzug. Die Daten sind UTF-8, aber einmal zu viel kodiert.
• Fall B – echtes latin1: Die Texte waren nie UTF-8, sondern „echtes“ altes latin1, werden aber jetzt als UTF-8 ausgegeben. Hier hilft eine reine Umstellung des Zeichensatzes, keine Rückrechnung.

Für den mit Abstand häufigsten Fall A (das verräterische Ã) zeigen wir hier die Reparatur. Mit einem Datenbank-Werkzeug wie phpMyAdmin (in fast jedem Hosting enthalten) oder Adminer / TablePlus kannst du prüfen, ob wirklich überall das Doppel-Muster vorliegt.

Schritt 2: Die Korrektur per SQL

Die eigentliche Heilung besteht darin, die überflüssige Übersetzung genau einmal zurückzunehmen. In SQL übernimmt das ein kompakter Befehl, den du pro Textspalte ausführst. Er liest den Text als latin1 zurück (macht die zu viel ausgeführte Konvertierung rückgängig) und speichert ihn als sauberes UTF-8:

Beispiel mit dem Standard-Präfix wp_ – passe es an dein eigenes Präfix an:

-- Beiträge und Seiten
UPDATE wp_posts SET
  post_content = CONVERT(CAST(CONVERT(post_content USING latin1) AS BINARY) USING utf8mb4),
  post_title   = CONVERT(CAST(CONVERT(post_title   USING latin1) AS BINARY) USING utf8mb4),
  post_excerpt = CONVERT(CAST(CONVERT(post_excerpt USING latin1) AS BINARY) USING utf8mb4);

-- Einstellungen (Seitentitel, Slogan, viele Plugin-Optionen)
UPDATE wp_options SET
  option_value = CONVERT(CAST(CONVERT(option_value USING latin1) AS BINARY) USING utf8mb4);

-- Zusatzfelder von Beiträgen (z. B. ACF, SEO-Plugins)
UPDATE wp_postmeta SET
  meta_value = CONVERT(CAST(CONVERT(meta_value USING latin1) AS BINARY) USING utf8mb4);

-- Kommentare, Kategorien/Schlagwörter
UPDATE wp_comments SET comment_content = CONVERT(CAST(CONVERT(comment_content USING latin1) AS BINARY) USING utf8mb4);
UPDATE wp_terms    SET name            = CONVERT(CAST(CONVERT(name            USING latin1) AS BINARY) USING utf8mb4);

Schritt 3: Der sichere Ablauf im Überblick

Damit es nicht wieder passiert: richtig umziehen

Die schönste Reparatur ist die, die man nie braucht. Mit zwei Maßnahmen verhinderst du, dass beim nächsten Umzug wieder Salat entsteht:

Der nachhaltigste Schritt ist die Umstellung auf utf8mb4. Dieser Zeichensatz ist heute der WordPress-Standard, beherrscht alle Sprachen und sogar Emojis – und beseitigt die alte latin1-Schieflage dauerhaft. Danach sind Umlaute auch bei künftigen Umzügen kein Thema mehr.

Wann du besser einen Profi fragst

Hand aufs Herz: Direkte Eingriffe in die Datenbank sind nichts, was man zwischen Tür und Angel macht. Hol dir Unterstützung, wenn einer dieser Punkte auf dich zutrifft:

• Du bist dir bei Backup, phpMyAdmin oder SQL unsicher.
• Es handelt sich um einen wichtigen Live-Shop oder eine geschäftskritische Seite.
• Das Schadensbild ist gemischt (teils Salat, teils sauber) – dann ist die Richtung der Korrektur nicht eindeutig und ein falscher Lauf richtet Schaden an.
• Neben WordPress hängen weitere Systeme an derselben Datenbank.

Mojibake sieht nach Katastrophe aus, ist aber in Wahrheit eines der dankbarsten WordPress-Probleme: Die Daten sind vollständig da, der Fehler folgt einem festen Muster – und genau deshalb lässt er sich sauber und vollständig zurückdrehen.

Michael Rademacher, Gründer realmaker

Fazit

Wenn nach einem Umzug überall „Grüße“ statt „Grüße“ steht, ist das kein Datenverlust, sondern eine Doppel-Kodierung: Die Umlaute wurden beim Klonen einmal zu viel von latin1 nach UTF-8 umgewandelt. Das Original funktionierte nur deshalb, weil sich dort zwei Zeichensatz-Fehler gegenseitig ausglichen – beim Umzug ist diese Balance zerbrochen. Die Lösung ist, die überflüssige Umwandlung mit einem gezielten SQL-Befehl genau einmal zurückzurechnen. Mit Backup, einem Test auf einer Kopie und anschließendem Cache-Leeren ist der Spuk in kurzer Zeit vorbei – und mit der Umstellung auf utf8mb4 kommt er auch nicht wieder.

Häufige Fragen

Dieser Beitrag ist Teil unserer WordPress-Wissensreihe von realmaker – deiner Kreativagentur für Film, Web und KI-Lösungen.