Trailing Slash und SEO: mit oder ohne Schrägstrich?

Ja, für Google sind /seite und /seite/ grundsätzlich zwei verschiedene URLs. Der Schrägstrich am Ende des Pfads ist Teil der Adresse, und ein Server darf unter beiden Varianten unterschiedliche Inhalte ausliefern. Bei der Startseite ist das anders: example.com und example.com/ sind identisch, weil der Pfad dort immer mindestens aus einem Schrägstrich besteht. Bei allen tieferen Seiten zählt die Schreibweise.

Wirklich schädlich ist der Schrägstrich nicht. Ein Ranking-Bonus für die eine oder andere Variante existiert nicht. Das Problem entsteht erst, wenn beide Varianten gleichzeitig mit demselben Inhalt antworten, wenn intern mal so und mal so verlinkt wird oder wenn Sitemap, Canonical und Weiterleitung sich widersprechen. Dann verteilen sich Signale auf zwei Adressen, Crawl-Budget wird doppelt verbraucht, und Google muss raten, welche Version die richtige ist. Dieser Beitrag zeigt, wie du prüfst, ob das bei dir passiert, wie du dich für eine Variante entscheidest und wie du sie technisch durchsetzt.

Warum Google beide Varianten als getrennte URLs behandelt

Eine URL besteht aus Schema, Host, Pfad und optional Query und Fragment. Der Pfad /blog/artikel unterscheidet sich vom Pfad /blog/artikel/ durch ein Zeichen, und nach den Regeln für URLs sind das zwei verschiedene Ressourcen. Historisch hat der Schrägstrich eine Bedeutung: Er kennzeichnet ein Verzeichnis, während ein Pfad ohne Schrägstrich eine Datei meint. Webserver wie Apache haben dieses Verhalten lange eingebaut, und daher stammt die Gewohnheit, Verzeichnisse mit Schrägstrich zu schreiben.

Heute hat diese Unterscheidung bei den meisten Websites keine Bedeutung mehr. Ein CMS erzeugt die Seite aus einer Datenbank, und ob die Adresse mit oder ohne Schrägstrich endet, ist reine Konfigurationssache. Trotzdem prüft Google die Adressen zunächst getrennt. Jede Variante wird einzeln gecrawlt, und erst danach entscheidet die Kanonisierung, welche als Hauptversion gilt. Sind beide Varianten inhaltlich identisch, erkennt Google das in der Regel und fasst sie zusammen. Verlassen solltest du dich darauf aber nicht, denn die Auswahl der kanonischen URL ist ein Signalmix und keine Garantie.

Dazu kommt ein Effekt, der gern unterschätzt wird: Jede doppelte Adresse wird vom Crawler angefragt. Bei einer kleinen Website fällt das nicht ins Gewicht. Bei einem Shop mit zehntausenden Produkt- und Filterseiten verdoppelt sich die Zahl der Kandidaten, und die Zeit, die der Bot auf deiner Domain verbringt, wird für Adressen verbraucht, die keinen zusätzlichen Wert liefern.

Der Unterschied zeigt sich im Alltag an mehreren Stellen. In der Search Console tauchen beide Varianten als eigene Zeilen auf. Im Bericht zur Seitenindexierung findest du dann Meldungen wie „Duplikat, Google hat eine andere Seite als der Nutzer als kanonische Seite bestimmt“. In Analytics werden Seitenaufrufe auf zwei Zeilen verteilt, und Linkprofil-Tools zählen Backlinks getrennt, je nachdem, wie andere Seiten auf dich verlinkt haben.

Mit oder ohne Schrägstrich: wie du dich entscheidest

Aus Sicht der Suchmaschine ist keine Variante besser. Die Entscheidung folgt deshalb praktischen Kriterien, und der wichtigste Grundsatz lautet: Nimm die Variante, die du mit dem geringsten Aufwand konsistent durchsetzen kannst, und ändere sie danach nicht mehr. Ein nachträglicher Wechsel auf einer bestehenden Website bedeutet, dass jede URL weitergeleitet werden muss, und jede Weiterleitung ist ein Risiko, das du dir ersparen kannst.

