SEO-Alerting mit Testomato

Alerting im SEO ist immer ein ziemlich anstrengendes, aber wichtiges Thema! In diesem Blogpost wollen wir Euch unsere Herangehensweise vorstellen und wie wir das Tool Testomato dafür zielgerichtet einsetzen.

Alerting im SEO: Das Ausgangsproblem

Vermutlich kennt es der SEO so gut wie kein anderer: Endlich werden die Anforderungen an die Plattform umgesetzt – die Freude ist groß! Bis die Optimierungen zwei Wochen später beim nächsten Deployment wieder rausgeflogen sind. Warum? Naja, das hatte man halt nicht so auf dem Schirm… Verstanden, wozu man es braucht, hat es sowieso keiner… dass man jetzt auch noch extra den SEO fragen muss, wenn man etwas an der Seite ändert, ist sowieso immer voll nervig, und eigentlich hat das Ticket gar nix damit zu tun gehabt… Viele Gründe, ein Fazit: Der SEO muss sich selbst darum kümmern, dass seine Optimierungen dauerhaft vorhanden bleiben und darauf eingestellt sein, dass es sonst keiner merkt, wenn wichtige Basics verloren gehen – naja, zumindest so lange, bis der Traffic ausbleibt. Furchtbarer Zustand, wenn alle denken, dass das Deployment perfekt lief, aber eigentlich bricht die Plattform organisch gesehen langsam zusammen. Ok, das war jetzt alles auch etwas sehr dramatisch formuliert, aber Ihr kennt sicherlich die Probleme, die sich vor allem in der agilen Entwicklung ergeben:

• die Seite ist im ständigen Wandel: kurze Sprintintervalle von z. B. zwei Wochen sorgen für permanentes Risiko
• der SEO wird nicht in alle relevanten Anforderungen involviert, da der anfordernde Stakeholder die SEO-Relevanz nicht erkennt
• bei der Qualitätssicherung von nicht direkt SEO-relevanten Themen wird der SEO übergangen, obwohl für ihn bereits eingerichtete Optimierungen verloren gehen
• der projektverantwortliche Entwickler/SEO/Projektmanager/etc. wechselt, was immer zu einem gewissen Know-how-Verlust führt – „Macht dieses extra Titel-Feld überhaupt Sinn oder kann diese Anpassung weg?!“
• SEOs und Entwickler sind schlussendlich auch nur Menschen und übersehen Fehler, gerade wenn Webseiten durch die ständigen Anforderungen immer komplexer und vielfältiger werden. Es ist kaum möglich, bei der kleinsten Änderung jedes Merkmal auf der gesamten Plattform zu prüfen.

Die Konsequenzen sind oftmals ziemlich veheerend. Wenn die Reichweite in Suchmaschinen sinkt, folgen die Umsätze in der Regel gleichermaßen. Und während schnelle Korrekturen oftmals das Schlimmste verhindern, sind dauerhafte Abweichungen (ein bis zwei Wochen) auch durchaus dazu fähig, der organischen Performance einen dauerhaften Knick zuzufügen. Einen recht spannenden Fall hat Pascal Landau dieser Tage bei Sistrix beschrieben: „Wie uns dieser seltsame Bug 30% Sichtbarkeit gekostet hat„. Auch hier konnte eine schnelle Korrektur das Schlimmste verhindern.

Was wir dank SEO-Alerting bemerken und schnell beheben können

Die Klassiker sind natürlich alle SEO-Elemente, die man nicht direkt auf der Seite sehen kann. Diese gehen schnell mal bei einem Release verloren und man bemerkt es erst mal nicht. Beispiele sind hier:

• Schema.org-Auszeichnungen waren nicht mehr vorhanden
• href-lang-Auszeichnungen waren nicht mehr vorhanden oder plötzlich fehlerhaft
• Descriptions hatten alle denselben Inhalt
• Canonical-Tags zeigten alle auf die Startseite
• Seitenweite noindex-Auszeichnungen, die so vom Testsystem übernommen wurden
• Robots.txt aus dem Testsystem wurde übernommen
• Title-Tags wurde alle auf CMS-Standard gesetzt und entsprachen der h1

Jeder dieser Fehler hätte fatale Auswirkungen auf die Reichweite bei Google für unsere Kunden gehabt. Da wir diese Fehler aber direkt bemerkt haben, konnten diese fatalen Auswirkungen verhindert werden. Die Nennung in der monatlichen „SISTRIX Wall of Shame“ blieb also erspart und der Umsatz erhalten. Es gibt aber auch andere Probleme, die durchaus direkt auf der Website sichtbar sind, oft aber ebenfalls zunächst unentdeckt blieben, beispielsweise:

