If a WordPress chatbot widget covers a button on mobile, choose its placement around the page's main task and the person who controls the published template. A floating launcher that suits an article may obstruct a contact form. An inline box can fit a help page while appearing nowhere else. Record those differences before changing the widget globally.
This guide provides a page ownership register, a placement decision table and an acceptance record. They help an owner or agency decide where chat belongs without treating an editor preview as proof. The examples are proposed scenarios, not customer tests or measured results.
Author: Achla AI, Organization. Reviewed: 14 October 2026. Prepared with AI assistance from official documentation and inspected product sources. This review date is not a publication date.
Start with the mobile task, not the chat corner
Write one sentence for each page family: “The visitor needs to read this policy,” “send this enquiry,” or “find the next relevant article.” Then identify the controls required to finish that task. A chatbot should help someone reach information without making the page's existing action harder.
Avoid choosing a universal corner first and negotiating around every collision later. The position of a phone button, cookie control or sticky navigation belongs in the decision. Chat placement is a shared layout choice, so include the person responsible for those elements.
There is a real audience need here: a WordPress support question describes a chat icon overlapping a mobile publishing button. That historical report concerns another plugin; it does not establish a defect in Achla or your site.
Who controls the markup on each WordPress page?
Separate three things: where someone edits content, which template produces the public page, and which integration loads the widget. They may have different owners. A content editor can move a block while an agency controls the footer and a plugin supplies the chat launcher.
For Gutenberg content, WordPress provides a Shortcode block for inserting shortcode output. Its presence identifies an editing location, not the final behavior of every integration. Write down which page contains it and verify the resulting public markup.
For Elementor pages, the documented HTML widget accepts HTML, scripts and shortcodes. That capability does not certify a particular chatbot in every Elementor template, popup or theme. Treat the builder as one part of the actual configuration you must inspect.
WordPress's Custom HTML documentation also explains permission-based filtering of disallowed markup. If code exists in someone's editor but is absent after saving, investigate the allowed editing workflow. Do not grant broader permissions simply to force a widget into a page.
Use this ownership register before deciding placement:
| Page family | Main visitor task | Public template or layout | Content editor | Widget output owner | Shared-control owner |
|---|---|---|---|---|---|
| Service pages | Understand the service | Record actual template | Name editor | Name maintainer | Name CTA owner |
| Articles | Read and find related information | Record article template | Name editor | Name maintainer | Name navigation owner |
| Contact page | Complete the existing enquiry | Record form layout | Name editor | Name maintainer | Name form owner |
Leave unknown owners visible. “Someone manages Elementor” is not enough to assign a fix affecting the site's shared footer.
Choose placement by visitor task and page family
The following table offers starting proposals, not defaults that have already passed testing. Choose a placement you can actually maintain under the integration's documented rules.
| Page family | Candidate placement | Decision question | Evidence needed |
|---|---|---|---|
| Brochure/service page | Floating launcher | Can visitors still reach the page CTA? | Public page with sticky controls visible |
| Long article | Floating launcher or a deliberate inline section | Is help discoverable without covering reading controls? | Actual article template and scroll states |
| Policy/help page | Inline in a clearly owned section | Does the box interrupt essential conditions? | Published content order and source links |
| Contact/form page | Existing contact path; evaluate chat separately | Can the form's own task finish while chat is open and closed? | Form controls, validation and software keyboard states |
For Achla's official WordPress connector, there is one placement mode for the whole site. In Inline mode, it loads on pages containing its shortcode or block; other pages get no widget. In Bubble or Attach mode, the shortcode/block does not provide an additional inline box. A floating button everywhere plus inline on one page requires the separately documented manual approach. See the current installation contract.
That constraint matters more than a preferred visual layout. A table proposing different placements cannot magically make a connector switch mode by page. If your requirements conflict, revise the proposed coverage or have the responsible maintainer evaluate an appropriate integration approach. The existing plugin versus embed guide covers that broader installation decision.
Build the placement and obstruction register
Create one row per meaningful page family, then add individual exceptions. Reuse the ownership table rather than keeping a second list of names. The register should connect a visible problem to a specific page, state and responsible person.
| Field | What to record |
|---|---|
| Page and task | Exact public URL and the action the visitor must complete |
| Editing and output scope | Editor, actual public template, widget mode and owner |
| Nearby controls | Sticky navigation, local CTA, consent control and form actions |
| Visitor state | New or returning visitor; relevant consent state; chat open or closed |
| Input state | Software keyboard visible or hidden, where applicable |
| Evidence | Screenshot or short reproduction; browser/device; review date |
| Finding | Specific covered control or missing expected output; “not checked” if unknown |
| Proposed correction | Smallest scoped change, responsible owner and affected page family |
| Retest and verdict | Same task/state after the change; accept, revise or pause |
Use the register in this order:
- Choose a representative public page and identify its actual template owner.
- Record the intended placement and the competing page controls.
- Capture the specific visitor state and any observed obstruction.
- Assign the smallest correction and repeat that same task before deciding.
Choose evidence names that another maintainer can recognize. “Contact page, chat open, keyboard visible, submit action unreachable” is more useful than “mobile looks bad.” A screenshot alone may show the collision but omit the sequence that produces it, so retain both.
Record absence as carefully as obstruction. In Achla Inline mode, a page without the inline shortcode/block has no widget by design. That is a coverage decision to review, rather than evidence that a popup should appear everywhere. Mark whether the absence is intended before opening a support issue.
Review the published page with its real competing controls
Use the public frontend that visitors receive. Check which expected container or loader is actually present, then confirm where the widget renders. Compare that result with the ownership register; an editor's canvas cannot settle which shared template or integration produced the final page.
Inspect the page with its own controls present. Elementor's Floating Button documentation describes placement controls for its floating elements. If the site already uses one, record its owner and position beside the chat requirement. Do not assume two independently positioned floating components will coordinate automatically.
Pay attention to the changing page state: a consent control may remain visible, a sticky CTA may appear after scrolling, or the software keyboard may reduce the usable area during form entry. Check the page action in each relevant state. The goal is a reproducible observation, not a generic promise that “mobile responsive” solves competing controls.
W3C's Focus Not Obscured guidance explains the requirement that focused components not be completely hidden by author-created content. Use that as a separate accessibility consideration. This placement register does not establish complete WCAG conformance.
Also check who supplies the loader. Achla documents using the official connector or a manual tag, never both. Its connector uses its own loader rather than a literal manual /w.js tag. A search for that one filename therefore cannot prove the plugin failed. Use the documented troubleshooting checks before adding another installation.
Worked examples: the same widget, different page owners
These hypothetical examples illustrate decisions to investigate; none records a completed browser test.
An article template and a contact page share a footer. The article owner proposes a floating launcher. The contact-page owner identifies a sticky enquiry action in the same area. Record both page families before changing the global placement. The proposed next step is to verify whether the shared placement preserves both tasks, not to accept the article preview as a site-wide result.
A Gutenberg help page contains an inline shortcode. The content owner places the box below the introductory explanation. The maintainer proposes Achla Inline mode and notes that ordinary service pages have no shortcode. The register explicitly says those service pages will have no widget under this connector mode. The owner can accept that coverage proposal or revise it before setup.
An Elementor page looks correct in the editor. The public page may use a shared template controlled by another person. Start by identifying the published template and actual output. If the required container is not present when the widget mounts, changing colors or moving the editor's placeholder does not prove the requirement has been satisfied. Assign the public-output question to the template owner.
These examples keep three decisions separate: where the interface is edited, where it appears, and whether visitors can finish the page's task.
Decide accept, revise or pause with a named owner
Accept a placement only for the pages and states with recorded evidence. A passing article row does not close an unchecked contact row. Keep a site-wide requirement unresolved until the relevant page families have been reviewed.
Revise when an identified control is covered, an inline location appears in the wrong context, or intended coverage differs from the connector's output. Assign the correction to the owner who controls that scope. Changing a shared template requires rechecking its affected rows, not only the page used to demonstrate the fix.
Pause when the visitor's primary action cannot be completed or ownership is unclear. Retain the ordinary contact or navigation path while the decision is unresolved. For operational keyboard, screen-reader and viewport checks, use the separate existing search-bar accessibility guide. This article's decision remains placement ownership and page obstruction.
Evaluate the documented WordPress connector against your register
Review the WordPress connector against your actual page coverage and placement requirements. Achla's documented job is public website-content answers with supporting sources. Do not treat it as verified staffed live chat, booking or form automation.
Compare the documented modes with your register, inspect the current plans, and use onboarding if that bounded job fits. If you are still choosing the type of search experience, the AI site-search overview supplies wider context. Keep your recorded placement conditions available for the owner who will approve any actual launch.