Post-Redirect-Get

Aus Wiki
Wechseln zu: Navigation, Suche

Zweck

Abbildung: Post-Redirect-Get - Autor: Seobility - Lizenz: CC BY-SA 4.0

Mit Hilfe des Post-Redirect-Get Patterns wird verhindert, dass Formulare auf einer Website, die per POST-Anfrage an den Server übermittelt werden, mehrfach an diesen gesendet werden, wenn ein User die entsprechende Seite aktualisiert oder den Zurück-Pfeil im Browser anklickt. Diese Problematik kann beispielsweise bei Bestellungen in einem Online-Shop oder Registrierungen auf einer Website auftreten. Folgendes Beispiel soll diesen Sachverhalt veranschaulichen:

Angenommen ein User schließt eine Bestellung in einem Online-Shop ab und gelangt anschließend direkt auf die Bestätigungsseite. Wenn er nun im Browser auf “Aktualisieren” oder “Zurück” klickt und kein Post-Redirect-Get implementiert ist, führt dies dazu, dass das POST-Formular (also die Bestellung) erneut an den Server übermittelt wird, was vom User mit Sicherheit nicht gewünscht ist.

In der Praxis reagiert in einem solchen Fall der Browser, indem er ein Fenster öffnet und den User fragt, ob er die Daten tatsächlich erneut senden möchte. Die meisten User, die kein tiefergehendes technisches Wissen besitzen, können mit dieser Frage jedoch wenig anfangen und die Usability der entsprechenden Website leidet. Auch aus diesem Grund sollte das Post-Redirect-Get Pattern für Formulare auf einer Website implementiert werden.

Hintergrundinformation: GET vs. POST Anfragen

Grundsätzlich können sowohl GET als auch POST Anfragen an einen Server gesendet werden.

Mittels einer GET Anfrage werden Daten von einem Server angefordert wie beispielsweise HTML-Dateien, Bilder etc. Solche Formulare können von Google gecrawlt werden.

POST ist hingegen eine Methode, mit der Daten an einen Server übertragen werden. Im Gegensatz zur GET Methode kann Google POST Formularen in den meisten Fällen nicht folgen.

Funktionsweise des Post Redirect Get

Zur Erläuterung der Funktionsweise des Post Redirect Get Patterns wird wieder obiges Beispiel (Bestellung in einem Online-Shop) herangezogen. Der Ablauf lässt sich hierbei in drei Schritte einteilen:

  • 1. Schritt (POST): Der User schließt den Bestellvorgang ab und sendet dabei mit seinem Browser eine POST Anfrage an den Server. Der Server verarbeitet wiederum diese Anfrage und speichert die Bestellung in der Datenbank ab.
  • 2. Schritt (REDIRECT): Anstatt anschließend direkt die Bestätigungsseite an den User zu senden, antwortet der Server dem Browser mit einem Redirect (mit dem Statuscode 3xx) auf eine neue URL, welche auf die Bestätigungsseite führt.
  • 3. Schritt (GET): Aufgrund des Redirects sendet der Browser daraufhin eine neue GET-Anfrage an den Server (da er eine neue URL abrufen muss), mit welcher die Bestätigungsseite angefordert wird.

Wenn der User die Seite nun aktualisiert, sendet der Browser erneut eine GET-Anfrage und der Server antwortet mit der Bestätigungsseite. Ohne das PRG Pattern würde der User jedoch durch das Aktualisieren der Seite die POST-Anfrage erneut senden und der Server würde die Bestellung doppelt abspeichern.

Code-Beispiel

Folgendes vereinfachtes Code-Beispiel soll die Funktionsweise des PRG Patterns veranschaulichen:

If post data transferred Then
  execute code (such as database updates)
End If 

set location header with requested URL
End

Nutzen für die Suchmaschinenoptimierung (SEO)

Das PRG Pattern verhindert nicht nur das mehrfache Senden von Formulardaten an einen Webserver, sondern kann auch im Bereich der Suchmaschinenoptimierung (SEO) sinnvoll eingesetzt werden, beispielsweise für Filter-Navigationen (Faceted Navigation) in Online Shops.

Solche Navigationen sind deshalb problematisch, da die verschiedenen Filterfunktionen (z.B. nach Farbe, Größe, etc.) durch URL-Parameter realisiert werden und somit eine Vielzahl an neuen URLs erzeugen. Die damit einhergehende Masse an internen Links beansprucht einen hohen Anteil des begrenzten Crawling-Budgets für eine Website, welches möglicherweise für andere Unterseiten benötigt wird. Zudem kann es zu Problemen mit (Near) Duplicate Content kommen, wenn sich die dargestellten Produkte auf den verschiedenen Filter-Seiten kaum unterscheiden.

Eine Lösung für dieses Problem liefert das PRG Pattern. Hierbei werden die Filter-Links auf der Website als POST-Formular integriert. Das Formular-Element wird dabei durch display: none bzw. visibility: 0 versteckt. Wenn ein solcher Filter-Link angeklickt wird, wird also eine POST-Anfrage an den Server gesendet. Dieser antwortet wiederum mit einem Redirect auf die ursprüngliche Ergebnisseite, welche nun die entsprechenden Parameter in der URL enthält. Da Google dem POST-Formular nicht folgt, findet der Crawler diese URL jedoch nicht, wodurch sowohl Duplicate Content vermieden als auch das Crawling-Budget für die Website effektiv ausgenutzt wird. Gleichzeitig existiert die entsprechende URL jedoch und kann somit beispielsweise von Usern geteilt werden.

Ein weiterer Vorteil, den diese Methode mit sich bringt, ist die Möglichkeit der Steuerung des Link Juice, der von einer Seite weitergegeben wird. Denn durch die Linkmaskierung mittels PRG Pattern können Webmaster genau kontrollieren, an welche Links dieser Link Juice abfließen soll und an welche nicht (=maskierte Links). Dies ermöglicht eine Bündelung des Link Juice auf die wirklich relevanten Seiten, die in den Suchergebnissen von Google auftauchen sollen.

Praxisrelevanz

Wie aus den obigen Beispielen bereits ersichtlich ist, ist das Post-Redirect-Get Pattern insbesondere für Online-Shops relevant, um doppelte Bestellungen zu vermeiden sowie Filter-Links für den Google Crawler zu verbergen.

Ein mögliches Problem für Webmaster besteht jedoch darin, dass das PRG Pattern nicht von jedem Content Management System unterstützt wird und die eigenständige Implementation tiefergehende Programmierkenntnisse erfordert. Aus diesem Grund wird die Methode trotz ihrer Vorteile von vielen Shop-Betreibern nicht wahrgenommen.

Weiterführende Links

Ähnliche Artikel