Search Camp Episode #59: Technical SEO für große Websites

24. Oktober 2018 | Von in Podcast "Search Camp", SEO

Groß ist nicht immer besser: Bestimmte SEO-Probleme betreffen vor allem große, komplexe Websites. Faceted Navigation, Paginierung, Duplicate Content, Crawl-Budget-Optimierung – alles Probleme, die man bevorzugt ab einer bestimmten Größe hat. Welche Lösungen es dafür gibt, verrät Sören Bendig von Audisto im Gespräch.

> Alle Episoden von Search Camp als RSS-Feed
> Search Camp bei iTunes
> Alle Folgen: www.searchcamp.de
> Auf Twitter folgen: @bloonatic (Markus Hövener)

Shownotes:

–

Transcript:

Moin und herzlich willkommen! Hallo, ihr seid wieder bei Search Camp, dem Online-Marketing-Podcast. Mein Name ist Markus Hövener und mein Thema ist heute Technical SEO für große Websites. Da habe ich mir den Sören Bendig als Spezialisten dazu geholt. Wir reden über so Themen wie Faceted Navigation, Crawl Budget Optimierung, Paginierung, alles so Themen, die man eben hat, wenn man große Websites. Wie geht man damit um, was sind so typische Lösungen, das klären wir gleich nach der Musik.

Markus Hövener: So. Wie versprochen haben wir den Sören Bendig in der Leitung. Thema ist heute Technical SEO für große Websites. Müssen wir gleich mal klären, was das meint, wo fängt groß eigentlich an. Aber fangen wir erst mit Sören an, stell dich mal kurz vor.

Sören Bendig: Hi Markus! Schön, dass ich dabei sein darf. Mein Name ist Sören Bendig, ich bin Geschäftsführer von Audisto und wir sind ein Tool-Anbieter und haben eine Crawler-Lösung beziehungsweise eine Testing-; Monitoring-Lösung und beschäftigen uns hauptsächlich mit großen Webseiten.

Markus Hövener: Und du bist der SEO Szene auch schon ein bisschen länger zugehörig oder?

Sören Bendig: Das stimmt, der ein oder andere kennt mich noch als Geschäftsführer von SEOlytics, wo ich einige Jahre das Unternehmen “betreut” habe, in Anführungszeichen, bevor wir dann irgendwann an Sistrix verkauft haben. Genau. Also insofern seit, ich weiß gar nicht ehrlich gesagt, müsste ich jetzt nachrechnen, aber schon einige Jahre in der Branche unterwegs. Genau, wir hatten ja vorher ein Thema abgesprochen oder haben überlegt, was können wir denn jetzt mal machen und wir sind erstmal auf Technical SEO gekommen. Das heißt wir reden jetzt heute nicht so unbedingt über WDF*IDF oder irgendwie große Content-Themen, sondern es geht eher so um technische Sachen. Und wir haben gesagt, wir reden über große Websites, weil das ist auch gleichzeitig der USP von Audisto, richtig?

Sören Bendig: Ja, also wenn wir über das oder eigentlich ist es bei beiden Produkten so, aber wenn wir über unser Technical SEO Tool sprechen, dann ist es hauptsächlich für Enterprise-Seiten ausgelegt. Das heißt ich kann das natürlich auch benutzen, wenn ich nur 5.000 Seiten habe, aber der Fokus liegt einfach auf großen Systemen.

Markus Hövener: Okay. Ja, dann lass uns mal klären, was ist groß für dich oder für euch?

Sören Bendig: Das ist natürlich von Fall zu Fall immer unterschiedlich, aber ich würde sagen, eine große Webseite fängt da an, wo ich selber manuell gar nicht mehr den Überblick behalten kann. Das heißt ich habe so viele Seiten in meinem Portal, dass ich die einzelnen gar nicht mehr kenne und einzeln gar nicht mehr zu Gesicht bekomme. Das heißt bei so ein paar Millionen fängt das dann. Das heißt also wir haben natürlich Kunden, die 1 Million Seiten crawlen, aber wir haben Kunden, die 50 Millionen Seiten crawlen und selbst das Erheben der Daten dauert also schon mehrere Tage, einfach aufgrund der technischen Geschwindigkeit von solchen Portalen. Das heißt aber mein Shop oder als Publisher oder so, meine Seite ist so groß und ist so komplex, dass ich ziemlich schnell den Überblick verliere und eigentlich mir einen ganz genauen Plan machen muss, wie ich damit umgeh.

Markus Hövener: Also es kann erst mal durch eine Anzahl der Seiten begründet sein, aber komplex heißt auch, sowohl Struktur der Website als auch natürliche Organisation dahinter, also das möglichst oder dass viele Agenturen und Unternehmen darin rumwurschteln, richtig?

Sören Bendig: Dass ich natürlich Dienstleister gegebenenfalls habe, die nochmal von sich aus Komplexität wieder mitreinbringen, das ist nochmal wieder ein anderes Thema, aber ja, ich kann natürlich auch, also ein Beispiel, ein Shop wie Otto hat 8 Millionen Produkte im Shop. So, das müssen ja nicht 8 Millionen Produkte sein, aber vielleicht habe ich auch weniger Themen, wo ich Kategorien habe, aber wenn ich dann komplexe Ober- und Unterkategorien habe und dann eine komplexe Filterung in meinem Shop drin habe, dann kommen wir dann doch schnell in so einen Bereich, wo man sagt, okay, da kann dann auch ein einzelner Fehler dazu führen, dass ich auf einmal ein paar Millionen Seiten mehr habe. Und die Komplexität über Dienstleister, die liegt natürlich auf der Hand, das heißt je mehr Köche ich habe, da passieren dann natürlich noch mal wieder Effekte, die ich vielleicht selber gar nicht so auf dem Schirm habe. Das heißt der SEO schreibt ein Ticket, irgendwas wird gefixt und 2 Monate später ist der gleiche Fehler wieder da, weil wieder der Dienstleister seine Staging-Systeme nicht im Griff hat und mir so einen Legacy Fehler wieder reinspült oder sowas. Also das kann auch passieren.

Markus Hövener: Oder ein Grund ist vielleicht auch, jemand kriegt irgendwie ein Ticket, um was zu fixen, aber er weiß gar nicht, warum er das jetzt fixt und dann ist auf einmal die robots.txt falsch, weil man ihm nicht gesagt hat, dass die Reihenfolge der Einträge vielleicht auch noch relevant ist oder?

