Vor dem Entfernen
Fundstelle und Wirkung beweisen
- Betroffene URL in privatem Browserfenster öffnen und Widget dokumentieren.
- Seitenquelltext und DevTools-DOM nach `id="chatbot"` durchsuchen.
- Im Netzwerk-Tab Scriptdomain und nachgeladene Requests erfassen.
- CMS-/Theme-/Tag-Manager-Suche nutzen, um die eigentliche Einbauquelle zu finden.
- Aktuelle Konfiguration oder Codeänderung für Rollback sichern.
Quellen: 1
Typische Einbauorte
Wo das Script stecken kann
| System | Typischer Ort | Sicheres Vorgehen |
|---|---|---|
| Statisches HTML | vor `</body>` in Layout/Seite | Template ändern, Build erzeugen, Deployment prüfen |
| WordPress | Theme Footer, Custom HTML, Plugin, Header/Footer Injector | Child Theme/Plugin-Einstellung statt Core-Datei ändern |
| Google Tag Manager | Custom-HTML-Tag mit Trigger | Tag pausieren, Version veröffentlichen, Preview/Live prüfen |
| Wix/Squarespace | Custom Code/Code Injection | Eintrag sichern, deaktivieren, veröffentlichen |
| SPA/Next/Astro | Root Layout, Script-Komponente oder Tag Manager | Komponente entfernen, Build testen, Route-Wechsel prüfen |
Nach dem Deployment
Vier Ebenen prüfen
- 01
HTML
Script-Tag ist im ausgelieferten Quelltext nicht mehr vorhanden.
- 02
DOM und Netzwerk
Kein dynamisch nachgeladenes Widget und keine Requests an die alte Widgetdomain.
- 03
Funktion
Navigation, Formulare, Consent und Ersatzkontakt funktionieren weiterhin.
- 04
Cache und Varianten
CDN, CMS-Cache, Mobilversion, Sprachseiten und wichtige Templates geprüft.
Keine Kontaktlücke
Ersatz oder temporären Kontaktweg bereitstellen
Wenn das neue Widget noch nicht freigegeben ist, bieten Sie mindestens einen klaren E-Mail-/Telefon-/Formularweg an. Ein sichtbar bleibender Chat-Button, der keine Nachrichten mehr weiterleitet, ist schlechter als ein ehrlicher temporärer Hinweis.
Bei WebChat wird ein neues Script mit der passenden Channel-ID vor dem schließenden Body-Tag eingebunden. Verwenden Sie niemals die Beispiel-ID einer anderen Sprache oder eines Testkanals.
Quellen: 2