Folgende Überlegungen helfen bei einer neuen Website oder einer Migration:

• Bestehende URLs zuerst: Läuft die Website seit Jahren, richte dich nach der Variante, unter der die meisten indexierten Seiten und Backlinks bereits erreichbar sind. Das minimiert Weiterleitungen.
• Technische Vorgabe der Plattform: Viele Systeme haben einen Standard. WordPress hängt bei der üblichen Permalink-Struktur einen Schrägstrich an, Next.js lässt ihn standardmäßig weg. Gegen den Standard zu arbeiten erzeugt Reibung, etwa bei Plugins, die eigene Links bauen.
• Dateiendungen: Adressen wie /datei.pdf oder /bild.jpg enden nie mit Schrägstrich. Wer alles mit Schrägstrich versieht, muss solche Ausnahmen sauber behandeln, sonst entstehen Fehlerseiten.
• Verzeichnisstruktur: Wenn Kategorien echte Übersichtsseiten sind und darunter Einzelseiten liegen, wirkt die Schreibweise mit Schrägstrich logisch. Bei flachen Strukturen ist die Variante ohne Schrägstrich oft kürzer und lesbarer.
• Statische Hosts: Plattformen, die Seiten als Ordner mit index.html ausliefern, verhalten sich mit Schrägstrich am natürlichsten. Prüfe die Dokumentation deines Hosts, bevor du gegen sein Verhalten konfigurierst.

Durchsetzen per 301-Weiterleitung

Die Entscheidung allein schützt nicht. Die abgelehnte Variante muss dauerhaft auf die gewählte weiterleiten, und zwar per 301 oder 308, damit Crawler und Nutzer auf derselben Adresse landen. Ein 302 ist hier die falsche Wahl, denn er signalisiert etwas Vorübergehendes. Wichtig ist außerdem, dass die Query erhalten bleibt: /produkte?farbe=rot muss zu /produkte/?farbe=rot werden, nicht zu /produkte/.

Bei Apache erledigt das meist eine Regel in der .htaccess. Sinngemäß prüfst du, ob die angefragte Adresse kein Verzeichnis und keine Datei ist und nicht mit Schrägstrich endet, und leitest dann mit dem Schrägstrich weiter. Für die entgegengesetzte Richtung entfernst du ihn. Beachte, dass das Modul mod_dir bei echten Verzeichnissen von sich aus auf die Variante mit Schrägstrich umleitet. Wer die Variante ohne Schrägstrich will, muss dieses Verhalten bewusst abschalten oder überschreiben, sonst laufen zwei Regeln gegeneinander.

Bei nginx steuerst du es in der Serverkonfiguration mit einer rewrite-Anweisung, die den Pfad prüft und mit dem Status 301 weiterleitet. Auch hier gilt: Schließe Dateien mit Endung aus, und teste Sonderfälle wie Adressen, die auf Schnittstellen oder Verwaltungsbereiche zeigen. Bei Anwendungen hinter einem Reverse Proxy entscheidet oft das Backend und nicht der Proxy, dann gehört die Regel in die Anwendung.

Ein Wort zur Statusfamilie: 301 und 308 gelten beide als dauerhaft. Der Unterschied liegt darin, dass 308 die Anfragemethode beibehält, was vor allem bei Formularen und Schnittstellen eine Rolle spielt. Für normale Seitenaufrufe sind beide gleichwertig, und Frameworks wählen häufig von sich aus den einen oder anderen Code. Wichtig ist nur, dass du nie versehentlich einen temporären Code ausspielst, etwa weil eine Hosting-Oberfläche Weiterleitungen standardmäßig als vorläufig anlegt.

Der häufigste Fehler sind Weiterleitungsketten. Stell dir eine Anfrage an http://example.com/seite vor. Die erste Regel leitet auf https um, die zweite auf www, die dritte ergänzt den Schrägstrich. Drei Sprünge statt einem kosten Zeit, und Google folgt bei langen Ketten nicht endlos. Baue die Regeln so, dass jede Anfrage in einem einzigen Schritt auf die endgültige Adresse zeigt. Mit einem Werkzeug wie curl und der Option -I siehst du jeden Sprung einzeln.

