SEO-Website-Monitoring mit Statping

Je größer die Website, desto schwieriger wird es, alle Bereiche im Blick zu behalten. Man benötigt einen Automatismus, der fortwährend jede wichtige Codezeile überwacht und bei Änderungen Alarm schlägt. Hier kommt ein SEO-Monitoring-Tool als Frühwarnsystem ins Spiel. Die meisten haben den Nachteil, dass sie kompliziert einzurichten sind – und/oder viel Geld kosten.

Anders: das kostenlose und leicht einzurichtende Open-Source-Web-und-App-Monitoring-Tool Statping. Dieses wurde von einer Coder-Community programmiert und mithilfe von Entwicklern der Handelsblatt Media Group exakt für SEO-Anwendungsfälle weiterentwickelt. Es ist einfach zu verwenden und bietet eine benutzerfreundliche Weboberfläche, die es auch weniger technikaffinen Benutzern zugänglich macht. Statping kann für einzelne Benutzer genauso wie für große Unternehmen eingesetzt werden.

Es lassen sich Tests für unterschiedliche Seiten-Templates aufsetzen, bei denen in gewünschtem Intervall der Status von beliebigen Elementen im Quellcode abgefragt und geprüft wird, ob Dienste und Anwendungen wie erwartet verfügbar sind. Wird an einer Stelle nicht das erwartete Code-Snippet zurückgegeben, erhält man eine Benachrichtigung, beispielsweise in Slack – einer Messaging-App für Unternehmen – oder per Push-Benachrichtigung direkt aufs Handy. Das Ganze lässt sich in der Praxis ohne Programmierkenntnisse nutzen.

Einrichtung Docker Hub

Um Statping verwenden zu können, muss es zunächst über Docker eingerichtet werden. Anschließend lassen sich zu überwachende Websites und einzelne URLs hinzufügen sowie benutzerdefinierte Benachrichtigungen einrichten. Docker ist eine Plattform, die es ermöglicht, Anwendungen in ausführbaren Umgebungen (Containern) zu betreiben.

Zunächst installieren Sie Docker auf Ihrem Windows-, Linux- oder Mac-Endgerät unter docs.docker.com/get-docker/: hierzu auf den jeweiligen Button für Ihr Betriebssystem klicken.

Im zweiten Schritt erstellen Sie ein Repository (auch „Repo“ genannt), in dem alle erforderlichen Statping-Dateien gespeichert und verwaltet werden. Es handelt sich dabei um eine Art Datenbank, die es ermöglicht, Änderungen an den Dateien nachzuverfolgen und verschiedene Versionen der Dateien zu vergleichen. Öffnen Sie Ihr Terminal und geben Sie den folgenden Befehl ein, um Statping auszuführen und einzurichten: docker run -it -p 8080:8080 handelsblattgroup/statping:latest. Das Terminal öffnen Sie, indem sie Terminal in die Suchleiste eingeben und anschließend auf das entsprechende Symbol klicken. Es handelt sich hierbei um ein textbasiertes Interface (Benutzeroberfläche), mit dem Sie direkt auf das Betriebssystem zugreifen und Befehle ausführen können.

Im dritten Schritt rufen Sie Ihren bevorzugten Browser (z. B. Chrome) auf und geben localhost:8080 in die Browserzeile ein, um Ihr persönliches Statping-Interface zu erreichen. Sie werden nun aufgefordert, einen Namen, eine Beschreibung, einen Benutzernamen, ein Passwort sowie eine E-Mail-Adresse für Ihr Monitoring zu vergeben. An allen anderen Feldern müssen keine Änderungen vorgenommen werden. Klicken Sie auf Einstellungen speichern.

Nun ist Statping auf Ihrem lokalen Rechner eingerichtet und einsatzbereit. Für größere Anwendungsfälle kann Statping auch auf einem Server und in einer separaten Datenbank eingerichtet werden, der entsprechende Deployment-Guide ist hier zu finden: github.com/handelsblattgroup/statping.

Tests einrichten – Übersicht

Loggen Sie sich nun mit Ihrem vergebenen Benutzernamen und Passwort ein. Sie sehen am oberen Bildschirmrand eine vertikale Menüleiste. Gehen Sie zum Menüpunkt Service und klicken Sie auf den grünen Button Create. Nun können Sie Ihren ersten Test einrichten.

1. Bereich: Service-Info

Als Erstes gilt es, die Felder im Bereich Service Info auszufüllen:

Service Name: Geben Sie Ihrem Test einen aussagekräftigen Namen.

