Wenn ein WordPress-Chatbot-Widget auf dem Smartphone eine Schaltfläche verdeckt, richten Sie seine Platzierung an der Hauptaufgabe der Seite und der für das veröffentlichte Template zuständigen Person aus. Ein schwebender Chat-Button, der zu einem Artikel passt, kann ein Kontaktformular behindern. Eine Inline-Box kann auf einer Hilfeseite sinnvoll sein und auf anderen Seiten ganz fehlen. Halten Sie diese Unterschiede fest, bevor Sie das Widget global ändern.
Dieser Leitfaden bietet ein Register der Seitenzuständigkeiten, eine Entscheidungstabelle zur Platzierung und ein Abnahmeprotokoll. Damit können Website-Verantwortliche oder Agenturen den passenden Ort für den Chat bestimmen, ohne eine Editorvorschau als Nachweis zu behandeln. Die Beispiele sind vorgeschlagene Szenarien, keine Kundentests oder gemessenen Ergebnisse.
Autor: Achla AI, Organisation. Geprüft am 14. Oktober 2026. Mit KI-Unterstützung anhand offizieller Dokumentation und geprüfter Produktquellen erstellt. Dieses Prüfdatum ist kein Veröffentlichungsdatum.
Mit der mobilen Aufgabe beginnen, nicht mit der Chat-Ecke
Formulieren Sie für jede Seitengruppe einen Satz: „Der Besucher muss diese Richtlinie lesen“, „diese Anfrage senden“ oder „den nächsten relevanten Artikel finden“. Bestimmen Sie anschließend die dafür nötigen Bedienelemente. Ein Chatbot soll Informationen zugänglich machen, ohne die bereits vorgesehene Seitenaktion zu erschweren.
Wählen Sie nicht zuerst eine universelle Ecke, um anschließend jeden Konflikt einzeln auszuhandeln. Die Position einer Anrufschaltfläche, einer Einwilligungssteuerung oder einer fixierten Navigation gehört zur Entscheidung. Die Chat-Platzierung ist eine gemeinsame Layoutentscheidung. Beziehen Sie deshalb die für diese Elemente zuständige Person ein.
Der Bedarf ist konkret: Eine WordPress-Supportfrage beschreibt ein Chat-Symbol, das auf dem Smartphone eine Veröffentlichungsschaltfläche überdeckt. Dieser ältere Bericht betrifft ein anderes Plugin. Er belegt keinen Fehler bei Achla oder auf Ihrer Website.
Wer kontrolliert das Markup der einzelnen WordPress-Seiten?
Trennen Sie drei Dinge: den Ort der Inhaltsbearbeitung, das Template für die öffentliche Seite und die Integration, die das Widget lädt. Dafür können unterschiedliche Personen zuständig sein. Ein Redakteur kann einen Block verschieben, während eine Agentur den Footer kontrolliert und ein Plugin den Chat-Button bereitstellt.
Für Gutenberg-Inhalte stellt WordPress einen Shortcode-Block bereit, der die Ausgabe eines Shortcodes einfügt. Seine Existenz zeigt einen Bearbeitungsort, nicht das endgültige Verhalten jeder Integration. Notieren Sie, welche Seite ihn enthält, und prüfen Sie das daraus entstehende öffentliche Markup.
Bei Elementor-Seiten unterstützt das dokumentierte HTML-Widget HTML, Skripte und Shortcodes. Diese Möglichkeit zertifiziert keinen bestimmten Chatbot für jedes Elementor-Template, Popup oder Theme. Betrachten Sie den Page Builder als einen Bestandteil der tatsächlich zu prüfenden Konfiguration.
Die WordPress-Dokumentation zu Custom HTML erläutert außerdem die berechtigungsabhängige Filterung unzulässigen Markups. Wenn Code im Editor vorhanden ist, nach dem Speichern aber fehlt, untersuchen Sie den erlaubten Bearbeitungsablauf. Erweitern Sie Berechtigungen nicht allein deshalb, um ein Widget auf einer Seite zu erzwingen.
Nutzen Sie vor der Platzierungsentscheidung dieses Zuständigkeitsregister:
| Seitengruppe | Hauptaufgabe des Besuchers | Öffentliches Template oder Layout | Inhaltsredaktion | Zuständigkeit für die Widget-Ausgabe | Zuständigkeit für gemeinsame Bedienelemente |
|---|---|---|---|---|---|
| Leistungsseiten | Die Leistung verstehen | Tatsächliches Template erfassen | Redaktion benennen | Wartungsverantwortlichen benennen | CTA-Verantwortlichen benennen |
| Artikel | Lesen und verwandte Informationen finden | Artikel-Template erfassen | Redaktion benennen | Wartungsverantwortlichen benennen | Navigationsverantwortlichen benennen |
| Kontaktseite | Die vorhandene Anfrage abschließen | Formularlayout erfassen | Redaktion benennen | Wartungsverantwortlichen benennen | Formularverantwortlichen benennen |
Lassen Sie unbekannte Zuständigkeiten sichtbar. „Jemand betreut Elementor“ reicht nicht aus, um eine Änderung am gemeinsamen Website-Footer zuzuweisen.
Platzierung nach Besucheraufgabe und Seitengruppe wählen
Die folgende Tabelle enthält Ausgangsvorschläge, keine bereits getesteten Standardlösungen. Wählen Sie eine Platzierung, die Sie unter den dokumentierten Regeln der Integration tatsächlich betreiben können.
| Seitengruppe | Mögliche Platzierung | Entscheidungsfrage | Benötigter Nachweis |
|---|---|---|---|
| Präsentations- oder Leistungsseite | Schwebender Chat-Button | Erreichen Besucher weiterhin den Seiten-CTA? | Öffentliche Seite mit sichtbaren fixierten Bedienelementen |
| Langer Artikel | Schwebender Chat-Button oder bewusst gewählter Inline-Abschnitt | Ist die Hilfe auffindbar, ohne Lesebedienelemente zu verdecken? | Tatsächliches Artikel-Template und Scrollzustände |
| Richtlinien- oder Hilfeseite | Inline in einem Abschnitt mit klarer Zuständigkeit | Unterbricht die Box wesentliche Bedingungen? | Reihenfolge der veröffentlichten Inhalte und Quellenlinks |
| Kontakt- oder Formularseite | Vorhandener Kontaktweg; Chat getrennt bewerten | Lässt sich die Formularaufgabe bei geöffnetem und geschlossenem Chat abschließen? | Formularbedienelemente, Validierung und Bildschirmtastaturzustände |
Für den offiziellen WordPress-Connector von Achla gilt ein Platzierungsmodus für die gesamte Website. Im Modus Inline wird das Widget auf Seiten mit seinem Shortcode oder Block geladen; auf anderen Seiten erscheint kein Widget. Im Modus Bubble oder Attach erzeugt der Shortcode beziehungsweise Block keine zusätzliche Inline-Box. Ein schwebender Button überall plus Inline-Ausgabe auf einer einzelnen Seite erfordert den gesondert dokumentierten manuellen Ansatz. Beachten Sie die aktuellen Installationsregeln.
Diese Einschränkung ist wichtiger als das bevorzugte Erscheinungsbild. Eine Tabelle mit unterschiedlichen Platzierungsvorschlägen kann den Connector nicht dazu bringen, seinen Modus je nach Seite zu wechseln. Bei widersprüchlichen Anforderungen müssen Sie die geplante Abdeckung überarbeiten oder den zuständigen Maintainer eine geeignete Integration bewerten lassen. Der vorhandene Leitfaden zu Plugin und eingebettetem Skript behandelt diese übergeordnete Installationsentscheidung.
Ein Register für Platzierung und Überdeckungen anlegen
Legen Sie je relevanter Seitengruppe eine Zeile an und ergänzen Sie einzelne Ausnahmen. Verwenden Sie die Zuständigkeitstabelle weiter, statt eine zweite Namensliste zu pflegen. Das Register soll ein sichtbares Problem mit einer bestimmten Seite, einem Zustand und einer verantwortlichen Person verbinden.
| Feld | Was festzuhalten ist |
|---|---|
| Seite und Aufgabe | Genaue öffentliche URL und die vom Besucher abzuschließende Aktion |
| Bearbeitungs- und Ausgabebereich | Editor, tatsächliches öffentliches Template, Widget-Modus und Zuständigkeit |
| Benachbarte Bedienelemente | Fixierte Navigation, lokaler CTA, Einwilligungssteuerung und Formularaktionen |
| Besucherzustand | Neuer oder wiederkehrender Besucher; relevanter Einwilligungszustand; Chat geöffnet oder geschlossen |
| Eingabezustand | Bildschirmtastatur sichtbar oder ausgeblendet, sofern relevant |
| Nachweis | Screenshot oder kurze Reproduktionsanleitung; Browser und Gerät; Prüfdatum |
| Feststellung | Konkret verdecktes Bedienelement oder fehlende erwartete Ausgabe; bei Unklarheit „nicht geprüft“ |
| Vorgeschlagene Korrektur | Kleinste gezielte Änderung, verantwortliche Person und betroffene Seitengruppe |
| Wiederholungsprüfung und Entscheidung | Dieselbe Aufgabe und derselbe Zustand nach der Änderung; annehmen, überarbeiten oder aussetzen |
Gehen Sie dabei in dieser Reihenfolge vor:
- Wählen Sie eine repräsentative öffentliche Seite und identifizieren Sie die tatsächliche Template-Zuständigkeit.
- Erfassen Sie die geplante Platzierung und konkurrierende Bedienelemente der Seite.
- Dokumentieren Sie den konkreten Besucherzustand und jede beobachtete Überdeckung.
- Weisen Sie die kleinste Korrektur zu und wiederholen Sie dieselbe Aufgabe vor der Entscheidung.
Benennen Sie Nachweise so, dass ein anderer Maintainer sie erkennt. „Kontaktseite, Chat geöffnet, Tastatur sichtbar, Absenden nicht erreichbar“ ist hilfreicher als „mobil sieht es schlecht aus“. Ein Screenshot zeigt möglicherweise die Überschneidung, aber nicht die auslösende Abfolge. Bewahren Sie deshalb beides auf.
Dokumentieren Sie fehlende Ausgaben ebenso sorgfältig wie Überdeckungen. Im Achla-Modus Inline hat eine Seite ohne Inline-Shortcode oder entsprechenden Block absichtlich kein Widget. Das ist eine zu prüfende Abdeckungsentscheidung und kein Nachweis dafür, dass überall ein Popup erscheinen müsste. Halten Sie vor einer Supportanfrage fest, ob das Fehlen beabsichtigt ist.
Die veröffentlichte Seite mit ihren tatsächlichen konkurrierenden Bedienelementen prüfen
Verwenden Sie das öffentliche Frontend, das Besucher erhalten. Prüfen Sie, welcher erwartete Container oder Loader tatsächlich vorhanden ist, und bestätigen Sie anschließend den Ausgabeort des Widgets. Vergleichen Sie das Ergebnis mit dem Zuständigkeitsregister. Die Editoroberfläche kann nicht klären, welches gemeinsame Template oder welche Integration die endgültige Seite erzeugt hat.
Prüfen Sie die Seite mit ihren eigenen Bedienelementen. Die Elementor-Dokumentation zu Floating Buttons beschreibt Platzierungseinstellungen für die schwebenden Elemente des Builders. Wenn die Website bereits eines nutzt, erfassen Sie dessen Zuständigkeit und Position neben der Chat-Anforderung. Gehen Sie nicht davon aus, dass zwei unabhängig positionierte schwebende Komponenten sich automatisch abstimmen.
Achten Sie auf wechselnde Seitenzustände: Eine Einwilligungssteuerung kann sichtbar bleiben, ein fixierter CTA nach dem Scrollen erscheinen oder die Bildschirmtastatur den nutzbaren Bereich während der Formulareingabe verkleinern. Prüfen Sie die Seitenaktion in jedem relevanten Zustand. Ziel ist eine reproduzierbare Beobachtung, keine allgemeine Zusage, dass „mobil responsiv“ konkurrierende Bedienelemente löst.
Die W3C-Erläuterungen zu nicht verdecktem Fokus erklären die Anforderung, dass fokussierte Komponenten nicht vollständig durch vom Seitenautor erzeugte Inhalte verdeckt werden dürfen. Berücksichtigen Sie dies als eigenständigen Aspekt der Barrierefreiheit. Dieses Platzierungsregister belegt keine vollständige WCAG-Konformität.
Prüfen Sie außerdem, wer den Loader bereitstellt. Achla dokumentiert entweder den offiziellen Connector oder einen manuellen Tag, niemals beide gemeinsam. Der Connector verwendet einen eigenen Loader statt eines wörtlichen manuellen /w.js-Tags. Die Suche nach diesem einzelnen Dateinamen kann deshalb kein Plugin-Versagen belegen. Nutzen Sie die dokumentierten Fehlerbehebungsprüfungen, bevor Sie eine weitere Installation hinzufügen.
Durchgespielte Beispiele: dasselbe Widget, unterschiedliche Seitenverantwortliche
Diese hypothetischen Beispiele veranschaulichen zu untersuchende Entscheidungen. Keines dokumentiert einen abgeschlossenen Browsertest.
Ein Artikel-Template und eine Kontaktseite teilen sich einen Footer. Die Artikelverantwortlichen schlagen einen schwebenden Chat-Button vor. Die Kontaktseitenverantwortlichen weisen auf eine fixierte Anfrageaktion im selben Bereich hin. Erfassen Sie beide Seitengruppen, bevor Sie die globale Platzierung ändern. Der vorgeschlagene nächste Schritt ist zu prüfen, ob die gemeinsame Platzierung beide Aufgaben ermöglicht, statt die Artikelvorschau als Ergebnis für die gesamte Website anzunehmen.
Eine Gutenberg-Hilfeseite enthält einen Inline-Shortcode. Die Inhaltsverantwortlichen setzen die Box unter die Einführung. Der Maintainer schlägt den Achla-Modus Inline vor und notiert, dass gewöhnliche Leistungsseiten keinen Shortcode enthalten. Das Register hält ausdrücklich fest, dass diese Seiten in diesem Connector-Modus kein Widget erhalten. Der Website-Verantwortliche kann diese Abdeckung vor der Einrichtung annehmen oder überarbeiten.
Eine Elementor-Seite sieht im Editor richtig aus. Die öffentliche Seite kann ein gemeinsames Template verwenden, für das jemand anderes zuständig ist. Identifizieren Sie zuerst das veröffentlichte Template und die tatsächliche Ausgabe. Fehlt der erforderliche Container beim Mounten des Widgets, beweisen weder geänderte Farben noch ein verschobener Editorplatzhalter, dass die Anforderung erfüllt ist. Weisen Sie die Frage zur öffentlichen Ausgabe dem Template-Verantwortlichen zu.
Diese Beispiele trennen drei Entscheidungen: wo die Oberfläche bearbeitet wird, wo sie erscheint und ob Besucher die Seitenaufgabe abschließen können.
Mit benannter Zuständigkeit annehmen, überarbeiten oder aussetzen
Akzeptieren Sie eine Platzierung nur für Seiten und Zustände mit dokumentiertem Nachweis. Eine bestandene Artikelzeile schließt keine ungeprüfte Kontaktzeile ab. Lassen Sie eine websiteweite Anforderung offen, bis die relevanten Seitengruppen geprüft wurden.
Überarbeiten Sie, wenn ein bestimmtes Bedienelement verdeckt wird, eine Inline-Position im falschen Zusammenhang erscheint oder die vorgesehene Abdeckung von der Connector-Ausgabe abweicht. Weisen Sie die Korrektur der Person zu, die diesen Bereich kontrolliert. Nach einer Änderung an einem gemeinsamen Template sind die betroffenen Zeilen erneut zu prüfen, nicht nur die Seite, mit der die Korrektur demonstriert wurde.
Setzen Sie die Entscheidung aus, wenn die primäre Besucheraktion nicht abgeschlossen werden kann oder Zuständigkeiten unklar sind. Lassen Sie den gewöhnlichen Kontakt- oder Navigationsweg verfügbar, solange die Entscheidung offen ist. Praktische Tastatur-, Screenreader- und Viewport-Prüfungen behandelt der separate Leitfaden zur Barrierefreiheit der Suchleiste. Hier geht es weiterhin um Platzierungszuständigkeit und die Überdeckung von Seiteninhalten.
Den dokumentierten WordPress-Connector anhand Ihres Registers bewerten
Prüfen Sie den WordPress-Connector anhand Ihrer tatsächlichen Anforderungen an Seitenabdeckung und Platzierung. Achlas dokumentierte Aufgabe sind Antworten aus öffentlichen Website-Inhalten mit unterstützenden Quellen. Behandeln Sie ihn nicht als nachgewiesenen, personell betreuten Live-Chat oder als Buchungs- beziehungsweise Formularautomatisierung.
Vergleichen Sie die dokumentierten Modi mit Ihrem Register, prüfen Sie die aktuellen Tarife und nutzen Sie das Onboarding, wenn diese begrenzte Aufgabe passt. Falls Sie noch die Art der Sucherfahrung auswählen, liefert der Überblick zur KI-Websitesuche den größeren Zusammenhang. Halten Sie Ihre dokumentierten Platzierungsbedingungen für die Person bereit, die einen tatsächlichen Start freigeben wird.