Campixx Vortrag: Tool- und Mindset für große Seiten

Die Campixx ist nun schon “etwas” her, aber ich hab es endlich geschafft mir die Zeit zu nehmen und meine Präsentation hier in einen Beitrag zu übernehmen. Ist arg lang geworden aber könnte noch viel viel länger sein nur irgendwann muss auch mal Schluß sein. Evtl. werden einzelne Punkte nochmal aufgegriffen für neue Artikel, aber der Vortrag sollte endlich online sein, daher ist es teilweise auch recht basic geblieben.

Das Thema war “Tool- und Mindset für große Seiten”. Gemeint war damit was man bei großen Seiten so beachten muss und welche Probleme auftreten können die man bei kleineren Seiten gar nicht beachtet oder beachten muss. Zudem habe ich drei Tools kurz vorgestellt die gerade bei größeren Seiten Sinn machen und vielleicht noch nicht jeder kennt. Und ein paar Gedanken wie man ein eigenes Tool entwickeln sollte habe ich ebenfalls mit aufgenommen. Eigentlich Stoff um einen Tag zu füllen aber ich hab versucht es in 45min unterzubringen. Naiv wie ich war dachte ich am Sonntag um 16Uhr kann ich das auch gut vortragen und die Leute sind noch interessiert und können/wollen was aufnehmen 😉

Hier jetzt eine Themenübersicht

• Probleme bei Online-Shops
• Interne Verlinkung
• Faceted Search
• Pagespeed
• Sitemaps
• Tools
  • Strucr
  • ServerDensity
  • New Relic
• Das eigene Tool

Ein paar Folien habe ich komplett rausgelassen bzw Teile davon nicht mit übernommen. Da der Artikel aber recht lang geworden ist habe ich die Präse auch hier hochgeladen.

Probleme bei Online-Shops

Online Shops haben ein paar grundsätzliche Probleme die man als SEO vielleicht gar nicht auf dem Plan hat. Dabei sind die meisten eigentlich nicht schwer zu erkennen und eigentlich ist die Lösung total einfach und logisch. Aber dran denken muss man eben.

Das größte Problem ist die Anzahl der Seiten. Wie schaffe ich es hier überall gute Titel und Descriptions zu erstellen? Per Hand ist dies meist nur in die wichtigsten Kategorien möglich, der Rest muss irgendwie per Algo gelöst werden. Und hier fängt das erste Problem an wenn man versucht Damen günstig zu verkaufen 😉

Ich musste eine zeitlang suchen bis ich noch einen Kandidaten gefunden habe der sowas macht. Scheint sich rumgesprochen zu haben dass solche Muster (Kategorie + “günstig kaufen”) nicht in allen Kategorien eingesetzt werden sollten. Die Lösung ist natürlich logisch und das Problem ist zB in allen Mode-Shops sowieso nicht vorhanden da hier Damen, Herren, Kinder, etc. eh als Oberkategorien genutzt werden und man somit per Hand den Titel schreibt.

Interne Verlinkung

Wie stehts aber mit der intenen Verlinkung, gerade in der Hauptnavi? Hier hat nicht SEO die oberste Prio, sondern Usability oder User Experience. Als SEO würde ich in Mode-Shop einfach Links wie folgt benennen: Damen Kleider, Damen Hosen, Damen Schuhe, etc. und so natürlich auch für Herren und Kinder. Sieht aber mal richtig scheiße aus und ist so gut wie unmöglich dies durchzubekommen. Meist gibt es Oberkategorien welche dann “Damen” und “Herren” heißen und darunter steht dann “Hose”, “Schuhe”, etc.. Immerhin ist ein Keyword enthalten, das Komplettpaket wäre aber besser.

Als Lösung bleibt hier leider “nur” die restliche interne Verlinkung, zB aus Unterkategorien oder von den unzähligen Produkten. Hier kann zB die Breadcrumb angepasst werden dass der Link auf Hosen nicht “Hosen” sondern “Herren Hosen” als Linktext hat.

Die Kruz der Produkte

Die Anzahl und Art der Produkte ist hier auschlaggebend. Gerade im Bereich Mode bekommt man hier schnell Probleme. So gibt es ein T-Shirt in 5 verschiedenen Farben. Hier gehen nun die großen Diskussionen mit Shop-Management los. Denn die hätten manchmal gern einfach 5 verschiedene Produkte. Aus SEO-Sicht nicht unproblematisch, denn der Text der Produkte ist ja bis auf die Farbe identisch, DC willkommen.

