Automation und Alerts

Ein Zeitplan plant einen Versuch, keinen garantierten Crawl

Wähle täglich, wöchentlich oder monatlich, eine benannte Zeitzone sowie Stunde und Minute. Wöchentliche Pläne brauchen einen Wochentag, monatliche einen Kalendertag. Jitter verteilt fällige Arbeit, damit nicht jeder Lauf gleichzeitig zugelassen werden muss.

Aktuell sind höchstens fünf Zeitpläne je Site möglich. Ein Schedule kann gespeichert sein, obwohl die Site noch nicht verifiziert ist; der Dispatcher überspringt ihn dann als `site_unverified`.

Fälligkeit und Zulassung sind getrennte Ereignisse

Erst der Dispatcher prüft Site, aktiven Lauf, Organisationskapazität, monatliche Quote, Schedule-Limits, Budget und Balance. Ein fälliger Eintrag ohne neuen Lauf ist deshalb kein stiller Erfolg.

Lies den konkreten Grund für einen übersprungenen Lauf

• Site nicht verifiziert oder nicht verfügbar
• bereits aktiver Lauf
• Organisationskapazität oder monatliche Organisationsquote erreicht
• monatliches Lauf- oder Budgetlimit des Zeitplans erreicht
• zu wenig Balance für die Reservierung

Lauf- und Budgetfenster folgen der Schedule-Zeitzone

Die aktuellen Defaults liegen bei vier Läufen und 50 Euro Budget pro Monat. Das Monatsfenster richtet sich nach der gewählten Zeitzone. Prüfe Schätzung, Reservierung und tatsächliche Abrechnung getrennt, besonders bei Rendering.

Pause, Fortsetzen und Löschen verändern die nächste Fälligkeit

Eine Pause entfernt die aktuelle Fälligkeit. Beim Fortsetzen wird sie neu berechnet. Löschen ist ein Soft Delete und bewahrt die Historie für die vorgesehenen Prüfpfade, statt vergangene Läufe umzuschreiben.

Alert-Regeln decken klar benannte Veränderungen ab

Unterstützt werden neue kaputte Links, neues Noindex, geänderte Robots-, Canonical-, Titel- oder Meta-Description-Signale, Structured-Data- und Sitemap-Regressionen, Health-Score-Rückgang und Bot-Anomalien. Wähle Schweregrad, Schwelle und optional einen Schedule-Scope passend zur Reaktion.

Ein Alert braucht eine geeignete Baseline

Die Regel vergleicht mit einem vorherigen geeigneten oder erfolgreichen Lauf. Nicht vergleichbare Runs werden nicht als echte Änderung bewertet. Digest-Einstellungen können run-basiert, täglich oder wöchentlich sein.

Prüfe mit Crawl-Historie und Vergleich die beiden Berichte hinter einer Meldung, bevor du nach ihrer Zusammenfassung handelst.

Empfänger brauchen Handlungskompetenz

Aktuell gelten höchstens 25 Regeln und zehn Empfänger je Site. Halte die Liste klein und benenne eine Person, die Evidenz prüfen oder die Untersuchung koordinieren kann. Ein Alert ist keine automatisch zugewiesene Produktentscheidung.

Stimme Teamzugriffe und Zuständigkeiten auf die Personen ab, die die Meldungen untersuchen sollen.

Alert-Ereignis und Zustellung sind getrennt

Pro Lauf werden höchstens 100 Ereignisse gespeichert, der Vergleich scannt bis zu 1.000 passende Elemente und hält standardmäßig fünf Beispiele fest. Die Zustellung hat eigenen Providerstatus und bis zu drei Versuche. Prüfe beides, wenn eine Nachricht fehlt.

Dämpfe Wiederholungen, ohne Evidenz zu verstecken

Die Unterdrückung kann zwischen null und 720 Stunden liegen und steht standardmäßig auf 24 Stunden. Nutze Schwellen und Suppression für erwartbare Schwankungen. Die zugrunde liegenden Läufe bleiben trotzdem die Quelle für die Untersuchung.

Reagiere vom Ereignis zurück zur Evidenz

Beispiel: Ein Release mit noindex rechtzeitig bemerken

Häufige Fragen