Server Optimierung mit Onpage.org – Teil 1 von 8

Wir freuen uns, dass wir als erster Partner von Onpage.org eine tolle Blogserie starten dürfen. Bevor wir uns aber dem eigentlichen Thema, der Server Optimierung widmen, wollen wir noch kurz etwas zu der Aktion an sich sagen. Wir finden es nämlich klasse, dass mit care.de ein großer Verein gefunden wurde, dem wir bei der Onpage-Optimierung behilflich sein dürfen. Wir sind auch vorallem auf das Ergebnis gespannt: Was passiert, wenn wirklich alle Optimierungsmaßnahmen, sowohl von uns als auch den weiteren Blogpartnern tatsächlich umgesetzt wurden? Insgesamt wird es acht Blogpartner geben, die jeweils ein eigenes Modul bzw. einen eigenen Bereich von Onpage.org vorstellen werden – alles gezielt am Beispiel von care.de. Zum Schluss gibt es auch noch eine kleine Überraschung. Schaut dazu einfach unter unser Fazit am Ende dieses Artikels.

Marcus und das gesamtes Team von Onpage.org haben mit dieser feinen Aktion mal wieder nur das Beste im Sinn. Daher unterstützen wir als Trust Agents natürlich gerne diese Charity-Aktivität. Wir haben dabei die Ehre, uns den Server-Bereich genauer anschauen und analysieren zu dürfen. Wir werden versuchen, möglichst alles sehr einfach und mit relativ praxisnahen Beispielen darzustellen und zu erklären.

Was versteht man unter der Server Optimierung unter SEO-Gesichtspunkten?

Spricht man von der Server Optimierung, so reicht das Themenspektrum von der Seitenladegeschwindigkeit bis hin zur internen/externen Serverarchitektur (u.a Software, Loadbalancer, CDN). Wir zeigen euch mit Hilfe des Onpage-Analysetools Onpage.org, wie ihr die wichtigsten Stellschrauben und Faktoren im Server-Bereich optimieren könnt und wieso man diese Punkte auch wirklich in Angriff nehmen sollte. Lasst uns dazu einfach direkt loslegen:

Informationen zum Server bei Onpage.org

Laut Onpage.org ist care.de im Server-Bereich bereits zu 94% optimiert. Das heißt aber, es ist definitv noch „Luft nach oben“. Aber schauen wir uns die vier Bereiche, die uns Onpage.org zur Verfügung stellt, doch mal etwas genauer an:

1. Status Codes

Details zu Status CodesAuf den ersten Blick sieht man eigentlich gleich, dass hier gerade die Status Codes ein wenig aus der Reihe springen. 307 Fehler auf knapp über 5000 geprüften Seiten ist schon eine Menge und lässt durchaus darauf schließen, dass hier etwas im Argen liegt. Aber gut, das schauen wir uns später noch genauer an.

2. Redirect Ziele

Redirect Ziele Onpage.orgHier werden die Redirects, die der Onpage.org-Bot auf der Seite gefunden hat, auf Validität geprüft. 94% ist zwar schon ein guter Wert, aber definitiv noch nicht perfekt. Durch kleine Redirect-Fehler kann eine Menge Linkjuice verloren gehen. Deshalb sollte man die Anmerkungen zu den Redirects ernst nehmen und schauen, dass hier möglichst keine Fehler auftreten.

3. Antwortzeiten

Antwortszeiten des Webservers

Die Frage ist: Wie schnell schafft es ein Server auf einen Request (eine Anfrage) zu antworten bzw. zu reagieren? Hier spielt der Serverstandort eine große Rolle. Umso weiter mämlich ein Server geographisch vom anfragenden Bot/User entfernt ist, umso mehr „Hops“ benötigt der Bot/User, um eine Antwort zu bekommen. Gerade große CDN (Content Delivery Networks), wie zum Beispiel Akamai, liefern hier, lokal gesehen, die Ergebnisse vom nächstgelegenen Serverstandort aus.
Theoretisch könnte man also seine komplette Seite ins CDN legen, um so eine hohe Ausfallsicherheit zu haben und lokal schnell ausspielende Seiten sicherzustellen, was sich dann durchaus positiv auf die Antwortzeiten auswirkt. Laut Onpage.org schafft es care.de, auf 94% der Anfragen in einer positiven Antwortzeit zu reagieren – ein guter Wert.

