Slugs und Permalinks 2026: warum URL-Struktur noch zählt

Eine URL ist nicht nur eine technische Adresse — sie ist ein winziges Stück Markenkommunikation, ein SEO-Signal, ein Vertrauenshebel im Tweet und der erste Eindruck einer Seite in den Google-Suchergebnissen. Trotzdem wird der "Slug" — also der menschenlesbare Teil hinter dem letzten Schrägstrich — in vielen Redaktionsworkflows einfach durch ein CMS-Default generiert und nie wieder angefasst. Dieser Artikel zeigt, warum das ein vermeidbarer Fehler ist, was eine gute URL ausmacht, welche RFC-Standards dahinterstehen und wie du 2026 noch eine Permalink-Struktur baust, die in fünf Jahren immer noch funktioniert.

Anatomie einer URL: Host, Pfad, Query — wo der Slug lebt

Eine URL ist nach RFC 3986 in mehrere Bestandteile zerlegt: Schema (https), Host (calcsi.com), optional ein Port, ein Pfad (/blog/slugs-permalinks-seo), optional eine Query (?utm_source=twitter) und ein Fragment (#abschnitt). Der "Slug" im engeren Sinne ist das letzte Segment des Pfades — also das, was nach dem letzten Schrägstrich kommt und keine Erweiterung wie .html braucht. In einem klassischen WordPress-Setup ist der Slug das, was du im Editor neben dem Feld "Permalink" anpassen kannst.

RFC 3986 unterscheidet zwischen "unreserved" Zeichen (Buchstaben, Ziffern, sowie - . _ ~), die in URLs unverändert vorkommen dürfen, und "reserved" Zeichen (etwa : / ? # [ ] @ ! $ & ' ( ) * + , ; =), die eine syntaktische Bedeutung haben und außerhalb dieser Bedeutung percent-encoded werden müssen. Alles, was nicht unreserved ist und keine syntaktische Funktion hat — Leerzeichen, Umlaute, Emojis, kyrillische Zeichen — muss prozentual codiert werden. Aus einem Leerzeichen wird %20, aus dem deutschen ü wird %C3%BC. Browser blenden das oft für den Nutzer hübsch um, technisch sind das aber zwei sehr unterschiedliche Strings.

Warum Slugs für SEO immer noch zählen

Es ist Mode geworden zu behaupten, URLs seien für Google egal. Das stimmt so nicht. Im Dokument "URLs in Search" listet Google die URL-Struktur ausdrücklich als einen von vielen kleinen Faktoren auf. John Mueller von Google hat in mehreren Office-Hours-Sprechstunden bestätigt: Keyword-in-URL ist ein leichtes Signal, kein dominantes. Wer aber zwei vergleichbar gute Inhalte hat, einer unter /tools/p?id=4711 und einer unter /tools/percentage-calculator, hat im Snippet, im Backlink-Profil und im Klickverhalten messbare Vorteile.

Über SEO hinaus gibt es harte UX-Gründe für saubere Slugs: Eine URL, die man im Telefonat ansagen kann ("calcsi.com slash tools slash bmi-rechner"), schafft Vertrauen. Screenreader sprechen aussagekräftige URLs verständlich aus, kryptische Hash-IDs hingegen werden Buchstabe für Buchstabe vorgelesen. Analytics-Reports sind mit lesbaren Pfaden auf einen Blick interpretierbar, ohne dass man Slug-IDs gegen eine Tabelle joinen muss. Und in Slack-, Teams- oder Discord-Vorschauen sehen menschenlesbare URLs schlicht professioneller aus.

Anatomie eines "perfekten" Slugs

Es gibt kein offizielles SEO-Regelwerk, aber aus zwei Jahrzehnten Praxis (und vielen Google-Statements) hat sich ein robustes Muster herauskristallisiert:

• Länge: 3 bis 6 Wörter sind der Sweet Spot. Unter 3 wirkt der Slug zu generisch (/blog/seo), über 6 wird er unhandlich und die wichtigen Begriffe rutschen ans Ende, wo Google sie weniger stark wertet.
• Schreibung: ausschließlich Kleinbuchstaben. Server unter Linux behandeln /Blog und /blog als zwei verschiedene Pfade, was zu Duplicate-Content-Problemen führt. Wer beides zulässt, sollte mit einem 301-Redirect von Groß- auf Kleinschreibung normalisieren.
• Trenner: Bindestriche, niemals Unterstriche. Matt Cutts (damals Google Web Spam Lead) erklärte 2008 unmissverständlich, dass Google Bindestriche als Worttrenner liest, Unterstriche jedoch als Wortverbinder. Bis heute ist das Verhalten unverändert: my_calculator wird als ein Token "my_calculator" indexiert, my-calculator als zwei Tokens "my" und "calculator". Für SEO macht das einen großen Unterschied.
• Stoppwörter: für kurze, dichte URLs raus damit. Aus /how-to-calculate-vat wird /calculate-vat oder noch besser /vat-calculator. Englische Artikel (the, a, an), deutsche Artikel (der, die, das) und Präpositionen tragen wenig zur Bedeutung bei, machen die URL aber länger.
• Transliteration: Umlaute, Akzente und Sonderzeichen in ASCII übersetzen. ü wird zu ue, é zu e, ß zu ss. Das verhindert Encoding-Probleme beim Kopieren und Teilen und sieht in jedem Kontext lesbar aus.

Nicht-lateinische Schriften: Punycode, Percent-Encoding und der pragmatische Weg

Für Domains gibt es seit RFC 3492 das Punycode-Verfahren: München.de wird intern als xn--mnchen-3ya.de codiert. Browser zeigen die Originalform, DNS spricht aber das Punycode-Format. Für den Pfad gilt Percent-Encoding nach RFC 3986 — das ü im Pfad wird zu %C3%BC. Beides funktioniert technisch — aber in geteilten Snippets, in E-Mail-Tools, in Slack-Vorschauen und in handgetippten URLs ist die transliterierte ASCII-Variante schlicht zuverlässiger.

Für arabische, kyrillische, chinesische oder japanische Inhalte gilt die gleiche Abwägung. Eine arabische URL behält ihre Originalschrift, wenn sie im Browser geöffnet wird, sieht aber kopiert in eine Latin-1-Umgebung wie %D8%A7%D9%84%D9%82%D8%B1%D8%A2%D9%86 aus. Bei mehrsprachigen Sites empfiehlt sich daher der Locale-Prefix-Ansatz (calcsi.com/ar-eg/tools/...) mit transliteriertem Slug, statt nicht-lateinischer Zeichen direkt im Pfad. Unser eigener Slug-Generator arbeitet genau nach diesem Prinzip.

Beispiele aus der Praxis

Vom Original-Titel zum sauberen Slug — die folgenden Transformationen sind eine gute Faustregel für Redaktionsworkflows:

• "Über uns!" wird zu ueber-uns oder noch kompakter uber-uns. Das Ausrufezeichen fällt weg (kein semantischer Mehrwert), das ü wird transliteriert, alles klein.
• "Müller's Café" wird zu muellers-cafe. Der Apostroph entfällt, das ü wird zu ue, das é zu e — alle drei Operationen sind verlustfrei für die Lesbarkeit.
• "C++ Tutorial" wird zu cpp-tutorial. Die Plus-Zeichen sind reserved characters, Percent-Encoding (c%2B%2B-tutorial) ist hässlich, die etablierte ASCII-Konvention "cpp" für "C++" wird seit Jahrzehnten verstanden — und das ist genau, was du willst.
• "5 Tipps für besseren Schlaf" wird zu schlaf-tipps oder besserer-schlaf — niemals zur 1:1-Übersetzung mit Zahl am Anfang. Zahlen im Slug verraten den Format-Click-Bait und altern schlecht, sobald jemand den Artikel auf 7 Tipps erweitert.

Der Umzug einer URL: das 301-Tanzritual

Wenn du einen bestehenden Slug änderst, musst du den alten Pfad mit einem 301-Redirect ("moved permanently") auf den neuen Pfad weiterleiten. Sonst passiert dreierlei: (1) Alle Backlinks von externen Seiten zeigen ins Leere, du verlierst die Linkkraft. (2) Google nimmt die alte URL irgendwann aus dem Index und fängt mit der neuen bei null Vertrauen an — Rankings können einbrechen. (3) Lesezeichen und intern verteilte Direktlinks deiner Stammleser werden zu 404-Fehlern, und du verlierst Wiederbesucher. Ein 302-Redirect ("temporarily") gibt Linkkraft hingegen schlechter weiter — für einen permanenten Umzug ist 301 (oder 308) Pflicht.

Ebenfalls eine harte Designentscheidung: die Trailing-Slash-Politik. /blog/slugs-permalinks-seo und /blog/slugs-permalinks-seo/ sind aus Web-Standard-Sicht zwei verschiedene URLs. Entscheide dich für genau eine Variante und leite die andere per 301 darauf um. Welche Variante du wählst, ist Geschmackssache — entscheidend ist Konsistenz, sonst hast du zwei Versionen jeder Seite im Index. Eine ähnliche Konsistenzentscheidung betrifft www-vs.-non-www: Beide gehören per 301 auf eine Variante normalisiert.

Praktische Permalink-Strukturen für 2026

Für die meisten Sites bewährt sich eine flache Hierarchie: /blog/slug, /tools/slug, /about, /pricing. Tief verschachtelte Pfade wie /blog/2024/06/04/category/slug sehen historisch nach WordPress aus, kosten aber bei jeder URL-Änderung Redirect-Aufwand und sind aus Mobile-Sicht in den Suchergebnissen unleserlich. Chrome auf dem Smartphone zeigt seit Jahren nur noch die Domain — ein langer Pfad wird gar nicht mehr angezeigt. Wenn die Kategorie für die Inhalts-Architektur wichtig ist (z. B. /tools/finance/vat-calculator), nutze sie — aber nie tiefer als zwei Ebenen unter der Root.

Daten im URL-Pfad sind 2026 eine schlechte Idee für evergreen content. Eine URL wie /blog/2024/seo-tipps signalisiert dem Leser zwei Jahre später: Veraltet. Selbst wenn du den Artikel aktualisierst, wirkt der Pfad alt — und beim Umstieg auf evergreen URLs musst du jede Seite redirecten. Für hochfrequenten Content (Live-Berichte, Wahlausgänge, Sport-Tagesergebnisse) ist ein Datums-Slug dagegen ehrlich und sinnvoll. Bei Content, der von einer Datenbank-ID dominiert wird (z. B. 100.000+ Produkte), ist der hybride Slug aus ID und Klarnamen ein guter Kompromiss: /product/12345-running-shoes-nike-air bleibt eindeutig, ist aber menschenlesbar und enthält Keywords.

Häufige Fragen

Soll ich das Datum in die URL aufnehmen?

Für evergreen content: Nein. Ein Datum im Pfad altert sofort sichtbar, und wenn du den Artikel später aktualisierst, sieht die URL trotzdem alt aus. Für News, Live-Berichte oder Tagesereignisse ist ein Datums-Slug dagegen sinnvoll — er sagt dem Leser ehrlich "Stand: 4. Juni 2026". Faustregel: Wenn der Inhalt in drei Jahren noch relevant sein soll, kein Datum in den Slug.

Soll die Kategorie in der URL stehen?

Kommt drauf an. Pro: Eine Kategorie wie /finance/vat-calculator macht die Site-Struktur klar und gibt schwachen kontextuellen Vorteil für Long-Tail-Keywords. Contra: Wenn du den Artikel später in eine andere Kategorie verschiebst (etwa /taxes/vat-calculator), musst du 301-redirecten und verlierst etwas Linkkraft. Praxisempfehlung: maximal eine Kategorie-Ebene unter der Root, und nur wenn die Kategorie stabil ist. Wenn du Kategorien als CMS-Filter brauchst, aber nicht in URLs willst, mach sie zu einem internen Tag.

Wie funktionieren WordPress-Permalink-Codes?

WordPress nutzt in der Permalink-Einstellung eine kleine Templating-Sprache mit Prozent-Variablen. Die wichtigsten: %postname% für den Slug, %year%, %monthnum%, %day% für Datumsteile, %category% für die Hauptkategorie, %post_id% für die numerische ID, %author% für den Autor-Slug. Die SEO-freundlichste Standardeinstellung ist /%postname%/ — flache Hierarchie, nur der Slug, kein Datum. Wer eine Kategorieebene möchte, nutzt /%category%/%postname%/. Wichtig: Permalinks rückwirkend zu ändern bedeutet immer eine Welle von Redirects — am besten einmal richtig entscheiden und dann nicht mehr anfassen.