Canonical und interne Signale in Einklang bringen

Die Weiterleitung ist die stärkste Maßnahme, aber sie ist nicht die einzige. Das Canonical-Tag im Kopf jeder Seite benennt die bevorzugte Adresse und sollte exakt die Schreibweise enthalten, die du durchsetzt. Ein typischer Fehler: Die Seite leitet von /seite auf /seite/ weiter, aber das Canonical-Tag zeigt auf /seite. Google bekommt dann zwei gegensätzliche Signale, und am Ende entscheidet der Algorithmus nach eigenem Gutdünken. Das Canonical sollte außerdem absolut angegeben sein, mit Schema und Host, damit keine Mehrdeutigkeit entsteht.

Genauso wichtig sind die internen Links. Wenn dein Menü auf /kontakt/ verweist, der Footer auf /kontakt und ein älterer Blogartikel wieder auf /kontakt/, dann löst jeder zweite Klick eine Weiterleitung aus. Das ist zwar kein Fehler im engeren Sinn, aber es verschwendet Crawl-Kapazität und zeigt, dass die Website keine klare Linie hat. Suche per Crawler nach allen internen Links, die auf eine weiterleitende Adresse zeigen, und korrigiere sie an der Quelle.

Die Sitemap gehört ebenfalls dazu. Sie soll ausschließlich die kanonischen Adressen enthalten, in der gewählten Schreibweise. Enthält sie die weiterleitende Variante, schickst du Google gezielt zu Seiten, die es gar nicht indexieren soll. Dasselbe gilt für hreflang-Angaben, Open-Graph-Adressen und strukturierte Daten, in denen URLs stehen. Alle diese Stellen werden oft von unterschiedlichen Plugins oder Templates erzeugt, und jede kann sich anders verhalten.

Ein Sonderfall sind relative Links. Steht auf der Seite /anleitung ein Link auf bilder/foto.jpg, löst der Browser ihn relativ zum Verzeichnis auf: Er landet bei /bilder/foto.jpg. Steht dieselbe Seite unter /anleitung/, landet er bei /anleitung/bilder/foto.jpg. Dasselbe HTML verhält sich je nach Schrägstrich anders, und defekte Bilder oder Stylesheets sind die Folge. Verwende deshalb absolute Pfade, die mit einem Schrägstrich beginnen, oder vollständige URLs.

Wie CMS und Frameworks Duplikate erzeugen

In der Praxis entsteht das Problem selten durch eine bewusste Entscheidung, sondern durch Voreinstellungen, die sich überlagern. Die folgenden Konstellationen begegnen Praktikern am häufigsten:

• WordPress: Der Kern leitet normalerweise über eine eigene Funktion auf die kanonische Schreibweise um. Kommen ein Caching-Plugin, eine Serverregel und ein SEO-Plugin dazu, kann jede Schicht eine eigene Meinung haben. Zusätzlich erzeugen Archive, Anhangseiten und Paginierung eigene Pfade, bei denen die Regel anders greifen kann.
• Next.js und ähnliche Frameworks: Die Konfigurationsoption trailingSlash legt fest, in welche Richtung umgeleitet wird. Standardmäßig wird die Variante mit Schrägstrich auf die ohne Schrägstrich weitergeleitet, mit gesetzter Option umgekehrt. Wer die Option später ändert, ohne die Links im Code anzupassen, erzeugt sofort tausende Weiterleitungen.
• Statische Generatoren und Hosting: Manche Hosts liefern /seite und /seite/ beide mit Status 200 aus, weil sie den Ordner mit index.html als Ziel kennen. Dann gibt es ohne eigene Regel zwei erreichbare Adressen. Bei anderen Hosts wird automatisch umgeleitet, aber nur in eine Richtung, die du nicht gewählt hast.
• Shop-Systeme: Kategorie-, Filter- und Sortierseiten hängen Parameter an. Ob der Schrägstrich vor dem Fragezeichen steht oder fehlt, entscheidet das Template, und Erweiterungen weichen oft voneinander ab.
• CDN und Reverse Proxy: Ein Proxy, der Anfragen vereinheitlicht oder Antworten zwischenspeichert, kann die Regel des Ursprungsservers verdecken. Kommt die Weiterleitung vom Ursprung, der Cache aber liefert die alte Antwort, sieht der Crawler scheinbar beide Varianten als gültig.

