Das wird von vielen Magento-Kunden sehr gern genutzt, unser Online-Marketing bemängelte jedoch regelmäßig, dass diese Informationen nur ungenügend für Werbezwecke und Suchmaschinenoptimierung genutzt werden können. Wir haben hierfür zwei Module konzipiert, die richtig eingesetzt aus Seiten der Layered Navigation starke Landing Pages generieren können:
- Sprechende FilterUrls
- und der Glossar.
Im weiteren Verlauf dieses Artikels wird auf die beiden Module und deren Wirkungsweise näher eingegangen. Es sei darauf hingewiesen, dass zum Zeitpunkt des Artikels leider nur die FilterUrls-Extension zum Einsatz bereit steht. Der Glossar ist zwar bereits produktiv im Einsatz, muss jedoch im Sinne der Flexibilität und Unabhängigkeit stark verändert werden. Vielleicht wäre ja auch das ein Thema für den Hackathon im Januar.
FilterUrls: Sprechende URLs für die Layered Navigation
Ausgangssituation
Die Layered Navigation ist ein starkes Feature von Magento, welches sowohl in der Community als auch der Enterprise Edition verfügbar ist. In sogenannten Anchor-Kategorien werden neben den Unterkategorien weitere Möglichkeiten zur Filterung der Produkte angeboten. Anchor-Kategorien beinhalten alle Produkte der Unterkategorien und mittels entsprechender Index-Tabellen bestimmt Magento die filterbaren Attribute eben dieser Produkte. Mit einem Klick auf eine Attribut-Option wird die Produktliste auf die Produkte mit dieser Ausprägung eingeschränkt.
So weit, so gut. Aber wie schauen die Links aus, welche die Layered Navigation hierbei generiert?
http://demo.magento.url/electronics/computers.html?manufacturer=117
Bei einem einfachen Klick auf den Hersteller „AMD“ in den Demodaten ergibt sich folgender Link: An die Kategorie-URL (/electronics/computers.html) wird einfach der GET-Parameter manufacturer=117 angehängt. Hierbei meint manufacturer den Attribute-Code des Filter-Attributes und 117 ist die Options-Id des gewählten Wertes. Magento und sein Layer-Model weiß damit, dass auf die Produkt Collection ein Filter angewendet werden muss. Was passiert, wenn wir mehrere Filter gleichzeitig aktivieren?
http://demo.magento.url/electronics/computers.html?color=24&manufacturer=117
Alle gewählten Attributfilter werden demnach einfach aneinandergereiht. Die Reihenfolge ist an sich nicht interessant: für den eigentlichen Filtervorgang ist die Reihenfolge nur von untergeordneter Bedeutung und für Suchmaschinen-Optimierungszwecke werden die Standard-URLs dank robots.txt selten sinnvoll verwendet: Sie sind nicht sprechend und auch nicht lokalisiert.
Es geht auch anders
An sich sind die Voraussetzungen sowohl für die sprechenden URLs und auch für die Lokalisierungen bereits gegeben: Man pflegt sie im Backend im Rahmen der Optionspflege der Attribute. Hier wird für jede Option eines Attributes eine Eingabe pro Store-View angeboten, welche für Übersetzungen genutzt werden sollten. Diese Übersetzungen werden auch für die Labels der Links innerhalb der Layered Navigation verwendet und sollten damit automatisch in allen Sprachen vorliegen. (Vorsicht: für die Demodaten müssen diese Informationen zunächst nachgepflegt werden!)
Das Modul verändert nun die URLs folgendermaßen: Ausgangslage ist die Kategorie-URL ohne HTML-Suffix – bleiben wir beim obigen Beispiel: http://demo.magento.url/electronics/computers. Dieser Teil der URL wird logischerweise verwendet, um die aktuelle Kategorie zu identifizieren. Nun wird jedoch ein weiterer Slash eingeführt gefolgt vom „Rewrite“ der gewählten Option, beispielweise also amd und schließlich das HTML-Suffix. Das Ergebnis sieht wie folgt aus:
http://demo.magento.url/electronics/computers/amd.html.
Natürlich müssen wir auch hier den Fall der Mehrfachauswahl bedenken. Was passiert also, wenn ich nun neben der Marke AMD auch noch die Farbe braun auswähle?
http://demo.magento.url/electronics/computers/amd-brown.html bzw. http://demo.magento.url/elektronik/computer/amd-braun.html in der deutschen Version (unter der Voraussetzung, dass die Kategorien eben auch übersetzt wurden!).
Die verschiedenen Attribut-Optionen werden demnach einfach mit einem „-“ getrennt aneinander gereiht. Wichtig hierbei ist die Pflege der Position der Attribute im Backend, weil diese als „Priorität“ interpretiert werden, so dass wichtige Attribute zuerst und unwichtige zuletzt in die URL eingegliedert werden. Außerdem kann nur so eine Stabilität der URLs gewährleistet werden.
Das Ergebnis ist nun eine sprechende URL, die sich neben der Kategorie aus den Werten der gewählten Filter zusammensetzt. Damit es nicht zu Kollisionen kommen kann, werden verschiedene Zeichen wie „-“, „&“ usw. durch „_“ ersetzt.
Wie funktioniert das?
Unser Ziel war immer das ganze sehr einfach zu halten. Das Modul besteht im Grunde aus zwei Dingen:
- Ein veränderter Link-Generierungsmechanismus. Zur Generierung der korrekten Links musste das Model Mage_Catalog_Model_Layer_Filter_Item geändert werden. Hierbei wird zunächst geprüft, ob bereits ein Rewrite für die aktuelle Kombination von Attribute, Option und Store generiert wurde. Liegt dieses bereits in der entsprechenden Datenbank-Tabelle vor, kann es wiederverwendet werden. Wird kein Rewrite gefunden, erstellt das Modul automatisch ein neues Rewrite.
- Ein Router versucht wiederum die gegebene URL in die ursprünglichen Parameter zurück zu übersetzen. Hierfür werden die mit „-“ getrennten Elemente der URL wieder extrahiert und mit der Datenbank abgeglichen. Die eigentliche Layered Navigation funktioniert unverändert weiter.
Und sonst? Wie geht es weiter?
Bis dahin ist die Geschichte wirklich einfach. Woher weiß die Suchmaschine von den URLs? Neben der internen Verlinkung selbst natürlich von Sitemaps. Aber wo bekommen wir die Sitemaps her? Okay, wir schauen uns die Sache an. Problematisch ist vor allem eins: Das Modul kennt bisher nur Rewrites, d.h. Übersetzungen einzelner Attribut-Optionen, nicht ganze URLs. Welche Kombinationen sollen nun also in eine Sitemap mit aufgenommen werden? Der Theorie nach nur die, die es wirklich gibt, weil die Menge von potentiellen Kategorie-Attribute-Optionen-Permutationen gegen unendlich gehen kann. Deshalb haben wir nachträglich noch ein Model eingeführt, welches die generierten URLs aufzeichnet und schließlich in eine Sitemap.xml integrieren kann. Diese URLs haben in Zukunft noch weitere Funktionen:- Es soll nachvollzogen werden, welche 301-Weiterleitungen im System eingeführt werden müssen, wenn eine Attributoptions-Übersetzung verändert wird. Wenn nun also beispielweise „Gelb“ in „Gold“ übersetzt werden sollte, müssten nach Möglichkeit nicht nur das Rewrite, sondern auch alle entsprechenden URLs ersetzt werden. Alte URLs würden dann automatisch auf neue weiterleiten.
- In einer zukünftigen Version wäre es auch sinnvoll, derartige URLs per Cronjob wieder aus der Sitemap zu nehmen, für die keine Ergebnisse mehr erzielt werden. Das haben wir bisher leider zeitlich nicht realisieren können.
- Sowohl Preis- als auch Kategorie-Filter sind von dieser Verarbeitung nicht betroffen. Ursache hierfür sind unterschiedliche Dinge: Kategorie-Filter müssen sich von normalen Kategorie-Links unterschieden, weil sonst zufälligerweise direkt in eine „Nicht-Anchor“-Kategorie (bieten keine Filter an!) verlinkt werden könnte. Das Ergebnis wäre unverständlich und schwer nachvollziehbar. Preis-Links werden sehr oft shopspezifisch angepasst, beispielweise um Preisspannen flexibler zu gestalten. Deshalb ist eine Bearbeitung dieser Funktionalität gefährlich, weil Inkompatibilitäten drohen. Abgesehen davon hat der Preis kaum Relevanz für eine suchmaschinenoptimierte URL.
- Es ist nicht geplant, Kollisionen mit anderen URLs abzufangen. Wird beispielsweise eine Unterkategorie wie ein Hersteller benannt, wird man bei Auswahl des entsprechenden Filters in der Unterkategorie landen statt den entsprechenden Filter zu setzen, weil der Kategorie-Router vorgeht. Eine Überprüfung wäre sehr aufwändig, eine Bevorzugung unseres Routers gefährlich. Gute Namen für Kategorien und für Attributoptionen helfen, dies zu verhindern.