• Paginierung war nach einem Release entfernt (also die Links im HTML).
• Alle Textmodule auf Kategorien hatten den selben Text.
• Produktdetailseiten hatten keine Navigation mehr.
• Alle Kategorientexte waren verschwunden.
• Statt einer Sperrung der Kommentarfunktion zu bestimmten Uhrzeiten (diese müssen im Newsbereich z. T. moderiert werden) hatten die Kommentare regelmäßig Feierabend und waren ab 18.00 Uhr bis morgens verschwunden.

Auch hier hilft das Monitoring natürlich weiter. Und jenseits von SEO werden hier massive Probleme der Usability von Kunden direkt erkannt und umgehend behoben. Zusammengefasst trägt der SEO also viel Verantwortung, ein hohes Risiko und ist unter Umständen nicht immer auf Platz 1 in der Rangfolge, wenn es um die Priorisierung im nächsten Sprint geht. Dem verantwortungsbewussten SEO bleibt also keine andere Wahl, als sich selbst um ein sauberes Monitoring und Alerting mit seinen eigenen Anforderungen zu erstellen. Klug angestellt lässt sich diese Selbstschutzmaßnahme auch für die Verbesserung des eigenen Standings nutzen: Der SEO unterstützt die IT bzw. den IT-Dienstleister in der Qualitätssicherung, und Fehler werden schließlich nicht bewusst begangen. Eine frühe Erkennung führt meist dazu, dass die Entwickler das Problem schnell reproduzieren können und der Bugfix schnell durchgeführt ist. Alternativ kann die Entscheidung für ein Rollback zeitnah getroffen werden. Die Komplexität der Aufgabe lässt sich einfach schneller einschätzen. Zum anderen wird man inhouse erleichtert sein: Denn erkennt man Fehler frühzeitig, ist klar, dass man es mit einem Bug zu tun hat. Nach 2 bis 3 Wochen muss man vermutlich wesentlich häufiger darüber diskutieren, ob tatsächlich ein Bug vorliegt oder es sich um einen Change Request handelt; Letzterer ist immer mit Kosten verbunden.

Tägliches SEO-Monitoring und Alerting

Grundsätzlich stellt sich bei einem Alerting oder Monitoring erstmal die Frage nach der Prüffrequenz. Wir bei [get:traction] unterscheiden hier zwischen Alerting, Monitoring und Reporting. Im Falle eines Setups mit Testomato findet man sich nach dieser Klassifikation klar im Bereich des Alertings wieder: Hier erfolgt eine mindestens täglich durchgeführte Überprüfung von erfolgskritischen Merkmalen einer Seite, also von IT-Hygienefaktoren, bis hin zu Optimierungen an der Informationsarchitektur, die proaktiv über Probleme informiert. Da die Betonung auf erfolgskritisch liegt, sollten wir das noch etwas detaillierter eingrenzen. Erfolgskritisch kann sich hier in zwei Ausprägungen zeigen:

1. Seitenweite Fehler, die im Einzelnen erst mal nicht problematisch sind, aber in der Menge zu großen Problemen führen können.
2. Fehler auf einer expliziten Seite, die für sich genommen schon erfolgskritisch für das Unternehmensziel ist (findet sich häufig bei kleinen Onlineshops, die vor allem mit ein bis zwei Produktkategorien besonders gut performen).

Wichtig ist es daher, den Fokus nicht aus den Augen zu verlieren, denn tägliche oder stündliche Überprüfungen können auch täglich oder stündlich eingehende E-Mails mit sich bringen. Wenn diese aber keine wirkliche Relevanz haben, fängt man irgendwann an, sie zu ignorieren, und der eigentliche Sinn des Systems wird hinfällig.

SEO-Alerting-Setup: Methodische Restriktionen und Herangehensweise

In den seltensten Fällen ist es möglich und sinnvoll, täglich die ganze Seite zu crawlen und den Crawl mit einem schnellen Überblick auszuwerten. Technische Ressourcen sowie die Tatsache, dass wir dann meistens im „Pull“-Bereich sind − also uns die Informationen selbst beschaffen müssen −, sorgen im Alltag dabei für Probleme.

Segmentierung der Seite nach Seitentypen

