Diese Onpage Fehler macht fast jeder SEO #SEODRIVEN #075

By | August 10, 2019


So Freunde, willkommen bei der 75-ten Folge von SEO-Driven und heute hab ich einen ganz besonderen Gast, den Tobias, Gründer und Geschäftsführer von Audisto. Ich glaube fast alle, hoff ich mal, kennen
ihn schon. Oder wenn ihr ihn noch nicht kennt, dann werdet ihr ihn heute kennenlernen und lieben lernen. Und es geht bei uns in dieser Woche um alles mögliche was man zum technischen SEO und Onpage SEO wissen muss. Wir fangen heute damit an, was es eigentlich so für klassische SEO-Onpage Fehler gibt, die man gleich am Anfang beseitigen sollte. Ja Tobias, du bist ja wirklich mit deinem
Tool Audisto ein Experte für große Website Crawlings, also wenn Onpage, Screaming Frog und Co. an ihre Grenzen kommen, dann spätestens schaltet man Audisto ein. Und du siehst da die größten Websites sozusagen in Deutschland, crawlst die durch mit deinem Team und deiner Software, berätst die Leute dann auch über die Ergebnisse. Und dann habt ihr eine ganze Menge so an klassischen Fehlern, die immer wieder kommen. Was ist das denn so? Genau, also grundsätzlich haben wir so drei Arten von Kunden: der erste ist quasi der, der sich mit seinen Fehlern beschäftigt. Dann haben wir den Kunden, der seine Seite versucht zu optimieren und der dritte ist der, der versucht das ganze zu automatisieren. Und bei diesen klassischen Fehlern kennt man natürlich die 404s, also einfach Links die nicht funktionieren oder Bilder nicht funktionieren, Das sind die häufigsten Dinge. Damit fängt es oft an. Ja das schöne an dem Crawler ist, dass man sie damit finden kann, wir erfassen die Seite dann strukturiert, fangen bei der ersten Ebene an, finden die ganzen Links, folgen denen, folgen den ganzen Bildern, Javascripts, CSS, alle Dinge die man sonst als SEO schwer aufnehmen kann. Ja vor allem bei den Content Management Systemen, die halt natürlich teilweise ohne dass man es weiß URLs produzieren, Thumbnails produzieren, Verlinkungen machen, GET Parameter, also die kompletten Onpage Hölle. Und sehr häufig auch Redirect Ketten, oder
sinnlose interne Redirects, die dann einfach zu zusätzlichen Performance Latenzen führen. Markup-Fehler sind gängiger Natur, dass man einfach kaputte Links hat, die z.B. von Leerzeichen gefolgt werden oder einfach solche Dinge. Ja von Hand gesetzte Links. Sowas kennen wir natürlich auch. Ja kann bei den Redirects, das ist ja so ein Thema was viel diskutiert wurde, wie stehst du zu den verschiedenen Statuscodes 301, 302 etcpp. 307? Ich glaube für die Suchmaschine macht es nicht so einen großen Unterschied, was das für ein Statuscode ist. Was einen sehr großen Unterschied macht ist der Browser. z.B. kann ein 301 Statuscode, der kann gecasht werden und es gibt ein schönes Beispiel: Wir hatten eine Nachrichtenseite, die hatten ein Bereich wo sie die Nachrichten des aktuellen Tages aufgelistet haben. Und die haben mehrere Hundert Nachrichten pro Tag produziert und so füllte sich eben die Paginierung über die einzelnen Stunden auf, und wenn du kurz vor Mitternacht auf diese Seite gegangen bist, dann konnte es
dir passieren, dass du dann 5 oder 6 Seiten Paginierung hattest. Und wenn du jetzt die Uhrzeit über die Mitternacht rübergesprungen, dann gab es natürlich für den neuen Tag keine Nachrichten. Und dann konntest du, wenn du vorher auf der Seite warst, die letzte oder die nächste Seite anklicken und wurdest dann mit dem 301 Redirect wieder auf die erste Seite geleitet, die dann gesagt hat: Ahh heute gibt es leider noch nichts. Jetzt kommst du am nächsten Tag wieder, auch wieder kurz vor Mitternacht, es gibt vielleicht noch mehr Seiten, jetzt klickst du genau die selbe Seite wieder an, es ist jetzt gecasht im Browser und du wirst wieder auf der Startseite landen. Es ist ein permanenter Redirect, der vom
Browser gecasht wurde. Und das sind oft die technischen Details,
auf die man achten muss. Wenn man Dinge nicht permanent umzieht, muss man temporäe Redirects benutzen und da bleibt eigentlich nur der 302 oder 307 oder 303. Wovon der 303 der einzige ist, der…. Und 307, was ist da das Besondere dran? Der 307 ist auch ein temporärer Redirect,
müsste nochmal selbst die Unterschiede nachgucken, der erhält die Request-Methode. Ah ok. Du hast ja Formulare, können ja per GET und per POST entsprechend sein, und oft ist es so, dass sich die Request-Methode ändern kann. Und mit dem 307 Redirect kannst du diese Request-Methode erhalten, das heißt du kannst mehrere Post-Geschichten machen, die dann auch weiterhin die Werte als POST übermitteln an folgende Redirects. Ah ok, ansonsten würdest du die Daten verlieren. Genau. Ok, spannend. Ja, was mir noch aufgefallen ist, dass wenn man mit 302 redirected, dass dann auch die ursprüngliche URL ganz gerne mal im Index bleibt, aber mit dem Inhalt des weitergeleiteten Dokuments. Genau, das passiert dir aber mit dem 301 Redirect oder 303-er genauso. Google hat vor Jahren angefangen die hübschere URL zu verwenden, und oft ist das eben die alte Variante oder eine kürzere Variante. Da gab es ein ganz prominentes Beispiel mit Velux Dachfenster und die haben in Medien geworben mit Velux.de/Dachfenster, die Seite gab es nie. Und war dann trotzdem die in den Suchergebnissen rankte, weil sie dann einfach auf einen anderen Inhalt weitergeleitet hat und Google die für schöner hielt. Ja, ok gut, das heißt es ist hier garnicht
so wichtig welcher Statuscode dahinter ist, sondern wie schön die URL ist? Das hab ich tatsächlich bei einem Kundenprojekt entdeckt und da hatte ich es allerdings auf den 302 geschoben, weil es ja auch irgendwo Sinn machen würde, weil die URL an sich bleibt und später vielleicht einen anderen Inhalt
hat. Aber der Aspekt macht natürlich auch Sinn. Cool. Man sollte natürlich auch gern den richtigen Statuscode verwenden, da muss man bisschen drauf achten. Nur so kann man sicher gehen, aber es würde natürlich auch abhängig von dem was man eigentlich vom Statuscode erwartet auch viel Schindluder getrieben. Gerade mit dem Linkaufbau und so weiter. Bis dann auch irgendwann die Penalties mitvererbt wurden bei der Weiterleitung. Viel schlimmer an den Redirects sind oft die Latenzen, wenn diese Redirects nicht schnell sind, dann führt es natürlich zum zusätzlichen
Ladezeiten. Im E-Commerce-Umfeld sagt man ja etwa 1% weniger Sales pro 100 Millisekunden Ladezeit, 100 Millisekunden ist nicht viel was man braucht um da schlechter abzuschneiden. Amazon hat es getestet, da kommt diese Zahl her. Und Akamai hat Latenzen getestet, wo sie rausgefunden haben, dass 4 Sekunden Ladezeit 30% der Leute den Tab geschlossen haben ohne dass sie irgendwelchen Inhalt gesehen haben. Das sind natürlich Dinge, wenn man solche Performance-Engpässe innerhalb seiner Seitenstruktur findet, die sollte man wirklich mit ganz hoher Priorität angehen. Da sind ja oft Javascript und CSS- Geraffel, gerade bei den beliebten Content Management Systemen, wo man dann 20 Plugins hat und jedes schiebt dann nochmal sein eigenes Javascript rein, und so weiter. Da hast du die ganzen Performance Best Practices, die legt diese Sachen zusammen, wobei man da sagen muss dass sich das auch bisschen gedreht hat. Jetzt haben wir ja HTTP2, da kannst du jetzt mehrere Requests über eine Verbindung, also über eine Connection abfrühstücken. Da dreht sich das schon wieder. Da kann es mitunter besser sein, das wirklich in Häppchen zu haben, Push-Mechanismen zu benutzen, oft sind aber diese Tools, die Performance Best Practices Tool noch garnicht drauf angepasst. Die wenden immer dasselbe Regelset an, und ignorieren eigentlich dass du da vielleicht schon auf der besseren Technologie bist. Ist so ähnlich wie mit den Sections, weil
da heißt es ja jetzt auch H1 kann jetzt doch mehrfach vorkommen, um so ein bisschen dieses One-Pager Thema abzudecken, aber egal mit welchem Tool ich das teste, bei eurem weiß ich das jetzt nicht weil wir damit nicht so häufig arbeiten, aber da wird mir jedes
Mal um die Ohren geworfen: H1 ist doppelt, bitte beheben. Wird aber am Schluß nicht der ausschlaggebende Faktor sein. Es gibt deutlich gravierendere technische
Mechanismen. Die meisten Leute sollten mit ihrem Inhalt
anfangen zu arbeiten, bevor sie dann sich um so Kleinigkeiten kümmern, wie die H1. Das ist schon das Stichwort, um die inhaltliche Optimierung geht es morgen. Also bleibt dran. Schaltet morgen wieder ein, dann haben wir den Tobias auch wieder hier, auf der schönen schwarzen Couch. Bleibt dran, gibt uns ein Daumen nach oben und wenn ihr Fragen habt könnt ihr gern kommentieren, ich leite das auch an den Tobias weiter. Tobias ist immer happy to help. Richtig? Ja. Super, bis morgen. Ciao, Ciao.

Leave a Reply

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