Service Type: Hier können Sie aus HTTP Service, TCP Service, UDP Service, ICMP Ping, gRPC Service und Static Service wählen.Für Website-Tests ist immer der Menüpunkt HTTP Service anzuklicken. TCP Service wäre beispielsweise für Server-Tests auszuwählen.

Group: Um nicht die Übersicht bei zahlreichen Tests in verschiedenen Seitenbereichen der Website zu verlieren, sollten die Tests logisch strukturiert werden, zum Beispiel in die Bereiche Website -> Template-Kategorie (wie Übersichtsseite, Detailseite) -> Template-Art (wie Artikel, Bildergalerie, Video).

Permalink URL: Für jeden Test wird automatisch ein Permalink aus dem angegebenen Service Name generiert – dieser URL-Name kann, muss aber nicht angepasst werden.

Public Service: Hier kann festgelegt werden, ob jeder mit Zugriff auf Statping den aufgesetzten Test sehen kann oder nur eine eingeschränkte User Group, wie zum Beispiel Admins.

Check Interval: Unter diesem Punkt wird festgelegt, wie häufig getestet werden soll, ob das jeweilige Code-Snippet im Quellcode der Website vorhanden ist, zum Beispiel alle 60 Sekunden, alle 60 Minuten oder alle 24 Stunden.

2. Bereich: Request Detail

Unter „Request Detail“ wird der eigentliche Test definiert. Hier ist zu beachten, dass nicht jedes Feld ausgefüllt werden muss, sondern einzelne Felder für einzelne Anwendungsfälle gedacht sind.

Service Endpoint (URL): Tragen Sie hier die vollständige Internetadresse ein, die bei Ihrem Test herangezogen werden soll.

Service Check Type: Für Website-Tests ist immer HTTP Service auswählen.

Request Timeout (Zeitüberschreitung): Tragen Sie in diesen Bereich ein, wie lange die URL Zeit hat, zu antworten, bis der Test fehlschlägt. Die Standardeinstellung beträgt 15 Sekunden.

HTTP Request Headers: In diesem Feld haben Sie die Möglichkeit, die HTTP Request Header (Hypertext Transfer Protocol Header) Ihrer Website abzufragen. Es können Informationen bezüglich Übertragung von HTTP-Anfragen mitgegeben werden. Für das SEO-Monitoring ist es besonders spannend, den jeweiligen Test aus der Perspektive einer Suchmaschine durchzuführen. Es können beispielsweise einer oder mehrere Google-User-Agents abgefragt werden. Für den User-Agent Google-Desktop zum Beispiel user-agent=Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/107.0.0.0 Safari/537.36 ins Feld eintragen, für den Google-Smartphone-Bot Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html).

Negate Header Checks: Konfigurierte Einstellungen unter Expected Headers im nächsten Feld lassen sich negieren, indem man diesen Schalter aktiviert. Das bedeutet, ein angegebener Response-Header darf nicht gefunden werden, andernfalls gibt es einen Alert.

Expected (Response) Headers (Regex): Hier haben Sie eine zweite Möglichkeit, die HTTP Response Header Ihrer Website abzufragen. In diesem Fall können Informationen bezüglich Übertragung von HTTP-Antworten mitgegeben werden.Dieses Feldhat beispielsweise die Funktion im SEO-Zusammenhang, die erwartete Zielseite zu hinterlegen, sofern man unter Expected Status Code eine Weiterleitung erwartet, und zwar im Format location=www.beispiel-domain.de/beispiel-url/.

Negate Reponse Checks: Die untereExpected Response lässt sich negieren, indem man diesen Schalter aktiviert. Das bedeutet, ein angegebener Code-Snippet darf nicht gefunden werden, ansonsten gibt es eine Benachrichtigung.

Expected Response (Regex): Das wichtigste Feld – hier werden Code-Schnipsel bzw. Tags für das Monitoring hinterlegt, die im HTML (Hypertext Markup Language), also dem beschreibenden und strukturierenden Quellcode der Website, vorkommen sollen. Möchten Sie prüfen, dass die strukturell wichtigste Überschrift wie erwartet vorhanden ist, tragen Sie <h1>Beispiel-Überschrift</h1> in das Textfeld ein. Es besteht die Möglichkeit, RegEx (auch als reguläre Ausdrücke bekannt) einzusetzen, um Muster zu erkennen oder mit Wildcards (Platzhaltern) zu arbeiten. So ließe sich beispielsweise prüfen, ob das H1-Tag mit einem beliebigen Text im Quellcode vorhanden ist: <h1>.*?</h1>, wobei .*? als Platzhalter fungiert.

