POST, GET & PRG-Pattern für Online-Shops

by Mario-Schwertfeger

POST, GET & PRG-Pattern für Online-Shops

by Mario-Schwertfeger

by Mario-Schwertfeger

Die Nützlichkeit von POST- und GET-Request und des PRG-Patterns für die Navigation in Online-Shops aus SEO-Sicht

HTTP ist das Übertragungsprotokoll, mit welchem Web-Browser und Web-Server ihre Daten austauschen. Hierfür gibt es HTTP-Anfragemethoden. Zwei HTTP-Anfragemethoden sind im Hinblick der Übertragung von Formulardaten von Bedeutung: GET und POST!

Doch worin unterscheiden sich die beiden Methoden und was ist sinnvoll für die Anwendung bei Online-Shops? Welche Methode gewählt wird, liegt in den Händen des Entwicklers. Deswegen sollten einige Hintergrundinformationen zu den beiden Methoden vorhanden sein. Und was ist eigentlich das POST-REDIRECT-GET -Pattern? Werfen wir mal einen Blick darauf:

Faceted Navigation bei Online-Shops

Gerade Online-Shops arbeiten im Normalfall mit einer Faceted Navigation (auch bekannt als Filter-Navigation). Hierbei kann eine große Auswahl an Datenmengen (z.B. Produkte in einem Online-Shop) anhand verschiedener Kriterien auf eine oftmals übersichtlichere Anzahl an Daten beschränkt werden.

Ein Beispiel hierfür findet sich in nahezu jedem x-beliebigen Shop. Sehen wir uns das Ganze mal im Herren-Uhrenshop von otto.de an:

filternavigation-bei-otto

 

 

 

 

 

 

 

Hier kann ich die Auswahl an Uhren anhand verschiedener Filter wie Farbe, Marke oder auch Armband verfeinern, um schlussendlich eine für mich relevante Auswahl an Uhren zu erhalten. Das Problem bei dieser Art der Navigation dürfte schnell deutlich werden. Zum einen kann hierdurch zahlreicher (Near) Duplicate Content entstehen, zum anderen werden durch die unendliche Anzahl an möglichen URLs, welche durch die Filternutzung entstehen, in extremen Maße Crawl-Ressourcen verschwendet. Allgemein gibt es für diese beiden Probleme zahlreiche Ansätze wie bspw. die Maskierung der Links via JavaScript, die Verwendung eines # (Hash) in der URL, die Parametrisierung von URLs und der Einsatz von Canonical-Tags.

Bezüglich dem Einsatz von JavaScript sei angemerkt, dass diese Methode unter Umständen nur noch bedingt funktioniert, da Google JavaScript auslesen will und ausliest, auch wenn John Mueller in einem Hangout gestand, dass dies aktuell sehr schwierig sei und noch nicht wirklich optimal funktioniert [ab Minute 50:00] und man indexrelevante URLs daher auch in einer XML-Sitemap anbieten soll, falls diese URLs an anderer Stelle nicht über einen HTML-Link erreichbar sind.

Auch in der Praxis ist unsere Beobachtung, dass das Maskieren der Navigation mittels JavaScript durchaus noch effektiv ist. Sollte Google aber irgendwann tatsächlich auch mittels JavaScript maskierte Filter auslesen und den Links dort folgen können, dann ergibt sich natürlich wieder das Problem, dass gerade bei großen Shops eine schier unendliche Anzahl an zusätzlichen URLs gecrawlt wird. Mit der Empfehlung JS aufgrund von Mobile-Optimierung zukünftig nicht mehr in der robots.txt auszusperren steigt diese „Gefahr“ natürlich weiter an. Ebenso beweist Google ja auch in den Webmaster Tools, dass sie Seiten schon komplett rendern können.

Ein interessanter Ansatz diesen Problemen zu begegnen ist dabei der Einsatz von POST- und GET-Anfragen, welches die beiden gebräuchlichsten http Request-Methoden sind.

Merkmale und Einsatzmöglichkeiten der GET-Methode

Die GET-Anfrage ist eine HTTP-Request-Methode, mit deren Hilfe Daten vom Server angefordert werden können. Dabei entstehen dynamische Parameter-URLs, die wie folgt aussehen können:

  • http://www.zalando.de/herrenbekleidung-shirts/?order=price

Gehen wir also einmal auf Zalando, um uns die Entstehung dieser URL anzusehen. Befindet man sich im Bereich Herrenbekleidung und betrachtet dort die Shirts, dann gibt es dort eine „Sortieren nach:“-Funktion.

 

 

 

 

Wählt man hier Sortieren nach: Höchster Preis, dann werden diese Daten vom Server per GET-Request angefordert. Im Quellcode sieht man das an folgendem Ausschnitt:

Quellcode GET Request

