Auto-Refresh — KB immer aktuell halten
Eure Webseite ändert sich — neue Blogposts, Pricing-Updates, FAQ-Erweiterungen. Damit der AI-Bot weiterhin korrekte Antworten gibt, kann SilentChat die Knowledge Base pro Domain automatisch re-indizieren. Das Feature ist opt-in pro Domain, gegen das normale AI-Token-Budget verrechnet (Crawling selbst kostet keine LLM-Calls, aber die Embedding-Erzeugung neuer Artikel schon).
Aktivierung
Einstellungen → Domains → verifizierte Domain → Schalter „Auto-Refresh"
Jede verifizierte Domain bekommt einen eigenen Toggle:
- Toggle An: nächster Crawl-Lauf wird im nächsten Tages-Tick eingeplant
- Intervall-Picker: 3 / 7 / 14 / 30 Tage (Default: 7)
- „Jetzt neu indizieren": löst einen Refresh sofort aus — nützlich nach einer großen Webseiten-Änderung, ohne auf den Cron-Tick zu warten
Unverifizierte Domains zeigen den Strip nicht — der Crawler verlangt DNS-Verifizierung (siehe Domain-Verifizierung) bevor er irgendwas zieht.
Was läuft im Hintergrund?
Drei Cron-Jobs orchestrieren das Feature:
-
crawl_refresh_scheduler(täglich) — listet alle Domains mitnext_crawl_at <= NOW(), queued pro Domain einen Crawl-Job + erstellt einecrawl_runs-Zeile, bumptnext_crawl_atum das konfigurierte Intervall. Cap: 50 Domains pro Tick (verhindert dass eine frisch-aktivierte Enterprise-Konfig den Worker-Pool flutet). -
crawl_runs_finalize(alle 5 Minuten) — findet Runs ohnefinished_atderen Jobs allecompletedoderfailedsind (oder > 30 Min alt). Berechnet die Diff viaCrawlDiffServiceund persistiert die Stats:{ "new": 3, "updated": 7, "removed": 2, "total_after": 47 } -
crawl_runs_purge(täglich) — dropptcrawl_runs-Zeilen älter als 90 Tage. Konsistent mit der allgemeinen Activity-Log-Retention.
Diff-Anzeige im Dashboard
Jede Domain bekommt eine kleine History-Strip (in Vorbereitung). Aktuell siehst du:
- Letzter Crawl-Zeitstempel unter dem Toggle
- „Letzte Indizierung: vor 4 Tagen" als dezenten Chip
Im nächsten Iteration kommt die Drill-Down-Modal mit der Artikel-Liste pro Run (neu / aktualisiert / entfernt) — bis dahin sind die Counts im Backend-Log via crawl_refresh tenant=... run=... diff=new:3 updated:7 removed:0 total:47 verfügbar.
Was wird gecrawled?
Aktuell crawled der scheduled Refresh nur die Root-URL der verifizierten Domain. Multi-Page-Discovery via Sitemap.xml ist ein separater Plan in der Roadmap (siehe crawler-refresh-scheduler.md).
Das funktioniert gut für:
- Pricing-Pages
- Changelog-Pages
- FAQ-Entry-Pages
- Single-Page-Pricing-Vergleiche
Wenn du heute mehrere Sub-Pages indizieren willst, nutze stattdessen den manuellen KB → Auto-Import Pfad (Plan #164), der eine URL-Liste verarbeitet.
Token-Verbrauch
- Crawling selbst: 0 LLM-Tokens (HTTP-Request + HTML-Parse)
- Embedding-Berechnung für neue / geänderte Artikel-Chunks: gegen
embed_indexBudget - Größenordnung: Eine 5 KB Webseite produziert 5-10 Chunks ≈ 5 000 Tokens für die Embedding-Indizierung. Bei 7-Tage-Intervall ≈ 22 000 Tokens/Monat pro Domain.
DSGVO
Der Auto-Refresh sendet kein PII an externe Services. Der Crawler liest nur die öffentlich erreichbare Webseite — selbe Datenschutz-Implikationen wie bei der ersten Indizierung im Onboarding-Wizard (Plan #163/#164). Die Einbettungen berechnet IONOS in Deutschland — derselbe Anbieter wie beim KI-Chatbot.
Häufige Fragen
Mein Auto-Refresh-Toggle ist an aber es passiert nichts.
Prüfe domains.next_crawl_at per SQL — falls in der Zukunft, wartet der Scheduler. Im Backend-Log nach crawl_refresh_scheduler filtern. Wenn der Tag durch ist, der Tick aber nicht lief, ist vermutlich das Lock noch von einem anderen Cron-Worker gehalten — beim nächsten Tag-Tick läuft es.
Kann ich Auto-Refresh global ausschalten?
Per Domain reicht — Toggle aus, next_crawl_at wird auf NULL gesetzt, der Scheduler überspringt die Domain. Global würde nur über das Stoppen des Cron-Containers gehen (oder Skip-Logic via RuntimeConfig — wird nachgereicht falls gewünscht).
Was passiert wenn der Crawl mitten im Run fehlschlägt?
Der crawl_runs_finalize-Job greift nach 30 Min auch hängende Runs auf und stempelt sie mit den Diff-Counts bis dahin. Der nächste Scheduler-Tick re-enqueued — kein Drop-Effekt.
Wie sehe ich die History?
Per API: GET /api/v1/domains/<id>/crawl-runs listet die letzten 20 Runs mit Timestamps + Stats. Die Drill-Down-UI dafür ist in Vorbereitung.
Frisst Auto-Refresh meine Plan-Limits?
Crawling selbst nicht (kein LLM-Call). Aber die Embedding-Erzeugung pro neuem Chunk schon — diese läuft gegen embed_index und unterliegt der Monthly-Embedding-Quota (siehe embedding-token-tracking.md für die Konfiguration).