Umlaute in URLs und Domains: ä, ö, ü, ß und SEO

Kurze Antwort: Technisch funktionieren Umlaute in URLs, Google versteht sie und indexiert sie. Trotzdem ist für die meisten deutschen Websites die transliterierte Schreibweise (ae, oe, ue, ss) im Pfad die robustere Wahl, und bei der Domain ist sie es fast immer. Der Grund ist nicht das Ranking, sondern das, was mit dem Link passiert, sobald er deine Seite verlässt.

Dieser Beitrag klärt, wie ä, ö, ü und ß in einer Adresse tatsächlich codiert werden, wie Google beide Schreibweisen behandelt, wo im Alltag Probleme entstehen und wie du eine Entscheidung triffst, die du in fünf Jahren nicht bereuen musst. Die allgemeine Frage, wie ein guter Slug aussieht, ist hier nicht das Thema. Es geht ausschließlich um die Sonderzeichen.

Wie Umlaute in einer URL wirklich aussehen

Eine URL darf nach dem Standard (RFC 3986) nur einen kleinen Satz ASCII-Zeichen enthalten. Ein ä, ö, ü oder ß gehört nicht dazu. Was du in der Adresszeile siehst, ist deshalb eine Anzeigeform. Übertragen und gespeichert wird etwas anderes: Das Zeichen wird als UTF-8 in Bytes zerlegt und jedes Byte als Prozentcode geschrieben. Aus dem ä werden die zwei Bytes C3 A4, also %C3%A4.

Die Adresse example.de/größe-tabelle wird dadurch zu example.de/gr%C3%B6%C3%9Fe-tabelle. Browser zeigen dir in der Regel die lesbare Fassung, der Server bekommt die codierte. Sobald du den Link kopierst und in ein Programm einfügst, das nicht mitdenkt, siehst du die codierte Variante mit all ihren Prozentzeichen.

Bei Domainnamen funktioniert es anders. Sie werden nicht prozentcodiert, sondern per Punycode in ASCII umgewandelt und mit dem Präfix xn-- versehen. Aus bücher.de wird xn--bcher-kva.de, aus müller.de wird xn--mller-kva.de. Diese Form nutzen DNS und Zertifikate intern. Den Mechanismus nennt man IDN, internationalisierte Domainnamen. Die Registry für .de erlaubt Umlaute und seit 2010 auch das ß.

Die wichtigsten Codierungen auf einen Blick:

• ä wird zu %C3%A4, Ä zu %C3%84
• ö wird zu %C3%B6, Ö zu %C3%96
• ü wird zu %C3%BC, Ü zu %C3%9C
• ß wird zu %C3%9F
• In Domains: Punycode mit xn--, etwa xn--bcher-kva.de

Wie Google beide Schreibweisen behandelt

Google crawlt und indexiert URLs mit Umlauten ohne Weiteres. In der eigenen Dokumentation zur URL-Struktur rät Google dazu, Zeichen außerhalb von ASCII als UTF-8 zu codieren und bei Domains Punycode zu verwenden. Der Suchmaschine ist es also egal, ob du gr%C3%B6%C3%9Fe oder groesse schreibst, solange die Adresse gültig ist und die Seite liefert.

Ein dokumentierter Rankingvorteil für eine der beiden Varianten existiert nicht. Wer dir erzählt, Umlaute im Slug würden für deutsche Suchanfragen bevorzugt oder bestraft, stützt sich auf Vermutungen. Belegt ist nur das technische Verhalten: Google verarbeitet die decodierte Form und zeigt sie in den Ergebnissen häufig lesbar an, auch wenn im Hintergrund die Prozentcodierung läuft.

Wichtig ist der Unterschied zwischen einem Ranking-Faktor und einem Nebeneffekt. Ein Wort im Slug hilft Google, das Thema einer Seite einzuordnen, aber es ist ein schwaches Signal neben Titel, Überschriften und Inhalt. Ob dieses Wort mit ue oder ü geschrieben ist, verändert die Stärke dieses Signals nicht messbar. Die Suchmaschine kennt die Gleichsetzung von ü und ue ohnehin aus den Suchanfragen selbst, denn viele Menschen tippen auf Tastaturen ohne deutsche Belegung.

