srsltid Parameter: Was ist das und wie gehen Sie in URLs damit um?

Was ist der srsltid Parameter?

Der srsltid Parameter ist eine Ergebnis ID, die Google an Ihre URL hängt, wenn jemand einen Produkteintrag anklickt. Er erscheint, sobald die automatische Tag Zuordnung im Merchant Center aktiv ist, und hilft zu messen, welcher Eintrag den Besuch ausgelöst hat. Sie erkennen ihn am Ende der Adresse nach ?srsltid=. Den Seiteninhalt ändert er nicht.

Die offizielle Merchant Center Hilfe zur Erfassung von Schlüsselereignissen nennt ihn eine "result id" und zeigt ihn in einer Beispieladresse. Google erzeugt den Wert, sobald das Ergebnis erscheint. Das heißt, Sie sehen für dieselbe Seite oft viele verschiedene Werte.

Daher behandelt dieser Artikel nur diese eine Situation. Website Betreiber stellen uns immer dieselben Fragen: Erzeugt der Parameter doppelte Inhalte? Verfälscht er meine Berichte? Soll ich ihn abschalten? Wir beantworten sie deshalb der Reihe nach.

Kurz gesagt, der srsltid Parameter ist eine Messkennung. Mit Ihrem Design, Ihren Texten oder Ihren Produktdaten hat er also nichts zu tun.

Warum taucht der srsltid Parameter in meinen URLs auf?

Google hängt beim Klick auf einen Produkteintrag eine kurzlebige ID an die Zieladresse. Dadurch kann Google das spätere Verhalten, zum Beispiel einen Warenkorb oder einen Kauf, diesem Eintrag zuordnen. Sie erzeugen den Wert nicht selbst, denn Google setzt ihn.

Daher bringt die Suche im Quellcode oder in Plugins nichts. Wenn Sie die Adresse im Browser öffnen, bleibt der Wert in der Adressleiste stehen. Ihr Server liefert dann in der Regel dieselbe Seite.

Andererseits berichten Branchenartikel und Betreiber, dass der Parameter auch bei normalen organischen Ergebnissen auftaucht, nicht nur bei Produktseiten. Die offizielle Hilfeseite beschreibt allerdings den Kontext der Produkteinträge. Deshalb behandeln wir das organische Verhalten als Beobachtung und nicht als feste Regel.

Die beste Antwort für Ihre Website liefern Ihre eigenen Suchergebnisse und Ihre Serverprotokolle. Suchen Sie zum Beispiel nach Ihrer Marke und schauen Sie auf das Ende der angezeigten Adressen.

Wie hängen die automatische Tag Zuordnung im Merchant Center und der srsltid Parameter zusammen?

Die automatische Tag Zuordnung (auf Englisch Auto Tagging) ist die Einstellung, die diese ID an Klickadressen anhängt. Laut offizieller Seite schaltet sie sich ein, sobald Sie eine neue Schlüsselereignis Aktion anlegen. Die Einstellung kann also aktiv sein, obwohl niemand sie bewusst gewünscht hat.

Der Ort der Einstellung kann sich allerdings mit der Zeit ändern. Die Hilfeseite beschreibt derzeit einen Reiter zur Einrichtung von Schlüsselereignissen in den allgemeinen Einstellungen. Wir empfehlen Ihnen daher, den passenden Bereich in der Merchant Center Hilfe zu bestätigen, statt sich auf Menünamen zu verlassen.

Zudem kann eine Verknüpfung zwischen Google Analytics und Merchant Center zu diesem Messaufbau gehören. Meist hat also eine Agentur oder ein früherer Entwickler sie eingerichtet. Zunächst sollten Sie also klären, wer die Einstellung wann aktiviert hat.

• Prüfen Sie, ob im Konto eine Schlüsselereignis Aktion existiert.
• Prüfen Sie, ob eine Analytics Verknüpfung besteht.
• Notieren Sie, ob der Schalter für die automatische Tag Zuordnung an oder aus ist.

