Wenn ein Website-Chatbot nicht lädt, bestimmen Sie vor Einstellungsänderungen die gescheiterte Stufe: Die Seite enthält möglicherweise keinen Loader, der Browser blockiert eine Ressource, eine Einwilligungsregel verzögert bewusst das Laden, die Konfiguration ist nicht verfügbar oder eine bereits eingebundene Oberfläche ist verborgen. Ein sichtbares Widget, das keine Antwort findet, ist ein anderes Problem. Beginnen Sie mit Seite, Besucherzustand und Browserbelegen und geben Sie dem richtigen Verantwortlichen einen eng eingegrenzten Fehlerbericht.
Dieser Leitfaden bietet eine eigene Ressourcen- und Zustandscheckliste zur Bewertung eines Website-Chat-Widgets. Er empfiehlt weder das Abschalten von Content Security Policy noch das Kopieren einer Freigabeliste eines anderen Anbieters oder die Erklärung einer Einwilligungslösung als rechtskonform. Eine nützliche Diagnose kann mit einem Kompatibilitätsstopp enden, statt die Sicherheitsrichtlinie der Website zu schwächen.
Autor: Achla AI, Organisation. Geprüft am 14. Oktober 2026. Der Rahmen verbindet aktuelle Browser- und Anbieterdokumentation mit geprüften Achla-Installationshinweisen und wurde mit KI-Unterstützung erstellt. Beispiele sind hypothetisch; es wurden keine Kundenfälle oder Browsertestergebnisse gemessen. Ziel ist ein prüfbares Ladeproblem, bevor Website-Verantwortliche ein Widget bewerten oder ändern.
Was fehlt: Oberfläche, Anfrage oder Antwortquelle?
Beschreiben Sie, was der Besucher tatsächlich sieht. „Der Chatbot ist kaputt“ vermischt mehrere Beobachtungen, die unterschiedliche Verantwortliche und Korrekturen brauchen.
Fehlt eine Schaltfläche oder ein eingebetteter Kasten, prüfen Sie Installation, Laden und Sichtbarkeit. Erscheint die Oberfläche, kann aber keine Konfiguration oder Antwort abrufen, untersuchen Sie die betreffende Anfrage und den dokumentierten Serverzustand. Liefert die Oberfläche eine Antwort, lässt aber eine bestimmte Seite aus, prüfen Sie Quellensammlung und Informationsabruf getrennt.
Ändern Sie keine Crawl-Berechtigungen, um eine fehlende Oberfläche zu reparieren. Ebenso beweist ein erfolgreich geladenes Skript keine erfolgreiche Antwortanfrage. Achlas Installationsdokumentation unterscheidet Platzierung und Verifikation, während die Fehlerbehebungshinweise Widget- und Suchprobleme trennen. Beginnen Sie auf der durch Ihre Beobachtung belegten Ebene.
Notieren Sie die genaue öffentliche Seite und den Zustand beim Auftreten des Problems. Die Vorschau eines angemeldeten Redakteurs belegt nicht das anonyme Besuchererlebnis. Halten Sie fest, ob die Seite frisch geöffnet, erneut besucht oder nach einer Einwilligungsentscheidung aufgerufen wurde.
Der Ressourcen- und Zustandsmatrix folgen
Nutzen Sie dieses eigene Arbeitsblatt, um Belege statt vermuteter Lösungen festzuhalten. Die Zeilen beschreiben mögliche Bedingungen, keine Messungen eines realen Vorfalls.
| Stufe | Zu erfassende Belege | Frage an den Verantwortlichen |
|---|---|---|
| Seiten-Markup | Erwartete Integration auf der veröffentlichten Seite vorhanden oder nicht | Ist dieses Template oder dieser Connector für den vorgesehenen Seitenumfang zuständig? |
| Loader | Skript-URL, Anfragestatus und relevante Konsolenmeldung | Wurde der Loader angefordert, blockiert oder konnte er nicht laden? |
| Konfiguration | Konfigurationsanfrage und beobachtbare Antwort | Erreichte sie den erwarteten Dienst und ist der dokumentierte Zustand bereit? |
| Antwortanfrage | Verhalten nach einer öffentlichen Testfrage | Ist die Anfrage blockiert, abgewiesen oder liefert sie eine nutzbare Antwort? |
| Eingebundene Oberfläche | Sichtbare Bedienelemente sowie verborgene oder verschobene Elemente | Wurde das Widget eingebunden, erscheint aber nicht am erwarteten Ort? |
| Einwilligungsfolge | Beobachtungen bei neuem Besuch, Ablehnung, Zustimmung und erneutem Besuch | Ist das verzögerte Laden beabsichtigt und funktioniert die freigegebene Folge? |
Lassen Sie unbekannte Felder unbekannt. „Keine Anfrage beobachtet“ und „Anfrage abgewiesen“ sind unterschiedliche Befunde. Erfassen Sie möglichst eine konkrete Konsolenmeldung oder ein Anfrageergebnis, statt jeden Fehler als „CORS“ zu bezeichnen.
Ergänzen Sie die fehlerhafte Zeile um eine Abnahmebedingung. „Nach der freigegebenen Einwilligungswahl erreicht die dokumentierte Konfigurationsanfrage den vorgesehenen Dienst“ ist nützlicher als „Den Bot sichtbar machen“. Bei einer verborgenen Oberfläche könnte die Bedingung eine bestimmte veröffentlichte Seite und den vorgesehenen Ort des Bedienelements nennen. Beides sind vorgeschlagene Kriterien, keine abgeschlossenen Prüfungen.
Weisen Sie die Zeile dem Verantwortlichen dieser Ebene zu. Ein Templateproblem gehört zum Website-Betreuer, eine strittige Richtlinienanforderung zum Sicherheitsverantwortlichen und eine beabsichtigte Verzögerung zum Einwilligungsverantwortlichen. Der Anbietersupport muss möglicherweise einen dokumentierten Mindestbedarf klären. Ändern Sie nicht eine andere Ebene, nur weil deren Einstellungen leichter erreichbar sind.
Bestimmen Sie auch den Integrationsmechanismus. Achlas WordPress-Connector und Drupal-Modul nutzen einen eigenen Loader statt eines direkt eingefügten /w.js-Tags. Die aktuellen Installationsanweisungen beschreiben den Unterschied. Allein das Fehlen dieses bestimmten Tags belegt keinen ausgefallenen Connector.
Nutzen Sie zur Prüfung der Antwortstufe eine kontrollierte öffentliche Frage. Hier geht es um den funktionierenden Anfrageweg, nicht um einen neuen Antwortqualitätsbenchmark. Sensible Kontodetails gehören weder in Testeingaben noch in Diagnoseaufzeichnungen.
Den Browser-Richtlinienfehler vor einer Direktivenänderung lesen
Content Security Policy ist eine Browserrichtlinie für Ressourcen. Der CSP-Leitfaden von MDN erläutert, wie sie einschränkt, welche Inhalte eine Seite laden oder ausführen darf. Ein Widget kann mehr als sein erstes Skript benötigen; auf einen erfolgreichen Loader können daher eine blockierte Konfigurationsanfrage oder blockierte Styles folgen.
Die Dokumentation zu script-src behandelt Skriptquellen und Ausführung. Die Dokumentation zu connect-src behandelt Verbindungen über Schnittstellen wie fetch. Styles und Frames haben eigene Richtlinienanforderungen. Ordnen Sie die tatsächliche Browsermeldung der genannten Ressource und Direktive zu.
Erstellen Sie einen kleinen Ressourceneintrag: angeforderte URL, erwarteter Anbieter, Ressourcentyp, genannte Direktive, beobachtetes Ergebnis und zuständiger Richtlinienverantwortlicher. Prüfen Sie die aktuell dokumentierten Anbieteranforderungen. Leiten Sie Ursprünge nicht aus dem Beispiel eines fremden Anbieters ab und genehmigen Sie keinen weitreichenden Platzhalter, nur um die Warnung zu beseitigen.
Die CSP-Fehlerbehebung von Intercom beschreibt Ressourcen und Richtliniendiagnose für Intercom. Die tawk.to-Hinweise zu fehlenden Widget-Bildern behandeln dessen eigene Ressourcensymptome. Diese Seiten zeigen, warum eine teilweise sichtbare Oberfläche ein ressourcenspezifisches Problem haben kann; es sind keine Konfigurationsrezepte für Achla.
Verwendet der Sicherheitsverantwortliche eine Report-only-Richtlinie zur Beobachtung, trennen Sie sie von der durchgesetzten Richtlinie. MDN unterscheidet Meldung und Durchsetzung. Eine Report-only-Beobachtung beweist nicht, dass die durchgesetzte Richtlinie das Widget erlaubt. Auch berechtigt deren Ergänzung nicht zum Entfernen bestehender Schutzmaßnahmen.
Einwilligung als Abfolge von Zuständen behandeln
Verzögertes Laden kann beabsichtigt sein. Klären Sie vor der Diagnose eines fehlenden Skripts als Defekt das freigegebene Ladeverhalten der Website und die Verantwortung für ihre Einwilligungskonfiguration.
Die Dokumentation zum Laden nach Einwilligung von ChatLab beschreibt einen ausdrücklichen Ansatz für ChatLab. Sie belegt weder eine automatische Integration mit jedem Consent-Manager noch dieselbe Abfolge bei einem anderen Anbieter. Der zuständige Website-Verantwortliche muss die anwendbare Einordnung und die Anforderungen bestimmen.
Verwenden Sie für jeden vorgesehenen Zustand einen eigenen Eintrag:
| Besucherzustand | Was zu beobachten ist | Was nicht angenommen werden darf |
|---|---|---|
| Neuer Besucher | Wird der Loader vor einer Entscheidung angefordert? | Jeder Chatbot müsse sofort laden |
| Ablehnung | Bleibt das freigegebene Ablehnungsverhalten erhalten? | Ein fehlendes Widget sei automatisch ein Defekt |
| Zustimmung | Beginnt und endet die erwartete Ladesequenz? | Ein erfolgreiches Skript beweise die gesamte Interaktion |
| Erneuter Besuch | Erzeugen gespeicherte Entscheidungen das gewünschte Verhalten? | Die Redakteurssitzung repräsentiere jeden Besucher |
Das sind Beobachtungshilfen, keine juristischen Schlussfolgerungen oder behaupteten Testergebnisse. Weichen erwartetes und beobachtetes Verhalten ab, notieren Sie den Zustand und geben Sie dem Einwilligungsverantwortlichen einen reproduzierbaren Befund. Umgehen Sie den Einwilligungsmechanismus nicht als allgemeine Abkürzung zur Fehlerbehebung.
Ein Einwilligungswerkzeug kann das Skriptladen steuern, während eine Browserrichtlinie eine spätere Anfrage kontrolliert. Erfassen Sie beides, statt voreilig eine Erklärung auszuwählen. Ein Zustand kann mehr als ein unabhängiges Problem sichtbar machen.
Was, wenn eine strenge Style-Richtlinie nicht zum Widget passt?
Manchmal lautet die richtige Schlussfolgerung, dass die dokumentierten Widget-Anforderungen nicht mit der Website-Richtlinie vereinbar sind.
Achlas aktueller Installationsleitfaden beschreibt, dass das Widget sein Stylesheet als style-Element einfügt, und führt eine Inline-Style-Erlaubnis unter den CSP-Anforderungen auf. Dies ist ein mit dem Sicherheitsverantwortlichen zu prüfender Kompatibilitätsfakt, keine Empfehlung für eine pauschale Ausnahme mit unsafe-inline. Die geprüfte Dokumentation belegt keine Achla-API für Nonce- oder Hash-Integration.
Ein anderer Anbieter kann einen anderen Mechanismus dokumentieren. Das CSP-Changelog von SiteSpeakAI beschreibt Nonce-Unterstützung für dessen eigenes Widget. Diese Aussage belegt keine entsprechende Unterstützung bei Achla und rechtfertigt kein Kopieren des Attributs in ein anderes Skript.
Verlangt die Website eine strenge Nonce- oder Hash-Richtlinie, halten Sie die Integration bis zum Nachweis kompatiblen Verhaltens an. Fordern Sie aktuelle Belege beim Anbieter an oder bewerten Sie eine Alternative, deren dokumentierte Anforderungen zur Richtlinie passen. Beziehen Sie den Richtlinienverantwortlichen ein: Eine sichtbar funktionierende Schaltfläche ist keine Abnahme einer geänderten Sicherheitsgrenze.
Auch die CSP-Fehlerbehebung von BoldDesk behandelt die Anforderungen seines eigenen Live-Chat-Widgets. Nutzen Sie anbieterspezifische Dokumentation für gezielte Fragen, nicht um Ausnahmen mehrerer Anbieter zu einer freizügigen Richtlinie zu kombinieren.
Ein bereinigtes Diagnosepaket vorbereiten
Eine nützliche Übergabe ermöglicht es Website-Betreuer, Einwilligungsverantwortlichem oder Anbieter, den Fehler ohne private Informationen nachzustellen.
Nennen Sie öffentliche Seite, Beobachtungsdatum, Integrationsmechanismus, vorgesehenen Platz, Einwilligungszustand und gescheiterte Matrixstufe. Ergänzen Sie betreffenden Ressourcenursprung, Anfrageergebnis und Konsolenmeldung. Geben Sie an, ob die Oberfläche fehlte, verborgen war, konfiguriert war, aber nicht antworten konnte, oder auf eine vorgesehene Einwilligungsentscheidung wartete.
Ein hypothetischer Eintrag könnte lauten: „Veröffentlichte Richtlinienseite; neue anonyme Sitzung; Zustimmung gewählt; Loader angefordert; Konfigurationsanfrage durch die genannte Verbindungsdirektive blockiert; noch keine Antwortanfrage.“ Das grenzt die Untersuchung ein, ohne zu behaupten, ein realer Kunde habe diese Folge erlebt.
Entfernen Sie Zugangsdaten, private Schlüssel, Sitzungskennungen, persönliche Nachrichten und Kontodaten. Ein Diagnosepaket sollte weder ein vollständiges privates Gespräch noch ein ungeprüftes Netzwerkarchiv enthalten. Erfassen Sie nur das Minimum, das Ressource und Fehlerzustand unterscheidet, und benennen Sie einen Verantwortlichen für die nächste Entscheidung.
Denselben Zustand nach einer freigegebenen Korrektur erneut prüfen
Definieren Sie Korrektur und Verantwortlichen vor der Umsetzung. Wiederholen Sie dann dieselbe Seite, denselben Besucherzustand und dieselbe öffentliche Frage. Notieren Sie, was sich geändert hat und welche Stufe nun erfolgreich oder weiterhin unbekannt ist. Bündeln Sie nicht Skriptaustausch, Einwilligungsänderung und Richtlinienänderung in einem unerklärten Ergebnis.
Meldet die Konsole weiter einen Richtlinienverstoß, geben Sie genaue Direktive und Ursprung an den Sicherheitsverantwortlichen zurück. Ist die Konfigurationsantwort nicht bereit, folgen Sie den dokumentierten Voraussetzungen des Anbieters. Ist nur die Oberfläche verborgen, untersuchen Sie ihre Platzierung statt Netzwerkberechtigungen zu ändern.
Ein erfolgreicher Ladewiederholungstest belegt nur das beobachtete Ladeverhalten. Er bescheinigt weder Barrierefreiheit noch Datenschutzkonformität, Antwortgenauigkeit oder Kompatibilität mit jedem Browser und jeder Seite. Mehrdeutige Fehler sollten mit einer Beleganforderung offen bleiben, statt mit einem ungeprüften Umgehungsweg eines anderen Anbieters beantwortet zu werden.
Aktuelle Achla-Anforderungen vor dem Verbinden bewerten
Nutzen Sie die ausgefüllte Matrix als Kompatibilitätscheckliste: Passen dokumentierte Installation, Richtlinienanforderungen und öffentliche Inhaltsanforderungen dieses Widgets zu genau dieser Website? Für CMS-spezifische Wege prüfen Sie den vorhandenen WordPress-Connector oder das Drupal-Modul. Ein allgemeiner Skriptweg hängt davon ab, ob die tatsächliche Website ihn einbinden und zulassen kann; er belegt keine eigene Integration mit einem anderen CMS.
Sind Oberfläche und Anfrageweg verstanden, verwenden Sie den separaten Leitfaden für Chatbots mit Website-Inhalten für Quellenentscheidungen und das Bewertungsblatt für belegte Antworten zur Antwortstützung. Passt der dokumentierte Umfang, starten Sie den vorhandenen Onboarding-Ablauf. Halten Sie eine Unvereinbarkeit mit strengen Richtlinien an, bis Belege sie klären. Das nützliche Ergebnis ist eine prüfbare Entscheidung über Ihre Website, deren Schutzmaßnahmen weiterhin verantwortet und unverändert gewahrt bleiben.