Hierdurch werden die T-Shirts nun nach dem höchsten Preis sortiert und es entsteht eine neue parametrisierte URL (siehe oben). Durch die Erzeugung einer neuen URL bei GET-Formularen entsteht in diesem Fall natürlich (Near) Duplicate Content. Zalando löst das in diesem Fall dadurch, dass sie ein Canonical auf die ursprüngliche „Herrenbekleidung Shirts“ setzen und zudem die Seite auf noindex stellen.

Eine weitere besondere Eigenschaft, welche das GET-Formular gegenüber dem POST-Formular hat, ist der Umstand, dass Google Formulare, welche mittels GET-Methode übermittelt werden crawlen kann. Im Gegensatz zum POST-Formular, welchem Google nicht folgen kann und bei welchem keine neuen URLs erzeugt werden, wird daher in diesem Fall natürlich dennoch Crawl-Budget verbraucht.

Sehen wir uns also im nächsten Schritt einmal das POST-Parameter an.

Merkmale und Einsatzmöglichkeiten der POST-Methode

Im Unterschied zur GET-Methode, welche Daten anfragt, übermittelt die POST-Methode Daten an den Server. Wie bereits erwähnt kann Google den POST-Formularen in den meisten Fällen nicht folgen (seit 2011 führt der Googlebot teilweise POST Requests durch). Dadurch werden also schon einmal Crawl-Ressourcen geschont, wenn man POST bei diesen Filtern oder Sortierfunktionen einsetzt, welchen Google nicht folgen soll. Zudem werden durch die POST-Methode keine neuen URLs erzeugt. Es besteht also keine Gefahr hinsichtlich der Entstehung von Duplicate Content.

Klingt prinzipiell gut, hat aber dennoch einen Haken: Hat der User sich ein bestimmtes Ergebnis an Produkten zusammengefiltert und möchte dies evtl. seinen Freunden mailen oder auf diversen Plattformen sharen, dann ist das natürlich nicht möglich, da es für dieses Filterergebnis keine individuelle URL gibt.

Ebenso haben Shop-Betreiber das Problem, dass sie für Sonderaktionen (bei welchen vorher gewisse Produkte gefiltert wurden) keine Möglichkeit haben für diese gefilterte Seite eine URL bspw. per Newsletter zu verschicken.

Eine Möglichkeit wäre hier natürlich zum Beispiel das Erstellen einer eigenen Landingpage mit individueller URL für solche Aktionen. Doch wollen wir uns mal ansehen, was man in diesem Fall mit POST und GET machen kann.

Das Post-Redirect-Get Pattern (PRG Pattern)

Eine gute Methode, um oben benannte Probleme zu vermeiden, bietet das sogenannte Post-Redirect-Get Pattern, auch bekannt als PRG Pattern.

Hierbei wird durch einen Klick auf den Filter ein POST-Request an den Server geschickt. Diesem kann Google wie erwähnt im den meisten Fällen nicht folgen. Das Problem mit den verschwendeten Crawl-Ressourcen wird hierdurch also umgangen. In der Datenbank wird diese Anfrage nun verarbeitet.

Anstatt dass der Server aber nun sofort die Ergebnisseite ausspielt, löst er einfach gesagt einen Redirect aus und leitet auf die Ergebnisseite zurück. Hierdurch wird das POST zu einem GET. In Folge dessen hat unsere Ergebnisseite nun auch eine eigene URL, welche auch in E-Mail-Newslettern usw. genutzt werden kann.

Insgesamt verhindert das PRG-Pattern also das Crawling durch Google und schont somit gerade bei großen Filternavigationen wertvolles Crawl-Budget, erzeugt aber dennoch individuelle URLs, welche sich teilen und verbreiten lassen. Daher kann das PRG Pattern bei Faceted Navigation also durchaus geeignet sein. Ein kritischer Faktor ist natürlich immer die technische Umsetzbarkeit im CMS und im Unternehmen. Als Sicherheitsmechanismus sollte man das Ganze aber noch mit noindex oder dem Canonical Tag versehen.

zusammenfassung-prg-pattern

 

 

 

 

 

 

 

Ich hoffe, ich konnte hiermit einen simplen Überblick über die SEO-Aspekte von POST, GET & PRG-Pattern geben. Wer technisch noch mehr ins Detail gehen möchte, dem empfehle ich unten aufgeführte Quellen.

Was ist eure Meinung und eure Erfahrung zum PRG Pattern? Habt ihr es schon irgendwo im Einsatz? Wie handelt Ihr die Schonung des Crawl-Budgets bei facetierter Navigation?

Anbei noch ein paar weitere, nützliche Quellen zum Thema:

 

[Hinweis: diesen Beitrag hatte ich ursprünglich im ehemaligen Catbird Seat Blog veröffentlicht]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Top