Sören Bendig: Ja, also das fehlende Verständnis von ich sag mal Webstandards und so Hygiene-, Best Practice Dingen, das stellen wir auch regelmäßig immer wieder fest. Also nur, weil ich jetzt eine große Seite mit 1 Millionen Unterseiten habe, heißt das ja noch lange nicht, dass ich es besser mache als jetzt jemand, der vielleicht nur ein paar tausend hat. Und da muss man auch so sagen, es gibt natürlich auch viele schlaue Leute da draußen, die sich tolle Konzepte ausdenken, aber es gibt auch Leute, die auf so großen Portalen sitzen, die jedoch ganz schön am Kämpfen sind und auch ein bisschen Angst davor haben teilweise Dinge anzufassen oder zu verändern, weil sie sich einfach unsicher sind, was das bedeutet und dann bin ich natürlich schnell in so einem Bereich, dass es dann vielleicht auch sinnvoll ist Dinge zu simulieren. Das heißt, wenn ich so ein großes Portal habe, dann kann es ja sogar sein, dass meine Staging-Umgebung nicht auf der Produktiv-Datenbank laufen kann oder nicht läuft aus irgendwelchen Gründen oder wie auch immer. Und irgendwelche neuen Features, die ich vielleicht einbauen will, ich will vielleicht meine Recommendation Engine möchte ich verändern und möchte aber vorher wissen, was das denn für meinen Seitenarchitektur bedeutet und das kann ich auf dem Staging aber nicht tun und muss es auf dem Live-System tun. Wie simuliere ich das und was mache ich dann? Also mit solchen Themen hat man ja dann auch zu kämpfen.

Markus Hövener: Ich habe mir ein paar Stichpunkte aufgeschrieben, so was ich denke, was so die typischen Probleme, technischen Probleme bei großen Websites sind. Ich würde dir die jetzt einfach mal hinwerfen und dass wir vielleicht mal zusammen festhalten, was sind denn so die Best Practices, was sind auch da so die häufigsten Probleme und warum ist das überhaupt ein Problem. Als erstes hatte ich mir aufgeschrieben, Filterseiten und, oder Faceted Navigation, was kann da schiefgehen?

Sören Bendig: Eine Menge. Also oft ist es ja so, bleiben wir jetzt beim Beispiel, also ich habe ein Shopsystem und ich habe Produkte, die ich in verschiedenen Farben und Größen und so weiter und sofort zur Verfügung habe und da muss der User irgendwie filtern können. Dann ist es ziemlich oft so, wenn man sich dann keine Gedanken darüber gemacht hat und auch kein Konzept gemacht hat und vielleicht technikbezogen auf den Umgang mit Parametern, da können wir die gängigsten Fehler gleich noch mal irgendwie ein bisschen durchgehen, aber ich habe kein Konzept dahinter, dann bedeutet das, dass ich aus einer URL auch ganz schnell mal viele, viele URLs mache. Also nur so als Beispiel, so ein häufiger Fehler bei sowas ist, ich habe also Parameter für so Filter-Einstellungen und jemand sortiert die nicht. Das bedeutet ich habe unterschiedliche Seiten oder je nachdem wie es dann wo verlinkt oder ausgewählt wird, ist also der eine Filter mal am Anfang, ist mal am Ende und technisch sind das zwei verschiedene URLs. Und wenn ich alleine sage, ich habe 5 Parameter in der URL und ein Parameter kann zwei verschiedene Werte haben, dann habe ich aus einer URL ja schon fast 2000 gemacht und wenn ich das Ganze noch vergrößere und ich habe irgendwie 10 Parameter mit zwei Werten, dann bin ich schon bei fast 200 Millionen URLs und wenn ich dann zusätzlich die Sortierung und den Umgang mit den Parametern nicht im Griff habe, dann generiere ja eine Höllenalarm an URLs und auch, wenn es der Nutzer so erstmal nicht mitbekommt, rein technisch gesehen ist jede URL eine andere URL und dann kann es auch sein, dass ich schnell in Probleme laufe, wenn es auch um sowas wie Crawl Budget geht oder sowas. Das heißt also diese ich sag mal technische Basics im Umgang mit URLs spielen dann bei sowas auch einfach eine deutliche Rolle, weil die so ein Problem dann schnell multiplizieren. Das heißt da sind wir jetzt noch nicht mal bei dem Facettierungs-Thema, aber ich habe jemanden, der seinen Server falsch konfiguriert hat. Das heißt es gibt Encoding-Fehler, das heißt es gibt Zeichen, die sind mal im Klartext, mal als Encoding in der URL oder ich habe irgendwie Backslashes, die fehlerhaft konfiguriert sind und ich kann im Zweifelsfall 5 Stück da drin haben oder ich habe Groß- und Kleinschreibung und das wird nicht vom Server gehandelt richtig. Das heißt es gibt also da viele so Basic-Probleme vom URL-Handling, die, wenn ich dann ein Problem mit Parametern habe, das dann exponentiell vervielfache. Um auf deine Frage, also bezogen auf Filterung und Facettierung zurückzukommen, es ist so, dass ich inzwischen ziemlich coole Möglichkeiten habe das anständig zu machen, aber da natürlich sich dann auch die Frage stellt, kann ich es den komplett neu machen oder muss ich mit dem leben, was ich habe? Das ist natürlich dann sehr unterschiedlich. Also du hattest schon PRG-Pattern als Stichwort angesprochen, wenn ich es sinnvoll machen kann, würde ich das immer bevorzugen, würde ich da auf jeden Fall für plädieren, würde mir vielleicht noch ein Konzept machen und überlegen, gibt es denn Filterseiten, die SEO-relevant sind, also die ich vielleicht als Landingpages benutzen möchte? Dann kann man sich auch da schlaue Konzepte machen und kann sagen, es gibt einfach gewisse Seiten, die möchte ich als URL erhalten und den Rest, habe da eine Logik dabei und den Rest biege ich dann auf PRG-Pattern um oder so. Also sowas geht ja auch. Aber erfahrungsgemäß gibt es immer noch viel zu wenig, die sich eigentlich damit beschäftigen und viel zu viele, die mit Parameter-Handling und so in Anführungszeichen am “Rumfummeln” sind, was jetzt manchmal noch nicht mal am SEO liegt, sondern klar, wenn ich so ein Riesensystem habe, da wird mir die Geschäftsführerin oder der Vorstand auch nicht mal eben erlauben das in die Tonne zu treten und komplett neu zu machen. Insofern ist es immer so ein Mittelweg, den ich irgendwie gehen muss, aber für facettierte Suche und sowas gibt es inzwischen von den technischen Standards sage ich mal, die ich verwenden kann, gibt’s ein paar tolle Möglichkeiten das richtig sauber zu machen. Erfahrungsgemäß sind es aber bislang die wenigsten, die das richtig gut umsetzen.

Markus Hövener: Du hast das Stichwort schon genannt, das zweite, was auf meiner Liste steht, ist Crawl-Budget-Optimierung. Jetzt könnte man ja eigentlich sagen, ist mir scheißegal, der Google Crawler schafft das schon irgendwie alles und was soll ich da jetzt noch optimieren?

