Tobias Schwarz: Best Practices für technisches SEO #SEODRIVEN #078

By | August 30, 2019


So Freunde bei mir ist immer noch der Tobias von Audisto und er ist Experte für das Crawling und die technische Optimierung von riesigen Websides. Wir haben diese Woche über paar Themen gesprochen. Einerseits wie man die klassischen Fehler
identifiziert und behebt, wie man den Inhalt optimiert, wie man die Struktur optimiert
und jetzt wollen wir nochmal durch ein Paar best Practices gehen, die der Tobias für
uns mitgebracht hat. Also bleibt dran. Ja Tobias. Du bist ja jemand der viele Websites sieht in seinem Leben und vor allen Dingen die ganz großen und dann nicht nur von Außen, sondern tatsächlich auch von Innen, nackt. Durch euren Crawler und eure Beratung. Was sind denn da so die best Practices die die jeder umsetzen sollte, könnte? Es fängt an bei sich einen vollständigen
Überblick zu verschaffen. Also Beispiel hatten wir schon vorhin beim Mittagessen, wir hatten großen Kunden der hat immer so 5 Millionen Unterseiten gecrawlt und wir haben dann im Crawl einen Indexwert von 27% gesehen. Da war immer die Aussage: ja das ist viel,
wir wissen das, aber läuft ja ganz gut bei uns. Dann haben wir strukturelle Dinge gemacht und dafür einen größeren Crawl gemacht, 50 Millionen Unterseiten gecrawlt, und dann war der Anteil der Indexseiten 97%, dann war: Wooow, was ist denn hier kaputt? Spaßeshalber hab ich dann irgendwann 100000 Seiten gecrawlt dann waren sie bei 2,7%. Das zeigt einfach, dass je tiefer man in eine Website reingeht, verschiebt sich irgendwann die inhaltliche Ausrichtung, also auf den
vorderen Ebenen hatte man die Kategorien, dann kommen irgendwann Produkte und in den ganz tiefen Ebenen waren irgendwelche Filterfacetten, wo man teilweise 3 oder 4 Filterfacetten miteinander kombiniert hat. Wo es dann so absurd wurde, dass man einfach Standard, dieser Inhalt bringt uns nichts, das stellen wir einfach auf Index. Aber es ist natürlich schwierig, wenn man
immer nur unvollständig seine Seite erfasst um da sinnvolle Entscheidungen drauf zu treffen, weil man die mitunter völlig auf falschen Daten trifft. Bei 27% war das Thema, hatte keine Priorität mit dem Verständnis, dass es 97% vielleicht sogar noch mehr Seiten betrifft, verändert
das natürlich alles. Das war die Top-Priorität, es wurde über
nichts anderes mehr geredet in den folgenden Wochen. Deshalb sollte man versuchen als best Practices immer seine Seite komplett zu erfassen und ich mein die größten Seiten, die ich im
deutschsprachigen Raum kenne, die werden mit 12 Millionen Seiten pro Tag gecrawlt von Google. Man kann ja ausrechnen, 12 Millionen 30 Tage müssen einmal im Monat gecrawlt werden soll bist du bei 360 Millionen Seiten, was willst du denn da mehr haben? Realistisch gesehen müssen die Inhalte mehrfach gecrawlt werden, Startseiten und so. Also paar Millionen Dokumente ist ok, wenn man mehr hat muss man dringen irgendwo abbauen. Das ist so ein Thema mit den Crawls, das gute ist ja bei den Themen jetzt Onpage, dass man tatsächlich alles crawlen kann, anders als
der Christoph Cemper z. B. von den Linkresearch-Tools, der immer jetzt ja runterbetet, wo er die
25 Linkquelle in dem Tool hat, dass man alle Backlinks versuchen sollte zu analysieren und dass es auf kleinem Set wenig Sinn macht, das ist ja genau das gleiche hier, nur hier hat man
immer die Chance, weil man kann komplette Seiten crawlen. Wenn man es nicht kann hat man ein strukturelles Problem, was man angehen muss. Es sollte irgendwo abgseschlossen sein, aber es gibt immer jemanden der die unendliche Paginierung oder den unendlichen Kalender gebaut hat. Ok. wie trifft man denn die richtigen Entscheidungen, wenn man solche Daten vorliegen hat? Indem man sich vor allem erstmal auf die großen Zahlen konzentriert. Also es ist bei großen Projekten nicht sinnvoll jetzt einzelne Titels von Hand zu machen das kann man für seine Startseite oder für Hauptkategorie machen, aber in der Regel sind die Hebel immer die Dinge, wo man mit einer einzelnen technischen Änderung 100000 oder Millionen von Seiten wirklich anfassen kann und dadurch dann einen großen Hebel hat. Man möchte seine Entscheidung quantifizieren und abschätzen können. Ein ganz wichtiger Bestandteil ist da auch
dass man Simulationen durchführt, also wenn wir strukturelle Änderungen an den Seiten
machen, dann kann man in dem Crawler z. B. URL´s umschreiben bis zu einem gewissen Punkt. Wir haben Kunden gehabt, die einfach immer ein Slash vergessen hatten in ihrer Hauptnavigation, das führt dann zu sinnlosen Redirects, und solche Änderungen kann man recht einfach simulieren. Wenn man noch Crawls hat wo noch Session ID´s auftauchen, kann man Simulation machen. Das gibt es noch? Ja, das gibt es leider immer noch. Dann kann man Simulationen machen
wie die Seite ohne diese Session ID´s aussehen würde. Man kann Seitenbereiche ignorieren. Also wie sieht die Seite ohne Sitemaps aus? Wenn man dann, wenn die ganzen Pfade für den Nutzer 3-4 Ebenen zusätzlich sind, dann muss man eben in andere Hierarchien einziehen. Wenn man das kombiniert mit einer Entwicklungsumgebung, da kann
man ja Features bauen, kann sein Life System gegen eine neue Variante auf der Seite testen. Das sind solche best Practices. Also muss man nicht erstmal warten bis die Seite life ist? Genau. Also man kann auf der, während des Entwickelns sollte man schon herausfinden, wie sich Dinge ändern. Da muss man nur bisschen gucken, dass man die Systeme da nicht lahm legt und dass es keine Codeänderungen gibt während des Tests, wahrscheinlich? Ja. Abgetrennte Staging Umgebungen sind da schon viel wert. Wie lange dauert denn so ein 50 Millionen
Crawl eigentlich? Das hängt stark von der anfordernden Seite ab, … so im Schnitt,? Meistens dauert es mehrere Wochen das zu erfassen. Selbst wenn die Systeme das leisten könnten oder mit hoch und runter skalieren, wäre ansonsten der Kosten Impact zu hoch dafür. Wir crawlen in der Regel mit 24 gleichzeitigen Requests. Wenn die Seiten sehr schnell antworten, also Request bedeutet ja nur: ich mache immer den nächsten und wenn eine Seite eine Sekunde Antwortzeit hätte, dann wäre das genau 1 Request pro
Sekunde, also 24. Wenn jetzt schon in einer halben Sekunde antworten, dann schaffen wir dann natürlich schon das doppelte, also 48. Wir crawlen große Seiten durchaus mit ein paar Hundert Request pro Sekunde, aber selbst dann bei 50Millionen Seiten, ist stupide Mathematik, kannst du ausrechnen wie lange es dauert. Und was kostet so ein Crawl? Die größten Crawls machen wir im Moment, wir haben Monatspreis 1590 Euro sind 50 Millionen Seiten bei uns. Wir sind heavy use, das heißt du kannst bei uns direkt den nächsten Crawl starten, sobald der erste durch ist. Weil nur so kannst du mit sowas arbeiten. Wenn du Fehler identifiziert hast, dann wirst du den natürlich beheben und im Anschluß möchtest du natürlich prüfen dass dieser Fehler behoben ist. Wenn das jetzt nicht der Fall war, muss da
nachgearbeitet werden musst du nochmal prüfen. Einige unserer Mitbewerber haben Pay-as-you-go-Modelle. Musst du dann jedes mal neu bezahlen, das führt dann realistisch dazu, dass nur alle paar Monate überhaupt gecrawlt wird. So ein kontinuierliches Monitoring, was du eigentlich bräuchtest, gar nicht stattfindet. Ist ja auch sozusagen der nächste Punkt. Monitoring, überhaupt auch die Veränderungen die so stattfinden. Bei großen Websites, E-Commerce Shops, wo Produkte teilweise automatisch rein und raus gehen, News Sites wo jeden Tag Tausend neue Artikel geschrieben werden. Kannst du ja nicht ein mal im Jahr crawlen. Da hast du komplexe Systeme. So Verlagswebseiten anschaue, die ganz
viel mit externen Partnern zusammenarbeiten, die riesige Teams haben wo teilweise mehrere Hundert Leute zusammen an einer Webseite arbeiten, da schleichen sich immer mal Fehler ein und du brauchst einen zeitlichen Verlauf um irgendwo sehen zu können: Seit dem Zeitpunkt haben wir hier Probleme, damit du dann gegensteuern kannst. Ist ganz wichtig, zyklisch das neu zu machen und einen Verlauf über solche Daten zu haben. Ok, also vollständige Crawls am besten nicht nur ein mal, sondern Monitoren wirklich Überwachung der Seite letzten Endes. Dann auch nicht nur im life System crawlen, sondern gerade bei Relaunch bevor das Ding life geht. In dem Sprint, letztes Teil des Sprint muss sein zu verstehen was man da eigentlich online stellen wollte. Im Optimalfall die Änderung vielleicht simulieren, damit man nicht vorher schon die Enwicklungskosten hat und dann feststellt, das können wir eigentlich gar nicht live stellen. Ok, coool. Das sind auf jeden Fall spannende Einblicke. Morgen werden wir das ganze nochmal zusammenfassen aus den vier Tagen. Es ist glaube ich eine der inhaltsreichsten Wochen gewesen, schwer zu verdauen. Und wir werden uns Mühe geben, das morgen nochmal in 10-15 Minuten zusammenzufassen. Also bis dann. Ciao. Ciao.

Leave a Reply

Your email address will not be published. Required fields are marked *