Häufig auftretende Strukturfehler kennen und beheben

Bei der Analyse von Webauftritten durch unseren Struktur-Analysedienstes strucr (https://strucr.com/) fallen immer wieder ähnliche Probleme im Aufbau von Webseiten auf. Zwei der häufigsten Strukturfehler wollen wir hier vorstellen und dabei erklären, wie man diese beheben kann. Es handelt sich dabei um das Problem der schleichenden Indizierung bei zu hoher Seitentiefe und das Problem der unkontrollierten Vermehrung durch Filter und Sortierung.

Kennst du deine Seite?

Unser Service crawlt komplette Webangebote und macht die anschließend eingehenden Analysen zugänglich. Wir haben nun einige Seitenbetreiber gebeten, vor den Crawls Schätzungen bezüglich Seitenanzahl und Tiefe ihrer Seite abzugeben. Diese lagen jedoch in den meisten Fällen um mehrere hundert Prozent unter den tatsächlichen Werten. Auch und insbesondere wenn die Schätzungen aufgrund einer Site-Abfrage bei Google getätigt wurden.

Nach bald einem Monat Betrieb von strucr.com kann man daher feststellen: Die meisten Seitenbetreiber kennen ihre Seiten kaum und haben keine realistische Vorstellung von Größe, Struktur und auch den Problemen ihrer Webseiten.

Hohe Seitentiefe – schleichende Indizierung

Viele der gecrawlten Webseiten hatten Probleme mit einer sehr hohen Seitentiefe. Vom Startpunkt des Crawls (Level 0) lagen Seiten oft mehr als zehn Ebenen weit entfernt. Große Teile des Angebots sind damit für Besucher und Suchmaschinen sehr schwer oder gar nicht zu erreichen. Die Verteilung der Seiten innerhalb der ersten Ebenen sieht oft wie in folgendem Beispiel aus:

Die häufigsten Ursachen für eine sehr hohe Seitentiefe sind eine undurchdachte Paginierung sowie unzureichend differenzierte und oft zu tiefe Kategoriestrukturen. Dies führt oft zu einer schleichenden oder nur teilweisen Indizierung in den Suchmaschinen.

Schlechte Paginierung ist bei kleinen und großen Angeboten gleichermaßen häufig zu finden. Die im Beispiel verwendete Webseite etwa umfasst ca. 975.000 Unterseiten welche sich auf mehr als 300 Ebenen verteilen. An einigen Stellen ist die Paginierung so gestaltet, dass immer nur eine Seite weiter geblättert werden kann. Das Resultat ist die extrem hohen Levelanzahl.

Eine gute Paginierung sollte folgende Bedingungen erfüllen:

• Es sollten sowohl benachbarte als auch entfernte Seiten verlinkt werden
• Benachbarte Seiten sollten vollständig abgedeckt sein
• Entfernte Seiten sollten punktuell verlinkt werden
• Auf jeder Seite sollten andere entfernte Seiten verlinkt werden

Eine hohe Zahl an Seiten bei einer Paginierung ist darüber hinaus ein Indiz für eine unzureichend differenzierte Kategorisierung der Inhalte. Die Zahl der Seiten kann bei Listen auch begrenzt werden, sofern die Daten dies erlauben.

Unsere Crawls haben auch gezeigt, dass die letzen Seiten in sehr langen, paginierten Listen fast durchgängig schwerwiegende Performance-Probleme haben. Dies liegt vor allem an den Kosten die auf Datenbankseite beim Prozess der Sortierung und Filterung und anschließendem Limit entstehen. Mehr als 15 Sekunden Laufzeit sind hier nicht unüblich.

Hohe Seitenzahlen – unkontrollierte Vermehrung

Einige der gecrawlten Webseiten wiesen eine hohe Zahl an im Endeffekt unnötigen Seiten auf. Gerade Shops und Vergleichsseiten kommen sehr schnell zu einer extrem hohen Zahl an erreichbaren Seiten. In einem Fall etwa waren dies in Ebene 3 bereits mehr als eine Million, insgesamt wären unter der Domain mehrere Milliarden Seiten abrufbar gewesen.

Wir nennen dies das Problem der unkontrollierten Vermehrung.

Die häufigste Ursache für eine solche Vermehrung sind schlecht umgesetzte Listen, Filter und Sortierungen. Die als Beispiel genannte Seite umfasst lediglich etwa 20.000 Produkte, die sich aber innerhalb der Produktlisten nach Preis, Farbe, Hersteller und diversen Produktkriterien filtern und sortieren ließen. Alle diese Filter waren kombinierbar und alle Kombinationen ließen sich über eigenständige Urls abrufen.

Das Gegenrezept sind Filter, die mittels eines POST-Requests gesendet werden. POST-Requests haben aber zwei Nachteile:

• Bei Betätigen des Back-Buttons im Browser kommt es zu einem Resubmit, vor den die Browserhersteller abschreckende Dialoge gestellt haben
• POST-Request haben keine URL, können also weder gebookmarkt noch in den sozialen Medien geteilt werden

Die Lösung dieser Probleme bietet das PRG-Pattern (Post/Redirect/Get, http://en.wikipedia.org/wiki/Post/Redirect/Get): Die Filtereinstellungen werden per POST über das Formular übermittelt und in einer Session gespeichert. Dann erfolgt ein Redirect auf die Startseite der Liste. Die Startseite der Liste sowie mögliche Paginierungsseiten lesen die Filter- und Sortierungseinstellungen aus der Session aus und stellen die Ergebnisse dar.

Direkte Links auf die gefilterten oder sortierten Listen können über die alten GET-Requests realisiert werden welche die Settings in eine Session schreiben und auf die Liste weiterleiten.

Derartige Listen bringen eine Reihe von Vorteilen mit sich:

• Die Zahl der Seiten reduziert sich stark
• Es kann auf NoFollow-Links sowie auf das Canonical-Element verzichtet werden
• Eingehende Links werden auf wenige wichtige Strukturseiten konzentriert
• Die Ansicht für Benutzer die über eingehende Links kommen kann nach wirtschaftlichen Gesichtspunkten optimiert werden