Das Gesamtbild der Shopping Seite zeigt Ihnen unser Leitfaden zu Google Shopping und Merchant Center. Hier bleiben wir daher beim Parameter selbst.

Schadet der srsltid Parameter dem SEO?

Allein löst er keine Strafe aus. Der Parameter ändert keinen Inhalt, daher entsteht nur das Problem, dass dieselbe Seite unter mehreren Adressen erscheint. Die eigentlichen Risiken sind also geteilte Signale und verwirrende Berichte.

Google versucht, Adressen mit gleichem Inhalt unter einer kanonischen Adresse zu bündeln. Der Leitfaden von Google Search Central zu kanonischen URLs nennt Weiterleitungen und das Canonical Tag starke Signale. Folglich hat eine sauber aufgebaute Website mit Parameteradressen meist keine Probleme.

Schwierig wird es allerdings bei fehlenden oder falschen Canonical Tags. Zum Beispiel nennt jede Parameteradresse sich selbst kanonisch, wenn das Tag immer die aktuelle Adresse wiedergibt. Dann wählt Google nach eigenen Regeln.

Die Logik doppelter Inhalte lesen Sie in unserem Artikel zu Duplicate Content. Danach schauen wir uns drei Bereiche an: Berichte, Canonicals und Caching.

Wie sieht der srsltid Parameter in Analytics Berichten aus?

In Seitenberichten kann dieselbe Seite in zwei Zeilen erscheinen, einmal mit und einmal ohne Parameter. Wir sprechen von einer ähnlichen Ansicht, denn Berichts- und Dimensionsnamen können sich in der Oberfläche ändern. Wenn die Daten einer Seite sich aufteilen, führen Seitenvergleiche leicht in die Irre.

Außerdem kann der Parameter in andere Kanäle wandern, wenn jemand die Adresse teilt. Das erschwert somit die Quellenanalyse. Das heißt, Sie müssen die Zeilen zusammenführen, um die Gesamtleistung einer Seite zu sehen.

1. Filtern Sie nach der Seitenadresse und listen Sie die Zeilen mit dem Parameter auf.
2. Addieren Sie sie zur Zeile der sauberen Adresse derselben Seite.
3. Nutzen Sie die Summe für Ihre Vergleiche.
4. Wenn Ihr Berichtstool den Parameter ausschließen kann, wählen Sie diese Option.

Fehlende Conversions können andere Ursachen haben. Dann ist unser Artikel zu fehlenden GA4 Conversions der bessere Startpunkt.

Wie verfolgen Sie srsltid Adressen in der Search Console?

Bei der Prüfung der Seitenleistung in der Search Console können Sie gezielt nach Parameteradressen suchen. Die angeklickte Adresse und die von Google gewählte kanonische Adresse können sich unterscheiden. Dieser Unterschied erklärt also die meisten verwirrenden Zeilen.

Das URL Prüftool zeigt die von Ihnen angegebene kanonische Adresse neben der von Google gewählten. Hat Google für eine Parameterseite die saubere Adresse gewählt, ist alles in Ordnung. Sonst prüfen Sie Ihre Canonical Einstellung.

Die Schritte finden Sie in unserem Artikel über Canonical Fehler in der Search Console. Zum allgemeinen Einstieg dient unsere Search Console Anleitung.

Zudem können Impressionen für Parameteradresse und Hauptadresse getrennt erscheinen. Prüfen Sie daher beide Formen, bevor Sie eine einzelne Seite bewerten.

Wie verhindert ein Canonical Tag Probleme mit srsltid?

Die sicherste Lösung ist also einfach. Das Canonical Tag jeder Seite sollte auf die saubere Adresse ohne Parameter zeigen. Dann sagen Sie Google klar, welche Adresse Sie bevorzugen, egal welcher Parameter ankommt. Diese Lösung gilt nicht nur für srsltid, sondern für alle Tracking Parameter.

Ein häufiger Fehler entsteht bei Seiten, die das Tag dynamisch im Template bauen. Der Code schreibt dann die aktuelle Anfrageadresse ins kanonische Feld. Die Parameteradresse zeigt dann auf sich selbst, und die Lösung greift nicht.

