SEO Portal

Qualitätsvergleich von Onpage Crawlern

Qualität von Onpage Crawlern
Hinweise zum Artikel
Gastautor: Daniel Wette
Vortrag auf der SEO Campixx 2015
Referenten: Victoria Samarina und Daniel Wette

In bisherige Tests von Onpagetools wurden häufig nur Features, Preise und UX bewertet. Ein solcher Vergleich ist als Überblick sicherlich auch sinnvoll, scheitert aber teilweise an den unterschiedlichen Ausrichtungen der Tools. So kann ich ein „Audisto“ (ehemals strucr) beispielsweise überhaupt nicht mit SISTRIX vergleichen. In unserem Test haben wir uns daher nur den Teil der Tools angesehen, bei welchem sie alle vergleichbar sind. Dem Crawler.

Planung und Vorbereitung

Als aller erstes haben wir in einem Brainstorming uns alle möglichen Sachen überlegt, mit welchen ein Crawler auf einer Internetseite zurechtkommen muss. Diese lassen sich grob in die Bereiche URL Normalisierung, Redirects, Relative Verlinkungen und Nofollow untergliedern. Hinzu kamen noch einige Einzeltests zu Themen wie robots.txt, Mentions, Javascript etc.

Zu jedem dieser Bereiche sind dann verschiedene Tests ausgearbeitet worden, welche wir alle in einem Testprojekt umgesetzt haben. Jetzt konnte der eigentliche Test endlich starten. Verglichen haben wir die folgenden Tools:

Audisto (ehemals strucr), Seoratio Tools, Deepcrawl, Botify, crawl.me, Onpage.org, OnpageDoc, SEORCH, SISTRIX, Searchmetrics, XOVI und Screaming Frog.

Der eigentliche Crawler-Test

Jedes Tools hat hierfür das Testprojekt gecrawlt. Wir haben dann die Daten der gecrawlten Seiten aus den Tools exportiert (ein Hoch auf die Tools mit Export-Funktionen!) und in einer großen Excel-Tabelle mit den Sollwerten verglichen. Bei vielen der Tests mussten wir ein negatives Ergebnis aber nochmals im Tool verifizieren. So werden von einigen Crawlern beispielsweise per „Nofollow-Attribut“ Verlinkte Seiten trotzdem gecrawlt. Im Tool wird diese Information aber entsprechend aufbereitet und auch so verarbeitet.

Obwohl unser Testprojekt mit rund 150 Seiten recht übersichtlich war, waren die Datenmengen, welche wir nun manuell auswerten und verifizieren mussten doch viel größer, als wir annahmen. Da der Vortrag aber bei Marco eingereicht war mussten wir da nun durch.

Für die Finale Auswertung haben wir verschiedene Einzeltests zu Testgruppen zusammengefasst. So wurde dann beispielsweise aus den 8 Einzeltests zum Thema relative Verlinkungen eine Testgruppe. Wenn ein Tool bei einem der Tests durchgefallen war, war damit die gesamte Testgruppe durchgefallen. Durch dieses Aggregieren haben wir insgesamt aber eine faire Vergleichsbasis geschaffen.

Auffälligkeiten

