Session Id In URL Rewrite
Was ist eine Session-ID im URL-Rewrite?
Eine Session-ID im URL-Rewrite ist eine eindeutige Sitzungskennung, die der Server direkt in den URL-Pfad schreibt, wenn die Zuordnung nicht über ein Cookie erfolgt. Dadurch kann dieselbe Inhaltsseite für jede Sitzung unter einer anderen Adresse erreichbar sein. Das erhält den Sitzungszustand, erzeugt jedoch leicht viele technisch unterschiedliche URLs mit gleichem Inhalt.
Die Session-ID im URL-Rewrite, auch URL-basierte Sitzungskennung genannt, verbindet mehrere Seitenaufrufe mit derselben Sitzung. Der Server ergänzt dazu jede interne Adresse um eine individuelle Zeichenfolge. Ruft ein Nutzer den nächsten Link auf, erkennt die Anwendung anhand dieser Kennung beispielsweise einen gefüllten Warenkorb oder einen begonnenen Anmeldevorgang.
So funktioniert die Sitzungskennung
Eine Webanwendung speichert Sitzungsdaten normalerweise auf dem Server und übermittelt dem Browser lediglich eine Kennung. Bei der Cookie-Methode wird diese Kennung im HTTP-Header übertragen. Beim URL-Rewriting erscheint sie dagegen sichtbar in der Adresse, etwa als Pfadbestandteil oder Parameter:
Der Server muss bei jeder ausgegebenen internen Verknüpfung dieselbe Kennung ergänzen. Fehlt die Session-ID im URL-Rewrite bei einem Folgeklick, kann die Anwendung die Sitzung je nach Implementierung nicht mehr zuordnen. Moderne Systeme verwenden URL-basierte Sitzungen deshalb meist nur als Rückfalllösung, wenn der Browser keine Cookies akzeptiert.
SEO-Risiken durch Session-IDs
Der verbreitete Denkfehler besteht darin, eine funktionierende Sitzung mit einer sauberen URL-Struktur gleichzusetzen. Eine Session-ID im URL-Rewrite kann technisch korrekt arbeiten und trotzdem das Crawling erschweren. Suchmaschinen müssen jede entdeckte Adresse zunächst abrufen und beurteilen, auch wenn sich mehrere Adressen nur durch ihre Sitzungskennung unterscheiden.
Session-IDs können eine nahezu unbegrenzte Zahl abrufbarer URL-Varianten erzeugen. Ein Crawler folgt beispielsweise einer Produktseite mit Kennung A, erhält dort Links mit Kennung A und entdeckt später denselben Pfad mit Kennung B. Die Anzahl der URLs wächst mit den Sitzungen, obwohl keine zusätzlichen Inhalte entstehen. Kuratierte technische Prüfunterlagen empfehlen deshalb ausdrücklich, Session-IDs in URLs zu vermeiden, weil sie viele Adressen mit identischem Inhalt erzeugen können.
Duplicate Content durch Session-IDs führt nicht automatisch zu einer Abstrafung. Das konkrete Problem liegt in der technischen Mehrdeutigkeit: Suchmaschinen müssen doppelte Versionen erkennen, gruppieren und eine kanonische URL auswählen. Prüfe deshalb nicht nur, ob die gewünschte Seite indexiert ist, sondern auch, ob Session-Varianten gecrawlt oder als alternative URLs geführt werden.
Canonical Tag reicht nicht allein
Ein selbstreferenzierendes Canonical Tag auf der sauberen URL und ein Canonical Tag von jeder Sitzungsvariante zur sauberen Adresse helfen bei der Konsolidierung. Das Canonical Tag ist jedoch ein Signal und beseitigt die URL-Erzeugung nicht. Verlinkt die Website weiterhin Adressen mit Session-ID, muss Google diese URLs trotzdem entdecken, abrufen und auswerten.
Eine robots.txt-Sperre ist ebenfalls keine vollständige Bereinigung. Blockierte Session-URLs können über interne oder externe Links bekannt bleiben, während Suchmaschinen den Seiteninhalt und das Canonical Tag nicht abrufen dürfen. Ein noindex verhindert bei erfolgreicher Verarbeitung zwar die Indexierung, reduziert aber nicht automatisch die Zahl erzeugter und gecrawlter Varianten.
Session-ID und URL-Parameter abgrenzen
Der Unterschied zwischen einer Session-ID und einem gewöhnlichen URL-Parameter liegt in der Funktion. Eine Session-ID identifiziert eine konkrete Sitzung. Filter-, Sortier- oder Tracking-Parameter verändern dagegen eine Ansicht oder dokumentieren die Herkunft eines Besuchs. Beide Varianten können Duplicate Content erzeugen, benötigen technisch jedoch unterschiedliche Regeln.
| Methode | Beispiel | SEO-Einordnung |
|---|---|---|
| Session-Cookie | Kennung im HTTP-Header | Die öffentliche URL bleibt stabil und teilbar. |
| Session-ID im Pfad | /ABC123/produkt | Jede Sitzung kann eine neue URL-Struktur erzeugen. |
| Session-ID als Parameter | /produkt?sid=ABC123 | Der Inhalt ist unter zahlreichen Parameter-URLs erreichbar. |
| Filterparameter | /produkte?farbe=blau | Der Parameter beschreibt eine Ansicht und keine Sitzung. |
Auch URL-Rewriting und Session-Rewriting sind nicht gleichbedeutend. Allgemeines URL-Rewriting wandelt technische Adressen häufig in verständliche Pfade um, etwa von produkt.php?id=25 zu /produkte/schreibtisch. Session-Rewriting ergänzt dagegen eine nutzerspezifische Kennung und macht eine stabile Adresse dadurch variabel.
Session-IDs technisch prüfen
Messbar ist das Problem, indem ein Crawler URLs nach wiederkehrenden Parametern oder Pfadmustern gruppiert und Seiten mit identischem Inhalt vergleicht. Der Technik-Crawler der Performance Suite unterstützt technische Prüfungen von URL-Strukturen, Canonical Tags und indexierbaren Seiten. Ergänzend zeigen Server-Logs, wie oft Suchmaschinen Session-Varianten tatsächlich abrufen.
Ein technischer Check sollte mindestens interne Links, XML-Sitemaps, Canonical Tags, Weiterleitungen und Statuscodes einbeziehen. Die kanonische Zieladresse sollte mit Statuscode 200 antworten. Interne Links und Sitemap-Einträge müssen direkt auf diese Adresse zeigen, damit Suchmaschinen einheitliche Signale erhalten.
Eine umfassende technische SEO-Analyse sollte zusätzlich klären, welches System die Sitzungskennungen erzeugt. Typische Ursachen liegen in älteren Shop-Konfigurationen, Framework-Einstellungen, fehlender Cookie-Unterstützung oder zwischengeschalteten Systemen. Der Leitfaden zum SEO-Technik-Crawler erklärt, wie technische Fehler systematisch erfasst und priorisiert werden.
Saubere Lösung im Webprojekt
Die bevorzugte Lösung besteht darin, Sitzungen über sichere Cookies zu verwalten und für alle Nutzer dieselbe öffentliche URL auszugeben. Die Webanwendung sollte Session-IDs nur dann in Links schreiben, wenn eine zwingende technische Anforderung besteht. Für Suchmaschinen, nicht angemeldete Besucher und öffentlich teilbare Seiten sollten stets stabile Adressen verfügbar sein.
Bestehende Sitzungsvarianten können auf die jeweilige saubere URL weitergeleitet werden, sofern die Sitzung anschließend per Cookie erhalten bleibt und beide Adressen denselben Inhalt ausliefern. Eine permanente 301-Weiterleitung ist nur passend, wenn die Session-URL dauerhaft keine eigenständige Funktion erfüllen soll. Eine pauschale Weiterleitung ohne Prüfung kann Warenkörbe oder Anmeldeprozesse unterbrechen.
Bei einem Relaunch gehört die Entfernung von Session-IDs in den Testplan. Prüfe vor dem Livegang, ob Navigation, Produktsuche, Warenkorb, Anmeldung und Checkout auch mit stabilen URLs funktionieren. Die SEO-Checkliste für den Website-Relaunch hilft dabei, URL-Änderungen, Weiterleitungen und Indexierung gemeinsam zu kontrollieren.
Häufige Fragen zu Session-IDs
Warum schreibt eine Website eine Session-ID in die URL?
Eine Website verwendet eine Session-ID in der URL, wenn sie eine Sitzung nicht über ein Cookie zuordnet oder URL-Rewriting als Rückfalllösung konfiguriert ist. Das kommt vor allem bei älteren Anwendungen und speziellen Cookie-Einstellungen vor.
Kann Google Session-IDs aus URLs entfernen?
Google kann URL-Varianten erkennen und zu einer kanonischen Adresse zusammenfassen. Darauf solltest du dich nicht verlassen, weil die Varianten weiterhin gecrawlt werden und widersprüchliche Signale entstehen können.
Sind Session-IDs in URLs Duplicate Content?
Session-IDs erzeugen Duplicate Content, wenn mehrere URLs mit unterschiedlichen Kennungen denselben Hauptinhalt ausliefern. Eine automatische Abstrafung folgt daraus nicht, doch Crawling, Indexierung und die Bündelung von Signalen werden erschwert.
Hilft ein Canonical Tag gegen Session-URLs?
Ein korrektes Canonical Tag kann Suchmaschinen die bevorzugte URL zeigen. Das Canonical Tag stoppt jedoch weder die Erzeugung noch das Crawling der Session-URLs, weshalb die Ursache in der Sitzungsverwaltung behoben werden sollte.
Sollte man Session-URLs in der robots.txt sperren?
Eine robots.txt-Sperre ist selten die vollständige Lösung, weil Suchmaschinen dann weder den Inhalt noch das Canonical Tag der URL abrufen können. Saubere interne Links, stabile URLs und eine Cookie-basierte Sitzung sind meist geeigneter.
Sind Session-IDs in URLs ein Sicherheitsrisiko?
Eine sichtbare Session-ID kann über geteilte Links, Browser-Verläufe, Protokolldateien oder Verweise weitergegeben werden. Sichere Cookies, kurze Gültigkeitszeiten und die serverseitige Erneuerung der Kennung reduzieren dieses Risiko.
Wenn Session-URLs deine Website betreffen, kann ein technischer Potenzialcheck die Ursache und den Umfang eingrenzen.
Kostenlosen Potenzialcheck anfragen
Sie haben noch Fragen?