Daher lohnt sich meist ein qualitativer Ansatz, der auf einem möglichst vollständigen und breiten Set an Seiten bzw. Templates basiert. Denn wie oben beschrieben gilt: Erfolgkritisch sind meist Seitenweite-Fehler, die sich durch einen Seitentyp bzw. ein Template hindurchziehen. Und habe ich einen Fehler auf einer Seite, dann ist dies meist auch auf allen anderen der Fall. Eine Auswahl von zwei bis drei Seiten pro Seitentyp ist daher für ein Alerting völlig ausreichend. Am Beispiel eines Publishers könnte die Auswahl an Seiten wie folgt aussehen. Besonders wichtig ist es dabei, nicht immer nur auf die offensichtlich wichtigen Seitentypen und -arten zu achten, sondern auch auf die, die eigentlich gar keine Relevanz für die SEO-Performance haben, aber eben genau deswegen nicht im Weg sein dürfen. Ein typisches Beispiel dafür sind Paginierungen oder Seiten der internen Suche. Einen Zweck in der SEO-Performance haben diese Seitentypen in der Regel nicht, aber genau deswegen gibt es dennoch klare SEO-Anforderungen an sie. Ob das nun eine saubere Paginierung via rel=prev,next, ein Canonical oder ein noindex sein soll, ist erst mal Geschmackssache oder eine Frage der Strategie. Aber diese Anforderungen müssen vorhanden sein und geprüft werden, da die Gesamtperformance der Seite durchaus in Gefahr sein kann. Man kommt also nicht darum herum, sich wirklich intensiv mit der eigenen Seitenstruktur zu beschäftigen und neben den einzelnen Seitentypen auch weitere SEO-relevante Dokumente, jeden einzelnen Get-Parameter sowie auch einige Sonderfälle stetig zu betrachten und zu prüfen. Sonderfälle können z. B. auch der dauerhafte 410-Status von gelöschten Inhalten sein oder auch die einfache Prüfung, ob die 301-Redirects aus dem letzten größeren Umzug auch nach einem halben Jahr noch vorhanden sind. All das kann sehr viel Zeit sparen, wenn „plötzlich“ die organische Performance mal wieder nach unten geht und man binnen kürzester Zeit erste Analysen und potentielle Gründe liefern muss.

SEO-relevante Merkmale auf Seiten- und Template-Ebene

Seite segmentiert? Perfekt! Doch so stellt sich direkt die Frage nach den Merkmalen, die man überwachen sollte. Auch hier lohnt es sich, zwei Schritte zurückzugehen und zu überlegen, welche einzelnen Elemente insbesondere aus SEO-Sicht erfolgskritisch sind und möglicherweise über die einfachen Indexierungsanweisungen hinausgehen. Letztendlich lassen sich fast alle Merkmale, für die man optimiert hat, in kleine, überwachbare Einheiten zerlegen. Von der angereicherten H2-Überschrift über die Breadcrumbs zu den Kategorietexten, Linkboxen und dem Hauptmenü (ja, auch das kann plötzlich verschwinden…). Entfällt eines dieser Merkmale bei meinen zwei bis drei ausgewählten Seiten, ist es wahrscheinlich, dass ein seitenweiter Fehler vorliegt. Und immer daran denken − das sollte ich pro Ableger bzw. Host meines Systems durchführen. Auf diese Weise komme ich schnell von meiner Desktopversion über die mobile Variante hin zu meinen AMP-Seiten. Alle mit anderen Anforderungen, die es zu überwachen gilt.

Testomato im SEO-Alerting

Testomato ist ein Tool, das genau für unseren Anwendungsfall gebaut ist − Testing und Alerting in kurzen Intervallen (Uptime alle 15 Sekunden und individuelle Kriterien alle 5 Minuten). Um jetzt nicht noch ausufernder zu werden und einen kompletten Walkthrough zu verfassen, kurz die Kernfeatures und ein paar Gedanken, die Ihr Euch bei der Einrichtung machen solltet. Ansonsten gibt es eine 30 Tage Testversion − einfach mal reinschauen, das Tool ist sehr leicht zugänglich.