Besonders viele Schwierigkeiten hatten die Tools mit der Normalisierung von doppelten Slash innerhalb von einer URL (http://www.test.de/test//test.html). Dies haben nur die Crawler von audisto und von SISTRIX entsprechend normalisiert.

Auch die Erkennung von Weiterleitungs-Ketten können die wenigsten Tools. Es werden zwar meistens die einzelnen Weiterleitungen erkannt und auch gecrawlt. Hier dann aber abhängig vom Tool in unterschiedlichen Tiefen. Eine Ausweisung als Redirect-Kette bzw. eine Analyse dieser Kette erfolgt nicht. Dies ist einem vielleicht etwas gemeinen Test aufgefallen in welchem wir bei einer Weiterleitungskette die letzte Weiterleitung dann auf die erste gesetzt haben und damit einen Loop erzeugten. Diesen Test hat ausschließlich audisto noch erfolgreich bestanden.

Zweidrittel der Tools sind auch am Themenblock der Normalisierung gescheitert. Erste erneute Crawls nach dem Test zeigten aber bereits, dass Toolanbieter sich um die Probleme kümmern um sie zu beheben.

Ein letzter auffälliger Punkt war, dass knapp 60% der Tools den x-robot Tag „nofollow“ ignorieren und auch in den Analysen nicht berücksichtigen.

Das kein Tool alle Tests bestanden hat, zeigt wie komplex das Thema Crawling ist. Unser Test-Projekt bestand natürlich überwiegend aus Tests, welche in normalen Projekten nur eher selten vorkommen. Damit ist die Fehlerquote der Tools in der „freien Wildbahn“ eventuell geringer als in unserem Versuch. Aber es zeigt auch, dass es Qualitätsunterschiede gibt, welche man bei der Toolauswahl durchaus berücksichtigen sollte. Und es gibt viele weitere Szenarien im Code von Webseiten, die selbst in umfangreichen Brainstormings einfach nicht ans Licht kommen.

Die Resultate

Im Gesamtergebnis konnte Audisto sehr überzeugend den ersten Platz erzielen. SISTRIX hat mit den zweiten Platz gezeigt, dass man auch als „Allround“ Tool eine hohe Crawlingqualität erreichen kann und auch OnPage.org, Seoratio Tools und der Screaming Frog welche sich den dritten Platz in unserem Test teilen konnten insgesamt mit sehr guten Ergebnissen überzeugen.

Onpage Crawler Auswertung
Onpage Crawler Auswertung – Klicken für Vollbild

Onpage-Crawler Gewinner

!Ende vom Gastartikel

Danke

Daniel Wette, Betreiber von RankingCoach für die Bereitstellung der Präsentation und des Gastartikels. Ich weiß wie aufwändig eine solche Auswertung ist und finde es toll, wenn sich jemand diese Zeit nimmt und es so objektiv wie möglich durchführt.

Rohdaten herunterladen

Du kannst über nachfolgendes Formular die Rohdaten aus dem Test anfordern. Diese werden dir nach der fertigen Anmeldung bereitgestellt. Weitere E-Mails folgen im Anschluss nicht. Es ist also völlig in Ordnung wenn man sich danach wieder austrägt.

Ich würde mich freuen wenn du diesen Artikel auf Facebook & Co. weiterleiten würdest. Die entsprechenden Buttons kennst du ja.

Mein Fazit

Teuer ist nicht immer gut und mit niedrigen Preisen trifft man auch nicht immer die beste Wahl. Viele Probleme die dieser Test aufdeckte, bemerkt man in der Oberfläche der Tools gar nicht. Sie bleiben für den Anwender oft unentdeckt. Und das ist das Problem. Denn Fehler die auf der Webseite vorliegen, werden nicht übermittelt und können deshalb nicht durch den Seitenbetreiber behoben werden. Gerade dafür aber – also zur Behebung von Fehlern – abonniert man die oft kostenintensiven Tools.

Die genaue Rangliste der Tools ist in der Präsentation zu finden und die Rohdaten sprechen auch für sich. Es bleibt also die Erkenntnis, sich genau überlegen zu müssen welches Tool den eigenen Ansprüchen gerecht wird und was man will. SISTRIX Toolbox, Onpage.org, SEORatio und Audisto sind die Gewinner der Auswertung in Bezug auf reine Online-Tools.

Ich hoffe natürlich darauf, dass die Toolanbieter die Resultate nutzen um ihre Crawler entsprechend zu verbessern. Teilweise sind es ja wirklich notwendige Verbesserungen!

Du möchtest aktuelle Informationen rund um Online-Marketing? Jetzt kostenlos eintragen.
Über eisy 523 Artikel
Hi, ich bin eisy (Soeren Eisenschmidt) und blogge seit 2007 auf eisy.eu. Meinen Weblog fülle ich bevorzugt mit Fachthemen rund um SEO, Affiliate-Marketing und relevanter Software. Regelmäßig ist mein Wissen bei Print- und Online-Magazinen gefragt.

14 Kommentare zu Qualitätsvergleich von Onpage Crawlern

  1. Ich hatte schon mit Daniel darüber diskutiert und möchte das nun nochmal an dieser Stelle festhalten: Die Thematik der Normalisierung kann man von zwei Perspektiven sehen:
    – Google-only View
    – Code Quality View

    Wenn man rein die Google-Brille aufzieht, ist der Test whrs richtig – zumindest kann man es nicht via inurl-Abfragen widerlegen.

    Beim OnPage.org Crawler haben wir die Code-Quality Brille. Wenn ich als Webmaster einen Coder beauftragt habe, der Links „HTTP://WWW.BEISPIEL.com/index.PHP“ schreibt, dann will ich das wissen. Ich finde es in einem solchen Szenario nicht zielführend, wenn ein Tool das dann runter normalisiert und den Anwender in den Glauben lässt, dass da nen Coder ist, der weiß was er da treibt. Gleiches gilt für „Duplicate Slashes“. Wenn der Coder relative Links so setzt, dass am Ende Duplicate Slashes rauskommen, will ich das wissen, damit ich ihm erklären kann wie es richtig geht, weil da ja scheinbar irgendwas falsch verstanden wurde – dass Google das dann evtl auto-corrected ist da für mich zweitrangig.

    Relative Links hat der OnPage.org Crawler afaik alle richtig erkannt (6/7), bis auf einen Fall wo eine URL an mehreren verschiedenen Stellen eine relative Angabe hat. Dieser Fehler ist bereits im Code-Review und wird whrs morgen ausgemerzt sein (Abseits davon: Ist bisher bei keinem Kundenprojekt von Belang gewesen, sonst hätten wir das schon vorher bemerkt). Die Graphik liest sich so, als würde unser Crawler keinerlei relative Links unterstützen. Das stimmt also so nicht.

    Zu guter Letzt noch die Redirect-Ketten die bei uns angekreidet werden: Der Crawler hat diese korrekt erfasst und hat alle URLs gecrawlt. Was es bei uns nicht gibt, ist ein „Weiterleitungs-Ketten-Report“, stattdessen bieten wir den Report „Status Codes von Weiterleitungszielen“, darüber kann man diese Ketten offenlegen (ggf. über Listen-Filter auch bis in die Dritte Ebene hinein). Grund dieser Lösung ist, dass bereits ein Doppel-Redirect schlimm genug ist, da dabei genug Link-Equity flöten geht. Sprich ich will als SEO eigentlich sowieso möglichst alle Redirects loswerden (weil dabei unnötig Link-Equity verloren geht) und Doppel-Redirects erst recht. Alles was darüber hinaus geht ist m.E. irrelvant, weil auf vorherigen Ebene zu lösen.

    Wenn man Redirectketten analysieren will, muss man eigentlich auch Canonicals, Meta-Redirects und JS-Redirects da mit einbeziehen (Redirect->Canonical->JS Redirect->Redirect = Weiterleitungskette von 4), denn das wäre aus SEO Sicht die wichtigste Information. Das würde allerdings die Benutzer eher verwirren, denn es passt nicht zum klassischen Wording „Redirect-Kette“, die noch aus der Zeit stammt, als es keine Canonicals gab. Daher reden wir stattdessen von Status Codes und deren Zielen und bieten dann den Benutzern die Möglichkeit via Filtern ihre Analysen anzupassen. Warum der Test jetzt die Erkennung von oldskool Header-Redirect-Ketten als das Must-Have ausweist, bleibt mir unverständlich. Wir werden aber zu diesem Thema die Kunden befragen und ggf. einen Extra Report „Vererbungsketten“ anbieten – sofern Bedarf besteht (auch hier: Hat sich bisher niemand beschwert, dass es nicht explizit angeboten wird).

    • Eines darf man natürlich bei dem Test nicht vergessen. Er war darauf ausgelegt zu prüfen, wo Crawler nicht weiterkommen oder gar nicht klarkommen. Also bewusst Szenarien gewählt die eventuell sogar niemals bei einem Toolanbieter ankommen würden. Sprich, auf keiner Webseite tatsächlich mal eintreten und wenn, ist die Wahrscheinlichkeit ja noch geringer, dass diese Webseite in einem der Tools landet.

      Und der nächste Punkt ist die Unterscheidung von Backend und Frontend. Diverse „Fails“ aus dem Test sind ja auch nicht schlimm, wenn das Tool diese dem Nutzer im Frontend dann kommuniziert.

      Zuletzt stehen wir aber bei Tools und Tests immer vor einem Problem: Vergleichbarkeit. Die gibt es nur an sehr wenigen Schnittpunkten und je mehr Tools im Test desto schwieriger. Dennoch gibt es hier auch Fails bei manchen Tools die nun wirklich abgestellt werden sollten. In den Funktionen der Tools wird die Vergleichbarkeit dann noch schwieriger. Hatten wir ja alles schon erlebt.

      • Naja, gecrawlt haben wir doch alles (bis auf den einen relativen Link) trotzdem wird OnPage.org da 5 Fehler attestiert. So gesehen, gings doch eher darum, das eine Tool zu küren, dass dieses extrem subjektive Testset mit den subjektiven gewünschten Resultaten am „Besten“ analysiert. Das unser Parser dabei dann zum Beispiel die meisten Metriken aus den Quellcodes ausliest, wird nicht „bewertet“ und dass unsere Interfaces die meisten Filtermöglichkeiten bieten (und damit die detailreichsten Analysen) auch nicht.

        Es steht Crawler-Test drüber und es gibt angeblich den „einen“ Gewinner. Da muss ich leider aus Sicht des SEO und aus Sicht eines Toolbetreibers deutlich widersprechen. (Dabei will ich nicht abstreiten, dass Strucr nen wunderbaren Job macht – aber es ist halt kein richtiger Test, als der er angepriesen wird).

  2. Danke für diesen sehr interessanter Test!
    Die Auswertung zum Thema URL-Normalisierung irritiert mich jedoch ein wenig. Der Crawler soll eine (falsche) URL ja nicht „normalisieren“ (z.B. ein leeres Verzeichnis bzw. doppelten Slash) ignorieren, sondern eine entsprechende URL im Report genau so melden wie sie ist. Am Beispiel Screaming Frog: Dieser normalisiert ein // nicht, und ich kann fehlerhafte URLs im Report erkennen.

  3. Ich hab mir lange überlegt ob ich hierzu was schreibe und ich muss es einfach tun weil Daniel einen sehr fairen und technisch einwandfreien Test aufgesetzt hat und ich nicht verstehen kann, dass man ihn dafür kritisiert.

    Es gibt beim bemängelten Crawlverhalten nur genau eine Sicht (https://tools.ietf.org/html/rfc3986). Wir lagen dort an einer Stelle falsch und haben den Fehler in wenigen Stunden behoben und würden jetzt 100% bei dem Test erzielen. Über Dinge die in einem Standard festgelegt sind kann man einfach nicht diskutieren und deshalb muss man URLs zu einem gewissen Grad normalisieren weil es einfach so festgelegt ist (https://tools.ietf.org/html/rfc3986#section-6.2). Natürlich hält das aber nicht davon ab auf potentielle Probleme und Fehler im Code hinzuweisen. Das tut man aber eben nicht durch fehlerhaftes Handling, sondern durch zusätzliche Informationen die man gesondert bereitstellt. Auch beim Handling von Redirects sollte man sich natürlich an die Empfehlungen halten und Loops erkennen (https://tools.ietf.org/html/rfc2616#section-10.3).

    Viele Grüße
    Tobias

    • Hey Tobi,

      das ist ja genau der Punkt. Laut RFC muss keine Normalisierung vorgenommen werden („This section describes various methods that may be used to compare URIs, the trade-offs between them, and the types of applications that might use them.“). Schema + Domain sind case-insensitive, sprich es ist legitim, dass ein Crawler (!) http://www.DOMAIN.com abruft, weils der Standard erlaubt. Dass man das im Interface dann mit alternativen Schreibweisen gruppiert, ist ja eine Interface-Frage und selbst das ist optional (wenn man z.B. den User explizit für verschiedene Schreibweisen sensitiveren will).

      Sie _kann_ gemacht werden. Wir haben uns an manchen Stellen bewusst dagegen entschieden (weil Focus auf Code-Quality – s.o.). Das Prädikat „failed“ in dem obigen Graphen suggeriert, dass es ein Fehler ist, es nicht zu tun. Das ist meine Kritik, denn der Otto-Normal-User weiß whrs. noch nicht mal um der Tiefe der Diskussion, geschweige denn, dass es eher hypothetische Szenarien sind. Wer den Artikel überfliegt (sich nur Graphen anschaut), bekommt dennoch einen klaren Gewinner serveriert, basierend auf Daten die teilweise kein eindeutiges richtig/falsch zulassen.

      Wir hatten ebenfalls einen Parsing Fehler (mehrfach-relative Angaben an verschiedenen Stellen der URL), den wir umgehend behoben haben. So gesehen ist es ja gut, dass man mal ne Fachdiskussion hat. Dennoch finde ich es etwas schade, dass man Lesern suggeriert, dass Fehler gemacht werden, wenn da formal keine sind. Was man bei uns hätte kritisieren können, wäre, dass wir es nicht optional anbieten, eine Normalisierung vorzunehmen. Das wirds in Zukunft geben, so dass der User entscheiden kann, wie er es haben möchte.

      Weitere Kritik ist der Einbezug eines „Redirect-Reports“, der ja nichts mit dem Crawling an sich zu tun hatte. Und dass auch unser alternativer Ansatz hierfür nicht als „Vergleichbar“ gewertet wurde.

      Long story short: Andere Überschrift und anderes Wording im Graphen und ich hätte nichts gesagt. Geht mir null darum Daniel oder gar dich zu kritisieren – will nur den Kontext klarstellen.

      • Hi!

        Ich glaube wir sind uns einig, dass die rfc3986 und deren Auslegung hier der Gegenstand der Diskussion sind.

        Ziel der rfc3986 ist es, eine kompakte Zeichenkette festzulegen, die eine abstrakte oder physischen Ressource identifiziert. Darüber hinaus geht es darum, Verfahren festzulegen wie z.B. relative Verweise aufgelöst werden.

        A Uniform Resource Identifier (URI) is a compact sequence of
        characters that identifies an abstract or physical resource. This
        specification defines the generic URI syntax and a process for
        resolving URI references that might be in relative form, along with
        guidelines and security considerations for the use of URIs on the
        Internet.

        Der ganze Normalisierungsteil zielt darauf ab, äquivalente URIs zu erkennen ohne dass ein Zugriff auf die Ressourcen nötig ist.

        One of the most common operations on URIs is simple comparison:
        determining whether two URIs are equivalent without using the URIs to
        access their respective resource(s).

        Die Normalisierung ist optional, da je nach Zweck ggf. Kompromisse bei der Erkennung von äquivalenten URIs gemacht werden können.

        URI comparison is performed for some particular purpose. Protocols
        or implementations that compare URIs for different purposes will
        often be subject to differing design trade-offs in regards to how
        much effort should be spent in reducing aliased identifiers.

        Die meisten HTTP-Clients (auch Browser und Crawler) machen hier keine Kompromisse und setzen alle Vorschläge für die Erkennung von äquivalenten URIs um – und vermeiden damit die Zugriffe auf die Ressourcen.

        Eine Normalisierung schließt übrigens nicht aus, dem Nutzer trotzdem alle Informationen im Bezug auf die Code-Quality zu geben, es wird nur deutlich aufwändiger. Wir haben dafür eine Vielzahl von Hints sowie einen extra Report für Similar URLs. Wir haben hier sehr viel Zeit investiert und hunderte Testcases geschaffen, um entsprechend dem Ziel der rfc3986 zu normalisieren und trotzdem die Probleme aufzeigen zu können.

        Abschließend möchte ich noch anmerken, dass sich ohne Normalisierung eine Vielzahl von nachgelagerten Problemen ergibt. Ohne saubere Normalisierung hat man mit inkorrekten Linkcountern für Ressourcen zu kämpfen und produziert damit auch inkorrekte Metriken z.B. bei einer Berechnung von internem Pagerank. Zusätzlich gibt es aufgrund der Uneindeutigkeit bei fehlender Normalisierung Fehler bei der Erkennung von doppelten Inhalten.

        Viele Grüße
        Tobias

  4. Tobias, Du hast es auf den Punkt gebracht. Wenn man schon als teuerster Toolanbieter selbst in seinem Spezialbereich nicht gewinnt, sollte man besser weniger kritisieren und einfach sein Tool besser programmieren!

  5. Hey Guys,

    First of all, apologies for being the only one to reply in English, you can blame my German teacher 😉

    Thanks for including us in the test above, I only spotted the post yesterday evening and have just had a chance to review today.

    We always look into any reported bugs and one of the above tests did discover an issue with our relative linking, which we have just fixed up. So thanks for the tests.

    On the other fails, these are a little more subjective –

    * Duplicate slashes is an interesting one, and I won’t add to the above comments 😉
    * The percent encoding bug should be fixed, I am not sure what version you used in the test above (but it was an issue in older versions).
    * For redirect chains and loops, I think you must have left the default setting at ‚5‘ redirects to follow (which is about where Google get bored in our tests). You can adjust the ‚max redirect fo follow‘ in the ‚advanced‘ tab of the spider configuration. You’d see we follow all the redirect chains and identify the loops, which are on the 10th redirect 😉

    So, based upon the above I think one issue was identified, so appreciate the tests.

    Cheers.

    Dan (@screamingfrog)

1 Trackbacks & Pingbacks

  1. Der SEO-Blog-Wochenrückblick KW 12

Kommentar hinterlassen

E-Mail Adresse wird nicht veröffentlicht.


*