Der eigentliche Hebel liegt deshalb woanders: Google behandelt zwei unterschiedliche Zeichenfolgen als zwei unterschiedliche URLs. /gr%C3%B6%C3%9Fe und /groesse sind für den Crawler zwei Adressen. Sind beide erreichbar und liefern denselben Inhalt, entsteht Duplicate Content, und Google wählt selbst, welche Variante es als kanonisch führt. Genau diese Entscheidung willst du nicht dem Zufall überlassen.

Ein Beispiel durchgespielt: Ratgeberseite „Grüne Fußmatten“

Angenommen, ein Onlineshop veröffentlicht eine Ratgeberseite mit dem Titel „Grüne Fußmatten für den Flur“. Das CMS erzeugt daraus je nach Einstellung vier mögliche Slugs: gruene-fussmatten, grüne-fußmatten, grne-fumatten oder gr-ne-fu-matten. Die ersten beiden sind sauber, die letzten beiden sind Folgen einer Zeichenbehandlung, die das Sonderzeichen einfach verschluckt oder durch einen Bindestrich ersetzt. Solche Slugs fallen oft erst Monate später auf, etwa wenn jemand die Adresse in einem Bericht sieht.

Nun kommt die Verbreitung hinzu. Die Marketingabteilung verschickt den Link im Newsletter, eine Redaktion verlinkt ihn aus einem Artikel, ein Kunde teilt ihn per Messenger. Bei der ASCII-Variante sieht jede Stelle exakt dieselbe Zeichenfolge. Bei der Umlautvariante kann der Newsletter-Dienst die codierte Form erzeugen, die Redaktion die lesbare, und der Messenger schneidet hinter dem ü ab. In der Auswertung tauchen dann drei Schreibweisen derselben Seite auf, und ein Teil der Besuche landet auf einem 404.

Die Gegenmaßnahme ist immer dieselbe: eine bevorzugte Form festlegen, alle anderen Schreibweisen per 301 auf sie umleiten und im Canonical der Seite nur die bevorzugte Form nennen. Teste das mit einem einfachen Abruf der lesbaren, der codierten und der transliterierten Adresse und kontrolliere, ob jeweils dieselbe Zieladresse und der Statuscode 301 beziehungsweise 200 zurückkommen.

Das eigentliche Problem: Links außerhalb des Browsers

Die Schwierigkeiten mit Umlauten zeigen sich selten in der Suche, sondern dort, wo Links weitergegeben werden. Ein Link mit ö im Pfad ist im Browser schön lesbar, in der Praxis aber an vielen Stellen anfälliger als ein reiner ASCII-Link.

Wenn jemand die Adresse aus der Browserleiste in eine E-Mail, einen Messenger oder ein Dokument kopiert, entscheidet das Zielprogramm, wie es mit dem Zeichen umgeht. Manche fügen die lesbare Form ein, manche die codierte, und manche erkennen den Link nur bis zum ersten Sonderzeichen. Dann endet der anklickbare Teil mitten im Wort, und der Empfänger landet auf einer Fehlerseite oder auf einer anderen URL als gedacht.

Dazu kommen Systeme, die Umlaute nicht sauber durchreichen: ältere Redirect-Module, Tracking-Parameter-Bauer, Newsletter-Tools, QR-Code-Generatoren und Social-Media-Vorschauen. Auch in gedruckten Medien ist die Situation unbequem. Wer eine Adresse mit ü von einem Plakat abtippt, muss wissen, ob er ue oder ü eingeben soll, und bei Domains kommt auf nicht-deutschen Tastaturen noch die Eingabe des Sonderzeichens selbst hinzu.