• • Ihr könnt den User-Agent einstellen, also ruhig direkt auf „Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)“ gehen – Ihr wollt ja vorrangig wissen, wie Google Eure Seite sieht.
  • Der Prüfintervall sollte mit Bedacht ausgewählt werden. Unsere Erfahrung hat gezeigt, dass je nach Kunde ein Intervall von 5 Minuten etwas zu „nervös“ sein kann. In der Regel reicht auch eine Stunde als Prüfungszeitraum. Denkt daran: false-positives müssen auch erstmal als solche entlarvt werden und erzeugen Arbeit.
  • Testomato erlaubt Euch den HTTP-Header zu prüfen! Testing auf Indexierungsanweisungen im Header, Komprimierung mit gzip oder Caching-Anweisungen sind also ohne Weiteres machbar!
  • Ihr könnt Seitengruppen anlegen, die alle die gleichen Eigenschaften aufweisen. Das spart Zeit und erleichtert das Leben. Allerdings muss man hier wirklich aufpassen, dass nur Merkmale angelegt werden, die wirklich überall gleich sind oder nur generisch geprüft werden sollen. Identisch (zumindest über ein CMS hinweg) ist in der Regel das Caching oder auch die Tracking ID. Generisch prüfen wir z. B. das Vorhandensein von OG-Tags, also Social-Media-Metadaten. Wenn wir schon einmal die Seiten auseinandernehmen, prüfen wir das direkt mit. Für die Inhalte sind wir in der Regel als SEO jedoch nicht verantwortlich und wissen zudem nicht, wie häufig hier Anpassungen vorgenommen werden. Verloren gehen sollten sie jedoch nie. Ein weiterer spannender Fall sind die Indexierungsanweisungen im HTTP-Header. Diese werden in den seltensten Fällen dort platziert. Daher prüfen wir diese in der Regel direkt mit ab (Plugins u. Ä. haben bei der Prüfung des Headers immer mal Probleme…), sofern wir hier nicht explizit andere Anforderungen gestellt haben. Die Anforderungen sind natürlich beliebig erweiterbar und immer im Wandel – wenn Ihr selbst noch wichtige Ergänzungen habt, schreibt Sie ruhig in die Kommentare!

• Ihr habt die Auswahl zwischen den folgenden Feldern und Vergleichsoperatoren (siehe Screenshot), Regex und XPath inklusive ♥, also wirklich mächtig in Regelerstellung!
• Werdet auf Seitenebene unbedingt spezifisch! Prüft also nicht, ob ein H1-Tag vorhanden ist oder die Breadcrumbs als div noch existieren, sondern auch, ob der Inhalt stimmt! Alle Anpassungen, die hier mal durchgeführt wurden, sind mitunter zunächst kein Standard im CMS und stehen daher bei jedem Update oder Deployment unter besonders hohem Risiko. Wir prüfen hier tatsächlich auch ganze Textabsätze und Überschriften-Gerüste, um das Fehlerpotential kleinzuhalten.

Das waren soweit einige wichtige Überlegungen und Infos, die man bei der Einrichtung und Nutzung von Testomato beachten sollte. Wie gesagt, eine genaue Detailanleitung habe ich mir an dieser Stelle erspart. Solltet Ihr hier mehr Details wünschen oder Fragen dazu haben, lasst es mich wissen!

Alerting mit Testomato – Einschränkungen

Wie Euch sicherlich klar geworden ist, hat ein entsprechendes Alerting − das liegt jetzt nicht nur an Testomato − ein paar Einschränkungen. Wir fixieren an dieser Stelle Merkmale und Optimierungen, die wir kennen und deren Zustand uns bekannt ist. Was wir damit allerdings nicht abdecken können, ist die Frage, was alles so auf meiner Seite stattfindet, was ich nicht vorhersehen kann, beispielsweise massenhaft falsche Verlinkungen, eigenartige Seitenfragmente, die vorher nicht bekannt waren, oder auch Duplikate und interne Redirects. Hierfür braucht es ein sauberes Monitoring bzw. ein regelmäßiges Crawlen der Seite inkl. einer stetigen Auswertung der Fehlermeldungen innerhalb der Google Search Console. In meinem Webinar bei OMT habe ich etwas über die Optionen und Möglichkeiten in diesem Kontext gesprochen. Wir werden dazu sicherlich auch in den kommenden Monaten noch den ein oder anderen Beitrag schreiben.

Fazit

Ein gut funktionierendes Alerting ist bei größeren Projekten und Webseiten kaum verzichtbar. Auch wenn die initialen Aufwände wie die Segmentierung und Definition von jedem einzelnen Merkmal etwas aufwändig sind, kann dadurch einiges an Budgets gespart und Umsatzausfälle vermieden werden. Zudem zwingt einen die Einrichtung dazu, sich Gedanken über Seiten und Anweisungen zu machen, die man vielleicht sowieso mal dringend überdenken sollte. Testomato ist für diesen Anwendungsfall ein sehr mächtiges Tool und ermöglicht einen Rundumblick auf viele Merkmale und Felder der Seite. Das Preis-Leistungs-Verhältnis ist in diesem Segment sicherlich Spitze und kann sich daher wirklich sehen lassen. Habt Ihr noch Fragen zum Vorgehen oder Testomato an sich? Schreibt mir oder stellt die Frage am besten direkt in den Kommentaren, vielleicht wollte sie ja auch jemand anders stellen. Und viel wichtiger: Wie ist Eure Erfahrung mit einem entsprechenden Alerting? Nutz Ihr eins? Kennt Ihr bessere Tools? Und welches Merkmal haben wir hier nicht erwähnt, was aber unbedingt mit auf die Liste sollte? − Fragen über Fragen − ich bin auf Euer Feedback gespannt!