Sören Bendig: Wenn ich eine kleine Seite habe, dann stimmt das, dann kann es eigentlich egal sein, weil ich einfach gar nicht in ein Ressourcenproblem laufe. Aber wenn ich jetzt ein System habe, was irgendwie bei 30, 40 Millionen Seiten sich befindet, dann habe ich ganz schnell ein Problem gegebenenfalls mit dem Crawl Budget. Das heißt Google crawlt nicht komplett alle Seiten und da muss ich mir ganz genau einen Überblick verschaffen, A) wie ist meine Architektur? Sind überhaupt meine wichtige Seiten von der Level Tiefe und so weiter und so fort gut zu erreichen? Sicherlich was, wo wir auch gleich noch mal im Detail drüber sprechen können. Und muss aber viel, viel stärker verstehen, was bedeutet das denn überhaupt, Crawl Budget für meine Seite und welche Seiten oder welche Seitentypen oder welche Kategorien werden denn überhaupt korrekt gecrawlt oder wo ist denn gar kein Google Bot mehr? Das heißt da bin ich dann auch schnell in so Bereichen, dass es vielleicht Sinn machen kann auch zusätzlich eine Logfile Analyse durchzuführen. Aber wichtig eigentlich, also alles, was Crawl-Budget-relevant ist, ich muss mir einen Überblick verschaffen, ist das für mich ein relevantes Thema? Wenn ich eine große Seite habe, ja, wenn ich eine große Seite habe und ich habe mir noch nie einen Kopf darüber gemacht oder ich habe gar keine Vorstellung davon, wie der Zustand, ist garantiert ein großer Hebel, wirklich ein großer Hebel da anzusetzen. Und dann ist ja mein Ziel eigentlich die SEO-relevanten Seiten herauszuarbeiten. Es wird immer passieren, dass es Seiten gibt, die entweder gar nicht gecrawlt werden oder aber auch vielleicht zu selten gecrawlt werden, dass es einfach nur ab und zu irgendwie relevant ist, aber ich muss einfach gucken, wie ist meine Architektur, wie ist meine Struktur und was ist denn mein Wunsch von Seiten, von Kategorien, die kontinuierlich gecrawlt werden und die dann auch indexiert werden.

Markus Hövener: Wenn du Logfile Analyse sagst, kann man überhaupt Crawl-Budget-Optimierung ohne Logfile Analyse machen?

Sören Bendig: Kann man schon, weil ich natürlich, wenn ich mich intensiv mit der Architektur beschäftige, auch eine Idee davon bekomme. Also Beispiel, du hast eine Seite, wo du eine ganz unglückliche Tiefenstruktur hast, dann ist es völlig klar, dass du dort auch nicht mehr besucht wirst und da passiert dann auch nichts mehr. Oder aber, wenn du technische Fehler hast, beispielsweise häufig, dass du siehst, wenn ein Relaunch durchgeführt wurde oder sowas, dass dann so durch relative Verweise unendliche Ketten erzeugt werden und sowas. Das heißt du hast so eine unendliche Kette, die erzeugt wird und sowas verbraucht natürlich alles Budget, wenn es an der falschen Stelle passiert. Insofern kannst du schon dein Crawl Budget optimieren, auch ohne Logfile Analyse. Besser ist es aber natürlich mit Logfile Analyse, weil du dann auch ganz genau verstehen kannst, wie verhalten sich denn die Bots auf deiner Seite, was tun sie. Aber Logfile Analyse selber ist jetzt ja auch nicht trivial. Es gibt zwar denkende Menschen, die denken, naja, dann nehme ich den Screaming Frog und dann schmeiße ich mein Logfile da irgendwie rein und dann war’s das, aber so ist es ja nicht. Muss man einfach sagen.

Markus Hövener: Nein, zumal der Screaming Frog, wenn du jetzt wirklich eine große Website hast und du hast auch ein gewaltiges Crawl Volumen, muss du ja erstmal die Log-Dateien handeln, aber …

Sören Bendig: Ja, kommt auch eine Menge Daten zusammen.

Markus Hövener: Ja klar.

Sören Bendig: Es ist ja so, wenn sich jemand nie damit beschäftigt hat, dann sagt der, na gut, selbst von so einem großen Shop, dann nehme ich halt mal 12 Monate Daten und dann analysiere ich die mal eben und dann kriege ich das halt so und dann ist es einmal so, 12 Monate Daten hat fast kaum jemand, meistens sind die Logfiles in dem Zustand, dass sie für eine Analyse gar nicht zu gebrauchen sind und ich meine, also wir haben es jetzt im Standard-Tool nicht drin, aber für ausgewählte Kunden machen wir dennoch mit unseren Möglichkeiten Logfile-Analysen und dann hast du auch mal 10 Milliarden Visits und 200 Millionen URLs in so einer Analyse drin. Und alleine darauf dann sowas also Bots zu identifizieren, es gibt halt Tools oder auch Leute, die sich dann erstmal nicht damit beschäftigen, die sagen, nehme ich halt den User Agent und da mache ich eine Analyse drauf. Stimmt aber ja nicht. Also nur weil der User Agent sagt, das ist jetzt der Google-Bot, heißt das ja heutzutage noch lange nicht, dass es der Google-Bot ist. Also gerade auf großen Systemen, wo viele Informationen sind, wo sich das lohnt für Leute, die zu sammeln, zu scrapen, hast du einfach viele Bots unterwegs, die da eigentlich gar nicht hingehören und alleine mit so einer Analyse kannst du irgendwie ein paar tausend Euro gegebenenfalls je nachdem wie deine technische Architektur ist, weil du sowas rausfilterst dann.

Markus Hövener: Ich hätte noch ein Stichwort hier, Paginierung oder Komponenten-Seiten.

Sören Bendig: Ja, gehört auch mit so ein bisschen zu Architektur. Da ist es ja so, dass ich beispielsweise Kategorie-Seiten habe und ich habe so viele Produkte, dass ich aber dennoch verschiedene Seiten drin habe und Paginierung ist auch immer sowas, wo die wenigsten intensiv sich mal mit beschäftigen. Es gibt da vielfältigste verschiedene Arten von Paginierung und im Endeffekt ist es ja so, dass ich dann in so einem Bereich bin, wo ich mir auch einen Kopf einfach machen muss, wo sind denn meine Autoritäten, wo sind denn meine Hubs, das heißt also auch mit PageRank und CheiRank arbeite und mir Überlegungen mache, die ich mir generell für meine Seite machen sollte. Aber wie ist denn von der Architektur, was sind denn meine wichtigsten Seiten, was sollen denn überhaupt die größten Autoritäten sein? Normalerweise ist es ja so, dass du sagst, meine Startseite, meine wichtigsten Kategorien, das sind meine stärksten Autoritäten und dann hast du immer gute Hubs, also CheiRank ist quasi der umgedrehte PageRank Graph und eine Seite, die einen hohen CheiRank hat, macht einfach andere Seiten am besten verlinkbar und da bist du natürlich schnell, deine besten Hubs sind häufig Paginierungs-Seiten. Aber selbst da gibt’s dann große Unterschiede und dann ist das was, wo man sich dann auch mal mit beschäftigen muss und sich eigentlich für die gesamte Seite, aber auch für so einzelne Teilbereiche dann mal mit PageRank- und CheiRank-Analyse beschäftigen sollte. Das heißt, dass ich dann mal genau schauen muss, wie sollte es sein und in der Realität, wenn man sich das dann mal in einer anständigen Berechnung anguckt, auch da ist es so, es gibt Leute, die sagen, naja, ich berechne das selbst oder ich habe hier so ein Tool, das berechnet mir dann irgendwie den PageRank und das macht dann eine Iteration und das war’s. Ist auch nicht korrekt. Also bei uns kann ich nur sagen, es ist so, wir machen bis zu 100 Iterationen bis sich die 4. Nachkommastelle nicht ändert. Und es gibt andere Tools, die machen das auch gut, aber es gibt auch Tools, die machen so, Wischi-Wischi und dann hat jemand die Idee und denkt, ja, jetzt arbeite ich damit und dann stimmt das aber gar nicht. Das heißt das ist nicht auch nicht mal eben in Excel gemacht so. Und dann würde ich mir das anschauen und würde mir erstmal einen Überblick verschaffen, wie ist denn der reale Zustand momentan und würde mir dann eigentlich bei so einer Strukturanalyse überlegen, also A) die wichtigsten Autoritäten, sind das denn auch die stärksten Autoritäten auf meiner Seite und wie ist denn meine Level-Architektur, wie ist denn die CheiRank-Verteilung, wie schaffe ich es denn auch durch eine geänderte und verbesserte interne Verlinkung die ganze Seite hochzuziehen, also zu verbessern.

