Sie sind hier:

Gibt es wirklich ein Problem oder spinnt mein Monitoring-Tool?

Mit Cronjobs Licht ins Dunkel bringen

Neele Troske
Neele Troske

Mehr von diesem AutorArtikel als PDF laden

Laut dem Monitoring-Tool Testomato stehen wichtige Kategorieseiten plötzlich auf „noindex“ – die Panik bei uns SEOs ist entsprechend groß. Wenn nach sämtlichen Prüfungen der Fehler weder gefunden noch reproduziert werden kann, ist die Verwirrung umso größer. Nun stellt sich die Frage: Ist das Tool oder wirklich die Seite das Problem? Gerade bei Custom entwickelten Content-Management-Systemen, in die externe SEO-Berater*innen weniger Einblicke haben, ist dies schwer zu beurteilen. Vor diesem Problem stand ich nun – und konnte letztendlich mithilfe eines Cronjobs Klarheit schaffen.

Website-Monitoring-Tool is going wild – Ausgangslage

Einer meiner ersten Schritte beim Set-up eines neuen Kundenprojekts ist das Aufsetzen der wichtigsten Seitentypen sowie robots.txt, Sitemap und Co. in einer Website-Monitoring-Software (ich entschied mich für Testomato). So wird man rechtzeitig über Probleme einer Seite informiert – idealerweise bevor der Kunde es merkt. Als Seitentypen trackte ich die Homepage, die wichtigsten Kategorie- und Subkategorie- sowie einige Produktdetailseiten.

Wer regelmäßig Projekte in Testomato überwacht, weiß, dass man normalerweise lediglich Benachrichtigungen erhält, sobald bei der Überprüfung von Seiten ein Problem auftritt oder ein Fehler behoben wurde. 
Kurze Zeit nach Aufsetzen des Projekts bekam ich jedoch im 5-Minuten-Takt Mitteilungen – einige der Seiten würden vermehrt einen noindex-Tag ausspielen.

Nach direkter Überprüfung stellte sich jedoch heraus, dass keine der Seiten, die von Testomato als fehlerhaft gemeldet wurden, einen noindex-Tag ausspielten – weder im initialen noch im gerenderten Quellcode. Bei keiner der Seiten fanden sich Meta-Robots- oder X-Robots-Angaben. Auch die Search Console zeigte keine Fehler an. Bei jeder Aktualisierung des eingestellten Monitorings konnte ich allerdings live mitverfolgen, dass die Seiten regelmäßig von indexierbar auf nicht indexierbar sprangen und umgekehrt.

Und ganz nebenbei wurde mein Postfach voller und voller …

Abbildung 1: Beispiele von Testomato-Meldungen

Auch wenn ich daraufhin einen Bug im Tool selbst vermutete (und die Benachrichtigungen schnell pausierte), ließ mich das Thema nicht los. Falls es nicht am Monitoring-Tool selbst lag, war es definitiv nicht gut, dass wichtige Kategorieseiten im 5-Minuten-Takt einen noindex-Tag ausspielten – wenn Seiten teilweise für Google nicht indexierbar sind, hat dies sicherlich auch Einfluss auf die Rankings.

Ich spielte die Frage an die zuständige Technikagentur des Kunden – deren Antwort: „Wir können das leider nicht reproduzieren“ – also eine Sackgasse.

Eine Lösung musste her …

Um den vermeintlichen Bug zu prüfen, brauchte ich also eine Möglichkeit, einen identischen Test an anderer Stelle laufen zu lassen. Unabhängig vom Tool musste eine Anzahl von URLs automatisiert zu einer bestimmten Zeit über einen längeren Zeitraum abgefragt werden. Meine Lösung: ein Cronjob.

Was ist ein Cronjob?

Ein Cronjob ist ein programmgesteuertes Skript, das auf einem Linux-Server zu bestimmten Zeitpunkten oder in bestimmten Intervallen automatisch ausgeführt wird.