Auch das Backlink-Profil hängt davon ab. Andere Seiten verlinken dich, und wenn sie dabei eine codierte, eine lesbare oder eine falsch abgeschnittene Variante verwenden, verteilt sich die Linkkraft auf mehrere Adressen, sofern du nicht sauber weiterleitest. Jede zusätzliche Schreibvariante ist eine weitere Stelle, an der etwas schiefgehen kann.

Die Domain: Umlaut-IDN oder Transliteration

Bei Slugs kannst du Fehler später mit Weiterleitungen beheben. Bei der Domain ist jede Änderung teurer, weil sie Marke, E-Mail-Adressen, Backlinks und Vertrauen berührt. Deshalb verdient diese Entscheidung mehr Gewicht als die über einen einzelnen Pfad.

Eine IDN wie bücher.de funktioniert im Browser und bei Google. Probleme machen vor allem die Randbereiche. E-Mail-Adressen mit Umlaut in der Domain werden nicht von jedem System akzeptiert, Formulare lehnen sie mitunter als ungültig ab, und ältere Mailserver oder Bibliotheken kennen nur die Punycode-Form. Ein Zertifikat wird immer auf die Punycode-Schreibweise ausgestellt, was für den Nutzer unsichtbar bleibt, bei der Konfiguration aber für Verwirrung sorgt.

Hinzu kommt ein Sicherheitsthema: Bei Unicode-Domains lassen sich optisch ähnliche Zeichen vertauschen, sogenannte Homographen. Browser zeigen deshalb in manchen Fällen die Punycode-Fassung statt der lesbaren an, wenn ihre Schutzregeln anschlagen. Für seriöse deutsche Umlautdomains ist das selten ein Problem, doch die Regeln sind Sache der Browser und nicht deine.

Praktisch empfiehlt sich meist folgender Weg: Die Hauptdomain wird ohne Sonderzeichen gewählt, etwa buecher.de oder die ss-Variante bei ß. Wer die Umlautvariante zusätzlich besitzt, weil sie getippt werden könnte, registriert sie und leitet sie per 301 auf die Hauptdomain um. So gewinnst du den Komfort für Nutzer, die das ü eintippen, ohne dass zwei Domains konkurrieren.

Umgekehrt kann es gute Gründe für die Umlautdomain als Hauptadresse geben, etwa wenn die Marke selbst das ü enthält und auf Werbematerial prominent steht. Dann gilt: genau eine Variante als kanonische Domain festlegen, die andere dauerhaft weiterleiten und überall in internen Links, Sitemaps, Canonicals und hreflang-Angaben konsequent dieselbe Form verwenden.

Transliterieren, aber richtig: die Regeln für den Slug

Wenn du dich für die ASCII-Variante entscheidest, brauchst du feste Regeln, sonst entstehen Wildwuchs und Duplikate. Die im Deutschen übliche Ersetzung lautet ä zu ae, ö zu oe, ü zu ue und ß zu ss. Sie folgt der Ersatzschreibung, die auch in Pässen und auf Schildern gilt, und ist dadurch für deutsche Leser sofort verständlich.

Der häufigste Fehler ist das schlichte Weglassen des Umlauts durch ein automatisches Slug-Werkzeug. Aus „für“ wird dann fur, aus „schön“ wird schon, und beides sind andere deutsche Wörter oder Nichtwörter. Noch schlimmer sind Systeme, die das Sonderzeichen durch einen Bindestrich ersetzen: Aus „Gemüse“ wird gem-se. Prüfe die Slug-Erzeugung deines CMS deshalb einmal gezielt mit Testtiteln, die alle vier Zeichen enthalten, in Groß- und Kleinschreibung.

Achte außerdem auf Großbuchstaben: Das Wort „Übersicht“ beginnt mit Ü, der Slug soll aber durchgehend klein sein, also uebersicht. Das große ẞ ist im Alltag selten, wird aber von manchen Systemen zu SS oder ss umgesetzt. Lege dafür eine Regel fest und teste sie.