Markus Hövener: Thema Klicktiefe. Vielleicht nochmal kurz erklären, was es ist und dann …

Sören Bendig: Im Endeffekt, wenn ich anfange, mich von der Startseite irgendwohin durch zu klicken, dann ist das die Anzahl der Klicks, die ich benötige, um bei irgendeinem Inhalt anzukommen. Das ist für den User so, das ist auch für den Bot so und ist kein Geheimnis, dass Google einfach irgendwann aufhört zu klicken, weil Google sagt, naja, auf Tiefe 20 befindet sich eh kein User mehr und deswegen gehen wir da auch nicht und die hören ja sogar noch viel früher auf. Das heißt eigentlich alles, was tiefer ist als Level 5 oder 6, das sollte ich mir ganz genau angucken, weil nicht nur, dass ich keinen Bot drauf habe, sondern im Zweifelsfall den User habe trotzdem auch eh nicht drauf. Das heißt eigentlich stimmt meine Architektur nicht an der Stelle. Und wenn ich dann irgendwie Seiten sehe, die Klicktiefe 100 haben oder so, dann sagst du, naja, aber wer klickt denn da noch? Tut ja keiner. Und dazu kommt noch, dass ich dann berücksichtigen muss, dass es verschiedene Tiefen eigentlich gibt. Bei uns ist es so, dass wir den Bot und den User unterschiedlich berechnen. Warum? Weil der User natürlich sich woanders lang bewegen darf als der Bot. Das heißt also beispielsweise ein Link ist mit nofollow verzeichnet, dann darf der Bot da nicht langgehen, wenn er sich dann an dieses Markup, aber der User dürfte da klicken. Und umgekehrt gibt es natürlich URLs, die der Bot verfolgen kann, die der User nicht sieht oder die er so nicht wahrnehmen kann und auch das kann dann zu einem Ungleichgewicht führen, weil wenn ich dann total verschobene Architektur habe für den Bot und den User, dann stimmt da auch irgendwas nicht. Das heißt also alles, was mit Strukturanalyse zu tun hat, da kann man richtig tief reingehen und wenn ich eine große Seite habe, dann ist das auch ein immenser Hebel, sich damit zu beschäftigen. Da habe ich natürlich dann die Problematik häufig, ja, wo fange ich denn jetzt mit an? Also oh, ich sehe, klar, der Klassiker, ich habe irgendwelche Seiten-Typen, die sind eine starke Autorität, weil sie überall verlinkt werden, das ist aber von mir nicht gewünscht und dann ist es aber auch schnell so, dass ich mir in so einer Kombination überlegen muss, also ich benötige eine intensive interne Verlinkung, aber es gibt immer noch viel zu viele Seiten, wo sich das mal irgendjemand überlegt hat aus Sicht des Bots, aber der jubelt alles, was irgendwie der internen Verlinkung dient, irgendwelche Archive und Paginierungs-Seiten und so von der Art und Weise wie sie gebaut und gestaltet sind, aber für den Nutzer überhaupt nicht zu gebrauchen sind. Das muss ja nicht so sein. Und wenn ich jetzt zum Beispiel an einen Shop denke, da ist es natürlich auch wieder davon abhängig, was habe ich für ein System, habe ich einen Shop oder habe ich ein Forum oder so, da funktioniert das alles ganz anders, aber wenn wir jetzt an der Paginierung denken in einem Shop, dann habe ich ja Bestseller, die ich verkaufen will, weil sie sich am besten verkaufen, weil meine Marge am größten ist wie auch immer und die will ich natürlich am Anfang haben und nicht am Ende. Und warum muss eine Paginierung immer irgendwie so Bot-optimiert sein und warum kann man nicht im Zweifelsfall vielleicht die ersten paar Seiten der Paginierung für den User optimieren und erst danach fange ich an das ausschließlich für interne Verlinkung zu nutzen.

Markus Hövener: Dann wird es auch hinreichend kompliziert oder?

Sören Bendig: Ja, also alles, was mit Architektur, interner Verlinkung, Struktur, zu tun hat, das ist natürlich nicht trivial. Dafür brauche ich dann auch entsprechende Tools und Berechnungen, um da einfach durchzusteigen und sonst habe ich da einfach gar keine Chance und selbst wenn ich diese Daten habe, muss ich ein anständiges Konzept mir machen und darf mich nicht so viel daran orientieren, was ist mein jetziger Ist-Zustand, sondern ich muss mir überlegen, wie wäre es denn auf der grünen Wiese. Dann verschaffe ich mir einen Überblick über den Ist-Zustand, dann habe ich mich nicht beeinflussen lassen von dem Ist-Zustand und dann muss ich mir angucken, okay, wie weit weicht denn das ab und wo habe ich denn Möglichkeiten auch vielleicht Bereiche, die in die tieferen Ebenen ziehen, sinnvoll nach vorne zu ziehen, damit ich einfach meine Architektur da verändern kann. Aber ja, es ist kompliziert. Wir haben jetzt gerade diese Woche wieder so einen Workshop in Hamburg veranstaltet, wo wir alleine 2 Stunden nur über Strukturoptimierung sprechen.

Markus Hövener: Vielleicht da kurz die Zwischenfrage. Jetzt streust du ja schon wahnsinnig viel Wissen hier ins Volk, ihr bietet aber quasi nur das Tool an, Beratung würde ich von euch nicht bekommen können oder?