• Bauen Sie die kanonische Adresse aus der gespeicherten sauberen Adresse der Seite, nicht aus der Anfrage.
• Entfernen Sie Parameter und deren Reihenfolge aus der Adresse.
• Öffnen Sie die Seite mit und ohne Parameter und vergleichen Sie den Quelltext.
• Nutzen Sie dieselben sauberen Adressen auch in alternativen Sprachversionen.

Wenn Ihnen die Grundlagen fehlen, lesen Sie unsere Anleitung zum Canonical Tag. Codebeispiele geben wir hier daher nicht. Sie können diese Sätze direkt an Ihren Entwickler weitergeben.

Weiterleitungen sind ebenso starke Signale. Allerdings kostet eine Weiterleitung bei jedem Klick Leistung und birgt Fehlerrisiken. Deshalb ist das Canonical Tag für die meisten Seiten die ruhigere Lösung.

Warum ist das Sperren des srsltid Parameters per robots.txt ein Fehler?

Laut Einführung von Google Search Central zur robots.txt ist die robots.txt kein Mechanismus, um eine Seite aus Google herauszuhalten. Zudem rät der Leitfaden von Google Search Central zu kanonischen URLs davon ab, die robots.txt zur Kanonisierung zu nutzen. Gesperrte Adressen können trotzdem ohne Inhalt im Index erscheinen.

Das bedeutet Folgendes: Sperren Sie den Parameter, kann Google diese Seiten nicht lesen. Daher sieht Google auch Ihr Canonical Tag nicht. Folglich funktioniert die Bündelung der Signale nicht mehr.

Außerdem kann eine gesperrte Adresse über Links anderer Seiten in den Index gelangen. Ergebnisse ohne Snippet sind zudem eine schlechte Erfahrung und machen Ihnen zusätzliche Arbeit.

• Schreiben Sie keine robots.txt Regel für den Parameter.
• Falls eine alte Regel existiert, prüfen Sie, warum sie existiert und was sie betrifft.
• Lassen Sie ein sauberes Canonical stehen und erlauben Sie Google das Crawlen der Seite.

Testen Sie, bevor Sie eine alte Regel entfernen. Denn eine breite Regel kann auch andere Adressen betreffen.

Was passiert mit srsltid in Caches und CDNs?

Eine Cache Schicht nutzt oft die vollständige Adresse als Schlüssel. In diesem Fall kann jeder andere srsltid Wert einen eigenen Cache Eintrag bedeuten. Der Server baut dieselbe Seite dann immer wieder neu, und die Trefferquote sinkt.

Stark besuchte Shops merken das also am deutlichsten. Die Seite wird nicht langsamer, allerdings leistet Ihr Server unnötige Arbeit. Zum Beispiel kann die Serverlast in einer Kampagne höher ausfallen als erwartet.

Die Lösung ist, Tracking Parameter aus dem Cache Schlüssel zu streichen. Das stellen Sie meist in der CDN- oder Cache Konfiguration ein. Menüs unterscheiden sich je nach Anbieter, deshalb bestätigen Sie die Details in der Dokumentation Ihres Anbieters. Unser Artikel zu Varnish Cache gibt außerdem einen allgemeinen Eindruck.

Allerdings sollten Sie vorsichtig sein, wenn Ihre Anwendung Inhalte nach einem Parameter ändert. Schließen Sie in diesem Fall nur diesen einen Parameter aus dem Cache Schlüssel aus.

Welche Vor- und Nachteile hat das Abschalten der automatischen Tag Zuordnung?

Das Abschalten ist eine Messentscheidung, keine SEO Korrektur. Zunächst stehen auf der Habenseite saubere Adressen und schlankere Berichte. Andererseits kann die Zuordnung von Conversions aus Einträgen schwächer werden.

Die beste Wahl hängt also von Ihrem Messbedarf ab. Ein Shop, der Umsatz aus Shopping Anzeigen und kostenlosen Einträgen erwartet, möchte die Messung vielleicht behalten.