Schlimmer wird es wenn man nun noch Sonderangebote zeigt. Hier wird das Produkt dupliziert und hängt noch einmal in einer weiteren Kategorie. Das Problem hierbei (oder auch wenn ein Produkt in mehreren Kategorien hängt) ist wieder die User Experience, denn der User muss natürlich immer genau wissen wo er ist, und dies zB in der Breadcrumb sehen. Dies dann zu lösen wird wieder schwieriger, der Canonical oder die Noindex-Steuerung kann aber ganz gut helfen manchmal. Sofern dies technisch machbar ist, denn gerade bei größeren Seiten sind viele Änderungen manchmal erst sehr spät oder gar nicht umsetzbar.

Interne Verlinkung

Die Pyramide kennt jeder. In den ersten Ebenen gibt es nur wenige Seiten und je tiefer man klickt, desto mehr gibt es. Die große Frage ist nun wo liegt eigentlich die Power in der Struktur und wo kann ich die besten Links setzen. Klar auf der Startseite macht es am meisten Sinn erstmal. Aber hier kann ich nunmal keine 500 Links unterbringen.

Probleme treten hier gern auf wenn man sich an die Kanallogik hält. Die ist durchaus sinnvoll aber entspricht nicht immer dem was der User sehen will, gerade in Onlineshops.

Also sollte man mal einen Blick in die tieferen Ebenen werfen und überlegen ob man evtl. auf Produktebene ein paar Links plazieren kann. Diese Links haben zwar einzelnd nicht mehr viel Power, aber dadurch dass ich “dort unten” 1 Million Seiten habe kann ich gleich hunderte Links setzen wodurch wiederum viel Power wieder in die oberen Kategorien wandert.

Faceted Search

Eigentlich ein altes Thema, aber das Fehlerpotenzial ist so groß, dass man hier wirklich drauf achten muss was passiert. Nehmen wir uns mal einen einfachen Fall mit wenigen Filtern:

Kein großes Ding wie man sieht, aber dennoch können hier ein “paar” Kombinationen gebildet werden. Hier ein paar Beispielrechnungen:

1 Filter = 7 (+1) Seiten

2 Filter versch. Typen = 12 + 4 (+8) = 24 Kombinationen

3 Filter versch. Typen = 12 (+24) = 36 Kombinationen

2 Filter = 64 (+8) = 72 Kombinationen

3 Filter = 729 (+72) = 801 Kombinationen

 

 

 

Und um es einmal richtig schlimm zu machen lässt man die Pfade noch so ind er Reihenfolge zusammen bauen wie der User sie angeklickt hat und dann haben wir mehr Möglichkeiten als man sich vorstellen möchte.

http://www.domain.de/tv/led/schwarz/sony
http://www.domain.de/tv/led/sony/schwarz
http://www.domain.de/tv/sony/schwarz/led

Dann nehmen wir jetzt einmal einen echten Anwendungsfall. Ich habe direkt markiert wo ich spontan Möglichkeiten sehe Filter nicht für Google zuzulassen. Lässt sich drüber streiten und man müsste natürlich jeweils genau schauen was wirklich wichtig für den User ist bzw was bei Google gesucht wird. Ich pers. würde nach Zoll und nicht Diagonale suchen, daher Diagonale raus.

Welche Möglichkeiten gibt es nun um hier den Weg für Google einzuschränken?

• robots.txt Sperrung
  Bin ich eigentlich kein Freund von. Früher ging das super dann wurde es geändert und war eine unschöne Lösung, inzwischen gabs jedoch wieder eine Änderung und es scheint wieder wie bis Mitte 2010 zu funktionieren.
• JS-Maskierung mit onClick oder MouseOver
  Statt einem Link gibt es zB ein span und wieder wird bei onClick oder MouseOver in einen Link umgewandelt. Ich würde MouseOver bevorzugen da hier der Mausrad-Klick (also öffnen im Tab) funktioniert.
• Maskieren per Formular mittels Post/Redirect/Get
  Auch eine interessante Lösung, siehe Wikipedia Artikel

Pagespeed

Pagespeed ist seit Jahren ein Thema. Den Standard-Krams wie gzip, Sprites, externe Dateien kombinieren, etc. hat jeder wohl schon auf dem Plan. Aber gerade bei großes Seiten macht es Sinn einen Blick auf die Kleinigkeiten zu werfen.

Schonmal in diesem Zusammenhang über Cookies nachgedacht? Auch wenn es sich hier meist um winzige Datenmengen von wenigen Byte handelt kann es große Auswirkungen haben wenn ich zB jedes meiner 100 Bilder von einer Subdomain lade und jedes Mal das Cookie mitgeschickt wird. Stichwort Cookieless Domain

Javascript in eine Datei einbinden ist für jeden klar. Aber teilweise macht es Sinn über asynchrones Javascript nachzudenken. Hier können viele Seiten noch extrem beschleunigt werden.

Die Komplexität des HTML zu überarbeiten ist inzwischen auch in jedem Pagespeed Tutorial erwähnt, aber wie schaut es mit Javascript und CSS? Ja richtig, auch das CSS kann beschleunigt werden. So ist die Verwendung von IDs schneller als Klassen und diese wiederum schneller als nur den HTML-Tag per CSS zu definieren.

