Jede Nacht ein Crawl: Änderungen erkennen mit jmx-cli

Freitagabend geht ein Deployment live. Danach steht in einem Template ein noindex, das dort nicht hingehört — nicht auf einer Seite, sondern auf 340. Gemerkt wird es, wenn die Klicks fehlen, und das ist frühestens zwei Wochen später, weil Google die betroffenen Seiten erst nachcrawlen muss, bevor sie aus dem Index fallen. Ein Befund im üblichen Sinn ist das nicht: Die Seite antwortet mit 200, der Titel stimmt, die Struktur auch. Nur gestern war sie anders.

So gehen Sie mit JMX vor

1. Einen ersten Crawl in der Oberfläche fahren und ihn über Projekt speichern als .jmx-Datei ablegen. Diese Datei ist der Bezugspunkt: Jeder weitere Lauf hängt sich an sie an, und ohne sie gibt es keinen Vorgänger, mit dem sich der neue Stand vergleichen ließe — beide Schalter der Änderungserkennung brauchen --project.
2. Unter Einstellungen → Segmente die Bereiche der Website beschreiben, je Name und Muster. Aus „24 Seiten geändert“ wird damit „21 davon im Shop“.
3. Die Crawl-Grenzen festlegen und danach in Ruhe lassen: --max-urls, --max-depth. Wer sie zwischen zwei Läufen verstellt, bekommt Hunderte Seiten als „neu“ gemeldet, die es nicht sind.
4. Den nächtlichen Aufruf in cron, Taskplaner oder CI einhängen: jmx-cli beispiel.at --project /var/jmx/beispiel.jmx --changes /var/jmx/aenderungen.xlsx --fail-on-change Critical --quiet. Ab dem zweiten Lauf auf dieselbe Projektdatei rechnet die Kommandozeile den Vergleich Seite für Seite von selbst.
5. Den Rückgabewert auswerten, denn daran erkennt ein geplanter Lauf sein Ergebnis: 0 nichts jenseits der Schwelle, 1 der Lauf selbst gescheitert, 2 es hat sich etwas Kritisches bewegt. Wer auch den Zustand und nicht nur die Bewegung scharf stellen will, hängt --fail-on Critical daneben.
6. Am Morgen die Projektdatei öffnen und im Reiter Verlauf den Abschnitt „Was sich an den Seiten geändert hat“ durchgehen. Die Tabelle beginnt mit dem Schlimmsten. Eine ausgewählte Zeile zeigt die Werte vorher und nachher nebeneinander, darunter die Bilanz je Segment.

Worauf Sie achten müssen

Der häufigste Fehler steckt im Skript, nicht im Werkzeug: 1 und 2 gleich zu behandeln. Ein abgelaufenes Zertifikat, ein voller Datenträger, ein DNS-Aussetzer — das ist eine 1 und keine Aussage über die Website. Umgekehrt ist es schlimmer: Wer nur auf 2 prüft und die 1 verschluckt, hat eine Nachtwache, die seit Wochen wegen eines Netzproblems gar nicht mehr durchläuft und trotzdem grün aussieht, weil kein einziger kritischer Befund gemeldet wurde.

Der Vergleich sieht nur, was der Crawl sieht. jmx-cli rendert kein JavaScript: Eine Seite, die ihr noindex erst im Browser setzt, steht in beiden Läufen unverändert da, weil das ausgelieferte HTML unverändert ist — dafür gibt es das Rendern in der Oberfläche. Search-Console-Zahlen, Rankings und Core Web Vitals holt der nächtliche Lauf ebenfalls nicht ab. Verglichen werden zwei Crawls, sonst nichts.

Der Sonderfall ist die geplante Umstellung. In der Nacht eines Relaunches meldet der Vergleich Hunderte kritische Zeilen und hat damit recht — nur ist das keine Störung, sondern die Migration. Fahren Sie vorher einen Lauf von Hand als neuen Bezugspunkt. Die Obergrenze von 25 Seiten ohne gültige Lizenz greift nur in der Oberfläche — jmx-cli kennt keine Lizenzprüfung und crawlt so viel, wie –max-urls erlaubt.

Lassen Sie die Schwelle auf Critical stehen — eine Nachtwache, die dreimal pro Woche wegen eines verlängerten Titels rot wird, ist nach vierzehn Tagen eine Regel im Postfach, die niemand mehr liest.