Sören Bendig: Wir sind ein SaaS-Anbieter, das heißt wir haben zum einen den Audisto Crawler, das ist unsere Technical SEO Software und zum anderen gibt es das Audisto Monitoring, das ist eine Testing- und Monitoring-Lösung, die oben drauf sitzt. Das heißt also, wenn ich festgestellt habe, das ist mein perfekter Ist-Zustand auf 10 Millionen Seiten und den möchte ich auch bitte behalten, dann gibt’s da so ein ausgefeiltes Alerting und komplexe Checks, die ich da (unv. #00:23:09.9#) kann. Aber ja, das ist die Software und dann ist es so, dass wir bei ausgewählten Kunden sicherlich auch mal eine zweite Meinung abgeben. Also wir sind keine Agentur, das heißt du könntest nicht zu uns kommen und könntest sagen, ich hätte aber gerne bitte eine SEO-Analyse von euch, sondern das häufigste, was ihr an Consulting machen, ist, also A) entweder, wenn es sich mit komplexen Strukturthemen beschäftigt, weil da die Expertise auch dünn gesät ist und dann zusätzlich ist es so, wenn du ein Konzern bist oder ein großer Enterprise-Kunde und selbst wenn du eine betreuende Agentur hast, dann ist es häufig so, dass man sich absichern will bevor zu große Änderungen durchgeführt werden und dann werden wir nach einer zweiten Meinung gefragt.

Markus Hövener: Und die Seminare, von denen du gerade sprachst, die macht ihr regelmäßig?

Sören Bendig: Wir haben jetzt das zweite gemacht und hatten das ehrlich gesagt auch eigentlich nicht vor, aber es ist so, dass alles, was so mit Technical SEO zu tun hat, Beispiel Struktur, wo gibt es jemanden, der dich dazu aufschlaut? Das ist ja schon relativ komplex. Also selbst die Agenturen, die sich intensiv mit Struktur von großen Portalen beschäftigen, kannst du an ein paar Fingern abzählen und wir immer wieder gefragt werden, könnt ihr denn nicht mal dazu einen Workshop machen. Weil wir Funktionalität natürlich im Tool drin haben, das heißt so Bot und User Level und PageRank und CheiRank und so weiter und so fort, also alles was mit Strukturanalyse zu tun hat. Und dann haben wir irgendwann gesagt, gut, wir nehmen uns technische Konzepte, wo wir der Meinung sind, die du wenig woanders hörst und dazu haben wir jetzt Workshops gemacht. Das heißt PRG-Pattern, Strukturanalyse, wichtige technische Konzepte, wo wir einfach immer wieder irgendwelche Fehler sehen. Hat aber jetzt nichts mit unserem Tool zu tun in dem Workshop, sondern ist reine Strategie- und Theorie. Paginierung ist auch Bestandteil.

Markus Hövener: Ich hatte noch ein, zwei Stichworte auf der Liste stehen. Pagespeed habe ich mir auch noch aufgeschrieben. Ist das ein Thema?

Sören Bendig: Ja, ist auf jeden Fall ein Thema. Jetzt ist es erfahrungsgemäß so, dass größere Webseiten meistens okay aufgestellt sind, aber wenn ich natürlich nicht genau genug hingucke, steckt da auch wieder der Teufel im Detail. Beispiel, ich gucke mir meinen Speed an über mein ganzes Portal, die Performance, ist doch alles okay. Wenn ich mir aber die Performance in Segmenten angucke, in den Einzelsegmenten, stelle ich auf einmal fest, dass meine Performance in den Kategorien unterirdisch ist, weil die Kategorien automatisch vom System zusammengebaut werden und das System da irgendwie nicht mit klarkommt und insofern auf meinen einzelnen Produktseiten ist die Performance super, aber auf den Kategorie-Seiten ist sie ganz gruselig. Das bedeutet, wenn ich mit großen Portalen arbeite, ist so eine Segmentierung wahnsinnig wichtig und es ist ja eh so, wenn wir jetzt von einer Seite sprechen die 10 Millionen Unterseiten hat, ich fasse keine einzelne URL von Hand an, sondern ich muss in Mustern denken. Das heißt also auch, wenn jetzt User bei uns mit dem Tool arbeiten, ist es so, dass du versuchst Muster zu erkennen. Das heißt du findest einen Fehler, den du wahrscheinlich nicht nur einmal hast, sondern auf tausenden von Seiten und musst verstehen, was ist das Muster dahinter? Wieso gibt es diesen Fehler? Weil wenn ich das einmal abstelle, dann ist es wahrscheinlich bei allen weg. Oder aber, wenn du jetzt Seiten, also du würdest verschiedene Seiten-Typen, du möchtest es filtern. Bei uns gibt es zum Beispiel so eine Musterdefinition, auf der du Cluster bilden kannst. Das heißt du sagst, aufgrund einer technischen Spezifikation oder die kann sogar im Quellcode irgendwie HTML mit XPath und sowas irgendwie stattfinden, sage ich, das ist immer eine Kategorie-Seite, das ist immer eine Produktseite oder eine Artikelseite oder sowas. Und so definiere ich mir dann so ein Muster und wenn der Crawler rübergeht, dann sortiert der die Seiten in die Segmente rein und es ist egal, ob du jetzt tausende neue Produkte hast oder nicht, weil einfach diese Mustererkennung dann greift und das gleiche versuche ich also auch beim Arbeiten mit dem Tool oder mit meiner Seite, mit meinem Portal zu erfassen. Und wenn ich jetzt auf sowas wie PageSpeed gucken, dann muss ich natürlich auf den Gesamt-Speed gucken, der kann auch immer mal Anomalien aufweisen. Also wir haben schon häufiger gesehen, wenn du jetzt eine große Seite hast und du machst jetzt einen Technical Crawl mit Audisto beispielsweise, dann dauert das auch mehrere Tage gegebenenfalls, also je nachdem wie schnell dein Portal das zulässt, dass du gecrawlt werden kannst und dann siehst du nachts zwischen 2 und 3, dass es irgendwie Timeouts gibt, aber immer nur zwischen 2 und 3. Und dann guckst du diese Timestamps an und schaust nach und dann stellst du fest, ah, zwischen 2 und 3 wird ein Backup gemacht im System und wenn das Backup gemacht wird, kann das System die User-Zugriffe nicht mehr handeln. Solche Anomalien kannst du dann auch schnell haben. Genau, also dass du unterschiedliche Seitentypen hast wie jetzt Kategorien oder so, wo der Speed eine Rolle spielt, definitiv auch eine Frage. Und dann ist es natürlich so, Beispiel, ich habe ein großes System, ich arbeite mit vielen Redirects und natürlich vielen Redirects und ein Redirect dauert in meinem System immer 150 Millisekunden. Jetzt gibt’s so diese Faustregel, ich glaube, die Amazon vor Jahren mal aufgestellt hat, 100 Millisekunden Speed ist 1 Prozent Umsatz. Das heißt jeder Redirect kostet 1,5 Prozent Umsatz, weil ich zu viele Redirects verwende und es einfach zu lange dauert. Das heißt also, selbst wenn eine einzelne Produktseite gegebenenfalls schnell genug da ist, dass ich sage, das ist okay, kann es sein, dass ich durch solche Effekte, weil ich Redirects habe oder Redirect-Ketten oder sowas, mir trotzdem meine Performance kaputtmache. Und das natürlich auch nicht trivial zu erkennen ist, deswegen ist so wichtig dann auch für solche Analysen, ich muss das komplette System crawlen. Es reicht nicht, nur einen Auszug zu crawlen, sondern ich muss einfach alles crawlen und dann muss ich mir so einen Überblick verschaffen.

Markus Hövener: Und um solche Bottlenecks wie zwischen 2 und 3 Uhr nachts zu finden, müsst ihr eben auch kontinuierlich über den Tag crawlen?

Sören Bendig: Ja, das ist mehr so ein, also ich sage mal ein Abfallprodukt. Bei uns ist es so, dass unser Crawler sehr, sehr stark konfigurierbar ist, das heißt der User kann bis hin zu URL Rewrites, wo er sagt, wie mit bestimmten URLs umgegangen werden soll und ob die umgeschrieben werden sollen für so Simulationen und sowas kann er da sehr, sehr viel machen. Und es ist einfach so, dass wir durch den Crawl-Prozess selber ein sehr ausführliches Logfile schreiben, was der User einsehen kann. Das heißt der User kann am Ende, wenn der Crawl fertig ist oder auch selbst, wenn der Crawl läuft, kann er da reingucken und sieht, ah, hier wird der Crawl automatisch gethrottelt, weil der Server verhält sich komisch. Hier ist es so, dass irgendwie der Timestamp immer so und so ist und dann habe ich irgendwie einen komischen Effekt oder bis hin zu robots.txt Analyse. Ich würde behaupten, bei jeder dritten Seite, die zu sehen bekomme, da ist die robots.txt in Anführungszeichen “kaputt”, also nicht konform und selbst, wenn das so Effekte sind, wo Google, also Google ist ja mittlerweile so drauf, dass sie die gängigsten Fehler, die im Internet immer wieder passieren, einfach ignorieren und für den User reparieren, weil sie einfach sagen, ich kenne die Intention dahinter. Aber das heißt trotzdem ja nicht, also gerade, wenn ich jetzt eine Bot-Steuerung habe, die soll natürlich auch für andere Systeme irgendwie funktionieren und nur weil sich der Google Bot vielleicht das selber interpretiert, wie er der Meinung ist wie es sein soll, ist es beim Bing Bot noch nicht mal so oder so. Auch das sind so Sachen, wo du einfach eine ausführliche Analyse dann brauchst und sehen musst, ah okay, hier gibt’s gewisse Parsing-Regeln, die werden da nicht eingehalten und so.

Markus Hövener: Also man sollte sich ja eh nie darauf verlassen, denn selbst, wenn der Google Bot das heute repariert, heißt das ja nicht, dass er das morgen auch noch kann oder irgendwann mal ein Update kommt und das Ding einfach komplett Amok läuft, deswegen …

Sören Bendig: Total. Also es ist ja so …

Markus Hövener: Das ist natürlich heikel.

Sören Bendig: dass du bei den ich sag mal die Web Standards, es gibt ja unterschiedliche Standards, die haben ja einen Grund, dass sie existieren und selbst bei sowas wie Lokalisierung, du glaubst nicht, wie häufig du Seiten siehst, wo du sagst, also eigentlich ist sowas wie Lokalisierung von HTML-Seiten nicht kompliziert, aber in Realität ist es dann doch so. Das fängt dann damit an, dass Leute sich ich sag mal die ISO-Spezifikationen für Sprach- und Länder-Auszeichnungen nicht bewusst machen und dann hast du Länder, wo es dann komplizierter ist als in Deutschland und dann kommen sie da irgendwie durcheinander oder jemand denkt sich das aus. Und dann ist es so, dass es ja eine Sprachauszeichnung für ein Dokument gibt, ich kann den Content aber auch noch mal sprachauszeichnen, was aber normalerweise nicht dafür gedacht ist, um eine Sprachsteuerung durchzuführen, weil eigentlich die Sprache des Dokumentes das ist, womit ich die Sprachsteuerung vornehme, aber es kann ja auch sein, dass ich mehrsprachige Inhalte habe, dann kann ich für den Content noch mal wieder eine andere Sprache spezifizieren und eigentlich total simple Web Standards, aber es wird halt dann schnell kompliziert und dann ist natürlich sowas wie hreflang oder so ist dann nochmal wieder eine Nummer komplexer.

Markus Hövener: Ich habe noch nie in all den Jahren seit es hreflang gibt, habe ich noch nie jemanden gesehen, der das fehlerfrei auf allen Seiten korrekt implementiert hat.

Sören Bendig: Ich schon, aber es ist selten.

Markus Hövener: Ja, ist wirklich selten. Von irgendwelchen Ländercodes, die es gar nicht gibt, x-default kennt auch kaum jemand. Also das sind so, manchmal finde ich es krass.

Sören Bendig: Jetzt ist es ja auch so, dass viel zu viele nur so eine Basis-hreflang-Analyse machen. Das heißt die gucken, ist denn hreflang implementiert? Ja. Und existieren die Seiten? Und das war’s. Das reicht ja aber nicht. Das heißt du kannst ja auch kaputte hreflang-Gruppen haben, die an anderer Stelle kaputtgemacht werden. Bei uns ist es zum Beispiel so, wir machen die hreflang-Analyse genauso wie PageRank oder CheiRank, das wird im Nachgang berechnet. Das heißt nachdem der komplette Crawl da ist, wird genau geguckt, wo verweist welche Seite per hreflang auf welche andere Seite und dann wird genau berechnet und geguckt, ist irgendwo die Gruppe kaputt. Weil es reicht, dass du irgendwo ein Mitglied in der Gruppe hast, was da nicht hingehört und es macht dir die Gruppe kaputt und wenn du nur auf den Rest der Gruppe gucken würdest, dann denkst du, ist ja alles in Ordnung, stimmt aber nicht und im Zweifelsfall, wenn das zu widersprüchlich ist, kann das auch mal sein, dass Google die Information einfach komplett ignoriert und sagt, ist alles irgendwie Kraut und Rüben, ich lasse das mal, ich orientiere mich mal an der Lokalisierung, die ansonsten irgendwie vorherrscht und bilde mir selber meinen eigenen Reim da drauf. Da ist ja Google immer sehr gut da drin, wenn sie irgendwie sagen, das ist irgendwie schlüssig, dann interpretieren sie halt wie sie das gerne hätten und dann bist du auch schnell wieder bei dieser Parameter-Problematik. Das heißt ich habe URLs, die Parameter besitzen und Probleme mit Parametern haben und die dann auf einmal aber Bestandteil von hreflang-Gruppen sind, weil die Original-URL, die das hreflang Markup besitzt, die ganzen parametrisierten URLs gegebenenfalls aber das nicht korrekt handeln und so tun als wären sie die Originalseite und schon ist die Gruppe kaputt, weil es stimmt einfach so nicht. Und das sind natürlich dann auch Dinge, die man sich dann, wo man sich das ganz genau im Detail dann anschauen muss. Und dazu kommen natürlich dann klar, so Probleme mit Sprachauszeichnungen, Länderauszeichnungen, kannst ja auch widersprüchliche Sprachinformationen in hreflang und in der Dokumentlokalisierung haben und so. Hatten wir schon alles Mögliche gesehen.

Markus Hövener: Dito. Ja. Wenn wir vielleicht kurz mal auf hreflang kommen, dann ist es ja schon so, ich meine, wenn da jetzt ein Fehler drin ist, dann passiert ja eigentlich nichts Schlimmes, ich kriege immer noch eine Seite ausgeliefert in den Suchergebnissen, im Worst Case lande ich dann halt auf der für Ost-Kirgisistan, aber ich lande zumindest erstmal auf irgendeiner Seite. Andere Sachen gibt es ja, die sicherlich viel, viel tödlicher sind, weil ich finde es auch immer schwierig, wenn man sich so eine Website anguckt und man hat irgendwie 120 Fehler identifiziert, das zu priorisieren und zu sagen, das bricht mir jetzt als erstes das Genick und hreflang kann ich vielleicht noch ein bisschen nach hinten schieben, weil es nicht schlimm ist. Hast du dazu eine Meinung, wie man mit sowas umgehen sollte?

Sören Bendig: Wenn du 120 hast, dann hast du eigentlich kein Problem.

Markus Hövener: Nein, ich meine 120 verschiedene Fehlerkategorien.

Sören Bendig: Ja, also definitiv, also eigentlich sind lustigerweise die zwei Fragen oder die drei Fragen, die ich am häufigsten höre, ist A) ich muss dir gestehen, ich habe keine Ahnung wie groß unser Portal ist, ich weiß es nicht. Das heißt also die SEOs wissen teilweise einfach nicht, wie groß die Seite ist. Das muss man dann erstmal durch so einen Crawl irgendwie herausfinden. Das zweite ist, wie schnell darf ich mich selber crawlen. Ich sag, ja, das kann dir eigentlich nur deine Technik beantworten. Also du kannst natürlich mit einem Rasenmäher rübergehen. Da muss man ja auch aufpassen. Also wir haben jetzt so normalerweise so ein automatisches Throttling drin, die kannst du aber ausstellen und vielleicht kleine Anekdote, aber wir hatten auch mal eine Agentur, die haben das ausgestellt, weil ihnen das zu langsam ging und die Seite zu viele Fehler geworfen hat und dann sind die mit dem Rasenmäher über den Shop vom Kunden rübergegangen und der war für einen Vormittag offline. Also das ist dann ja wie eine DDoS-Attacke. Das ist, wenn du das zu stark einstellst und der kann das nicht handeln und das kriegt keiner mit und das ging sogar hinterher vor Gericht, weil es natürlich eine Schadensfrage ist.