Expected Status Code: Für SEOs kann der mitgegebene Status Code ein interessanter Test sein. Dabei wird geprüft, ob die Antwort des Servers auf eine Anfrage eines Clients (z. B. Webbrowser oder Googlebot) erfolgreich war – oder nicht. Dies kann in diesem Feld definiert werden. Wird ein Status Code 200 (= Seite ist erreichbar) erwartet, wird die entsprechende Zahl in das Feld eingefügt. Wird eine dauerhafte Weiterleitung bei dem Test erwartet, wird die 301 eingetragen.

Follow Redirects: Ist der Schalter aktiviert, wird Weiterleitungen gefolgt und die jeweilige Zielseite für den Test herangezogen.

Verify SSL: Tests können auch ohne geprüftes SSL-(Secure Sockets Layer)-Zertifikat durchgeführt werden, wenn diese Option deaktiviert ist. Es handelt sich hierbei um die Standardtechnologie zum Schutz von Internetverbindungen und zur Absicherung sensibler Daten im Internet. HTTPS (Hyper Text Transfer Protocol Secure) wird in der URL angezeigt, wenn eine Website durch ein SSL-Zertifikat abgesichert ist.

Use TLS Cert: Bei der Aktivierung dieses Switches werden TLS-(Transport Layer Security)-Zertifikate ignoriert. Hierbei handelt es sich um eine aktualisierte Version von SSL.Diese Option kann in der Regel für SEO-Monitoring-Zwecke ignoriert werden.

3. Bereich: Notification Options

Hier können die Bedingungen festgelegt werden, wann ein Alarm versendet wird.

Enable Notifications: Sollen generell Mitteilungen für den aufgesetzten Test versendet werden?

Notify After Failures: Wie oft darf der Test fehlschlagen, bis eine Mitteilung gesendet wird?

Notify All Changes: Einmaliges Senden einer Mitteilung bei fehlgeschlagenem Test oder fortwährend wiederholen?

Sind die oberen Felder befüllt, klicken Sie auf den grünen Button Create Service und ein Test ist angelegt. Es können beliebig viele Monitoring-Szenarien angelegt werden, die dann alle unter dem Menüpunkt Dashboard oder Services einsehbar sind. Zudem kann eine Benachrichtigung bei fehlgeschlagenem Test an einen externen Service gesendet werden, um im Ernstfall direkt informiert zu werden.

Notifier einrichten

Unter Settings in der oberen Menüleiste lassen sich ein oder mehrere Notifier definieren – also das Tool, in dem Sie benachrichtigt werden möchten, wenn Tests fehlschlagen. Sie können sich per E-Mail, per Push-Benachrichtigung auf dem Handy oder über diverse Apps (z. B. Slack, Discord oder Telegram) über den Status Ihres Monitorings informieren lassen. Hierzu einfach dem entsprechenden Einrichtungsprozess Ihres bevorzugten Benachrichtigungstools folgen.

Relevante SEO-Tests für das Monitoring

Es ist empfehlenswert, SEO-Tests für verschiedene Seitentypen aufzusetzen. So lässt sich exemplarisch auf verschiedenen Ebenen der Website überprüfen, ob die relevanten Elemente wie gewünscht vorhanden sind. Fehler, die sich durch einen Seitentyp oder ein Template hindurchziehen, sind in der Regel erfolgskritisch – und wenn sie auf einer Seite auftreten, sind sie oft auch auf allen anderen Seiten vorhanden. Für das SEO-Monitoring reicht es daher im Normalfall aus, eine Auswahl von Seiten pro Seitentyp zu überprüfen.

Beispiele von Seitentypen:

• Startseite
• Übersichtsseiten (Hubpages oder Themenseiten)
• Kategorieseiten (Produkte)
• Paginierungsseiten von Übersichts-/Kategorieseiten
• Seiten mit Parametern
• Detailseiten (Artikel, Premiumartikel)
• Suchergebnisseiten
• Check-out/Registrierung
• Impressum, Datenschutz, Kontakt
• Subdomains
• Partnerangebote
• Robots.txt
• XML-Sitemaps

Was soll überwacht werden?

Als Nächstes stellt sich die Frage, was genau überwacht werden soll. Hierzu sollte man bedenken, welche Website-Elemente SEO-erfolgskritisch in Bezug auf Crawling, Indexierung und Ranking bei Google für die eigene Seite sind. Wichtige Website-Elemente müssen hinsichtlich ihrer Existenz und ihres erwarteten Werts überprüft werden. Im Folgenden einige Beispiele, was im Auge behalten werden kann und welche entsprechenden Fragen sich dazu gestellt werden können:

