Umlauts Broken After a WordPress Move? How Mojibake Happens – and How to Fix It

Your website was running perfectly a moment ago – after the move to a new server, suddenly “Grüße” appears everywhere instead of “Grüße”. Umlauts (German letters like ä, ö, ü), the ß and special characters have turned into strange letter soup. The good news up front: your text is not lost. This is a well-known, clearly named problem with a reliable fix. In this post we explain in plain terms what happens technically, why the move of all things causes the damage – and how to fix it completely, step by step.

The symptom: “Grüße” becomes “Grüße”

The damage always looks the same and is easy to recognize. Wherever a German umlaut or special character should appear, two or more foreign characters show up instead. Typical examples from real cases:

Experts call this character soup mojibake (Japanese for “character transformation”). The pattern gives it away: almost always a capital Ã appears, followed by a second character. That Ã is the signature of the problem – and at the same time the key to the repair.

Don’t panic: nothing is lost

That is the crucial difference from real data loss: here the letters are not gone, just “mistranslated”. If you know the wrong translation, you can reverse it exactly. And we know it.

How WordPress stores text (explained simply)

To understand what goes wrong, you only need one idea: a computer does not store letters, it stores numbers (bytes). Which number stands for which letter is defined by the so-called character set – essentially the dictionary between numbers and letters. Three terms matter for German websites:

The crux: in UTF-8 a “ü” is two bytes long (technically: the numbers C3 A4 for “ä”, C3 BC for “ü”). If a program mistakenly looks up these two bytes in the old latin1 dictionary, it reads two separate characters from them – namely Ã and ¼. That is exactly where the soup begins.

Why the original works but the clone is broken

This is the question almost everyone affected asks: “Everything was right on the old site – why not anymore?” The answer is surprisingly logical.

Many older installations – especially those created with a 1-click installer in cPanel (Softaculous & co.) – have a small inconsistency built in: the text is stored as modern UTF-8, but the database is declared to the outside as latin1. That sounds like a mistake – and in principle it is one. But as long as saving and displaying happen on the same system with the same (wrong) settings, the two errors cancel each other out. The site looks perfect. Nobody notices anything.

The move destroys exactly this silent agreement. The migration tool takes the “latin1” label of the old database literally and dutifully “converts” the data to UTF-8 – even though it is already UTF-8. Every umlaut byte gets encoded a second time. That is how one character suddenly becomes two. On the new server the compensating counter-inconsistency is missing, and the soup becomes visible.

1. Original: stored as UTF-8

   In the old database “Grüße” is correctly stored as UTF-8 – the “ü” takes up two bytes. Everything is stored cleanly.

2. Original: two errors cancel out

   The database is labeled latin1 even though it contains UTF-8. WordPress reads it back with the same skew – the display is correct anyway. Nobody notices the problem.

3. Move: the tool takes “latin1” seriously

   When cloning, Duplicator (or another migration tool) reads the “latin1” label and converts the data to UTF-8 – even though it is already UTF-8. One conversion too many.

4. Move: every umlaut gets doubled

   The unnecessary conversion turns the “ü” (bytes C3 BC) into four bytes – the characters “ü”. One character has become two. This is what is called double encoding.

5. Clone: the soup becomes visible

   On the new server the compensating skew no longer fits. WordPress now honestly shows what is in the database: “Grüße” instead of “Grüße”.

What “double encoding” means in practice

Think of it as a double translation: a German sentence is translated into English – and then the English result is treated as if it were German and “translated” again. Nonsense comes out. With mojibake it is exactly the same, only with 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

Because this process follows a fixed rule and affects the entire database uniformly, it can be reversed exactly: you simply have to calculate the unnecessary translation back exactly once. Afterwards the clean “ü” is there again.

The typical trap: cPanel installers and Duplicator

The problem almost always occurs in the same constellation – so it is worth knowing it:

Repair step by step

Now for the solution. The repair is quite doable, but it intervenes directly in the database. That is why one iron rule applies before anything else happens:

Step 1: The diagnosis – which case is it?

There are two variants of the problem, and they need different solutions. The best approach is to look closely at an affected piece of text:

• Case A – double encoding: You see patterns like ü, ö, ä, ß (always with the capital Ã). This is the most common case after a Duplicator move. The data is UTF-8, but encoded once too often.
• Case B – genuine latin1: The text was never UTF-8 but “genuine” old latin1, and is now output as UTF-8. Here a plain change of the character set helps, not a back-calculation.

We show the repair here for by far the most common case A (the telltale Ã). With a database tool like phpMyAdmin (included with almost every hosting plan) or Adminer / TablePlus you can check whether the double pattern really is present everywhere.

Step 2: The correction via SQL

The actual cure consists of undoing the unnecessary translation exactly once. In SQL a compact command does this, which you run per text column. It reads the text back as latin1 (undoing the conversion that was performed once too often) and saves it as clean UTF-8:

Example with the standard prefix wp_ – adapt it to your own prefix:

-- 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);

Step 3: The safe process at a glance

1. Create a backup

   Pull a complete database export and store it safely. Only then continue.

2. Test on a copy

   Restore the backup into a test or staging environment and run the repair there first. That way you see the result without risk to the live site.

3. Run the correction

   Run the SQL commands exactly once per text column. With many plugin tables it is worth including their text columns too.

4. Check the result

   Spot checks on the site and in the database: are clean umlauts showing everywhere now? Does the capital “Ô no longer appear anywhere? Then it worked.

5. Clear the cache

   Finally, clear all caches – page cache, optimization plugins and, if needed, the browser cache. Otherwise the site still shows old, cached soup versions.

So it doesn’t happen again: move it properly

The best repair is the one you never need. Two measures prevent soup from appearing again with the next move:

The most sustainable step is switching to utf8mb4. This character set is the WordPress standard today, handles all languages and even emojis – and removes the old latin1 skew for good. After that, umlauts are no issue for future moves either.

When you should rather ask a professional

Let’s be honest: direct interventions in the database are not something you do on the side. Get support if any of these points applies to you:

• You are unsure about backups, phpMyAdmin or SQL.
• It is an important live shop or a business-critical site.
• The damage is mixed (partly soup, partly clean) – then the direction of the correction is not clear and a wrong run causes damage.
• Besides WordPress, other systems are connected to the same database.

Mojibake looks like a catastrophe but is actually one of the most rewarding WordPress problems: the data is fully there, the error follows a fixed pattern – and that is exactly why it can be reversed cleanly and completely.

Michael Rademacher, Founder of realmaker

Conclusion

If “Grüße” appears everywhere after a move instead of “Grüße”, that is not data loss but double encoding: the umlauts were converted from latin1 to UTF-8 once too often during cloning. The original only worked because two character set errors canceled each other out there – the move broke that balance. The solution is to calculate the unnecessary conversion back exactly once with a targeted SQL command. With a backup, a test on a copy and clearing the cache afterwards, the nightmare is over in no time – and with the switch to utf8mb4 it won’t come back.

Have mojibake repaired · More about our WordPress services

This post is part of our WordPress knowledge series from realmaker – your creative agency for film, web and AI solutions.