Weiterleitungen prüfen
Zwischen dem Link, den jemand anklickt, und der Seite, die erscheint, liegen oft mehrere Stationen. Der Browser zeigt nur die letzte.
Wie Ketten entstehen, ohne dass es jemand merkt
Kaum eine Kette wird absichtlich gebaut. Sie wächst, weil jede Umstellung eine weitere Regel hinterlässt:
- Die Seite wechselt von
httpaufhttps– eine Weiterleitung. - Danach von
wwwauf die nackte Domain – die zweite. - Ein Relaunch ändert die Adressstruktur – die dritte.
- Ein Affiliate- oder Kürzungsdienst schaltet sich davor – die vierte.
- Der Zielshop leitet auf seine Länderfassung – die fünfte.
Jeder Schritt für sich ist richtig. Zusammen ergeben sie einen Umweg, den niemand entworfen hat und den im Alltag auch niemand sieht.
Warum das nicht nur unschön ist
Es kostet Zeit. Jeder Sprung ist eine eigene Anfrage samt Namensauflösung und TLS-Aufbau. Auf dem Mobilfunknetz summiert sich das spürbar, bevor überhaupt ein Byte der eigentlichen Seite geladen wird.
Es kostet Klarheit. Suchmaschinen folgen Ketten zwar, aber jede zusätzliche Station macht es unsicherer, welche Adresse am Ende als die maßgebliche gilt.
Und es bricht leise. Fällt eine Station in der Mitte aus – ein abgeschalteter Kürzungsdienst, eine gelöschte Regel – ist der Link tot, obwohl Start und Ziel beide einwandfrei funktionieren. Wer nur das Ziel prüft, findet den Fehler nie.
Die Fälle, die man einzeln sehen muss
Die Schleife
A verweist auf B, B zurück auf A. Browser brechen nach einigen Runden mit einer Fehlermeldung ab, Suchmaschinen geben die Adresse auf. Typische Ursache: eine Regel erzwingt www, eine zweite erzwingt das Gegenteil.
Der Wechsel der Anfragemethode
Bei 301 und 302 dürfen Browser ein abgesendetes Formular (POST) unterwegs in einen einfachen Abruf (GET) verwandeln – die eingegebenen Daten sind dann weg. Wer das nicht will, nimmt 307 oder 308: was die Codes im Einzelnen bedeuten.
Der stille Sprung ins Nichts
Manche Ketten enden nicht bei der erwarteten Seite, sondern auf einer Startseite oder einer Fehlerseite, die trotzdem 200 meldet. Für Suchmaschinen sieht das aus wie ein gültiges Ergebnis. Nur der Vergleich von angefragter und endgültiger Adresse deckt es auf.
Der Unterschied je nach Besucher
Nicht jeder wird gleich weitergeleitet. Manche Server schicken Mobilgeräte woandershin als Desktop-Browser, und Suchmaschinen-Bots noch einmal anders. Was im eigenen Browser sauber aussieht, kann für den Googlebot eine ganz andere Kette sein.
Weiterleitungen, die nicht im Header stehen
Die klassische Weiterleitung ist eine Antwort mit einem 3xx-Code und einem Location-Feld im Header. Nicht jeder Umweg sieht so aus. Interstitials, Einwilligungs-Brücken und Zwischenseiten von Affiliate-Netzwerken antworten regelmäßig mit einem freundlichen 200 – und schicken den Besucher erst danach weiter. Wer nur Header liest, hält so eine Zwischenstation für das Ziel.
Meta-Refresh
Im Kopf des Dokuments steht dann eine Zeile wie <meta http-equiv="refresh" content="0; url=…">. Browser folgen ihr, Suchmaschinen behandeln sie bestenfalls als schwaches Signal – als Ersatz für eine 301 taugt sie nicht, weil weder Dauerhaftigkeit noch Ziel eindeutig ausgezeichnet sind. Seltener, aber gleich wirksam: derselbe Befehl als Refresh-Header.
LinkSniffer folgt beiden wie einem gewöhnlichen Sprung. Die Station in der Kette ist als Meta-Refresh bzw. Refresh-Headergekennzeichnet – man sieht also, dass dieser Schritt nicht aus dem Header kam.
Sprünge per JavaScript
Die dritte Variante steht im Skript: location.replace(…), location.href = … und ihre Verwandten. Für Besucher ist das eine Weiterleitung wie jede andere. Technisch ist es keine – es gibt keinen Statuscode, kein Ziel im Header, nichts, dem ein einfacher Abruf folgen könnte.
Hier zeigt LinkSniffer bewusst weniger. Solche Ziele werden im Quelltext der Seite erkannt und getrennt ausgewiesen – aber nicht verfolgt. Wir führen kein JavaScript aus; ob der Browser wirklich dorthin geht, hängt an Bedingungen, die nur beim Ausführen gelten (Einwilligung, Gerät, Zeitpunkt). Ein solcher Fund als Station in der Kette wäre eine Behauptung, kein Messwert. Er steht deshalb als Hinweis daneben und zählt nicht zu den beteiligten Domains.
Für die Praxis heißt das: Endet eine Kette auf einer Zwischenseite und darunter steht ein erkanntes Skript-Ziel, ist genau das der nächste Schritt, den man von Hand prüfen sollte.
Wie man die Kette sichtbar macht
Der Browser hilft hier wenig: Er führt alle Sprünge aus und zeigt am Ende nur das Ergebnis. LinkSniffer geht die Kette stattdessen Schritt für Schritt und hält jeden Sprung mit seinem eigenen Statuscode fest – bis zu 20 Stationen.
Jede Station steht dabei mit ihrer vollständigen Adresse da, samt Pfad und allen Parametern. Das ist kein Detail: Ob eine Kampagnen-Kennung unterwegs verlorengeht, welcher Zielbereich in einem return=-Parameter steckt und welche Kennungen eine Affiliate-Station anhängt, sieht man nur an der ganzen Adresse – am Hostnamen allein nicht. Darunter stehen die beteiligten Domains in ihrer Reihenfolge.
Wählbar ist dabei auch, als was gefragt wird: Desktop-Browser, Mobilgerät oder Googlebot. Genau daran zeigt sich, ob eine Weiterleitung für alle gleich funktioniert.