Was ist ein URL-Slug?

Ein guter Slug erfüllt wenige Regeln, aber alle gleichzeitig. Er sollte kurz sein: je weniger Wörter die Seite beschreiben, desto besser liest er sich im Browser und im Suchergebnis. Er sollte beschreibend sein: wer nur die URL sieht, ohne die Seite geöffnet zu haben, soll sich eine vernünftige Vorstellung davon machen können, was ihn erwartet. Und er sollte das Ziel-Keyword der Seite enthalten, die zwei, drei Wörter, die zusammenfassen, worum es geht, ohne Varianten oder Synonyme drumherum zu häufen.

Diese Seite zeigt das an der eigenen URL-Struktur. Auf Spanisch: https://zds.es/que-es-url-slug. Auf Deutsch: https://zds.es/de/was-ist-url-slug/. Auf Englisch: https://zds.es/en/what-is-url-slug/. In allen drei Fällen ist der letzte Abschnitt kurz, komplett in Kleinbuchstaben, ohne Umlaute oder Sonderzeichen, und die Wörter sind mit Bindestrichen getrennt, nicht mit Unterstrichen. Google behandelt den Bindestrich (-) als Worttrenner und liest „url" und „slug" als zwei eigenständige Begriffe; den Unterstrich (_) behandelt Google als verbindendes Zeichen, sodass „url_slug" als ein einziges Wort gelesen würde und die Relevanz jedes einzelnen Begriffs verwässert.

Das Präfix /de/ oder /en/ vor dem Slug in der deutschen und englischen Version gehört nicht zum Slug selbst, sondern zum Pfad, der die Sprache der Seite markiert. Der Slug ist nur der letzte Abschnitt, der von Artikel zu Artikel innerhalb derselben Sprache wechselt.

Der dritte Fall verdient eine eigene Anmerkung, weil er nicht immer ein offensichtlicher Fehler ist. Großbuchstaben, Umlaute und Unterstrich zerstören die Seite nicht, erzeugen aber ein reales Problem: Die meisten Server behandeln /Akku-Bohrschrauber und /akku-bohrschrauber als zwei verschiedene URLs, nicht als dieselbe mit anderer Schreibweise. Und ein Umlaut in der URL landet in der Adresszeile fast immer kodiert, etwa als %C3%B6 für ö, was niemand von Hand tippt oder sich merkt.

Ein kurzer, klarer Slug zahlt sich auch dort aus, wo ihn niemand technisch analysiert: In der Ergebnisliste einer Suchmaschine steht die URL sichtbar unter dem Titel, und wer sie überfliegt, entscheidet in Sekundenbruchteilen, ob der Klick lohnt. Ein Slug wie /akku-bohrschrauber-test wirkt vertrauenswürdig, weil er genau das ankündigt, was folgt. Eine lange Kette aus IDs oder Parametern wirkt dagegen wie ein technischer Zufallstreffer, selbst wenn die dahinterliegende Seite inhaltlich gut ist.

Beim Streichen von Füllwörtern lohnt sich ein Blick auf das eigene Beispiel dieses Glossars: Alle deutschen Slugs beginnen mit „was-ist-", wie bei „was-ist-url-slug". Das ist kein Widerspruch zur Regel, Füllwörter zu vermeiden, sondern eine bewusste, durchgängige Konvention der ganzen Seite, die das Frage-Antwort-Format jedes Artikels schon in der URL ankündigt. Füllwörter vermeiden heißt, keine Begriffe einzubauen, die für eine konkrete URL nichts bringen, nicht ein Muster zu brechen, das die Seite selbst absichtlich in allen Artikeln durchhält.

Den Slug einer bereits veröffentlichten Seite zu ändern ist keine einfache Textkorrektur: Es ändert die komplette URL, und eine neue URL ist sowohl für den Server als auch für Google eine andere Ressource als die vorherige. Wechselt ein Artikel von /bohrschrauber-guide-2024 zu /bester-akku-bohrschrauber, existiert die erste Adresse in dieser Form nicht mehr. Wer versucht, sie aufzurufen, sei es eine Person mit gespeichertem Link oder der Crawler von Google, stößt auf einen Fehler, wenn sonst nichts unternommen wird.

Hier kommt der Redirect 301 ins Spiel: das Werkzeug, das signalisiert, dass diese URL dauerhaft auf die neue Adresse umgezogen ist, und das sowohl Besucher als auch das über Links und Crawling-Historie aufgebaute Ranking-Signal mitnimmt. Ohne diesen Redirect ist der Slug-Wechsel nicht neutral: Die Seite verliert die Spur dessen, was unter der alten URL aufgebaut wurde, und startet unter der neuen fast bei null.

Das wiegt bei externen Links noch schwerer. Interne Links lassen sich von Hand anpassen, einen nach dem anderen, in wenigen Minuten. Backlinks, die andere Websites auf die alte URL gesetzt haben, liegen nicht in der eigenen Kontrolle: Niemand geht in einen drei Jahre alten Blogartikel und korrigiert den Link, nur weil der Slug gewechselt hat. Dieser Backlink zeigt für immer auf die ursprüngliche Adresse, und nur ein Redirect 301 auf genau dieser Adresse sorgt dafür, dass der Wert dieses Links tatsächlich bei der neuen Seite ankommt.