Nutzen Sie gar keine Shopping Daten, ist das Abschalten somit der einfachere Weg. Prüfen Sie vor der Entscheidung, wie stark Ihre Berichte auf diesem Parameter beruhen.

Diese Entscheidung gehört allen, die für die Messung zuständig sind, nicht nur einer Person. Sonst schaltet ein Team die Einstellung ab, und ein anderes Team findet eine Woche später fehlende Daten.

Wie schalten Sie die automatische Tag Zuordnung im Merchant Center ab?

Laut offizieller Merchant Center Hilfe zur Erfassung von Schlüsselereignissen ist die Einstellung ein Schalter im Bereich für Schlüsselereignisse unter den allgemeinen Einstellungen. Die Oberfläche kann sich allerdings ändern. Deshalb beschreiben wir die Bereiche und nennen keine genauen Schaltflächentexte.

1. Melden Sie sich mit Administratorrechten im Merchant Center Konto an.
2. Suchen Sie in den allgemeinen Einstellungen den Bereich für Schlüsselereignisse.
3. Notieren Sie den aktuellen Zustand des Schalters.
4. Haben Sie sich fürs Abschalten entschieden, stellen Sie ihn aus und speichern Sie.
5. Prüfen Sie nach einigen Tagen Adressen in den Suchergebnissen und Ihre Berichte erneut.

Die Änderung erreicht nicht sofort alle Suchergebnisse. Denn Google braucht Zeit, um neue Adressen zu verarbeiten. Für die Dauer fanden wir keine offizielle Zahl, daher raten wir nicht.

Machen Sie außerdem vor dem Abschalten einen Screenshot Ihrer aktuellen Berichte. Dann können Sie den Unterschied danach richtig deuten.

In welcher Reihenfolge sollten Sie vor dem Abschalten entscheiden?

Wir empfehlen diese Reihenfolge: zuerst die Messung, dann die technische Bereinigung, zuletzt die Einstellung. Wer sofort abschaltet, kann Daten verlieren, die er noch braucht, und sie nicht zurückholen.

1. Klären Sie, welche Berichte von diesem Parameter abhängen.
2. Sprechen Sie mit Ihrem Werbe- und Shopping Team über den Messbedarf.
3. Prüfen Sie, ob Canonical Tags auf die saubere Adresse zeigen.
4. Kontrollieren Sie Tracking Parameter im Cache Schlüssel.
5. Ist alles erledigt, lassen Sie die Einstellung an oder schalten sie ab.

Diese Reihenfolge verhindert somit übereilte Beschlüsse. Zum Beispiel stört der Parameter Sie vielleicht nicht, wenn Ihre Canonicals stimmen. Dann bringt die eingeschaltete Einstellung bessere Messdaten.

Kurz gesagt, Sie wollen den Parameter nicht vernichten, sondern harmlos machen. Dieser Blick spart unnötige Änderungen und gibt den Teams eine gemeinsame Sprache.

Zum Beispiel verantwortet das Werbeteam die Messung, der Entwickler das Canonical, und Sie die Entscheidung. Kennt jeder seine Rolle, wird der srsltid Parameter nicht zur langen Besprechung.

Verarbeitet Ihre Website Parameteradressen korrekt, und wie testen Sie das?

Die offizielle Hilfeseite weist darauf hin, dass manche Websites beliebige URL Parameter nicht zulassen, und rät zum Test. Der Test ist einfach, denn jeder Betreiber kann ihn ausführen. Hängen Sie einen Beispielparameter an die Adresse einer Produktseite und beobachten Sie das Ergebnis.

• Beispiel: Hängen Sie an eine Produktseite auf example.com einen beliebigen Tracking Parameter an.
• Öffnet sich die Seite mit gleichem Inhalt, ist alles gut.
• Sehen Sie eine Fehlerseite oder eine Weiterleitungsschleife, informieren Sie Ihren Entwickler.
• Probieren Sie auch Warenkorb und Kasse mit einer Parameteradresse.