4. Verfügbarkeit

Verfügbarkeit onpage.org care.deDie Verfügbarkeit ist nicht nur ein reiner SEO-Faktor, sondern spielt natürlich auch als ein wichtiges Element eurer Webseite eine große Rolle. Wenn die Seite nicht erreichbar ist, dann ist das zugleich in mehreren Fällen kontraproduktiv: Man verägert nicht nur die User/Kunden, sondern die Seite kann ihren Zweck (Information, Transaktionen, …) nicht mehr erfüllen. Auch Google nimmt eine Seite nach einer gewissen Zeit aus dem Index, sollte diese nicht erreichbar sein. Eine sehr hohe Verfügbarkeit ist daher besonders wichtig.
Die meisten Webhoster gerantieren normalerweise eine Verfügbarkeit von 99,9%, auf ein Jahr gesehen. Dies entspricht einer Ausfallzeit von 8,7 Stunden pro Jahr, die aus meiner Erfahrung allerdings auch erreicht wird 🙁

Analyse „Status Codes“

Schauen wir uns den Bereich „Status Codes“ doch mal etwas genauer an.

HTTP Statuscode Onpage.org

Hier sehen wir eigentlich sehr schnell, dass der Download-Bereich und der Klartext-Bereich wirklich gute Ergebnisse erzielen. Unter Klartext versteht man dabei den direkten Output von Dateien an den Browser, also zum Beispiel txt-Dateien.

Im HTML-Bereich liegt mit Sicherheit das größte Potenzial verborgen. Bei den „200“ern, also den positiven Response-Codes sieht soweit alles gut aus. Daher springen wir direkt zu den „301“ern.

Hier gibt es aktuell 57 interne 301er. Unter einem 301 versteht man einen permanenten Redirect, also den Verweis auf einen dauerhaften Umzug einer URL Was leider bei jedem 301er passiert: Man verliert ein wenig Power, ein sogenannter Linkjuice Puffer. Normalerweise eigentlich vernachlässigbar, aber bei einer 100%-Optimierung würde ich versuchen, die Linkziele auf der Seite direkt anzusprechen und die Anzahl der Redirects auf ein Minimum zu reduzieren.

301-Weiterleitungen im Detail

Was sollte das care.de-Team hier am besten machen?

Interne Links, die aktuell redirected werden, in direkte Links umwandeln. Hierzu wäre eine Übersicht der gefundenen Links sinnvoll, um zu sehen, auf welcher Seite der alte Link gefunden wurde, damit man diesen dann direkt auszutauschen kann. Dazu muss man bei Onpage.org einfach die genauen Details aufrufen. Diese sollten dann nach und nach ausgewertet und die Links angepasst werden.

Interne 301 Weiterleitungen

Somit hätten wir die 301er abgehandelt. Kommen wir nun zu den 302ern. Immer wenn ich 302 höre, streuben sich meine Nackenhaare. Der einzige Use-Case, der mir dafür einfällt, ist, wenn die URL innerhalb kürzester Zeit wiederkommt. Damit würde man verhindern, das die URL von Google deindexiert wird. Da dieser Use-Case aber wirklich extremst selten ist, sollte man alle 302er kritisch hinterfragen. Gerade die erste URL, die ich hier schon sehe, ist definitv ein Fall für einen 301. Aber auch alle weiteren internen Links oder Verlinkungen auf weitere eigene Domains sollten ausschliesslich per 301 verlinkt werden.

Temporäre Weiterleitungen (onpage.org)

Was sollte das care.de Team hier am besten machen?

Die Redirects sollten statt mit einem modifiziertem 302, mit einem sauberen 301 weitergeleitet werden, sofern die Umleitungen permanent sind.

Weiter gehts mit den 404er und damit praktisch mit dem Worst Case einer Webseite. Der 404 bedeutet, dass die Seite nicht mehr gefunden wurde. Entweder ist das Dokument nicht mehr auf dem Server vorhanden, umbenannt worden und ein Redirect wurde vergessen oder es ist einfach falsch verlinkt worden. Aber schauen wir uns das doch einfach mal genauer mit Onpage.org an.