• Status Code (Erreichbarkeit der Seite, Weiterleitungen): Senden wichtige URLs den Status Code 200 und sind demzufolge für User und Search-Crawler, die die Website nach neuen und geänderten Inhalten durchsuchen, erreichbar? Funktionieren Weiterleitungen wie gewünscht, wenn beispielsweise ein Artikel aktualisiert und neu veröffentlicht wird? Ist die Testumgebung für das Crawling von Google ausgeschlossen und sendet dementsprechend zum Beispiel einen Status Code 403 an alle nicht autorisierten Zugriffe?
• HTTP vs. HTTPS: Funktioniert die 301-Weiterleitung von HTTP zu HTTPS und auch darüber hinaus das stringente URL-Handling? Gibt es also jeweils nur eine URL-Version und keine doppelten Inhalte, weil URLs unterschiedlich aufrufbar sind, beispielsweise mit .html am Ende und ohne?
• Desktop vs. mobile Version (bei einer nicht responsiven Seite) vs. AMP (sofern im Einsatz): Senden die mobile und die AMP-Version die gleichen Status Codes an Suchmaschinen und User? Werden identische Inhalte ausgespielt – oder gibt es Unterschiede?
• Wichtige SEO-Tags (z. B. Title Tag, Meta Description, Robots Meta, Canonical, Schema.org-Anweisungen, Hreflang): Sind die entsprechenden Elemente wie erwartet vorhanden, zum Beispiel Page Title oder die Meta Description? Steht die Meta-Robots-Anweisung auf index, follow, noarchive? Ist das Canonical-Tag selbstreferenzierend? Werden die schema.org-Daten für WebPage, Breadcrumb etc. wie gewünscht ausgespielt? Wird Google bei internationalen Websites korrekt über die lokalisierten Versionen Ihrer Website informiert?
• Interne Verlinkung (Navigation, Breadcrumb, Footer, Verlinkungsmodule): Sind alle wichtigen Seiten in der Main und Secondary Navigation sowie dem Footer verlinkt? Werden Verlinkungsmodule, wie ähnliche Artikel, ausgespielt und enthalten Links?
• Content-Elemente (Überschriften, Text, relevante Teaser, Kommentare): Sind relevante inhaltliche Elemente auf der Website vorhanden, können von Besuchern und Suchmaschinen erfasst werden und werden im gewünschten Zeitfenster geladen?
• Tracking-Parameter: Sind Tracking-Parameter, wie zum Beispiel User-Tracking oder Event-Tracking, im Quellcode ausgewiesen, damit die Anzahl und Häufigkeit der Zugriffe von Website-Besuchern auf die Website bzw. bestimmte ausgeführte Handlungen auf der Seite auch korrekt nachvollzogen werden können?
• Social Tags: Sind Social Tags wie og:title, og:type und og:url korrekt im Quellcode hinterlegt, damit soziale Netzwerke die entsprechenden Metadaten auslesen können?
• Call-to-Action: Funktionieren Buttons, Links, Formulare, die für Ihr Businessmodell wichtig sind, wie gewünscht? Also solche Elemente, mit denen der User zum Beispiel zur Registrierung, zum Kauf oder zum Download gelangt.
• Verfügbarkeit von JS/CSS: Sind Javascript und CSS-Dateien zur korrekten Bedienung und Ansicht der Website in gewünschter Form vorhanden?
• Caching-Angaben (Zwischenspeicher): Sind Caching-Header wie gewünscht in Bezug auf Caching-Art und maximales Alter hinterlegt, bevor die Caching-Ressource abläuft?

Priorisierung

Je größer die Website ist, desto größer die Anzahl an möglichen Tests. Man kommt schnell auf Hunderte zu überprüfende Testszenarien. Dabei gilt es, nicht durch zu viele gleichzeitig ausgespielte Alerts den Überblick zu verlieren. Es bietet sich an, eine Priorisierung anhand der Fragestellung vorzunehmen, wie negativ sich eine Änderung oder ein Ausfall des getesteten Elements auf die SEO-Performance auswirken würde. Ist beispielsweise der Evergreen-Artikel nicht mehr für Google erreichbar, der monatlich die meisten Besucher auf die Website lockt, sollte es umgehend einen Alert geben und dieses Testszenario dementsprechend häufig im Minutentakt überprüft werden. Ändert sich der Title auf einer Hubpage, ist die Dringlichkeit als mittel einzustufen. Hierzu sollte es innerhalb von 24 Stunden einen Alert geben. Verschwindet das Favicon bei einer Subdomain, kann die Prio auf niedrig gesetzt werden, es reicht gegebenenfalls ein Alert innerhalb von 48 Stunden.