Häufig auftretende Strukturfehler kennen und beheben

November 8, 2011 by  
Filed under Optimierung, Statistik, Tools

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:

Prozentuale Anzahl der Seiten pro Level in Prozent.

Prozentuale Anzahl der Seiten die innerhalb der angezeigten Level erreicht werden in Prozent.

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

Comments

12 Responses to “Häufig auftretende Strukturfehler kennen und beheben”
  1. Pascal sagt:

    Wenn es speziell um Google geht, kann man in dem oben geschilderten Problem eventuell auch mit den Parametereinstellungen dagegen vorgehen. Julian hat diesen Problemfall unter http://www.seokratie.de/duplicate-content-bei-google-vermeiden/ vor kurzem erst vorgestellt.

    Bei der POST-Lösung bin ich etwas skeptisch. Letzte Woche hat Google erst angekündigt, dass sie nun zum Teil auch POST Requests durchführen um bisher unbekannte Inhalte indexieren zu können > http://googlewebmastercentral.blogspot.com/2011/11/get-post-and-safely-surfacing-more-of.html

    Nichts desto trotz ist strucr allerdings nen geiles Tool 😉

    Grüße
    Pascal

  2. Tobias Schwarz sagt:

    @Pascal: Google ist im Allgemeinen sehr smart und versucht schon eine Vielzahl von Problemen zu erkennen und für alle Beteiligten vorteilhaft zu handhaben. Das Problem mit den Parametereinstellungen und auch mit dem Canonical-Element ist jedoch, dass diese von Google lediglich als Hinweise verstanden werden und Google sich vorbehält selbst zu entscheiden wie entsprechende Seiten gehandhabt werden. Der Webseitenbetreiber erreicht also durch den Einsatz von Parametereinstellungen und Canonical-Element einen Zustand in dem er nicht mehr weiß wie die Strukturen wirklich gehandhabt werden. Darüber hinaus bekämpfen Parametereinstellungen und Canonical-Element lediglich die Symptome und nicht das eigentliche Problem. Die Seiten werden nach wie vor von Google bis in eine gewisse Tiefe gecrawlt. Bei sehr Tiefen Seiten bricht Google irgendwann ab und dort versickert letztendlich zwangsweise ein Teil vom Juice.

    Die POST-Requests von Google sind mir durchaus bewusst. Diese wird Google in erster Linie einsetzen um AJAX-Inhalte nachzuladen und diese mit abzuspeichern. Das Abrufen von komplett eigenständigen Seiten wäre für Google eigentlich nur für die Deepwebdiscovery interessant. Ein Darstellung in den Suchergebnissen würde bedeuten, dass Google die POST-Requests von dort aus direkt initieren müsste und das kann ich mir aktuell nicht vorstellen.

  3. Olaf sagt:

    Hallo Tobias,

    schöner Artikel und befasst sich mit einem Thema mit dem wir tagtäglich aufgrund unserer Spezialisierung auf Online Shops viel zu tun haben. Eine Frage zu Eurem Tool. Wie wird das Level der Seitentiefe bestimmt? Geht Ihr da nach Verzeichnistiefe oder Klicks von der Startseite?

  4. Tobias Schwarz sagt:

    Hallo Olaf! Mir ist nicht ganz klar, was du mit Verzeichnistiefe meinst, strucr ermittelte momentan die Seitentiefe aber entspricht der Klicks von der Startseite aus. Theoretisch ließen sich auf Basis der Daten mit erheblichem Aufwand auch noch die längsten Klickpfade für jede einzelne Unterseite berechnen. Die Algorithmen die man dazu benutzt lassen sich aber nur schwer auf großen Seiten anwenden, da sie sehr zeitaufwändig sind.

  5. Olaf sagt:

    Ok. Werde ich mal testen …

  6. Sehr interessanter Post. Ich kann die Probleme bei der Kombination von Parameterbehandlung in den Webmastertools und Canonical bestätigen und werde mir das von Dir erwähnte PRG-Pattern einmal genauer ansehen.

  7. Nils K. sagt:

    Danke für die Auflistung. Werde ihn gerne auf Twitter teilen. 🙂

    lg Nils

  8. Sehr interessanter Artikel, Als Internetagentur in Paderborn kommt öfter vor, dass wir aufgrund der grossen Anzahl von Seiten, die unter TYPO3 erstellt werden müssen, gar nicht auf die Seitentiefe achten.

  9. Michael sagt:

    Hallo Tobias,
    hast du zufällig einen Beispiel-Shop der PRG Pattern einsetzt?
    VG
    Michael

  10. Hi Michael,

    es gibt inzwischen diverse Shops die das umgesetzt haben. Ich empfehle jedoch einen Blick auf die Beispielimplementierung (https://mxsearchfilter.vdtapp.com/search) von Max Lielje (https://pagespeed.io/) zu werfen, da dort die technischen Aspekte sehr gut zu sehen sind.

    Viele Grüße
    Tobias

Trackbacks

Check out what others are saying about this post...
  1. […] Schwarz schreibt auf seo.de über die Erkennung von Strukturfehlern und ihre Behebung. Schöne Zwischenüberschrift: […]

  2. […] senden (warum wir das tun sollten und wie das geht, erklärt Tobias Schwarz in diesem Artikel: Häufig auftretende Strukturfehler erkennen und beheben). Allerdings verlangen die Anforderungen an Shop-Systeme in der Regel, dass […]



Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!

css.php