Traffic bricht ein: die Ursache eingrenzen statt raten

Am Montag liegen die Klicks 30 Prozent unter der Vorwoche. Niemand hat etwas veröffentlicht, niemand hat etwas abgeschaltet, die Startseite sieht aus wie immer. Teuer wird nicht der Einbruch, sondern die Woche, in der jeder eine andere Vermutung hat und niemand einen Beleg — währenddessen fällt jede Seite, die seit dem letzten Deploy noindex trägt, still weiter aus dem Index.

So gehen Sie mit JMX vor

1. Reiter Verlauf. Projektdatei öffnen, den letzten Lauf gegen den davor stellen. Der Abschnitt Was sich an den Seiten geändert hat zeigt Seite für Seite, was neu, verschwunden oder verändert ist, mit einem Risiko je Zeile: Eine Seite, die seit dem vorigen Lauf noindex trägt oder mit 404 antwortet, ist Kritisch und steht oben. Je Segment steht die Bilanz — Shop oder Blog.
2. Search Console, dann Suchanalyse. Daten laden holt Klicks, Impressionen, CTR und Position. Gewonnen / Verloren vergleicht mit dem unmittelbar davorliegenden, gleich langen Zeitraum; Abschnitte der Website zeigt, welcher URL-Bereich verliert.
3. Reiter Technik. Acht Kernfragen auf einer Seite: Crawler-Zugriff, robots.txt, Sitemaps, Indexierbarkeit, Weiterleitungen, Sprachcodes. Was nicht geprüft werden konnte, heißt dort „Nicht prüfbar“ und nicht „in Ordnung“.
4. Logdateien auswerten. Apache-, nginx- oder IIS-Log gegen den Crawl halten. Status (Bot) neben Status (Crawl) ist der Grund, ein Log zu lesen: Weicht die Spalte ab, bekommt die Suchmaschine etwas anderes als Sie. Als Bot zählt nur, was Reverse- und Forward-DNS bestätigen.
5. JavaScript rendern. Der Vergleich zwischen ausgeliefertem und gerendertem HTML findet die Seiten, die ihr noindex erst im Browser setzen — für jeden nicht rendernden Crawler sehen sie indexierbar aus.
6. Search Console, URLs prüfen. Für die verdächtigen Seiten den echten Indexierungsstatus abfragen, die einzige autoritative Antwort auf „ist diese Seite im Index?“. Das Kontingent liegt bei 2.000 Abfragen pro Tag und Property; JMX zählt mit und stoppt vorher.
7. Reiter Aufgaben. Aus den Befunden der Arbeitsplan: Auswirkung in Punkten, geschätzter Aufwand, Hebel in Punkten je Personentag, Einteilung von Sofort bis Zurückstellen.

Worauf Sie achten müssen

„Verschwunden“ heißt im Verlauf nicht „gelöscht“, sondern „in diesem Crawl nicht gefunden“. Wer zwischen zwei Läufen die maximale Tiefe, die URL-Obergrenze oder die Ausschlussmuster verändert hat, bekommt eine Liste verschwundener Seiten, die nichts über die Website aussagt und alles über die geänderte Einstellung. Ohne Lizenz endet jede Auswertung bei 25 Seiten; ein Vergleich zweier gekappter Läufe ist keiner.

JMX vergleicht ausschließlich, was in der Projektdatei liegt: Gibt es dort nur einen einzigen Lauf, dann ist der erste Crawl nach dem Einbruch eine Bestandsaufnahme und keine Ursache, weil nichts da ist, wogegen er sich halten ließe. Die Search Console reicht 16 Monate zurück, die Rank-Tracking-Historie beginnt beim ersten bezahlten Lauf. Ein Core Update, ein überholender Wettbewerber, weggebrochene Nachfrage: JMX sagt, was sich an Ihrer Website geändert hat, nicht, was sich in der Suche geändert hat.

Der Sonderfall: Der Einbruch ist gar nicht organisch. Die Webanalyse trennt die Kanäle, Besuche aus KI-Apps ohne Referrer zählen prinzipbedingt als „Direkt“, und der laufende Monat steht in keiner Kennzahl — ein halber Monat gegen einen ganzen wäre ein erfundener Einbruch. Manchmal fehlt schlicht der Zähler. Die Textsuche im Modus enthält nicht, eingeschränkt auf /shop, findet die Seiten ohne Tracking-Code.

Wer die Ursache eines Einbruchs sucht, sucht in Wahrheit einen zweiten Zeitpunkt. Ein nächtlicher jmx-cli-Lauf auf dieselbe Projektdatei mit --fail-on-change Critical liefert ihn und endet mit Rückgabewert 2, sobald sich etwas Kritisches bewegt hat.