PRG-Pattern - Was ist das?
Online-Shops kennen wir alle. Die übliche Art der Navigation durch einen Shop mit tausenden von Artikeln ist eine Filter-Navigation (auch Faceted-Navigiation). Wir wählen hier die Farbe, Form oder den Preis (und Weiteres) der Hose, der Uhr, der Tasche, die wir kaufen möchten aus und können uns so einen besseren Überblick verschaffen.
Aus SEO-technischer Sicht entstehen hier Probleme: Die etlichen Artikel sorgen dafür, dass Near Duplicate Content (ein Inhalt auf der Seite, welcher einem anderen in vielen Belangen spiegelt) entsteht oder entstehen kann. Für unsere Suchmaschinenoptimierung ist Duplicate Content jeder Art einfach nicht gut. Außerdem generieren die Filtereinstellungen eine unüberschaubare (oder sogar unendliche) Menge an URLs. Diese unnötigen URLs brauchen das Crawling-Budget des Google Robot im Nu auf, denn Google überlässt jeder Webpräsenz nur einen gewissen Anteil an Ressourcen um die Seite zu durchforsten.
Um diesen Problemen entgegen zu wirken wird das Post-Redirect-Get (PRG)-Pattern angewandt: Eine Art der Linkmaskierung, die, neben Canonicals und dem Aussperren von URLs in der robots.txt, für Shops mit Faceted-Navgation eine sinnvolle (und absolut nötige!) Erweiterung bietet.
Post, Redirect, Get
Damit ein vom Nutzer ausgewählter Filter auch angewandt wird, werden mit Hilfe einer GET-Methode vom Server die Daten angefordert, nach welchen der Nutzer den Shop gefiltert haben möchte.
Nehmen wir an, der User möchte die Artikel (beispielsweise Hosen) dem Preis nach ordnen und schickt diese Daten per GET an den Server und erhält anschließend eine neue Unterseite, auf welcher alle Hosen dem Preis nach geordnet sind. Diese Unterseite hat natürlich eine neue, dynamische URL erstellt, durch welche der Near Duplicate Content entsteht.
Wie bereits erwähnt wäre es nun möglich diesen Einstellungen einen Canonical-Verweis auf die eigentliche Shopseite mit Hosen zu geben. Ein Canonical verbraucht jedoch auch Crawling-Budget, was wir vermeiden wollen.
Die POST-Methode übermittelt im Gegensatz zur GET-Methode Daten an den Server und empfängt sie nicht. Google kann POST-Formularen nicht (oder nur kaum) folgen, was das Crawling-Budget schont. Ebenfalls erstellt die POST-Methode keine neuen URLs – das Problem mit dem (Near) Duplicate Content löst sich auch.
Problem: Da keine neue URL entsteht, können Nutzer ihre Filtereinstellungen nicht untereinander teilen.
Lösung: Das PRG-Pattern. Da Google einem POST-Request nicht folgen kann, wird bei einer Filtereinstellung zunächst dieser an den Server geschickt. Der Server gibt nun jedoch nicht wie direkt die Seite mit den Ergebnissen aus. Über einen Redirect führt er den Nutzer auf die Ergebnisseite zurück – der POST-Request verwandelt sich in einen GET.
Unendliche Möglichkeiten für Robots
Die Vorteile des PRG-Patterns liegen auf der Hand:
- Durch Verwenden eines POST-Befehls entsteht keine neue URL. Duplicate Content wird nicht erstellt.
- Die Umwandlung in einen GET-Befehl erlaubt die Generierung einer neuen URL (die vom Nutzer weitergegeben, als Lesezeichen verwendet oder auch vom Shop-Betreiber für Sonderaktionen genutzt werden kann), welche jedoch durch den zuvor gesendeten POST-Befehl nicht gecrawlt wird.
- Das PRG-Pattern hält den Google Robot davon ab die unendlichen Möglichkeiten einer Filternavigation zu durchleuchten und spart wertvolles Crawling-Budget ein, welches speziell für Shop-Seiten mit vielen Artikeln eine wichtige Ressource ist.
Ja, Nein, Vielleicht
Das Ganze noch einmal zusammengefasst:
Kleiner Nachtrag: Unterstützt unser Content Management System (CMS) das PRG-Pattern nicht, arbeiten wir auf jeden Fall mit Canonical-Tags und noindex-Einträgen!