Grundlage ist die Datei crontab, die man für die Einrichtung bearbeitet. Diese Datei enthält die Liste der auszuführenden Jobs für den Cronjob. Jeder Job besteht aus sechs Spalten, wobei die ersten fünf Spalten den Zeitstempel und die sechste Spalte den auszuführenden Befehl enthalten (Abbildung siehe unten).

Im Hintergrund läuft der Cron-Daemon, der zeitliche Impulse gibt, damit die Aufgaben zu den geplanten Zeitpunkten ausgeführt werden können.

Was sind die Voraussetzungen, um einen Cronjob erfolgreich anzulegen und die Ausführung sicherzustellen? 

  • Zugriff auf den Computer oder Server, auf dem der Cronjob eingerichtet werden soll
  • Die Berechtigung, die crontab-Datei zu bearbeiten

So bin ich in meinem Fall vorgegangen: 

  1. Erstellen einer CSV-Datei namens „check.csv“, die eine Liste von URLs enthält, die geprüft werden sollen
  2. Anschließend Erstellen eines PHP-Skripts („skript.php“), das ausgeführt werden soll
  3. Um den Cronjob einzurichten: Cronjob-Konfiguration auf dem Server über den Befehl „crontab -e“ im Terminal öffnen. Dort den Zeitplan sowie den Pfad zur auszuführenden Datei („skript.php“) angeben

In meinem Fall wollte ich die aufgeführten URLs aus der Datei „check.csv“ im 5-Minuten-Takt prüfen lassen. Die Konfiguration im Cronjob sah wie folgt aus

5 * * * * /pfad/pfad2/skript.php

Nachdem die Konfiguration gespeichert wurde, rief der Cronjob alle fünf Minuten das PHP-Skript auf, das den darin enthaltenen Code ausführte. Dabei wurden die URLs aus der CSV-Datei abgerufen und der Output in einer separaten Datei namens „final.csv“ abgespeichert. 

Die wichtigsten Schritte im PHP-Skript sahen wie folgt aus: 

Abbildungen 2 bis 4: Ausschnitte aus dem PHP-Skript
Abbildungen 2 bis 4: Ausschnitte aus dem PHP-Skript
Abbildungen 2 bis 4: Ausschnitte aus dem PHP-Skript

Was macht das Skript genau?

Funktion: readCSV
Sie liest die URLs, die ich prüfen wollte, aus einer CSV Datei in das Skript ein.

Funktion: writeCSV
Sie schreibt die Ergebnisse in eine neue CSV-Datei.

Funktion: fetchURL
Sie ruft eine URL per cURL auf und gibt das reine HTML zurück.

Die Schleife (foreach):
Sie nimmt jede eingelesene URL, ruft das HTML ab, extrahiert per xPath die Inhalte der Meta Robots und speichert sie dann im CSV.

CMS oder Monitoring-Tool – woran hat’s gelegen?

Nach ein paar Tagen hatte ich so mehr als 44.000 Abrufe in meiner CSV-Datei gesammelt – das musste als Datengrundlage reichen. Und meine Vermutung wurde bestätigt: Der Export zeigte eindeutig, dass die noindex-Tags immer wieder sporadisch auftraten (insgesamt 90-mal). Der Effekt trat unregelmäßig und über den gesamten Zeitraum von 24 Stunden auf, sodass kein bestimmter Zeitpunkt festgestellt werden konnte.

Abbildung 5: Ausschnitt aus dem Output des Cronjobs, Datei „final.csv“

Mit der Fehlerliste hatte ich nun den Beweis, dass in diesem Fall tatsächlich das CMS-System des Kunden selbst Grund für den Bug sein musste. Somit hatte ich auch eine fundierte Argumentationsgrundlage, um die IT-Agentur des Kunden weiter mit dem Problem zu behelligen – alles im Sinne der Sicherung von erkämpften Ranking-Positionen, die uns nicht durch technische Bugs verloren gehen sollten.

Zeitsprung – ein paar Monate später: Die Ursache für das Problem habe ich leider nicht parat, die IT-Agentur ist noch bis heute auf der Suche nach dem Grund ...

Viel Spaß beim Ausprobieren!