Markus Hövener: Ich wollte gerade sagen, wir müssen ja hier nicht annehmen, dass das ein kleiner Shop ist, wo man das gemacht hat?

Sören Bendig: Nein. Und das ging dann vor Gericht und es ist also auch ein Schaden festgestellt worden dann. Also insofern muss man natürlich immer wissen, was man da tut. Und dazu ist natürlich dann die nächste Frage und da schließt sich der Kreis, wo fange ich denn jetzt an?

Markus Hövener: Ja genau.

Sören Bendig: Und natürlich ist es so, wenn ich jetzt feststelle, ich habe meine Google Snippets, zu 20 Prozent ist der Titel zu lang, verdiene ich 1 Euro mehr damit, wenn ich das fixe? Da kommt es aber immer so ein bisschen drauf an, was für Probleme habe ich denn überhaupt? Das heißt also die gravierenden oder ich sag mal die Stärke der Probleme unterscheidet sich ja auch immer immens und es ist auch so, für das eine System ist das ein Problem und für das andere ist es aber kein Problem, wo das total egal ist. Im Endeffekt ist es so, dass alles, was sich mit User-Führung und natürlich auch Struktur, Architektur und so technischen Dingen, die ich einfach eklatant falschmache, das hat natürlich nach hinten raus einfach einen großen Effekt und das sollte ich natürlich als erstes fixen und kann natürlich immer weiter ins Detail reingehen. Und natürlich kann das sein, wenn ich jetzt einen Shop mit 8 Millionen Produkten und ich baue mir die Titel vom System automatisch zusammen und derjenige, der sich das Konzept überlegt hat, hat sich das aber nicht so gut überlegt und dann hast du am Anfang vom Titel immer stehen “günstig im Onlineshop sowieso einkaufen” und dann kommt der Artikel, den ich kaufen kann und ich habe aber dann irgendwie in der Google-Suche vielleicht vom Artikel noch irgendwie 7 Zeichen frei oder so, weil vorher der ganze andere Kladderadatsch kam, dann ist es natürlich Conversion-relevant. Also ich bin ja in so einer technischen Optimierung auch schnell in so einem Bereich, wo man sich dann schnell die Frage stellt, ist es jetzt Aufgabe des SEOs, ja oder nein? Aber da muss man natürlich dann sich vom Gesamtkonzept überlegen, wo habe ich Probleme, die meine Conversion verhindern, wo habe ich Probleme, die dazu führen, dass der User abspringt oder aber auch vielleicht nicht an die richtigen Dinge irgendwie überhaupt hinkommt. Wir haben ja zum Beispiel, Hints nennt sich das bei uns, das heißt wir haben so 140 verschiedene Technical SEO Hinweise, die geflagt werden und die ich für so eine Filterung und eine Analyse verwenden kann und das können einfache Dinge sein wie, du möchtest herausfinden irgendwie, alle URLs, die keinen Canonical beinhalten oder sowas. Das kann aber auch dann komplexer sein, sowas wie, ich möchte den Anfang einer Redirect-Kette finde, also von dem Loop. Das sind 140 verschiedene und dann sitzt jemand davor und sagt, ja aber wo fange ich denn jetzt an? Da ist es einfach, dass ich überlege muss, also alles, was verhindert, dass jemand anständig bei mir einkaufen kann oder mich aber natürlich über die Suchmaschine sinnvoll finden kann und sich auch durchbewegt, das sind natürlich dann die relevanten Dinge und wo, kommt dann drauf an. Wenn ich irgendwie Seitenbereiche habe, die total kaputt sind oder ich habe so Redirect-Ketten, die sich 5-mal durchschlängeln, dann sind das natürlich eklatante Fehler. Oder aber, ist ja auch nicht unüblich, dass man dann feststeht, oh, es gibt hier widersprüchliche noindex-Informationen, die muss ich auch irgendwie aufheben, weil es einfach gewisse Bestandteile gibt, die werden einfach gar nicht indexiert und dann kann es natürlich auch niemand finden. Insofern kann man leider nicht sagen, mach erstens das, mach zweitens das, aber ich würde sagen, so technische Probleme aufräumen, Performance natürlich ganz wichtiger Part und dann komme ich aber auch schnell an den Bereich Indexierung. Ich bin immer wieder schockiert, wie wenig Verständnis für so Indexierungsthemen und Index-Steuerung vorherrscht, was gerade bei großen Seiten einfach schnell viel komplexer wird und du dann im Zweifelsfall so Effekte hast, dass widersprüchlich Information vorherrscht. Du hast also irgendwo vielleicht Information an einer Stelle, wo es heißt, da darf der Bot aber nicht hin und an anderer Stelle darf er da aber hin und so. Ja und dann aber natürlich auch alles, was so mit Architektur zu tun hat, wo du dir auch überlegen musst, okay, was bedeutet das auch für den Nutzer.

