Chatbot in WordPress einbinden: Widget, Block oder Shortcode

Öffne WordPress Admin → WebChatAgent → General. Füge die vollständige UUID in Chatbot ID ein, aktiviere das Widget nur für einen websiteweiten Floating-Button und wähle Save Settings. Schreibgeschützter Titel und Vorschau müssen den vorgesehenen Assistenten zeigen.

Der blaue Hinweis ist entscheidend: Darstellung, Position, Texte, Wissen und Antwortverhalten werden im WebChatAgent-Dashboard verwaltet. WordPress soll keine zweite widersprüchliche Konfigurationsquelle werden.

Ein erfolgreicher Save bestätigt nur die lokale Speicherung. Erst geladener Assistententitel und Vorschau belegen zusätzlich, dass ID, öffentliche Konfigurationsabfrage und Allowed websites zusammenpassen.

Nutze das Floating Widget für websiteweiten Support, der beim Seitenwechsel verfügbar bleiben soll. Verwende einen Inline-Chat, wenn das Gespräch direkt zu einer Support-, Pricing-, Onboarding- oder Wissensseite gehört.

Öffne Inline Embed für beide Editorwege. Gutenberg-Nutzer sollten WebChatAgent Inline Chat bevorzugen, weil Redakteure den Block visuell finden und optional eine seitenbezogene ID setzen können. Classic Editor, Elementor, Divi und Text-Widgets verwenden `[webchatagent_inline]` in einem Shortcode-fähigen Element.

Beide Inline-Methoden übernehmen standardmäßig die Chatbot-ID aus General. Dadurch bleiben spätere Assistentenwechsel zentral und wartungsarm.

Öffne eine normale Frontend-Seite und prüfe, dass der Chat-Button im sicheren Bereich rechts unten bleibt und weder Consent-Steuerung, Checkout-Aktionen noch mobile Navigation verdeckt. Öffne ihn einmal und kontrolliere Assistententitel, Begrüßung, Farben und Tastaturfokus.

Das Floating Widget lädt dort, wo das aktive Theme `wp_footer()` ausführt. Erscheint es in der Admin-Vorschau, aber nicht auf der Website, prüfe Theme-Footer und Optimierungs-Plugin vor einer Änderung der Chatbot-ID.

Teste Startseite, eine gecachte Unterseite und ein privates Browserfenster. Eine bereits warme Admin-Sitzung kann Consent-, Cache- und Persistenzprobleme verdecken.

Erstelle oder bearbeite die Zielseite, öffne Block Inserter und suche nach „chat“. Wähle WebChatAgent Inline Chat unter Embeds. Setze vor dem Block eine klare Überschrift und einen Satz, der Besuchern mögliche Fragen erklärt.

Der Editor zeigt absichtlich einen Platzhalter statt des echten Remote-Widgets. So entstehen beim Verschieben von Inhalten keine Besuchersitzungen oder unnötiger Chat-Traffic.

Veröffentliche zunächst auf Staging. Öffne die öffentliche URL und prüfe die vollständige Chat-Höhe auf Desktop und Mobil; bewerte das Endlayout nicht nur anhand des Editor-Platzhalters.

Lasse Chatbot ID in der Block-Seitenleiste leer, um General Settings zu übernehmen. Trage nur dann eine vollständige UUID ein, wenn die Seite bewusst einen Spezialassistenten benötigt – etwa Onboarding-Hilfe im Portal bei allgemeinem Floating-Support.

Dokumentiere Seiten-URL, Assistentenname und verantwortliche Person für den Override. Wird ein Assistent gelöscht oder ersetzt, bleiben versteckte Ausnahmen sonst leicht unbemerkt.

Antworten Inline- und Floating-Chat unterschiedlich, vergleiche zuerst öffentliche Assistentennamen und IDs, bevor du Wissen oder Modellkonfiguration untersuchst.

Füge ein Shortcode- oder HTML-fähiges Modul ein und setze `[webchatagent_inline]` ein. Das ist die sicherste Variante für Classic Editor, Elementor, Divi, wiederverwendbare Widgets und Templates mit WordPress-Shortcodes.

Für einen bewusst spezialisierten Assistenten nutze `[webchatagent_inline chatbot-id="UUID"]`. Der Alias `chatbot_id="UUID"` ist für Builder vorgesehen, die Bindestriche in Attributnamen entfernen.

Füge bei aktivem Plugin nicht zusätzlich das rohe JavaScript-Installationssnippet auf derselben Seite ein. Das Plugin lädt das Inline-Asset bereits nur dort, wo Block oder Shortcode gerendert wird.

Soll eine Inline-Seite nur einen Chat enthalten, deaktiviere den globalen Floating-Schalter websiteweit oder entferne dort den Inline-Block. Da das Plugin keine seitenbezogene Floating-Ausnahme bietet, sollte eine gemischte Strategie vor dem Rollout geplant werden.

Lade optionalen Chat- oder Tracking-Speicher erst nach dem laut deiner Richtlinie erforderlichen Consent-Status. Das WebChatAgent-Widget akzeptiert einen Consent-Status; dein WordPress-Consent-Manager entscheidet weiterhin, wann optionale Skripte laufen dürfen. Dokumentiere Rechtsgrundlage, Aufbewahrung und Auftragsverarbeitung.

Schließe `web-chat-agent.js` und `chat-widget-inline.js` von Delay, Script-Kombination und aggressiver Minifizierung aus. Leere nach Platzierungs- oder ID-Änderungen WordPress-, Page-Builder-, Reverse-Proxy- und CDN-Caches.

Öffne die veröffentlichte Seite in einer frischen Besuchersitzung. Prüfe genau einen Inline-Chat, den beabsichtigten Floating-Status, englische Bedienelemente, lesbare mobile Breite und fehlenden horizontalen Überlauf. Stelle danach eine Frage mit exakter Antwort in einer indexierten Quelle.

Geprüfte Eingabe: „What is the exact onboarding code for the WordPress embed lab?“ Erwartetes und beobachtetes Ergebnis: `WP-EMBED-47`. Das echte Inline-Widget antwortete: „The exact onboarding code for the WordPress embed lab is WP-EMBED-47.“

Wiederhole dieselbe Frage nach Änderungen an Plugin, Theme, Cache, Consent, Assistent oder Wissen. Teste zusätzlich eine unbelegte Frage und verlange eine ehrliche Nichtwissen-Antwort statt einer plausiblen Vermutung.