Prüfen, ob du ein Problem hast

Ein schneller Test braucht keine Spezialsoftware. Rufe eine beliebige Unterseite mit und ohne Schrägstrich auf und beobachte, was passiert. Es gibt genau drei mögliche Ergebnisse, und nur eines davon ist gewollt: Die falsche Variante leitet per 301 auf die richtige, die richtige liefert den Status 200, und beide sind im Canonical-Tag eindeutig. Antworten beide Varianten mit 200, hast du ein Duplikat. Liefert eine der beiden einen Fehler, hast du ein anderes Problem, nämlich tote Links.

Für die systematische Prüfung eignet sich diese Reihenfolge:

• Prüfe mit curl -I die Statuscodes und den Location-Header für mehrere Seitentypen: Startseite, Artikel, Kategorie, Paginierung, Dateien.
• Crawle die Website mit einem Crawler und filtere nach internen Links, die auf Weiterleitungen zeigen, sowie nach Seiten, deren Canonical nicht mit der eigenen Adresse übereinstimmt.
• Vergleiche die Sitemap mit den Ergebnissen. Jede Sitemap-Adresse sollte mit Status 200 antworten und ihr eigenes Canonical tragen.
• Sieh in der Search Console unter den Seiten-Berichten nach, ob Duplikat-Meldungen auftauchen, und prüfe mit der URL-Prüfung, welche Adresse Google als kanonisch gewählt hat.
• Suche im Logfile, falls verfügbar, nach Anfragen an die abgelehnte Variante. Bleiben sie dauerhaft hoch, stammen sie meist von internen Links oder externen Verweisen, die du korrigieren oder ignorieren kannst.

Häufige Fehler und Sonderfälle

Ein klassischer Irrtum ist, das Problem nur mit einem Canonical-Tag zu lösen und die Weiterleitung wegzulassen. Das Canonical ist ein Hinweis und keine Anweisung. Nutzer, die auf der abgelehnten Variante landen, bleiben dort, und Backlinks auf diese Variante werden nicht sauber gebündelt. Die Weiterleitung ist der verbindliche Teil, das Canonical die Absicherung.

Ein zweiter Fehler ist die pauschale Regel, die auch Adressen mit Dateiendung, Schnittstellen oder Verzeichnisse für Verifizierungsdateien trifft. Wenn die Bestätigungsdatei für ein Werkzeug plötzlich weitergeleitet wird, schlägt die Bestätigung fehl. Teste deshalb nach jeder neuen Regel auch die technischen Adressen wie robots.txt, die Sitemap und Feeds.

Drittens wird oft vergessen, dass der Schrägstrich auch die Berichte verzerrt. Wenn du die Schreibweise änderst, vergleiche Zahlen nicht einfach mit dem Vormonat. Die Search Console führt die URLs mit der neuen Schreibweise als neue Adressen. Die Werte normalisieren sich nach einiger Zeit, aber die ersten Wochen sind schwer zu lesen. Notiere den Zeitpunkt der Umstellung, damit du spätere Schwankungen einordnen kannst.

Schließlich gibt es Fälle, in denen der Schrägstrich tatsächlich zwei verschiedene Seiten trennt, etwa wenn ein alter Bereich /shop als Datei und /shop/ als Verzeichnis existiert. Solche Konflikte sind selten, aber sie zeigen, warum eine pauschale Regel ohne Prüfung gefährlich ist. Bevor du umleitest, kläre, welcher Inhalt unter welcher Adresse lag, und entscheide erst dann, was bleibt.