Und natürlich sollte man sich auch Gedanken über die eigene Server- und Software-Struktur im Backend zu machen. So gab es (oder gibt es noch immer?) einen Fehler in einer php-Version auf 64-Bit Servern. Selbst WordPress hatte hier Probleme wenn nur 16mb Ram zur Verfügung stehen. Denn teilweise wurde der Speicher einfach verdoppelt und schon was das Memory-Limit erreicht und WordPress gab auf.

Grundsätzlich sollte man sich zum Testen einfach einmal einen Rechner zulegen der in die Jahre gekommen ist und diesen mal über ISDN die Seite aufrufen zu lassen. So stellt man hier fest dass zB die Seite zwar ruckzuck übertragen wurde, der alte Rechner aber arge Probleme mit dem DOM-Processing hat und daher die Seite dann doch 10 Sekunden zum Aufbau braucht. Auch alte Flash oder Browser Versionen sollten geprüft werden.

Sitemaps

Einfach eine Sitemapfür alles erstellen kann jeder. Auch eine Sitemap für Produkte und eine für Kategorien zu erstellen ist nicht weiter wild. Aber wenn man größere Seiten wirklich beobachten will um einmal nachzuvollziehen wie Google die Seite in welchen Bereichen indiziert muss man sich Gedanken machen welche Sitemaps man aufbauen möchte.
Hier sollte man mehrere, auch überlappende, Sitemaps erstellen. Kategorien, Produkte, statische Seiten und eine Sitemap für jeden einzelnen Branch ist hier schon eine bessere Lösung. Inzwischen bietet Google hier ja auch schöne Grafiken an um die Analye zu vereinfachen.

Verwendung von externen Tools

Vorgestellt hatte ich auf der Campixx die Tools strucr.com, serverdensity.com und New Relic. Ein richtiger Test würde den, ohnehin schon großen, Maßstab des Artikels sprengen, daher einfach ein paar Stichpunkte und Screenshots. Schaut euch die Tools einfach mal selbst an, Testversionen sollte es überall auch geben.

Strucr

• Verification File notwendig
• Crawling einstellbar
  • Anzahl Pipes
  • wie viele Ebenen
  • User-Agent
  • extra robots.txt
• Kosten (25, 100, 200, 350 Euro)

Serverdensity

Eigentlich entwickelt um zu prüfen ob die eigene Website noch online und erreichbar ist, aber lässt sich sehr schön für SEO Tests missbrauchen.

Das eigene Tool

Die Königsdisziplin ist das eigene Analyse-Tool. Einfach nur Rankings und Traffic zu vergleichen ist nur der Anfang. Denn ein solches Tool sollte viel mehr können und ist, wie die eigene Seite, niemals fertig gebaut.

Ein paar Ideen:

• Pageviews (Besucher / Google)
  • Logs vs. Analytics
    Vorsicht Falle: gecachte Pfade werden evt nicht vom Logging erfasst
  • Statuscodes: 200, 301, 404, 503
• Fehlermeldungen WMT (interessanter Artikel bei seomoz)
  • 404
  • robots.txt
    geht inzwischen ja nicht mehr
  • Sitemap
• Crawling WMT
  leider nicht über die API auslesbar
• tägliche Rankings
• Sichtbarkeit
• Backlinks
  • Anzahl
  • Entwicklung
  • Werte wie Authority diverser Tools

Am Ende hat aber eh jeder seine eigenen Anforderungen. So ist die Conversion natürlich wichtig, sofern es überhaupt eine gibt.  Wirklich interessant wird es dann wenn man mehrere Daten mischt. Zum Beispiel wenn ich meine Backlinkdaten mit meinen Rankings mische oder die Rankings einzelner Keywords mit dem Traffic oder der Conversion der Landingpage.

Und zu guter Letzt ein Screenshot von einem Tool mit welchem ich hin und wieder arbeite. Gezeigt ist hier das Vor-dem-Kaffee-Dashboard. Ein Blick um morgens schnell zu schauen ob alles ok ist. Der Traffic des Vortages passt und die Rankings von heute morgen passen auch noch. Alles weitere guckt man sich mit dem Becher Kaffee an 😉

Fazit

Worauf wollte ich mit dem Vortrag eigentlich heraus? Eigentlich wollte ich nur einmal zeigen worüber ich mir hin und wieder meine Gedanken mache und welche Tools ich u.a. nutze. Grundsätzlich kann man sagen dass gerade bei großen Seiten der Blick auf der Detail sehr wichtig ist. Auf einem Blog brauche ich mir niemals Gedanken um Cookies bez. Pagespeed zu machen oder duzende Sitemaps anlegen. Bei großen Seiten sind aber selbst die kleinsten Verbesserungen oft sehr viel Geld wert.