Eine Entscheidung gehört ebenfalls in das Regelwerk: Wörter wie „Masse“ und „Maße“ fallen beim Transliterieren zu masse zusammen. Das ist bei Slugs selten tragisch, weil der Kontext die Bedeutung klärt, aber innerhalb einer Website sollte kein Slug doppelt vergeben werden. Kollisionen lassen sich mit einem Zusatzwort im Slug lösen.

Wenn du schon Umlaute in URLs hast: Stolperfallen und Umstieg

Viele Websites haben bereits Umlaut-URLs, etwa durch WordPress-Voreinstellungen, Shopsysteme oder importierte Datenbestände. Hier ist die Frage nicht, was ideal wäre, sondern ob sich ein Umbau lohnt. Solange alles konsistent ist, die Seiten ranken und die Links funktionieren, gibt es keinen zwingenden Grund für eine Migration. Jede URL-Änderung erfordert saubere 301-Weiterleitungen, muss von Google neu verarbeitet werden und birgt das Risiko, Rankings vorübergehend zu verlieren.

Prüfe stattdessen diese typischen Fehlerquellen:

• Doppelte Erreichbarkeit: Sind sowohl die Umlaut- als auch die ae-Variante erreichbar, ohne dass eine auf die andere weiterleitet? Dann brauchst du eine 301-Weiterleitung und ein Canonical auf die bevorzugte Form.
• Groß- und Kleinschreibung der Prozentcodes: %C3%BC und %c3%bc sind technisch gleichwertig, werden von manchen Systemen aber als unterschiedliche Adressen behandelt. Normalisiere auf Großbuchstaben, wie es der Standard empfiehlt.
• Unicode-Normalisierung: Ein ü kann als ein einzelnes Zeichen oder als u plus kombinierendem Trema gespeichert sein. Die beiden sehen gleich aus, ergeben aber unterschiedliche Bytefolgen. Das passiert besonders bei Dateinamen, die auf dem Mac entstanden sind, und bei kopierten Texten. Der Slug sollte in einer einheitlichen Form gespeichert werden, üblicherweise NFC.
• Rewrite-Regeln: Apache und nginx vergleichen Muster je nach Konfiguration mit der decodierten oder der codierten Adresse. Weiterleitungsregeln, die Umlaute enthalten, müssen deshalb getestet werden, und zwar mit dem tatsächlichen Request und nicht nur im Editor.
• Sitemap und Canonical: Die URLs in der XML-Sitemap müssen UTF-8-codiert und korrekt maskiert sein und exakt der Form entsprechen, die im Canonical steht. Weichen sie voneinander ab, sendest du widersprüchliche Signale.
• Auswertung: In Search Console und Analytics tauchen Umlaut-URLs in prozentcodierter Form auf. Wer Berichte filtert, muss nach der codierten Fassung suchen oder die Reports decodieren.

So entscheidest du: eine Faustregel für neue Projekte

Für eine neue deutschsprachige Website spricht fast alles für ASCII im Pfad und in der Domain: ae, oe, ue, ss. Die Adresse ist überall kopierbar, lässt sich in jeder Umgebung fehlerfrei verarbeiten und erzeugt keine zweite Schreibweise, um die du dich kümmern musst. Der Verlust an Lesbarkeit ist minimal, denn deutsche Leser kennen die Ersatzschreibung.

Umlaute im Pfad sind vertretbar, wenn dein Publikum sie erwartet und dein Redaktionssystem sie konsequent behandelt. Das gilt etwa bei enzyklopädischen Angeboten, die seit Jahren so arbeiten. Ein Wechsel lohnt dort nicht. Ein Neustart mit dieser Variante ist dagegen selten begründet.

Nimm die Entscheidung bewusst und einmalig, halte sie in einer kurzen Richtlinie fest und setze sie technisch durch: im Slug-Generator, in den Weiterleitungsregeln, im Canonical und in der Sitemap. Ist das erledigt, spielt die Wahl für die Suche keine große Rolle mehr, denn was zählt, sind eindeutige, stabile Adressen.