Bei einer Weiterleitungsschleife hilft unser Artikel zum Fehler zu viele Weiterleitungen. Für viele Adressen auf einmal spart Ihnen unser Redirect Checker Zeit.

Führen Sie den Test getrennt für Produkt Template, Kategorie Template und Startseite durch. Denn jedes Template kann eine eigene Canonical Logik haben.

Werden srsltid und UTM Parameter verwechselt?

Nein. Sie stammen aus verschiedenen Quellen und dienen verschiedenen Zwecken. UTM Tags fügen Sie selbst hinzu, um eine Kampagnenquelle zu melden. Den srsltid Parameter fügt Google hinzu, um einen Klick auf einen Eintrag zu markieren.

Beide können allerdings in einer Adresse stehen. UTM ist ein eigenes Thema, das wir in unserem Leitfaden zu UTM Parametern erklären. Für eigene Links nutzen Sie unseren UTM Generator.

Wichtig ist hier: Beide Parameter sollten über das Canonical Tag auf dieselbe saubere Adresse zeigen. Dann behält die Seite, egal welche Art von Tracking ankommt, eine einzige Identität.

Wenn Sie Ihr eigenes Tagging und die automatische Tag Zuordnung zusammen planen, testen Sie außerdem vorab auf Überschneidungen. Das ist eine gute Gewohnheit.

Ist es sinnvoll, den Parameter per Weiterleitung zu entfernen?

Technisch ist das möglich, aber wir raten bei den meisten Seiten davon ab. Entfernt Ihr Server den Parameter und leitet auf die saubere Adresse um, kann die Klick ID verschwinden, bevor Analytics sie liest. Folglich bricht Ihre Messung.

Der Grund ist einfach. Das Tracking Skript liest den Wert beim Laden der Seite aus der Adresse. Hat die Weiterleitung ihn schon gestrichen, findet das Skript somit nichts mehr. Zudem verlangsamt eine zusätzliche Weiterleitung die Seite.

Trotzdem können Sie die Option mit Ihrem Entwickler besprechen, wenn Sie keine Messung brauchen und die Einstellung nicht abschalten wollen. Testen Sie die Weiterleitung zuerst auf einer Testseite.

Die Unterschiede der Weiterleitungsarten frischen Sie mit unserem Artikel zu 301, 302, 307 und 308 auf. Meistens ist daher das Canonical Tag plus eine Cache Einstellung der ausgewogenste Weg.

Wann müssen Sie gar nichts tun?

Stimmt Ihr Canonical Tag, zeigt die Search Console die saubere Adresse als gewählte kanonische Adresse, und leiden Ihre Berichte nicht, müssen Sie nicht eingreifen. Der Parameter ist eine harmlose Tracking Kennung.

Ein häufiger Fehler ist, jeden Parameter in der Adressleiste als Problem zu sehen. Die meisten sind allerdings harmlos. Unnötige Eingriffe erzeugen dagegen neue Fehler.

• Das Canonical Tag zeigt auf die saubere Adresse.
• Die Cache Last liegt auf einem akzeptablen Niveau.
• Die Berichte zeigen keine Abweichung auf Seitenebene, oder Sie können sie leicht beheben.
• Produktseiten öffnen sich auch mit Parameteradresse einwandfrei.

Treffen alle vier Punkte zu, lassen Sie den Parameter in Ruhe und kontrollieren ihn regelmäßig. Für die meisten Shops ist das die risikoärmste Option.

Zum technischen Gesamtbild eines Shops lesen Sie auch unseren Artikel zu E-Commerce SEO.

Wie unterscheiden sich Canonical, Weiterleitung und robots.txt?

Die Tabelle fasst drei verbreitete Methoden für Parameteradressen zusammen. Sie stützt sich auf die Dokumentation von Google Search Central. Auf Ihrer Website kann das Ergebnis abweichen.

Nehmen Sie nur saubere Adressen in Ihre Sitemap auf, denn Parameteradressen stiften Verwirrung. Für die Datei hilft Ihnen unser XML Sitemap Generator.