Markus Hövener: Vielleicht so zum Schluss noch, möchtest du noch ein bisschen dein Schatzkästlein öffnen und nochmal irgendwie so die 2, 3 schlimmsten Beispiele sagen, was du so in den ganzen Jahren jetzt so gesehen hast?

Sören Bendig: Also ein Thema, was man immer wiedersieht, ist am Facettierung, Filterung, Parameter, da gibt’s teilweise ganz, ganz krasse Effekte, teilweise, wo dann Seiten so groß sind, dass du sie gar nicht richtig analysieren kannst, wo du dann überlegen musst, was machst du, nimmst du jetzt, sagst du jetzt, ich habe das Problem erkannt und nimmst du so ein Rewriting und ignorierst dann einfach Bestandteile, weil du sagst, naja, bis das gefixt ist, dauert das jetzt eh 6 Monate. Also sowas ist immer ein Problem und du bist bei so großen Shop-Seiten auch schnell einfach in Bereichen, wo du dir überlegen musst, habe ich eine Strategie und ist mir bewusst, was da passiert und wie gehe ich damit um. Also selbst mit sowas wie, ich habe Kategorien und dann habe ich ja vielleicht, also auch im Reisebereich siehst du das ganz häufig, dass es zu bestimmten Themen irgendwelche Angebote gibt und dann läuft das irgendwann leer. Ich habe keine Inhalte mehr oder ich habe einen Inhalt oder sowas, was eine schlechte User Experience ist, wenn der User dahinkommt. Wieso darf er da überhaupt noch hinkommen und wieso ist es überhaupt möglich, dass sowas passiert? Oder Effekte, dass du Seiten hast, wo der Nutzer keinen Call to Action hat, um ein Produkt zu kaufen. Das sind dann so Themen, wo du schnell im Bereich bist, wo du sagst, naja, ist das jetzt ein SEO-Thema? Aber der SEO ist derjenige, der es eigentlich am besten mitbekommt. Also alles, was so Testing und Monitoring angeht, ist halt bei vielen auch immer noch so in den Kinderschuhen, da wird so ein bisschen Template-Testing betrieben und das war’s. Aber man würde sich wundern, wie viele Shops es gibt, die im Zweifelsfall auch mal ein Produkt für 0 Euro verkaufen. Da sagt man ja, das gehört sich eigentlich so nicht und eigentlich müsste ich das über irgendwelche Worker, die auf der Datenbank laufen, abfragen, passiert aber trotzdem. Und kann es nicht vielleicht sein, dass der SEO, weil er einfach den besseren, besten Gesamtüberblick hat und die Schnittstelle auch mit einer Conversion-Optimierung und mit der Technik und so, dass er ich sag mal mehr den Überblick behält und auch vielleicht je nachdem, was für Projekte und Themen gerade anstehen, so eine bessere Schnittstellenfunktion wahrnehmen kann. Passiert ja auch teilweise in den Unternehmen. Das ist sicherlich was, wo man dann drüber nachdenken muss. Und fehlendes Verständnis von Indexierung, wie gehe ich mit Struktur um, was für große Hebel das sein können. Das ist so ein Effekt, wenn es um so technische Dinge geht, dann bräuchte ich eigentlich nur ein gutes Tool, um zu gucken, was sind denn jetzt die Basics, die ich eigentliche sinnvoll machen sollte? Selbst da ist es so, auch bei den großen sind die dann nicht perfekt. Wir haben jetzt vor weiß ich gar nicht vor ein paar Monaten oder so haben wir mal so ein Industriemonitoring gelauncht, das ist bei uns auf der Webseite zu sehen, da gibt es so Branchen, da kannst du zum Beispiel dir dann die Top Player aus dem E-Commerce Bereich angucken und dann siehst du einfach nur so Web Standards und so Basics, die überprüft werden, technischer Natur und siehst, dass da trotzdem haufenweise Seiten dabei sind, die irgendwo Probleme haben, weil im Zweifelsfall irgendjemand entschieden hat, wir verdienen nicht einen Euro mehr damit oder aber, weil es niemand auf dem Schirm hat, weil vielleicht der SEO sich für Security Themen nicht zuständig fühlt und die Security sich aber nicht für so Web Security Themen irgendwie zuständig fühlt, sondern nur sagt, wir passen auf, dass hier nicht die bösen Bots kommen. Also wirklich von bis, muss man sagen. Und ich glaube strukturiertes Vorgehen und wirklich einen Überblick zu haben und einfach eine Strategie und einen Masterplan, ich glaube, dass das das Wichtigste ist und dass ich da einfach auch eine gute Datengrundlage brauche und auch verstehen muss, wo, wie, welche Effekte da sind. Also ich höre auch häufig, wenn man mal aufzeigt, pass auf, da hast du die und die Probleme, dann sagt jemand, nein, da habt ihr doch einen Fehler bei euch im Tool. Das ist alles korrekt bei uns. Dann sagst du, nein, du hast einfach nicht verstanden, wie das funktioniert und guckst du so und so und egal, ob es jetzt irgendwie SSL Problematiken sind oder weiß der Geier was. Es ist auch komplex, also man kann auch sicherlich keinem den Vorwurf machen, dass er sich irgendwie perfekt mit allem auskennt. Und ich finde es, also ich bin jetzt ja von meinem Hintergrund auch Ökonom, insofern ich finde es auch ökonomisch vom Vorgehen, dass man bei bestimmten Fehlern entscheidet, interessiert mich überhaupt nicht. Mir ist es bewusst, ich weiß, da ist es nicht dem Standard entsprechend und ich weiß, ja, das müsste man, damit es irgendwie technisch perfekt und hübsch ist, müsste man es fixen, aber ich habe einfach gerade ganz andere Baustellen, die sind mir viel, viel wichtiger und damit verdiene ich Geld. Ist auch völlig in Ordnung, Hauptsache es ist eine bewusste Entscheidung und keine zufällige Entscheidung.