404 Fehler

Wenn wir uns nun eine 404 Seite im Detail anschauen, sehen wir sehr genau, dass auch Onpage.org uns die Empfehlung gibt die internen Links, Redirects und Canonical-Tags, die zu diesen 404 Seiten führen, zu entfernen. Alternativ sollten interne Links angepasst werden.

404-Fehler im Detail

Wenn wir nun ein wenig weiter nach unten schauen, dann sehen wir eine Übersicht, wie oft die Seite intern verlinkt wurde. Durch einen weiteren Klick kommen wir direkt zu einer detailierten Ansicht, die uns die entsprechenden Verlinkungen aufzeigt.

Wer verlinkt auf die 404 Seite?

Dadurch haben wir die Möglichkeit, die entsprechenden Links zu identifizieren, um diese dann anzupassen bzw. im Bedarfsfall auch entfernen zu können.

Was sollte das care.de Team hier am besten machen?

Jeder 404-Fehler sollte analysiert und anschließend behoben werden, entweder durch das Entfernen der fehlerhaften Verlinkung(en) oder durch das Anpassen des Links an das neue Linkziel. Jeder fehlerhafte, interne Link sorgt dafür, dass der interne Linkjuice nicht optimal verteilt werden kann.

Zu guter Letzt kommen die Status Codes der Reihe 5xx:
Care.de HTTP 500 Requests
Wenn wir uns das Ergebnis der Onpage.org-Auswertung anschauen, dann sehen wir einen TYPO3-Ordner, der einen Fehler produziert. Ohne validen Referrer wird der Bot an dieser Stelle ausgesperrt bzw. es tritt ein Fehler beim Ausführen der Anmeldeseite auf und erzeugt daher einen 500er-Fehler. Nichts wildes oder bedeutendes, aber es wäre durchaus interessant zu wissen, wo der Bot den Link zum Backend gefunden hat. Ich würde empfehlen, dass man diesen Link entfernt, da hier auf einen geschützen und sensiblen Bereich verlinkt wird, der eigentlich nicht ins öffentliche Interesse rücken sollte.

500 Fehler im Detail

Ich habe mir mal die Quellseite genauer angesehen und im Quelltext eine „leere“ Verlinkung ausfindig gemacht, die an dieser Stelle mit Sicherheit unnötig ist. Also liebes Care.de Team: Entfernt den Link – der Onpage.org-Spider wird es euch danken.

Als zweiten Bereich des Server Optimierung schauen wir uns mal die Redirect Ziele an, die das Onpage Tool analysiert.

Was Onpage.org analysiert, ist die erste Ebene der Redirects sowie das Ziel, worauf die Redirects zeigen. Man sollte sogenannte Redirect-Schleifen auf jeden Fall vermeiden/reduzieren, da durch jeden zusätzlichen Redirect ein Stück des Linkjuice verloren geht. Besonders auf die 302-Redirects sollte man grundsätzlich verzichten. Da sich bei care.de die Anzahl der Redirects in Grenzen hält, kann man die entsprechenden Hinweise in relativ kurzer Zeit abarbeiten.

Springen wir daher gleich zum nächsten Punkt, da er wesentlich mehr Optimierungspotenzial birgt:

Die Antwortzeiten des Servers

Page Speed ist ein Ranking-Faktor, der vielleicht nicht den größten Einfluss hat, aber wenn wir die Optimierung detailiert ausführen wollen, dann müssen wir uns auch die Seitenladegeschwindigkeit detailliert ansehen und schauen, dass wir die Response Time des Servers verbessern.

Serverresponsezeit von care.de

Hier macht care.de wirklich einen guten, aber halt noch keinen perfekten Job. Wir müssen an dieser Stelle ein klein wenig ausholen und erklären, was genau unter der Serverantwortzeit zu verstehen ist:

1. Was wertet Google als Seitenladegeschwindigkeit?

Google misst das Ausliefern der kompletten Seite inklusive aller Bilder etc., also nicht nur des reinen HTML-Codes.

2. Wie misst Google?