So wird die Rolle jeder Methode klar. Das Canonical Tag ist die Hauptlösung, die Sitemap unterstützt es, und die robots.txt ist für diese Aufgabe das falsche Werkzeug.

Wie finden Sie srsltid Adressen in Serverprotokollen?

Zugriffsprotokolle des Servers zeigen Anfragen mit dem Parameter am deutlichsten. Filtern Sie die Zeilen, deren Adresse auf srsltid endet, dann sehen Sie, welche Seiten mit dieser ID geöffnet wurden. Danach vergleichen Sie die Zahl der einzigartigen Werte mit der Gesamtzahl der Anfragen.

Meist taucht jeder Wert nur wenige Male auf, denn die ID entsteht beim Einblenden des Ergebnisses. Viele verschiedene Adressen sind also normal. Wichtig ist, dass alle zur selben Seite führen und Ihr Server schnell antwortet.

• Prüfen Sie, ob sich Parameteranfragen auf Produktseiten konzentrieren.
• Schauen Sie Googlebot Anfragen mit Parameteradresse getrennt an.
• Kontrollieren Sie die Antwortcodes; die Fehlerquote sollte bei Parameteradressen nicht steigen.
• Können Sie den Cache Status protokollieren, vergleichen Sie Treffer und Fehlschläge.

Für die Protokollanalyse geben wir weder Code noch Befehle, weil jede Hosting Umgebung anders arbeitet. Ihr Entwickler kann diese vier Punkte aber leicht beantworten.

Was passiert mit geteilten Links, die srsltid tragen?

Nutzer können eine Adresse kopieren und in Foren, Nachrichten oder soziale Netzwerke einfügen. Externe Links zeigen dann auf die Parameteradresse. Die Linkstärke kann dadurch auf zwei Adressen verteilt aussehen.

Auch hier spielt das Canonical Tag eine Rolle. Ist es korrekt, versucht Google, diese Adressen auf einer Seite zu bündeln. Meist geht der Linkwert also nicht verloren. Sie sehen nur zwei Zeilen in Ihren Berichten.

Versprechen können wir natürlich nichts. Googles Bündelung hängt von Signalen ab und wählt nicht immer die erwartete Adresse. Daher verwenden Sie in internen Links immer saubere Adressen.

In Menüs, Blöcken mit verwandten Produkten und Newslettern sind saubere Adressen die sicherste Gewohnheit. Kurz gesagt, ein Link mit dem srsltid Parameter ist an sich kein Verlust, aber saubere Links kosten Sie nichts.

Was sagen Sie Ihrem Entwickler zum srsltid Parameter?

Arbeiten Sie mit einem technischen Team, halten Sie die Bitte kurz und messbar. Eine vage Bitte wie "Reparieren Sie den Parameter" führt zu falschen Lösungen. Die Liste unten ist ein einfacher Rahmen, den unser Team zum Start nutzt.

1. Die kanonische Adresse jeder Seite ist die saubere Adresse ohne Parameter.
2. Interne Links nutzen nur saubere Adressen.
3. Parameteradressen öffnen sich fehlerfrei und mit gleichem Inhalt.
4. Der Cache Schlüssel ignoriert Tracking Parameter.
5. Die Sitemap enthält nur saubere Adressen.

Alle fünf Punkte verstehen Sie ohne Code. Zudem kann ein Entwickler jeden einzeln testen. Die Diskussion schrumpft dann auf eine Frage: Funktioniert es oder nicht?

Hinweis: Wir geben hier Orientierung, wir betreiben nicht Ihre Infrastruktur und keine Server. Setzen Sie Änderungen mit Ihrem Entwickler oder Hosting Anbieter um.

Welche Fehler passieren beim srsltid Parameter am häufigsten?

Der häufigste Fehler, den wir sehen, ist der Versuch, den Parameter sofort zu sperren. Zweitens prüfen viele das Canonical Tag nie. Drittens bauen manche eine Weiterleitung, die die Messung stört.