Markus Hövener: Ja, finde ich gut. Vielen Dank sage ich schonmal für deine Zeit.

Sören Bendig: Sehr gerne.

Markus Hövener: Vielleicht noch kurz die Frage, sehen wir dich in diesem Jahr noch irgendwo, eine der üblichen Konferenzen?

Sören Bendig: Dieses Jahr, ich überlege gerade, ob aus dem SEO-Bereich, momentan nichts Großes geplant. Es ist so, dass wir jetzt mit dem Testing- und Monitoring-Tool, was wir jetzt haben, also häufiger mal in so Richtung Produktmanagement, Quality Management unterwegs sind, weil man da auch ganz, ganz viele interessante Dinge machen kann. Das heißt da habe ich super Vorträge, aber jetzt was so SEO-Themen angeht, was öffentlich wäre, nicht. Also es gibt häufiger mal, dass wir zu internen Konzernveranstaltungen, die dann mehrere Tochtergesellschaften haben, da mal hinkommen und wir sind dann immer gerne gesehen den nassen Waschlappen rauszuholen und mal zu sagen, hier, so sieht’s aus und irgendwie, du hast es gut gemacht und du hast es schlecht gemacht.

Markus Hövener: Cool. Okay, dann sage ich dir nochmal vielen Dank.

Sören Bendig: Sehr gerne.

Markus Hövener: Und euch da draußen auch. Vielen Dank fürs Zuhören und bis bald. Tschüss!

Sören Bendig: Viel Erfolg beim Optimieren. Ciao!

Nächste Events

Nächste Webinare

Alle kommenden Webinare

Nächste Seminare

Alle kommenden Seminare

The following two tabs change content below.
Avatar-Foto
My Instagram profile

Markus Hövener

Markus Hövener ist Gründer und SEO Advocate der auf SEO und SEA spezialisierten Online-Marketing-Agentur Bloofusion. Als geschäftsführender Gesellschafter von Bloofusion Germany ist er verantwortlich für alle Aktivitäten in Deutschland, Österreich und der Schweiz. Markus Hövener ist Buchautor, Podcaster und Autor vieler Artikel und Studien rund um SEO.

Markus hat vier Kinder, spielt in seiner Freizeit gerne Klavier (vor allem Jazz) und genießt das Leben.

Kommentieren