Die Mechanik des Redirects selbst, wie er eingerichtet wird, der Unterschied zum temporären 302, wie man prüft, dass der Server wirklich den Code 301 zurückgibt, steht ausführlich im eigenen Artikel zu Redirect 301. Hier zählt nur die Schlussfolgerung, die den Slug direkt betrifft: ihn ohne den passenden Redirect zu ändern, ist keine Kleinigkeit, sondern ein Verzicht auf das Ranking, das diese URL bereits angesammelt hatte.

Der Canonical Tag wird häufig mit der Lösung für einen Slug-Wechsel verwechselt, ist es aber nicht. Canonical ist für eine andere Situation gedacht: wenn derselbe Inhalt, oder ein sehr ähnlicher, unter mehreren URLs erreichbar ist, die beide weiter funktionieren müssen, zum Beispiel eine Produktseite mit und ohne Farbparameter. Dort zeigt Canonical Google an, welche der beiden Versionen bevorzugt wird, lässt aber beide erreichbar.

Ein Slug-Wechsel ist das genaue Gegenteil: Die alte URL muss nicht erreichbar bleiben, sie muss wirklich verschwinden und Platz für die neue machen. Ein Canonical auf der alten URL, das auf die neue zeigt, statt eines Redirects, hält diese alte URL am Leben und ist darauf angewiesen, dass Google das Signal respektiert, das Google als starke Empfehlung behandelt, nicht als Befehl. Ein Redirect 301 lässt diesen Spielraum nicht zu: Die alte URL antwortet nicht mehr eigenständig, und der Traffic landet direkt bei der neuen.

Die praktische Regel trennt beide Fälle eindeutig. Müssen beide URLs weiter existieren, gilt Canonical. Muss die alte URL verschwinden, weil sich der Slug wirklich geändert hat, gilt Redirect 301.

Ein zusätzlicher Punkt hilft, beide Werkzeuge nicht zu verwechseln: Jede Seite sollte ein Self-Referencing Canonical tragen, das auf die eigene URL zeigt, auch diese hier. Das bestätigt die Referenzadresse, solange sich nichts ändert. Ändert sich der Slug wirklich, zeigt dieses Self-Referencing Canonical künftig auf die neue URL, weil die Seite jetzt dort lebt, und es ist der Redirect 301, nicht das Canonical, der dafür sorgt, dass die alte URL nicht mehr eigenständig antwortet.

Wer beide Werkzeuge gleichzeitig einsetzt, richtet oft mehr Schaden an als mit nur einem falschen: ein Canonical von der alten auf die neue URL, kombiniert mit einem 301 auf dieselbe Adresse, ist doppelt gemoppelt und überflüssig, denn sobald die Weiterleitung greift, sieht Google die alte URL ohnehin nicht mehr eigenständig an. Der Redirect 301 allein reicht für einen echten Slug-Wechsel vollständig aus.

• Lege den endgültigen Slug vor der Veröffentlichung fest, nicht danach: eine nachträgliche Änderung kostet immer mehr, als ihn gleich richtig zu wählen.
• Baue das Haupt-Keyword der Seite ein, aber nur das; wiederhole keine Varianten oder Synonyme im selben Slug.
• Verwende nur Kleinbuchstaben, Bindestriche als Worttrenner und keine Sonderzeichen, Umlaute oder ß.
• Streiche Artikel, Präpositionen und Füllwörter ohne eigene Bedeutung, außer sie gehören zu einer bereits etablierten Konvention der übrigen Seite.
• Halte ihn kurz: passt der Slug nicht vollständig, ohne abgeschnitten zu werden, in eine Zeile eines Suchergebnisses, stecken wahrscheinlich überflüssige Wörter drin.
• Musst du ihn trotzdem ändern, richte den Redirect 301 von der alten zur neuen URL im selben Moment ein, in dem du die Änderung veröffentlichst, nicht erst Tage später.
• Prüfe interne Links, die auf die alte URL zeigen, und aktualisiere sie auf die neue Adresse, statt sie über die Weiterleitung laufen zu lassen.

• Den Slug zur „Verbesserung" ändern, ohne den passenden Redirect 301 einzurichten, und die alte URL herrenlos zurücklassen.
• Unterstriche statt Bindestriche zum Trennen von Wörtern nutzen, wodurch Google den Slug als ein einziges Wort liest.
• Datum, interne ID oder Session-Parameter in den Slug packen und so eine URL erzeugen, die schnell veraltet oder sich bei jedem Aufruf ändert.
• Zu viele Keywords in denselben Slug packen, in der Annahme, dadurch für alle gleichzeitig zu ranken, obwohl das nur die Lesbarkeit verschlechtert.
• Einen Slug-Wechsel mit einer Duplicate-Content-Situation verwechseln und ein Canonical einsetzen, wo ein Redirect 301 nötig gewesen wäre.
• Großbuchstaben oder Umlaute in der URL belassen und dadurch ohne echten Grund zwei erreichbare Varianten derselben Adresse erzeugen.