Si un widget de chatbot de WordPress tapa un botón en el móvil, decide su ubicación según la tarea principal de la página y la persona que controla la plantilla publicada. Un botón flotante adecuado para un artículo puede obstaculizar un formulario de contacto. Una caja integrada puede encajar en una página de ayuda sin aparecer en ninguna otra. Registra estas diferencias antes de cambiar el widget en todo el sitio.
Esta guía ofrece un registro de responsables por página, una tabla para decidir la ubicación y un acta de aceptación. Ayudan al propietario o a la agencia a decidir dónde corresponde incluir el chat sin considerar la vista previa del editor como prueba. Los ejemplos son escenarios propuestos, no pruebas de clientes ni resultados medidos.
Autor: Achla AI, organización. Revisión: 14 de octubre de 2026. Elaborado con ayuda de IA a partir de documentación oficial y fuentes del producto examinadas. Esta fecha de revisión no es una fecha de publicación.
Empieza por la tarea móvil, no por la esquina del chat
Escribe una frase por cada familia de páginas: «El visitante necesita leer esta política», «enviar esta consulta» o «encontrar el siguiente artículo pertinente». Después identifica los controles necesarios para completar esa tarea. Un chatbot debe facilitar el acceso a la información sin dificultar la acción que ya existe en la página.
Evita elegir primero una esquina universal y negociar después cada colisión. La posición de un botón de llamada, un control de cookies o la navegación fija debe formar parte de la decisión. La ubicación del chat es una decisión compartida sobre la distribución: incluye a quien se responsabiliza de esos elementos.
La necesidad del público es real: una consulta en el soporte de WordPress describe un icono de chat que se superpone a un botón de publicación móvil. Ese informe histórico se refiere a otro plugin; no demuestra un defecto de Achla ni de tu sitio.
¿Quién controla el marcado de cada página de WordPress?
Separa tres cuestiones: dónde se edita el contenido, qué plantilla genera la página pública y qué integración carga el widget. Pueden tener responsables distintos. Un editor de contenido puede mover un bloque, mientras una agencia controla el pie de página y un plugin proporciona el botón de chat.
Para contenido de Gutenberg, WordPress ofrece un bloque Shortcode que inserta la salida de un código corto. Su presencia identifica un lugar de edición, no el comportamiento final de todas las integraciones. Anota qué página lo contiene y comprueba el marcado público resultante.
En páginas de Elementor, el widget HTML documentado admite HTML, scripts y códigos cortos. Esa capacidad no certifica un chatbot concreto en cualquier plantilla, ventana emergente o tema de Elementor. Considera el constructor como una parte de la configuración real que debes examinar.
La documentación de HTML personalizado de WordPress explica también el filtrado del marcado no permitido según los permisos. Si un código existe en el editor pero desaparece tras guardar, investiga el flujo de edición autorizado. No amplíes permisos solo para forzar la inserción de un widget.
Usa este registro de responsabilidades antes de decidir la ubicación:
| Familia de páginas | Tarea principal del visitante | Plantilla o distribución pública | Editor del contenido | Responsable de la salida del widget | Responsable del control compartido |
|---|---|---|---|---|---|
| Páginas de servicios | Comprender el servicio | Anotar la plantilla real | Identificar al editor | Identificar al mantenedor | Identificar al responsable de la llamada a la acción |
| Artículos | Leer y encontrar información relacionada | Anotar la plantilla del artículo | Identificar al editor | Identificar al mantenedor | Identificar al responsable de navegación |
| Página de contacto | Completar la consulta existente | Anotar la distribución del formulario | Identificar al editor | Identificar al mantenedor | Identificar al responsable del formulario |
Deja visibles los responsables desconocidos. «Alguien lleva Elementor» no basta para asignar una corrección que afecte al pie compartido del sitio.
Elige la ubicación según la tarea y la familia de páginas
La tabla siguiente propone puntos de partida, no valores predeterminados que ya hayan superado pruebas. Elige una ubicación que puedas mantener de acuerdo con las reglas documentadas de la integración.
| Familia de páginas | Ubicación candidata | Pregunta para decidir | Prueba necesaria |
|---|---|---|---|
| Página corporativa o de servicio | Botón flotante | ¿Se puede seguir accediendo a la llamada a la acción? | Página pública con los controles fijos visibles |
| Artículo largo | Botón flotante o sección integrada deliberadamente | ¿Se descubre la ayuda sin tapar controles de lectura? | Plantilla real del artículo y estados de desplazamiento |
| Página de políticas o ayuda | Integrada en una sección con responsable claro | ¿La caja interrumpe condiciones esenciales? | Orden del contenido publicado y enlaces a fuentes |
| Página de contacto o formulario | Vía de contacto existente; evaluar el chat aparte | ¿Se completa la tarea del formulario con el chat abierto y cerrado? | Controles, validación y estados del teclado en pantalla |
El conector oficial de WordPress de Achla tiene un único modo de ubicación para todo el sitio. En modo Inline se carga en las páginas que contienen su código corto o bloque; las demás no muestran el widget. En los modos Bubble o Attach, el código corto o bloque no proporciona otra caja integrada. Un botón flotante en todo el sitio junto con una caja integrada en una página requiere el enfoque manual documentado por separado. Consulta el contrato de instalación actual.
Esta restricción pesa más que una preferencia visual. Una tabla que propone ubicaciones distintas no puede hacer que el conector cambie de modo por página. Si los requisitos entran en conflicto, revisa la cobertura propuesta o pide al mantenedor responsable que evalúe un enfoque de integración adecuado. La guía existente sobre plugin frente a script de inserción aborda esa decisión de instalación más amplia.
Crea el registro de ubicación y obstáculos
Crea una fila por cada familia significativa de páginas y añade después las excepciones individuales. Reutiliza la tabla de responsables en vez de mantener una segunda lista de nombres. El registro debe relacionar un problema visible con una página, un estado y una persona concretos.
| Campo | Qué registrar |
|---|---|
| Página y tarea | URL pública exacta y acción que debe completar el visitante |
| Ámbito de edición y salida | Editor, plantilla pública real, modo del widget y responsable |
| Controles cercanos | Navegación fija, llamada a la acción local, control de consentimiento y acciones del formulario |
| Estado del visitante | Nuevo o recurrente; consentimiento pertinente; chat abierto o cerrado |
| Estado de entrada | Teclado en pantalla visible u oculto, cuando corresponda |
| Pruebas | Captura o reproducción breve; navegador y dispositivo; fecha de revisión |
| Hallazgo | Control concreto tapado o salida esperada ausente; «sin comprobar» si se desconoce |
| Corrección propuesta | Cambio mínimo delimitado, responsable y familia afectada |
| Repetición y veredicto | Misma tarea y estado tras el cambio; aceptar, revisar o pausar |
Utiliza el registro en este orden:
- Elige una página pública representativa e identifica al responsable real de su plantilla.
- Registra la ubicación prevista y los controles que compiten con ella.
- Captura el estado concreto del visitante y cualquier obstrucción observada.
- Asigna la corrección mínima y repite la misma tarea antes de decidir.
Elige nombres de pruebas que otro mantenedor reconozca. «Página de contacto, chat abierto, teclado visible, envío inaccesible» resulta más útil que «se ve mal en móvil». Una captura puede mostrar el choque y omitir la secuencia que lo causa: conserva ambos elementos.
Registra la ausencia con el mismo cuidado que la obstrucción. En modo Inline de Achla, una página sin el código corto o bloque no tiene widget por diseño. Es una decisión de cobertura que revisar, no una prueba de que deba aparecer una ventana emergente en todas partes. Indica si la ausencia es intencional antes de abrir una incidencia.
Revisa la página publicada con sus controles reales
Utiliza la interfaz pública que reciben los visitantes. Comprueba qué contenedor o cargador esperado está realmente presente y confirma después dónde se representa el widget. Compara el resultado con el registro de responsables; el lienzo del editor no determina qué plantilla compartida o integración produjo la página final.
Examina la página con sus propios controles presentes. La documentación de Floating Button de Elementor describe controles de ubicación para sus elementos flotantes. Si el sitio ya utiliza uno, registra su responsable y posición junto al requisito del chat. No supongas que dos componentes flotantes posicionados de manera independiente se coordinarán automáticamente.
Presta atención a los cambios de estado: un control de consentimiento puede permanecer visible, una llamada fija puede aparecer al desplazarse o el teclado en pantalla puede reducir el área utilizable durante el formulario. Comprueba la acción de la página en cada estado relevante. El objetivo es una observación reproducible, no una promesa genérica de que «adaptado a móviles» resuelva la competencia entre controles.
La guía de W3C sobre foco no oculto explica que los componentes enfocados no deben quedar completamente tapados por contenido creado por el autor. Úsala como consideración de accesibilidad aparte. Este registro de ubicaciones no demuestra conformidad completa con WCAG.
Comprueba también quién suministra el cargador. Achla documenta el uso del conector oficial o de una etiqueta manual, nunca ambos. El conector emplea su propio cargador, no una etiqueta manual literal /w.js. Buscar ese único nombre de archivo no demuestra, por tanto, un fallo del plugin. Sigue las comprobaciones documentadas de resolución de problemas antes de añadir otra instalación.
Ejemplos: el mismo widget y distintos responsables
Estos ejemplos hipotéticos ilustran decisiones que investigar; ninguno registra una prueba de navegador completada.
Una plantilla de artículo y una página de contacto comparten pie. El responsable del artículo propone un botón flotante. El de contacto identifica una acción fija de consulta en la misma zona. Registra ambas familias antes de cambiar la ubicación global. El siguiente paso propuesto consiste en verificar si la ubicación compartida conserva ambas tareas, no en aceptar la vista previa del artículo como resultado para todo el sitio.
Una página de ayuda de Gutenberg contiene un código corto integrado. El responsable del contenido sitúa la caja debajo de la explicación inicial. El mantenedor propone el modo Inline de Achla y anota que las páginas de servicios habituales no tienen código corto. El registro indica expresamente que esas páginas no tendrán widget en ese modo del conector. El propietario puede aceptar esa cobertura o revisarla antes de configurar.
Una página de Elementor parece correcta en el editor. La página pública puede usar una plantilla compartida controlada por otra persona. Empieza por identificar la plantilla publicada y la salida real. Si el contenedor necesario no existe al montar el widget, cambiar colores o mover el marcador del editor no demuestra que se haya satisfecho el requisito. Asigna la cuestión de la salida pública al responsable de la plantilla.
Estos ejemplos separan tres decisiones: dónde se edita la interfaz, dónde aparece y si los visitantes pueden completar la tarea de la página.
Decide aceptar, revisar o pausar con un responsable identificado
Acepta una ubicación únicamente para las páginas y estados con pruebas registradas. Una fila de artículo aprobada no cierra una fila de contacto sin comprobar. Mantén abierto un requisito para todo el sitio hasta revisar las familias pertinentes.
Revisa cuando un control identificado quede tapado, una ubicación integrada aparezca en un contexto incorrecto o la cobertura prevista difiera de la salida del conector. Asigna la corrección al responsable de ese ámbito. Cambiar una plantilla compartida obliga a volver a comprobar sus filas afectadas, no solo la página usada para demostrar la corrección.
Pausa cuando no se pueda completar la acción principal o la responsabilidad no esté clara. Mantén la vía habitual de contacto o navegación mientras se resuelve. Para procedimientos de teclado, lector de pantalla y área de visualización, utiliza la guía de accesibilidad existente de la barra de búsqueda. La decisión de este artículo sigue siendo la responsabilidad de ubicación y la obstrucción.
Evalúa el conector documentado de WordPress frente a tu registro
Revisa el conector de WordPress frente a tus requisitos reales de cobertura y ubicación. La función documentada de Achla consiste en responder sobre contenido público del sitio con fuentes de apoyo. No lo consideres un chat humano atendido, un sistema de reservas o una automatización de formularios verificados.
Compara los modos documentados con tu registro, consulta los planes actuales y utiliza la incorporación si encaja esa función delimitada. Si aún estás eligiendo el tipo de experiencia de búsqueda, la visión general de búsqueda con IA aporta más contexto. Conserva las condiciones de ubicación registradas para quien deba aprobar cualquier lanzamiento real.