Mit Hilfe der Google Toolbar 😉 Es gab eine ganze Weile den Performance-Report in den Google Webmaster Tools (Stichwort: Website Leistung) – an dieser Stelle der Hinweis auf das Google Webmaster Tools E-Book von unserem Geschäftsführer Stephan. Dieser ist dort aber seit Kurzem nicht mehr zu finden (nun wohl in Google Analytics). Auch hier sieht man schön das Google solche Faktoren unabhängig von Anzeigeort in seinen Rankingfaktoren aufnimmt.

Hier der offizielle Wortlaut von Google – für die Skeptiker unter den SEOs:

„Sie zeigt die durchschnittliche Seitenladezeit für Seiten auf Ihrer Website, den Trend der letzten Monate und einige Vorschläge, um die Seitenladezeit zu verkürzen. Die Ladezeit einer Seite ist die Gesamtzeit ab dem Zeitpunkt, an dem ein Nutzer auf einen Link zu Ihrer Seite klickt, bis zu dem Zeitpunkt, an dem die gesamte Seite geladen wurde und in einem Browser angezeigt wird. Diese Informationen werden direkt bei Nutzern abgerufen, die die Google Toolbar installiert und die PageRank-Funktion aktiviert haben. „

Es hat aber durchaus Vorteile, die Antwortzeiten auch für den Bot zu minimieren. Ein Bot, der schnelle Antwortzeiten bekommt, der kalkuliert seine Crawlrate entsprechend. Ein Server der schnell und zuverlässig antwortet verkraftet mehr und kann öfter und auch tiefer gecrawlt werden.

Was sind die größten Zeitverschwender?

1. Schlechte Programmierung
2. Rechenintensive Datenbank-Abfragen

Wenn wir uns nun die sehr langsamen Seiten (mehr als vier Sekunden Antwortzeit) anschauen, dann sehen wir gleich an erster Stelle eine ungecachte Seite. Was heißt ungecached? Diese Seite wird im Hintergrund vom CMS bei jedem Aufruf neu generiert. Das ist natürlich sehr rechenintensiv, was dadurch verständlicherweise auch die Antwortzeit des Servers wesentlich erhöht. Bei der Kontaktseite wurde anscheinend darauf verzichtet, Caching zu nutzen, da es ansonsten Probleme mit dem Captcha geben könnte. Um so eine Seite cachen zu können, wären ein paar programmiertechnische Tricks vonnöten.

Bei den weiteren Seiten, die über eine längere Ladezeit verfügen, sollte ebenfalls über ein Caching nachgedacht werden, damit die Seiten performant und schnell ausgeliefert werden können. Obendrein sollte man überprüfen, ob der Server auch die gzip-Auslieferung unterstützt. Um zu testen, ob dies eventuell bereits aktiv genutzt wird, habe ich einen Header Checker angeworfen und den HTTP-Header einer Seite untersucht – erfolgreich. Daher gibt es zumindest in diesem Bereich kein Optimierungsbedarf.

Header Check

Was ich dabei festgestellt habe, ist, dass das Browser-Caching deaktiviert ist. Das heißt, bei jedem Refresh oder neuen Besuch der Seite wird diese neu geladen. Nicht optimal, wenn die Seite nicht wirklich viele und schnelle Änderungen für den Nutzer bereitstellt. Dafür wäre ein Caching im Browser nicht verkehrt. Das bringt für den Bot direkt keine Verbesserung, aber der User wird es euch danken, falls er mal mit dem „Zurück“-Button im Browser navigiert.

Ein weiterer wichtiger Punkt: die Timeouts. Das ist so ziemlich der unschönste Punkt. Ein User oder auch ein Bot folgt einem Link, der einfach nicht funktionieren will. Hier sollte geprüft werden, warum dies der Fall ist. Wird eine Endlosschleife im CMS ausgelöst, auf die man keine Antwort erhält, oder wurden Links einfach falsch gesetzt, so dass Sie keinen passenden Inhalt bzw. keine richtige Antwort liefern können. Das sieht man gerade bei der letzten URL die zu einem Timeout führt.

Timeouts des Servers

Als letzten Punkt gibt es noch die Verfügbarkeitsübersicht.

Auslastung

