Kurz gesagt: Wenn aus „ä“ plötzlich „ä“, „�“ oder „?“ wird, passen irgendwo zwei Zeichensätze nicht zusammen: Datenbank, Datenbankverbindung und Dateien müssen alle UTF-8 sprechen. In WordPress heißt das: Tabellen in utf8mb4, in der wp-config.php DB_CHARSET auf utf8mb4 (oder utf8) und Theme-/Plugin-Dateien als UTF-8 ohne BOM speichern. Bereits kaputte Texte reparierst du danach gezielt mit Suchen und Ersetzen, nachdem du ein Backup gemacht hast.
Das Problem ist so alt wie WordPress selbst und taucht vor allem nach einem Umzug, einem Datenbank-Import oder dem Bearbeiten von Dateien mit dem falschen Editor auf. Die gute Nachricht: Das Schadensbild verrät meistens schon, wo der Fehler sitzt.
Schadensbild erkennen: Was siehst du genau?
| Anzeige statt „Größe“ | Was passiert ist | Wo du ansetzt |
|---|---|---|
| „Größe“ | UTF-8-Bytes werden als Latin-1 (ISO-8859-1/Windows-1252) gelesen. Klassiker nach Import mit falschem Zeichensatz. | Datenbankverbindung (DB_CHARSET) oder doppelt kodierte Daten in der Datenbank |
| „Gr�e“ (Raute mit Fragezeichen) | Latin-1-Bytes werden als UTF-8 gelesen, das Byte ist kein gültiges UTF-8. | Datei (Theme, Plugin) oder Tabelle ist noch Latin-1 |
| „Gr??e“ | Beim Speichern in die Datenbank ließ sich das Zeichen nicht abbilden und wurde endgültig durch „?“ ersetzt. | Tabelle/Spalte mit falschem Zeichensatz, Daten sind verloren und müssen aus Backup kommen |
| Emojis werden zu „????“ oder Beitrag wird leer gespeichert | Tabelle ist utf8 (max. 3 Byte), Emojis brauchen 4 Byte. | Tabellen auf utf8mb4 umstellen |
| „“ oder Leerzeile ganz oben, dazu „Cannot modify header information“ | Eine Datei wurde als UTF-8 mit BOM gespeichert. | Datei ohne BOM neu speichern |
Tritt der Fehler nur in bestimmten Texten auf (etwa nur in alten Beiträgen), liegt es fast immer an den gespeicherten Daten. Sind dagegen auch Menüpunkte oder Texte aus dem Theme betroffen, liegt es an der Datei oder an der Verbindung.
Schritt für Schritt reparieren
1. Backup machen
Bevor du an Zeichensätzen drehst, sicherst du Datenbank und Dateien. Eine falsche Konvertierung lässt sich sonst nicht zurücknehmen. Wie das geht, steht in Backup von WordPress erstellen.
2. Einstellungen in der wp-config.php prüfen
Öffne die wp-config.php im Hauptverzeichnis und suche diese beiden Zeilen:
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );DB_CHARSETsollteutf8mb4oderutf8sein. WordPress wechselt beiutf8automatisch aufutf8mb4, wenn der Server es kann.DB_COLLATEbleibt leer, dann wählt MySQL/MariaDB die passende Sortierung.- Achtung: Steht dort seit Jahren
latin1oder fehltDB_CHARSETkomplett, und die Seite lief bis gestern korrekt, dann änderst du den Wert nicht einfach. Dann liegen die Daten vermutlich „doppelt kodiert“ in der Datenbank, und ein Umschalten macht alles kaputt. Das löst du mit Schritt 5.
3. Datenbank-Update und utf8mb4 prüfen
Seit WordPress 4.2 werden Tabellen beim Datenbank-Update automatisch auf utf8mb4 umgestellt, sofern der Server es unterstützt. Unter Werkzeuge → Website-Zustand → Bericht → Datenbank siehst du die Server-Version und den Zeichensatz der Verbindung. In phpMyAdmin zeigt die Tabellenübersicht die „Kollation“ jeder Tabelle, erwartet ist etwa utf8mb4_unicode_520_ci oder utf8mb4_unicode_ci. Einzelne Tabellen mit latin1_swedish_ci stammen oft von alten Plugins.
4. Dateien als UTF-8 ohne BOM speichern
Hast du functions.php, eine Template-Datei oder eine Übersetzung bearbeitet, prüfe den Editor. In Notepad++ heißt die richtige Einstellung „Kodierung → UTF-8“ (nicht „UTF-8-BOM“), in VS Code steht die Kodierung unten rechts in der Statusleiste. Windows-Editor speichert seit Windows 10 (1903) standardmäßig ohne BOM, ältere Versionen nicht. Eine BOM vor <?php erzeugt zusätzlich die Meldung, die in Cannot modify header information erklärt ist.
5. Bereits kaputte Texte reparieren
Sind nur wenige Stellen betroffen, korrigierst du sie im Editor von Hand. Bei vielen Beiträgen helfen gezielte Ersetzungen der typischen Muster, etwa mit dem Plugin „Better Search Replace“ oder per WP-CLI (siehe unten). Die häufigsten Paare:
| Kaputt | Richtig |
|---|---|
| ä | ä |
| ö | ö |
| ü | ü |
| Ä | Ä |
| Ö | Ö |
| Ãœ | Ü |
| ß | ß |
| € | € |
| „ und “ | „ und “ |
Ersetze zuerst die längeren Muster (etwa „„“), dann die kurzen. Und teste immer erst mit einem Probelauf.
6. Beim Umzug richtig exportieren
Die meisten Fälle entstehen beim Umzug. Exportiere mit mysqldump --default-character-set=utf8mb4 oder in phpMyAdmin mit Zeichensatz „utf-8“ und importiere mit demselben Zeichensatz. Öffne SQL-Dumps nicht in Programmen, die die Datei beim Speichern umkodieren. Wenn du dabei auch die Domain wechselst, hilft WordPress-URL ändern.
Für Fortgeschrittene: Diagnose und Reparatur per SQL und WP-CLI
Mit WP-CLI prüfst du schnell, welche Tabellen noch nicht auf utf8mb4 stehen:
wp db query "SELECT TABLE_NAME, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA = DATABASE() AND TABLE_COLLATION NOT LIKE 'utf8mb4%';"Eine einzelne Tabelle, deren Inhalte korrekt sind, konvertierst du so:
ALTER TABLE wp_beispiel CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;Bei doppelt kodierten Daten (UTF-8-Bytes in einer Latin-1-Spalte, im Frontend „ä“) hilft CONVERT TO nicht, weil MySQL die ohnehin falschen Zeichen ein zweites Mal umwandeln würde. Der saubere Weg führt über einen Umweg über BLOB, damit die Bytes unverändert bleiben:
ALTER TABLE wp_posts MODIFY post_content LONGBLOB;
ALTER TABLE wp_posts MODIFY post_content LONGTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci NOT NULL;Das musst du für jede betroffene Textspalte wiederholen (post_title, post_excerpt, comment_content, meta_value und so weiter), jeweils mit dem ursprünglichen Typ und den ursprünglichen Attributen. Probiere es zuerst auf einer Kopie der Datenbank.
Einzelne Muster ersetzt du mit WP-CLI, das auch serialisierte Daten korrekt behandelt:
wp search-replace 'ä' 'ä' --all-tables-with-prefix --dry-run
wp search-replace 'ä' 'ä' --all-tables-with-prefixBOM-Dateien in Theme und Plugins findest du auf der Shell mit:
grep -rl $'^\xEF\xBB\xBF' wp-content/themes wp-content/plugins --include=*.phpFrage dazu? Beschreib im WPDE-Forum unter „Fehler & Probleme“, was genau angezeigt wird und was du zuletzt geändert hast (Umzug, Import, Datei bearbeitet). Mit dem Schadensbild lässt sich die Ursache meist schnell eingrenzen.
Weitere typische Fehlerbilder und ein systematisches Vorgehen findest du im Überblick Wie gehe ich am besten vor, wenn Fehler in meinem Blog auftreten?.
Häufige Fragen
Soll ich DB_CHARSET einfach auf utf8mb4 ändern?
Nur wenn die Tabellen tatsächlich UTF-8-Daten enthalten. Lief die Seite jahrelang mit latin1 korrekt, sind die Daten wahrscheinlich doppelt kodiert. Dann erst die Daten reparieren (Schritt 5 bzw. BLOB-Umweg) und danach umstellen.
Warum funktionieren Umlaute, aber keine Emojis?
Weil die Tabelle noch utf8 (in MySQL ein 3-Byte-Zeichensatz) nutzt. Emojis brauchen 4 Byte und damit utf8mb4. Ein Datenbank-Update über das Dashboard oder wp core update-db stellt um, wenn der Server es unterstützt.
Die Umlaute sind nur in der Mail-Benachrichtigung kaputt. Woran liegt das?
Meist an einem SMTP- oder Mail-Plugin, das einen eigenen Zeichensatz setzt. Prüfe dort die Einstellung. Bei sehr alten Installationen lohnt außerdem ein Blick auf die Option blog_charset (etwa per wp option get blog_charset), sie sollte „UTF-8“ sein. Im Dashboard ist das Feld seit WordPress 3.5 nicht mehr sichtbar.
Kann ich „??“ statt Umlauten wiederherstellen?
Nicht automatisch. Die Fragezeichen wurden gespeichert, das ursprüngliche Zeichen ist verloren. Hilfe gibt es nur über ein Backup vor dem Fehler oder durch Handarbeit.