Vor einigen Monaten tauchten in den organischen Suchergebnissen von Google plötzlich URLs mit seltsamen srsltid-Parametern auf. Was viele Webmaster und SEOs zunächst als Bug bewerteten, dürfte von Google aber als Feature verstanden werden, weshalb wir diese srsltid immer noch in den normalen organischen Suchergebnissen sehen.
Relativ schnell kristallisierte sich heraus, dass das Phänomen vor allem Online-Shops betrifft, und spätestens seit einem Post von John Mueller auf LinkedIn war klar, dass die srsltid-Parameter von der „auto-tagging“-Funktion des Google Merchant Centers (GMC) angehängt werden:
Über das Google Merchant Center können Produktfeeds bereitgestellt werden, um Produkte aus dem Online-Shop in Google Shopping zu bringen und natürlich auch, um Shopping Ads über Google Ads zu bewerben.
Damit Conversions, an denen dieser Kanal beteiligt war, zugeordnet und getrackt werden können, empfiehlt Google die Nutzung der Auto-Tagging-Funktion im Merchant Center und setzt diese auch per Default auf aktiv.
Anstatt, dass das srsltid-Parameter eben nur Produkt-URLs, die über Google Merchant Produktfeeds gemanagt werden, hinzugefügt wird, kann es sein, dass der Parameter an jede URL der Domain in den Suchmaschinen-Ergebnisseiten angehängt wird.
Hinsichtlich der Suchmaschinenoptimierung könnte das zu folgenden Komplikationen führen.
John Mueller schreibt in seinem Post:
“[It] doesn’t affect crawling, indexing, or ranking…”.
Knackpunkt darin, dass der Wert des Parameters – ein 56 Zeichen langer zufälliger String aus Buchstaben und Zahlen – scheinbar bei jedem SERP-Aufscheinen neu generiert wird. Theoretisch entstehen so abertausende individuelle URLs. Würden diese alle von Google gecrawlt werden, könnten auch kleinere Webshops mit einer übersichtlichen Anzahl an URLs unter Umständen mit Crawl-Budget Problemen zu kämpfen haben.
Der Tool Anbieter OnCrawl hat sich dazu Log Files angeschaut und festgestellt, dass der Googlebot URLs mit srsltid-Parameter durchaus crawlt, jedoch nur in einem sehr geringen Umfang. Tatsächlich dürften diese URLs nur gecrawlt werden, wenn der Googlebot abseits der SERPs über einen Link auf eine solche URL stolpert. Findet der Bot allerdings eine srsltid-URL, wird sie zunächst verarbeitet wie jede andere URL mit beliebigem Parameter auch.
Das bringt uns zum nächsten Punkt: Duplicate Content. Selbst wenn es nicht tausende URLs betrifft, entsteht durch die Vielzahl leicht veränderter Parameter-Varianten ja rein technisch gesehen eine große Anzahl an eigenständigen URLs.
Google behandelt solche Parameter-URLs zunächst einmal als eigenständige Seiten – unabhängig davon, ob sich der sichtbare Inhalt überhaupt unterscheidet. Das gilt besonders für Websites, die mit Query-Strings arbeiten. Auch wenn sich mittlerweile gut lesbare „Pretty URLs“ durchgesetzt haben, gibt es immer noch sehr viele Seiten, die mit Query-String-URLs und GET-Parametern arbeiten.
Query-String-Parameter oder GET-Parameter sind eigentlich eine Methode, um HTTP-Requests an einen Webserver zu stellen. Sie bestehen aus einem Namen und einem Wert und werden mit einem ? an die URL angehängt. Mehrere Parameter werden einfach mit einem & verknüpft:
?name=wert&nocheinname=nocheinwert
Unterscheiden lassen sich dabei aktive und passive GET-Parameter:
Damit solche Parameter-Varianten nicht als Duplicate Content gewertet werden, empfiehlt es sich, einen Canonical Tag auf die URL ohne Parameter zu setzen. Genau das empfiehlt ja auch John Mueller in seinem Post.
Ein Problem, das viele SEOs hinsichtlich der srsltid-Parameter (und möglicherweise auch anderer passiver GET-Parameter) aber nicht auf dem Schirm haben, ist deren Impact auf das Caching.
Ein gewisses Level an Caching sollte heute jede Website aufweisen. Für SEOs gehört das Tüfteln am Cache zu wichtigen technischen SEO-Tasks, weil die Ladegeschwindigkeit einer Website nicht erst seit gestern ein Ranking-Faktor ist.
Das Problem mit unserem Parameter: Er ist ein Cache-Buster!
Ein Standard-Page-Caching funktioniert grob zusammengefasst so, dass beim ersten Aufruf einer URL durch einen User das HTML der jeweiligen Seite aus den verschiedenen Template-Teilen und Datenbankeinträgen „zusammengebaut“ und auf dem Server zwischengespeichert wird. Wird diese URL später von weiteren Usern erneut aufgerufen, kann das HTML-Dokument direkt und damit deutlich schneller aus dem Zwischenspeicher ausgeliefert werden.
Kommen User über Google-Suchergebnisse auf URLs, die jedes Mal mit einem neuen, zufälligen srsltid-Parametern „verziert“ sind, kann es sein, dass alle diese User niemals die gecachte Seite ausgeliefert bekommen – weil es für den Server jedes Mal neue URLs sind.
Daher sollte das Caching-Setup unbedingt überprüft werden. Hier ein Überblick, wie die beliebtesten WordPress-Caching-Plugins mit dem Problem umgehen:
Das weit verbreitete Caching-Plugin WP-Rocket ignoriert bereits automatisch viele bekannte Parameter wie UTM-Kampagnen-Parameter, Facebooks Werbe-Parameter oder Matomo- & Piwik-Tracking-Parameter. Es scheint momentan das einzige Plugin zu sein, das auch den srsltid-Parameter – aufgeführt als Google-Shopping-Parameter – in seiner Standard-Ignore-Liste hat. Dazu bietet WP-Rocket sogar ein zusätzliches Add-On, über das eigene Parameter definiert werden können.
Im recht umfangreichen W3 Total Cache Plugin findet sich unter > Page Cache > Advanced das Textfeld „Accepted Query Strings“. Hier sind bereits zahlreiche bekannte Parameter hinterlegt. Der srsltid-Parameter ist jedoch nicht in der Liste und sollte hinzugefügt werden (anders als die Beschreibung des Textfeldes vermuten lässt, wird hier tatsächlich definiert, welche Parameter W3 Total Cache ignorieren soll, sodass die gecachte, kanonische Seite ausliefern wird).
Auch bei Automattics WP Super Cache Plugin findet sich unter dem Tab > Erweitert die Möglichkeit, Tracking-Parameter zu definieren, die für die Auslieferung einer gecachten Seite ignoriert werden sollen. Auch hier sollte der srsltid-Parameter unbedingt ergänzt werden, weil das Plugin Parameter-URLs standardmäßig cacht und somit für jede Variante ein neues File in den Zwischenspeicher legen würde.
LiteSpeed erstellt für alle Query-Strings standardmäßig eine eigene gecachte Seite. Mit immer neuen srsltid-URLs kann der Cache dann recht schnell sehr groß werden. Unter > Settings > Cache > Drop Query String sollte man unbedingt nicht nur srsltid einfügen, sondern auch andere bekannte Tracking-Parameter wie utm, gclid, fbclid usw. hinterlegen (Wildcards sind erlaubt).
WP Fastest Cache erstellt grundsätzlich keinen Cache, wenn eine URL mit Query-String aufgerufen wird. Nur für bestimmte Parameter liefert das Plugin die gecachte Standard-Variante der URL aus. Momentan sind das jedoch lediglich UTM-Parameter, Googles GCLID, Facebooks fbclid und Yandex Tracking Parameter. Eigene Parameter können nicht definiert werden.
Auch Cloudflares Automatic Platform Optimization Plugin spielt per default nur für eine Liste definierter Parameter die gecachte Standard-Variante der URL aus, auf der die srsltid-Parameter bis jetzt noch nicht stehen. Wobei aber Cloudflare verschiedene Wege bietet, das Problem zu umgehen.
Immerhin ignoriert Google Analytics 4 die srsltid-Parameter (bzw. nutzt sie eben zur Zuordnung). Und auch in der Google Search Console tauchen die srsltid-IDs seit Anfang September 2024 nicht mehr im Performance-Report auf. Die historischen Daten bis zu diesem Zeitpunkt lassen aber erahnen, wie schnell aus einer einzelnen URL sehr viele werden können:
Der srsltid-Parameter ist kein Bug, sondern ein bewusst eingesetztes Tracking-Element aus dem Google Merchant Center. Ursprünglich für das Tracking von Google Shopping entwickelt, kann der Parameter in der SEO-Praxis zu einem potenziellen Störfaktor werden. Obwohl er laut Google Crawling, Indexierung und Rankings nicht beeinflusst, besteht durch das Hinzufügen des srsltid-Parameters in organischen Suchergebnissen die Gefahr, dass unnötig viele URL-Varianten entstehen, die das Caching aushebeln und so zu längeren Ladezeiten führen. Wir empfehlen, die Tracking- und Caching-Einstellungen entsprechend zu überprüfen und anzupassen.
