SilentChat

Auto-Refresh — KB immer aktuell halten

Zuletzt aktualisiert: 16. September 2026

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:

  1. crawl_refresh_scheduler (täglich) — listet alle Domains mit next_crawl_at <= NOW(), queued pro Domain einen Crawl-Job + erstellt eine crawl_runs-Zeile, bumpt next_crawl_at um das konfigurierte Intervall. Cap: 50 Domains pro Tick (verhindert dass eine frisch-aktivierte Enterprise-Konfig den Worker-Pool flutet).

  2. crawl_runs_finalize (alle 5 Minuten) — findet Runs ohne finished_at deren Jobs alle completed oder failed sind (oder > 30 Min alt). Berechnet die Diff via CrawlDiffService und persistiert die Stats:

    {
      "new": 3,
      "updated": 7,
      "removed": 2,
      "total_after": 47
    }
    
  3. crawl_runs_purge (täglich) — droppt crawl_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_index Budget
  • 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).

Auto-Refresh — KB immer aktuell halten — Help Center — SilentChat | SilentChat