✓ individuelle SEO-Beratung & -Betreuung ✓ keine Abnahmeverpflichtung ✓ zertifizierte SEO-Experten ✓ transparente & faire Arbeitsweise ✓ nachhaltige SEO-Strategien
info@gettraction.de 030 / 296 73 998
Inhaltverzeichnis
Der großartige Stefan Fischerländer hat auf der SMX einen tollen Vortrag zum Thema Weiterleitungsmanagement für SEOs gehalten. Zunächst hatte er die Befürchtung, wie er mit diesem Thema eine Stunde füllen soll. Nach kurzer Zeit ist ihm aber bewusst geworden, wie umfangreich das Thema ist und so konnten die Zuhörer 60 Minuten gebannt zuhören, welche Facetten es zu beachten gibt, was die Status Codes technisch überhaupt bedeuten und wie ein vernünftiges Weiterleitungsmanagement aussieht. Entsprechend möchte ich an dieser Stelle gar nicht auf das Warum eingehen, sondern vielmehr an seinen Vortrag anschließen und das Wie beleuchten.
Um es nicht ganz aus den Augen zu verlieren, hier aber dennoch ein sehr kondensiertes tl;dr zum Weiterleitungsmanagement an sich:
Das Weiterleitungsmanagement – sprich: das Einrichten neuer und die Pflege bestehender Weiterleitungen – ist ein signifikanter Aspekt der SEO-Arbeit. Es stellt sicher, dass nicht mehr erreichbare Seiten zielgerichtet auf andere, thematisch-relevante Seiten weitergeleitet werden können. Dadurch wird sichergestellt, dass Nutzer nicht in “Sackgassen” stecken bleiben und bestehende Rankings ggf. auf äquivalente Seiten übertragen werden.
Nun ist es dabei natürlich wichtig, dass derartige Weiterleitungen ad hoc im System eingepflegt werden können, ohne bspw. einen Umweg über die IT gehen oder ein Release abwarten zu müssen. Hierfür bietet es sich an, dass es einen zentralen Editor gibt, der alle Weiterleitungen übersichtlich darstellt. Darum soll es in diesem Beitrag gehen.
Was muss ein solcher Redirect-Editor an Funktionen bereitstellen?
Nun denn, wie haben wir uns einen solchen Redirect-Editor vorzustellen? Grundsätzlich fordern wir ihn als eigenständiges Modul im CMS des Kunden an, damit dieser an einer zentralen Stelle seine Weiterleitungen setzen und pflegen kann. Wichtig ist dabei das graphische User-Interface, dass die Arbeit so angenehm wie möglich machen sollte. Denn sind wir ehrlich, die Definition von Weiterleitung macht jetzt nicht gerade Spaß. Und wenn ich Redirects in Excels dokumentieren und diese womöglich händisch in der htaccess pflegen muss, kann ein jeder nachvollziehen, warum dieses Thema mitunter stiefmütterlich gehandhabt wird.
Der Editor könnte wie folgt aufgebaut sein.
Falls euch das Layout bekannt vorkommt, so ist das kein Wunder, denn ich habe mich hier schamlos beim Editor des WordPress-Plugins Yoast bedient. Ich habe es allerdings um Funktionalitäten ergänzt, die sich in der täglichen SEO-Arbeit mit großen Websites herauskristallisiert haben.
Der Redirect-Editor besteht aus fünf Komponenten, die verschiedene Aufgaben übernehmen. Sie dienen konkret dem Anlegen, Betrachten und Exportieren von Weiterleitungen. Diese Komponenten schauen wir uns nun nachfolgend im Detail an. Mitunter gehen wir dabei sehr in die Tiefe, denn wie bereits anfangs geschrieben, kommt das Thema vermeintlich einfach daher – werden allerdings einzelne Fälle betrachtet, muss man sehr viel dabei bedenken und entscheiden. Entsprechend optional muss der Editor auch sein, um sich bei jedem Fall für die eine oder andere Variante zu entscheiden. Aber legen wir los.
Das zentrale Feature des Editors ist es – welch Überraschung –, Weiterleitungen anzulegen. Dabei muss aber zwischen dem manuellen Anlegen von Redirects – also ich trage eine einzelne URL ein und spezifiziere ein konkretes Weiterleitungs-Ziel für diese URL –, dem Import von Redirect-Listen und dem automatischen Weiterleiten von geänderten oder gelöschten URLs differenziert werden.
Der folgende Screenshot zeigt das Modul für das Anlegen von einzelnen Weiterleitungen. Die gelben Notizenzettel stellen die möglichen Ausprägungen der Dropdowns dar.
Wie im Screenshot zu erkennen, bietet das Modul dem Nutzer verschiedene Freitext- und Auswahlfelder, mit den folgenden Funktionalitäten:
https://example.com/foo?q=lorem+ipsum enthält die Zeichen ? und +, die in Regex Meta-Zeichen mit eigener Bedeutung darstellen.Da ihr einen derartigen Redirect-Editor mit Sicherheit nicht Out-of-the-Box bekommen werdet, sondern ihn bei eurer Technik anfordern müsstet, werde ich euch zu jedem Modul auch noch die Details geben, wie mit der Eingabe des Nutzers zu verfahren ist. Ansonsten kommt ihr nämlich sehr schnell in unzählige Abstimmungsrunden mit eurer IT, weil „das ja nie in der Form so angefordert wurde“.
Wird ein manueller Redirect über den Button Redirect hinzufügen eingetragen, sind folgende Prüfpunkte abzuarbeiten, bevor der Redirect ins System übernommen wird.
Ist eine der Bedingungen nicht erfüllt, bricht die Eintragung ab und der Nutzer erhält einen spezifischen und verständlichen Hinweis darauf, welches Prüfkriterium verletzt wurde. Noch mal, der Nutzer erhält einen Hinweis, mit dem er etwas anfangen kann. Häufig wird dieser Redirect-Editor nicht nur von SEOs verwendet, sondern auch von Redakteuren oder Produkt-Managern. Letztere sind wahrscheinlich schon genervt, dass sie überhaupt diese „SEO-Weiterleitungen“ bedenken müssen. Entsprechend müssen die Hürden beim Anlegen eines Redirects so gering wie möglich sein. Und nichtssagende Fehlermeldungen sind einer der maßgeblichen Gründe, ein Tool nach dem ersten Versuch nie wieder zu verwenden und fortan den SEO zu nerven, die Redirects einzutragen.
Sind alle Bedingungen erfüllt, wird der Redirect ins System übernommen und unmittelbar in der Übersichtstabelle dargestellt. Die folgenden Spaltenwerte – die nicht durch den Bearbeiter manuell definiert wurden – werden dabei automatisch befüllt.
YYYY-MM-DD. Und nein, MM.YYYY oder MM/DD/YYYY oder was auch immer, sind keine Option. Sortiert mal nach einem solchen Datumsformat und ihr wisst warum.<title> des Weiterleitungsziels zum Zeitpunkt der Eintragung des Redirects. Auch hier gilt, dass diese Information ggf. nicht zum Zeitpunkt der Eintragung unmittelbar zur Verfügung steht – dann muss sie zu einem späteren Zeitpunkt nachgetragen werden. Wichtig ist diese Information aber auf jeden Fall, denn Nutzer denken häufig nicht unbedingt in URLs – insbesondere, wenn diese nicht sprechend sind – sondern orientieren sich am Title einer Seite, um den Inhalt schnell zu erfassen und das Weiterleitungsziel auf Relevanz zu prüfen. Beim Zeitpunkt der Eintragung wird der Nutzer die Ziel-Seite eh manuell identifizieren. Später, beim Verwenden der Übersichtstabelle, ist der Title aber unabdingbar, um sich einen schnellen Überblick über den Inhalt zu verschaffen.
Häufig – insbesondere im Zuge von Relaunchs – muss eine Liste von Weiterleitungen eingepflegt werden. Um den manuellen Aufwand gering zu halten, kann hier eine CSV in definiertem Format hochgeladen werden. Das vorgegebene Format ist wie folgt.
[Bearbeiter];[Anmerkung];[alte URL];[neu URL]
...
Ein Beispiel:
Erika Musterfrau;Relaunch Bulk Redirect 00001;https://example.de/;https://example.com/
...
Da es sich hier um eine automatisch zu verarbeitende CSV handelt, ist es wichtig, dass der Ersteller der Liste einige Konventionen beachtet:
Erika Mustermann; Max Mustermann angegeben werden. Es kann in sehr seltenen Fällen vorkommen, dass URLs Semikolons enthalten. Diese dürfen somit nicht importiert werden, sondern müssen manuell eingetragen werden.Der Nutzer wird somit bewusst eingeschränkt, um den Import so reibungslos wie möglich zu gestalten. Ich kann als Nutzer tausende von URLs hochladen und damit enorm viel Zeit sparen – muss mich dafür aber auch an ein paar Regeln halten.
Aller Einschränkungen zum Trotz kann der Import aber dennoch missgeformt sein. Daher muss er entsprechend der folgenden Kriterien evaluiert werden
Wurde eine Datei ausgewählt, prüft das System, ob die Datei dem vorgegeben Format entspricht. Sollte dies nicht der Fall sein, bricht der Import ab und der Nutzer erhält eine Fehlermeldung, die ihn auf das inkorrekte Format hinweist. Inkorrekte Formate können bspw. bedingt sein durch falsche Trennzeichen (Kommata, Tabs etc. statt Semikolons) oder zu wenige / zu viele Spalten.
Wird die Datei akzeptiert, gibt die nebenstehende Fortschrittsanzeige an, wie viele der Redirects verarbeitet wurden. Ist der Import abgeschlossen, sind folgende Prüfpunkte abzuarbeiten, bevor die Redirects ins System übernommen werden.
;;https://example.de/;https://example.com. Erfahrungsgemäß ist gerade beim Bulk-Import von Redirects sicherzustellen, dass der Verantwortliche ermittelt werden kann und in welchem Kontext die Redirects eingepflegt wurden. Daher sollten auch beim Import die Pflichtfelder – wie bei der manuellen Erstellung eines Redirects – gelten.Ist eine der Bedingungen nicht erfüllt, sind unterschiedliche Verhalten des Redirect-Editors denkbar.
Alle gültigen Redirects werden importiert und in das System eingetragen. Alle Zeilen – sprich: Redirect-Definitionen – die ein Prüfkriterium verletzt haben, werden nicht in das System eingetragen. Am Ende des Importvorgangs erhält der Nutzer eine tabellarische Übersicht aller Redirects sowie die jeweilige Beanstandung. Die Tabelle kann wie folgt aufgebaut sein.
Der Nutzer hat dann die Möglichkeit, die zurückgewiesenen Redirects nacheinander manuell zu bearbeiten. (Zur detaillierten Beschreibung der Funktionalität der Tabelle s. Übersichtstabelle). Wird durch die Bearbeitung der Verstoß behoben, wird der Wert in der Spalte Import-Fehler zu Import-Fehler behoben geändert. Entsteht durch die Bearbeitung ein anderer Verstoß, wird dieser als Wert in die Spalte Import-Fehler geschrieben. Lässt sich ein Fehler nicht beheben, kann der Redirect über löschen vom Import ausgenommen werden.
Der Nutzer hat über den unter der Tabelle befindlichen Button Redirects erneut importieren jederzeit die Möglichkeit, alle Redirects, die valide sind, erneut zu importieren. Die validen, erneut importierten Redirects werden ins System eingetragen und aus der Übersichtstabelle entfernt.
Erfahrungsgemäß ist der Implementierungsaufwand für Option 1 hoch. Auch wenn Option 1 anzustreben ist, da es die Arbeit signifikant erleichtert, kann die nachfolgend beschriebene Option eine Alternative darstellen.
Tritt bei der Evaluation der importierten Liste ein Verstoß gegen eines der Prüfkriterien auf, bricht der gesamte Import ab. Der Nutzer erhält eine Fehlermeldung mit dem Hinweis darauf, welches Kriterium verletzt wurde und in welcher Zeile der CSV dies aufgetreten ist. Der Nutzer muss dann in der CSV selbst den Fehler beheben und die CSV erneut importieren.
Keine Option ist es, Redirects, die eines der Prüfkriterium verletzten, stillschweigend – also ohne Feedback an den Nutzer – zu übergehen.
Es ist nie verkehrt, alle Redirects exportieren zu können – bspw. um sie als Input für einen Crawler zu verwenden.
Über den Button Export starten können alle eingetragenen Redirects exportiert werden. Die CSV-Datei ist wie folgt aufgebaut und weist eine Überschriften-Zeile auf.
"ID";"Erstellt";"Bearbeiter";"Anmerkung";"Typ";"Status Code Redirect";"alte URL";"neue URL";"Status Code neue URL";"Title"
"[ID]";"[Erstellt]";"[Bearbeiter]";"[Anmerkung]";"[Typ]";"[Status Code Redirect]";"[alte URL]";"[neue URL]";"[Status Code neue URL]";"[Title]"
...
Es kann vorkommen, dass Nutzer beim manuellen Anlegen von Redirects Semikolons verwenden. Da diese als Trennzeichen in der Export-CSV verwendet werden, werden alle Zellenwerte standardmäßig durch Anführungszeichen “ qualifiziert. Treten innerhalb der Zellenwerte ebenfalls Anführungszeichen auf, sind diese automatisch zu escapen („Das ist eine \"Anmerkung\" mit Anführungszeichen„).
Die Übersichtstabelle dient zur Darstellung aller eingepflegten Redirects. Sie muss es dem Benutzer ermöglichen, die Eigenschaften eines Redirects schnell erfassen und ggf. bearbeiten zu können.
Die Tabelle besteht aus folgenden Spalten:
YYYY-MM-DD.<title>) der neuen URL (für die detaillierte Beschreibung der Ermittlung des Titles s. Regelmäßige Abfrage der Status Codes und Titles der Weiterleitungsziele).Bearbeiten
Buttons zum Bearbeiten oder Löschen des nebenstehenden Redirects. Beim Klick auf den Button werden die Spaltenzellen des jeweiligen Redirects direkt in der Tabelle in Form von Dropdowns und Freitextfeldern editierbar. Die Optionen in der Spalte Bearbeiten ändern sich zu aktualisieren, um die Änderung am Redirect zu übernehmen, und abbrechen, um die Bearbeitung abzubrechen.
Es können alle Spalten editiert werden ausgenommen der Spalten ID und Erstellt. Der Wert der Spalte Erstellt aktualisiert sich nach dem Speichern der Bearbeitung automatisch entsprechend des aktuellen Datums.
Wie zuvor bereits erwähnt, weist die Übersichtstabelle in der ersten Spalte Checkboxen auf, mit denen sich eine oder mehrere Redirects markieren lassen. Die Checkbox in der Tabellenüberschrift dient zur Aus- / Abwahl aller Redirects der aktuellen Pagination (befindet sich der Nutzer also auf Seite 1 der Tabelle und wählt die Checkbox in der Tabellenüberschrift aus, werden nur die Redirects der Seite 1 und nicht der Seiten 2 – n markiert).
Wurden ein oder mehrere Redirects markiert, kann der Nutzer über das oberhalb der Tabelle befindliche Dropdown eine Aktion durchführen:
Durch das Betätigen des Ausführen-Buttons wird die ausgewählte Aktion durchgeführt.
Die Suche dient dazu, die Übersichtstabelle ad hoc filtern zu können, um somit nur die gewünschten Redirects betrachten zu können. Ohne eine vollwertige Such- und Filterfunktionalität ist die effiziente Arbeit mit einem Redirect-Editor kaum möglich. Denn erfahrungsgemäß müssen bestehende Redirects immer mal wieder angefasst werden. Um nur einen Anwendungsfall zu nennen: Ich schaue mir wöchentlich den Status Code der Zielseiten an, ob diese weiterhin erreichbar sind. Dazu filtere ich die Spalte auf den Status Code 404 und arbeite dann Redirect für Redirect ab. Ohne die Filtermöglichkeiten artet allein so etwas sehr schnell in Export-Aufbereitungs-Import-Kaskaden aus.
Die Suche besteht aus drei Dropdowns und einem Freitextfeld.
/foo/ trifft sowohl die alte URL https://exp.com/foo/bar/ als auch die Anmerkung Weiterleitung des Verzeichnisses /foo/.https://exp.com/foo/ trifft die neue URL https://exp.com/foo/ aber nicht https://exp.com/foo/bar/./fo.*?/ trifft https://exp.com/foobar/. Es wird also nur geprüft, ob das angegeben Pattern im Wert enthalten ist. Das Pattern muss nicht den gesamten Wert treffen. Es ist somit nicht nötig, das Pattern als .*/fo.*?/.* zu definieren, um https://exp.com/foobar/ zu treffen.Ein Klick auf den Button Suchen führt die definierte Suche aus und aktualisiert die untenstehende Tabelle entsprechend der Ergebnisse.
So wie das Weiterleitungsmanagement nicht „mal eben“ gemacht ist, ist auch die Anforderung eines Redirect-Editors, mit dem ich die Weiterleitungen überhaupt erst umsetzen kann, nicht „mal eben“ definiert. Ich hoffe, ich konnte euch mit der obigen Beschreibung einen ersten Wurf an die Hand geben, um gemeinsam mit eurer IT in die Abstimmung zu gehen. Wie das in unserem Feld aber immer so ist, gibt es nicht die eine Lösung. Einige der skizierten Funktionen werden für euch vllt. nicht sinnvoll sein oder sind in der Umsetzung derartig aufwendig, dass sie ignoriert werden müssen. Wie immer also: It depends.
Als ich eingangs davon gesprochen habe, dass ich „nur“ den Editor beschreiben werden, habe ich natürlich gelogen. Der Editor muss von gewissen Prämissen ausgehen, auf die ich bereits ständig verwiesen habe und die im nachfolgenden, technischen Appendix im Detail beschrieben werden.
Im Nachfolgenden gilt die Prämisse, dass es sich bei der vorliegenden Domain um https://www.example.com/ handelt.
Im Rahmen des Redirect-Managements – sprich: wie mit URLs verfahren wird, die nicht der Standard-Form entsprechen – gelten die folgenden Redirects als vorgelagert. Das heißt, eine nicht standardkonforme URL durchläuft die folgende Kaskade, bevor sie gegen die im Redirect-Editor definierten Weiterleitungen geprüft wird. Dadurch wird sichergestellt, dass die auf einen möglicherweise bestehenden Redirect zu prüfende URL in einer standardisierten Form vorliegt, die keine Unklarheiten zulässt. Die Reihenfolge der zu durchlaufenden Standardisierungsschritte ist die folgende:
http angefragt werden, werden auf https via 301 weitergeleitet.http://example.com/foö → https://example.com/foöhttp://example.com/foö?q=bar → https://example.com/foö?q=barhttp://example.com/foö#bar → https://example.com/foö#barwww. weitergeleitet. Natürlich kann auch der umgekehrte Fall eintreten, wenn die nicht-www-Variante die Standard-Form ist. Zu bedenken ist der Umgang mit einer etwaig vorhandenen mobilen Subdomain (https://m.example.com/). An dieser Stelle wird davon ausgegangen, dass die www-Variante die bevorzuge Variante ist.https://example.com/foö → https://www.example.com/foöhttps://example.com/foö?q=bar → https://www.example.com/foö?q=barhttps://example.com/foö#bar → https://www.example.com/foö#barhttps://www.example.com/foö → https://www.example.com/fooehttps://www.example.com/foö?q=bar → https://www.example.com/fooe?q=barhttps://www.example.com/foö#bar → https://www.example.com/fooe#barhttps://www.example.com/fooe → https://www.example.com/fooe/https://www.example.com/fooe?q=bar → https://www.example.com/fooe/?q=barhttps://www.example.com/fooe#bar → https://www.example.com/fooe/#barDurch die Normalisierung der URLs wird sichergestellt, dass innerhalb des Redirect-Editor keine Unklarheit darüber besteht, in welcher Form die weiterzuleitende URL einzutragen ist. Angenommen eine URL mit dem Pfad /foo/bar/ soll weitergeleitet werden. Der Nutzer trägt in den Redirect Editor nur die URL https://www.example.com/foo/bar/ ein. Er kann sich damit sicher sein, dass alle abweichenden Verlinkungen – bspw. http://example.com/foo/bar – ebenfalls durch den eingetragenen Redirect adressiert werden.
Nach den vorgelagerten Redirects, die die URL normalisieren, greifen Redirects, die im Redirect-Editor definiert werden.
Zum Schluss greifen Redirects, die spezifische Bestandteile von URLs umschreiben – ein klassisches Beispiel ist hier eine Verzeichnisänderung in der Form: https://www.example.com/altes-verzeichnis/foo/ → https://www.example.com/neues-verzeichnis/foo/. Diese Art der Redirects muss zum Schluss greifen und kann nicht vorgelagert werden, da ansonsten alle bestehenden 1:1- und n:1-Redirects, die bereits definiert wurden, durch eine neu eingeführte Umschreibung eines Verzeichnisses nicht mehr greifen würden.
Normalisierung des Protokolls
http://example.com/bar/foö/→ https://example.com/bar/foö/
Normalisierung der Subdomain
https://example.com/bar/foö/ → https://www.example.com/bar/foö/
Normalisierung eines Umlauts
https://example.com/bar/foö → https://www.example.com/bar/fooe
Normalisierung des Trailingslashs
https://www.example.com/bar/fooe → https://www.example.com/bar/fooe/
1:1-Weiterleitung
https://www.example.com/bar/fooe/ → https://www.example.com/bar/lorem/
Umschreiben des Verzeichnisses
https://www.example.com/bar/lorem/ → https://www.example.com/ipsum/lorem/
Unter Berücksichtigung der vorgenannten Redirect-Kaskaden zur Normalisierung der URLs können weiterzuleitende URLs nur in einer Standard-Form eingetragen werden, da sie ansonsten zu Konflikten mit den vorgelagerten Redirect-Kaskaden führen. Beim Eintragen einer alten URL müssen daher folgende Kriterien geprüft werden. Wird ein Kriterium verletzt, wird der Redirect nicht ins System übernommen und dem Nutzer eine Fehlermeldung unter Angabe des verletzten Kriteriums angezeigt.
https://m.example.com/, so ist diese auch als zulässig zu definieren. Gibt es darüber hinaus weitere Domains – bspw. https://www.beispiel.de/– so ist im Detail zu klären, ob diese zulässig sind.Darüber hinaus sind die folgenden Punkte sicherzustellen:
https://www.example.com/foo/ → https://www.example.com/bar/. Die URL https://www.example.com/bar/ kann somit nicht als weiterzuleitende URL (alte URL) definiert werden, da ansonsten für die URL https://www.example.com/foo/ eine Weiterleitungskette entsteht.Fehler - Weiterleitungskette: Die URL https://www.example.com/bar/ ist selbst ein Weiterleitungsziel (neue URL). Siehe ID [ID].https://www.example.com/foo/ → https://www.example.com/bar/. Die Weiterleitung https://www.example.com/foo/ → https://www.example.com/lorem/ kann somit nicht eingetragen werden, da die weiterzuleitende URL ansonsten zwei unterschiedliche Weiterleitungsziele hätte.Fehler - nicht eindeutiges Weiterleitungsziel (neue URL): Die URL https://www.example.com/foo/ leitet bereits weiter auf https://www.example.com/bar/. Siehe ID [ID].Eine Problematik hinsichtlich der weiterzuleitenden URLs, die durch die Prüfung nicht abgefangen werden kann, resultiert daraus, wenn diese als Regex angelegt sind. Hier stellt sich die Frage, wie die folgenden, weiterzuleitenden Patterns zu evaluieren sind.
^https://www.example.com/foo/.* → https://www.example.com/lorem/^https://www.example.com/foo/bar/.* → https://www.example.com/dolor/Beide Patterns matchen die URL https://www.example.com/foo/bar/dolor/, zeigen aber auf unterschiedliche Weiterleitungsziele.
Eine Prüfung darauf, ob bei Regex-Redirects ein Zielkonflikt auftritt, ist erfahrungsgemäß schwierig zu implementieren. Auch eine Logik, dass das spezifischste Pattern den Vorzug erhalten soll, ist nicht einfach umsetzbar.
Die einfachste Lösung ist, dass derjenige Regex-Redirect, der als erstes trifft, ausgeführt wird. Im obigen Beispiel würde somit die Weiterleitung auf /lorem/ erfolgen. Der zweite Regex-Redirect wird gar nicht mehr evaluiert.
Dies kann mitunter zu unerwarteten Weiterleitungen führen, wenn ein Nutzer einen neuen Regex-Redirect einträgt, der dann gar nicht greift, weil bereits ein weiterer, ebenfalls treffender Regex-Redirect besteht – ein weiteres Faktum, weshalb musterbasierte Weiterleitungen mit Vorsicht zu genießen sind.
https://www.example.com/foo/ → https://www.example.com/bar/. Die URL https://www.example.com/foo/ kann somit nicht als Weiterleitungsziel (neue URL) definiert werden, da ansonsten für neu weiterzuleitenden URL eine Weiterleitungskette über die URL https://www.example.com/foo/ entsteht: https://www.example.com/neue/weiterleitung/ → https://www.example.com/foo/ → https://www.example.com/bar/.Fehler - Weiterleitungskette: Die URL https://www.example.com/foo/ wird selbst weitergeleitet (alte URL). Siehe ID [ID].Wird im System eine Seite verschoben – das heißt, eine bestehende URL ändert sich in einer Form, sodass die Seite erhalten bleibt, aber bspw. in einem anderen Verzeichnis liegt – so muss sichergestellt werden, dass die alte URL automatisch per 301 auf die neue URL weiterleitet.
Wird ein automatischer Redirect ausgeführt, ist dieser in der Übersichtstabelle zu ergänzen. Folgende Felder sind systemseitig zu befüllen
Es ist wichtig, laufend den Status Code und den Browser-Title abzufragen und in der Übersichtstabelle darzustellen, damit der Nutzer Weiterleitungsziele identifizieren kann, die ggf. nicht mehr erreichbar sind oder erneut weiterleiten. Dadurch soll eine kontinuierliche Pflege der Weiterleitungen erleichtert und sichergestellt werden.
Die Abfrage des Browser-Titles dient dazu, das Thema eines Weiterleitungsziels für den Nutzer schneller erfassbar zu machen, wenn dies durch die URL an sich nicht möglich ist.
Erfahrungsgemäß ist die Abfrage der Status Codes und des Titles nicht in Echtzeit möglich, da je nach Anzahl der eingetragenen Redirects der Prozess sehr lange dauert. Es bietet sich daher an, ein Abfrageintervall von 24 Stunden zu definieren, sodass der Prozess nachts die beiden Werte erhebt und die Übersichtstabelle aktualisiert wird, sodass der Nutzer am nächsten Morgen einen aktuellen Stand vorfindet.
Aus diesem Grund wird dem Nutzer im Redirect-Editor kein Button zur ad hoc Abfrage aller Status Codes und Titles angeboten (dies ist nur für die Mehrfachauswahl möglich), da der Prozess ggf. sehr lange läuft und somit das Arbeiten blockiert.
200, 301 etc.) in die Spalte Staus Code neue URL geschrieben.200 abweichen, werden farblich hervorgehoben:
300 bis 399 werden in gelb/orange hervorgehoben, wodurch eine Warnung impliziert wird.400 bis 499 werden in rot hervorgehoben, wodurch ein Fehler impliziert wird.Das Weiterleiten von parametrisierten URLs ist nicht trivial und kann hier nur in einem ersten Ansatz beschrieben werden. Die finale Ausprägung der Weiterleitungslogik wird maßgeblich durch die von der Website verwendeten Parameter und ihrer Funktionalität bestimmt. Der Umgang mit Parametern, die eine Pagination anzeigen (page=2), ist noch recht einfach umzusetzen, da hier der Parameter eine eigenständige Seite erzeugt, die auch als Verzeichnis (/2/) gedacht werden kann.
Gleiches gilt für Parameter – insbesondere Tracking-Parameter -, die den Seiteninhalt gar nicht verändern.
Wenn jedoch der Seiteninhalt durch Parameter verändert wird – bspw. Filterungen, Sortierungen, Inhalte -, muss im Detail überlegt werden, wie die Weiterleitung derartiger URLs umzusetzen ist. Sind sie als eigenständige URLs zu werten r können sie ggf. auf die kanonische URL weitergeleitet werden.
Im Vorfeld ist somit genaustens zu prüfen, welche Parameter auf der Website auftreten.
Nachfolgend wird daher nur eine exemplarische Logik beschrieben. Ihr liegt zugrunde, dass – wie oben beschrieben – die Mitnahme von Parametern an das Weiterleitungsziel optional ist.
Per Default werden die Parameter von URLs mitgenommen. Dadurch wird sichergestellt, dass bei einer Verzeichnis-Änderung paginierte Seiten 1:1 weitergeleitet werden. Im Redirect-Editor wird somit folgende Weiterleitung eingetragen:
https://www.example.com/foo/ → https://www.example.com/bar/Wird die URL https://www.example.com/foo/?page=2 aufgerufen, wird der Parameter automatisch mitgenommen und der Nutzer gelangt auf die Seite https://www.example.com/bar/?page=2. Durch die explizite Angabe an dem Redirect, dass Parameter nicht erhalten bleiben sollen, würde alle Aufrufe von paginierten Seiten auf die Seite 1 weitergeleitet:
https://www.example.com/foo/?page=2 → https://www.example.com/bar/Wird eine weiterzuleitende URL explizit mit einem Parameter angegeben, wird nur diese weitergeleitet – nicht die unparametrisierte URL:
https://www.example.com/foo/?utm_source=google → https://www.example.com/bar/
https://www.example.com/bar/https://www.example.com/bar/?utm_source=googlehttps://www.example.com/bar/ – also ohne den explizit angegeben Parameter – auf, wird er nicht weitergeleitet.https://www.example.com/foo/?utm_campaign=test-campaign → https://www.example.com/foo/?utm_campaign=live-campaign
https://www.example.com/foo/?utm_campaign=test-campaign auf die URL https://www.example.com/foo/?utm_campaign=live-campaign&utm_campaign=test-campaign weitergeleitet. In diesem Fall muss somit systemseitig sichergestellt werden, dass der initiale Parameter nicht einfach nur angehängt wird (falsch: https://www.example.com/foo/?utm_campaign=test-campaign?utm_campaign=live-campaing), sondern korrekterweise mittels & mit dem neuen Parameter verknüpft wird.https://www.example.com/foo/?utm_campaign=test-campaign → https://www.example.com/bar/?utm_campaign=live-campaign
https://www.example.com/foo/?utm_campaign=test-campaign → https://www.example.com/bar/?utm_campaign=live-campaignhttps://www.example.com/foo/?utm_campaign=test-campaign → https://www.example.com/bar/?utm_campaign=live-campaign&utm_campaign=test-campaign
Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.
SEO Berlin – [sichtbar & erfolgreich]
Wielandstraße 9, 12159 Berlin
030 / 296 73 998
berlin@gettraction.de
SEO Darmstadt- [sichtbar & erfolgreich]
Berliner Allee 58, 64295 Darmstadt
06151 / 860 69 85
darmstadt@gettraction.de
5 Gründe für get:traction:
SEO News im September 2020 - SEOHouse SEO Podcast Podcast
[…] Redirect-Editor: Unser Kollege Patrick hat in seinem Blogartikel funktionale Anforderungen für ein effizientes & effektives Weiterleitungsmanagement definiert. […]