• Das Sperren per robots.txt nimmt dem Canonical das Signal.
• Ein noindex auf allen Adressen kann auch Ihre Produktseiten entfernen.
• Parameteradressen in der Sitemap stiften Verwirrung.
• Wer die Einstellung ohne Rückfrage abschaltet, kann die Messung des Werbeteams stören.
• Wer eine Beobachtung für eine Regel hält, übersieht, dass organisches Verhalten je nach Seite abweicht.

Nutzen Sie die Liste als Prüfliste. Trifft ein Fehler auf Sie zu, beheben Sie ihn zuerst. Erst danach denken Sie über die Einstellung nach.

Diese Fehler verursachen den Großteil der Sorgen rund um den srsltid Parameter. Ruhiges Prüfen reicht meist aus. Zudem ist ein Parameter aus Googles Eintragsmessung kein Zeichen für einen Hack oder eine Sicherheitslücke.

Wie lautet die Entscheidungshilfe zum srsltid Parameter?

Der Entscheidungsweg auf einen Blick: Ist Ihr Canonical Tag sauber und brauchen Sie die Messung, lassen Sie den srsltid Parameter an und beobachten ihn. Ist das Canonical falsch, beheben Sie es zuerst. Brauchen Sie keine Messung und wollen schlichte Adressen, erwägen Sie das Abschalten der automatischen Tag Zuordnung.

In jedem Fall verzichten Sie auf die robots.txt Sperre und auf unnötiges noindex. Beides schadet dem Canonical Signal. Dokumentieren Sie außerdem Ihre Entscheidung: wer was wann und warum geändert hat.

So ist die Antwort bereit, wenn jemand sechs Monate später dieselbe Frage stellt. Die Notiz hilft zudem bei einem Agenturwechsel. Der Umgang mit dem srsltid Parameter ist also eine kleine Prozessentscheidung und keine einmalige Korrektur.

Wie sollte eine monatliche Prüfliste aussehen?

Vergessen Sie den Parameter nicht nach einer einzigen Korrektur. Eine Einstellung im Merchant Center, ein Theme Update oder ein neues Plugin kann die Lage ändern. Deshalb empfehlen wir einmal im Monat eine kurze Kontrolle.

1. Prüfen Sie an einigen Produktadressen, dass das Canonical Tag die saubere Adresse zeigt.
2. Kontrollieren Sie in der Search Console die kanonische Wahl für Parameteradressen.
3. Prüfen Sie im Merchant Center den Zustand der automatischen Tag Zuordnung.
4. Sehen Sie sich in Analytics die Zeilen der Parameterseiten an.
5. Achten Sie auf einen ungewöhnlichen Einbruch der Cache Trefferquote.

Halten Sie die Ergebnisse in einer einfachen Tabelle oder einer gemeinsamen Notiz fest. Datum, geprüfte Adresse und Beobachtung genügen. So vergleichen Sie vorher und nachher, und das Wissen bleibt auch bei Teamwechsel erhalten.

Diese Liste dauert weniger als eine Viertelstunde. Eine umfassende technische Prüfung finden Sie bei unserer SEO Beratung. Zu Nachbarthemen schrieben wir außerdem über die Kontingent Warnung der Search Console und über ein falsches Vorschaubild in den Suchergebnissen.

Wie helfen Talha Aslan und Team bei diesem Thema?

Wir sind ein Digitalmarketing Team aus Istanbul und arbeiten seit 2012 in der Praxis. Bei einem Parameter wie diesem prüfen wir meist drei Dinge: die Canonical Logik, den Messaufbau und die Cache Einstellung. Oft liegt das Problem nicht in der Einstellung selbst, sondern im Zusammenspiel dieser drei Bereiche.

Garantien für Ergebnisse geben wir natürlich nicht. Jede Website ist anders, und Googles Verhalten kann sich mit der Zeit ändern. Für aktuelle Angaben prüfen Sie immer die offiziellen Hilfeseiten.

Hinweis: Dieser Artikel ist allgemeine Information und keine Rechts- oder Finanzberatung. Sichern Sie Ihre Daten, bevor Sie technische Änderungen live schalten.