Hier sehen wir deutlich, dass es immer wieder zu solchen Spitzen kommt. Gerade in Hinblick auf Ausstrahlungen im Fernsehen führen zu solchen Spitzen, die wiederrum dazu führen können, dass der Server in die Knie geht. Das ist natürlich nicht optimal und der User springt ab. Wenn also mit hohen Besucherströmen zu rechnen ist, sollte überlegt werden einen stärkeren Server anzuschaffen oder die ganze Serversturktur zu überdenken. Mögliche Setups wären Loadbalancer, die die Last auf mehrere Webserver im Hintergrund verteilen, beispielsweise ein DNS Round Robin mit mehreren Webservern oder aber auch ein CDN im Hintergrund, welches die Last an Usern abfängt.

Grundsätzlich sollte hier genau beobachtet werden, ob die bestehende Serverarchitektur den Besucherströmen stand hält. Falls es immer wieder zu Verfügbarkeitsengpässen kommt, sollte auch auf SEO-Sicht genau überlegt werden, ob man nicht die Serverstruktur überarbeitet und care.de performater ausliefert.

Fazit

Alles in allem macht care.de einen soliden Eindruck. Ich denke aber, dass alleine im Bereich „Server“ noch so einiges an Potenzial vorhanden ist. Wichtig wäre, dass man die 302er sowie 404-Fehler der Seite berichtigt. Dann sollte aus SEO-Sicht ein wirklich gute Basis vorhanden sein.

Zum Schluss wollen wir euch nicht den Onpage.org-Starschnitt vorenthalten. Natürlich hat der Server-Bereich dabei den Bizeps zugewiesen bekommen, denn nur mit Server-Power kann man SEO auch stemmen! 🙂

Captain Onpage Starschnitt mit Trust Agents

Weitere Teile der Review-Serie:

Seodeluxe: Keyword-Optimierung mit Onpage.org – Teil 2 von 8
Dennis Farin: Meta-Daten Optimierung mit onpage.org – Teil 3 von 8
Eric Kubitz: Das Inhalts-Care-Paket – Teil 4 von 8
Martin Missfeldt: Was bietet Onpage.org für Bilder? Teil 5 von 8
David Richter: Informationsarchitektur bei care.de – Teil 6 von 8
– (To be announced) Teil 7 von 8
– (To be announced) Teil 8 von 8

Diesen Artikel teilen



Kommentare (6)

  • Witali Antworten

    Vielen Dank für die wirklich ausführlichen Ausführungen zum Bereich Server und zur Nutzung von OnPage.org. Freue mich schon auf die weiteren Teile der OnPage.org Artikel-Serie!

  • Daniel Weihmann Antworten

    Wow! Das war aber mal etwas Interessantes zum Abend … [+1]
    Ich freue mich jetzt schon auf die kommenden 7 Teile und sage einfach mal danke für spitzenmäßige Analyse.

  • Rene Antworten

    Na, das macht Cpt. OnPage doch ein wenig interessanter, auch wenn das Tool nach wie vor ungewohnt teuer ist.

  • Gretus Antworten

    Hallo,

    coole Aktion, mal sehen was die anderen sieben Teile zu zu Tage bringen…

    Grüße

    Gretus

  • Martin Berner Antworten

    Hallo,

    die Seite hier zeigt es recht gut. Es ist sehr farbig bei onpage.org von einer gruppe die sich als „lauter lustige leute“ bezeichnet.

    für jeden, der genre für farben 99 euro im monat ausgeben mag, der kann sich anmelden.

    für einen seriösen seo ist weggeworfenes geld. das bekommt man alles auf englischen seiten kostenlos und kann es dann uneingeschränkt nutzen.

    sehr enttäuschedn projekt, zumal ich immernoch nicht weiss, ist onpage.org ernst gemeint oder eher ein fake?! das geld behalten die tatsächlich, insofern meinen sie es wohl wirklich ernst…schade

    verbrennt euer geld besser woanders!!!

  • Pingback: Die Werkzeuge von Onpage.org – Analyse von care.de « SEO Scene

Hinterlasse einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht.

Wir sind bekannt aus...

  • Werben und Verkaufen
  • Internet World Business
  • lead Digital
  • t3n
  • https://www.trustagents.de/wp-content/uploads/2016/07/5.png
  • Markt und Mittelstand
  • IHK
  • n-tv