Cuando un chatbot del sitio no carga, identifica la etapa que falla antes de cambiar ajustes: puede que la página no contenga el cargador, el navegador bloquee un recurso, una regla de consentimiento lo retrase deliberadamente, la configuración no esté disponible o una interfaz montada permanezca oculta. Un widget visible que no encuentra una respuesta es otro problema. Parte de la página, del estado del visitante y de las pruebas del navegador, y asigna un problema acotado al responsable adecuado.
Esta guía ofrece una lista original de recursos y estados para evaluar un widget de chat. No recomienda desactivar Content Security Policy, copiar la lista de permitidos de otro proveedor ni declarar conforme una configuración de consentimiento. Un diagnóstico útil puede terminar en una suspensión por incompatibilidad en lugar de una instrucción para debilitar la política del sitio.
Autor: Achla AI, organización. Revisión: 14 de octubre de 2026. El marco combina documentación actual de navegadores y proveedores con instrucciones de instalación de Achla examinadas, preparado con ayuda de IA. Los ejemplos son hipotéticos; no se midieron incidentes de clientes ni resultados de pruebas en navegador. El objetivo es hacer verificable un problema de carga antes de que el propietario evalúe o modifique el widget.
¿Qué falta: interfaz, solicitud o fuente de la respuesta?
Describe lo que ve realmente el visitante. «El chatbot está roto» reúne varias observaciones que necesitan responsables y correcciones diferentes.
Si no aparece un botón o recuadro insertado, investiga instalación, carga y visibilidad. Si aparece la interfaz pero no obtiene su configuración o respuesta, investiga la solicitud correspondiente y el estado documentado del servidor. Si devuelve una respuesta pero omite una página concreta, examina la recopilación de fuentes y la recuperación de información por separado.
No cambies permisos de rastreo para arreglar una interfaz ausente. Del mismo modo, cargar correctamente un script no demuestra que la solicitud de respuesta haya funcionado. La documentación de instalación de Achla distingue ubicación y verificación, mientras que sus orientaciones de solución de problemas separan problemas del widget y de búsqueda. Empieza por la capa respaldada por la observación.
Registra la página pública exacta y el estado en que ocurre el problema. La vista previa de un editor conectado no demuestra la experiencia de un visitante anónimo. Anota si la página acaba de abrirse, se visita de nuevo o se alcanza después de elegir el consentimiento.
Sigue la matriz de recursos y estados
Usa esta hoja original para registrar pruebas en lugar de adivinar una solución. Las filas describen condiciones posibles, no mediciones de un incidente real.
| Etapa | Pruebas que registrar | Pregunta para el responsable |
|---|---|---|
| Marcado de la página | Integración prevista presente o ausente en la página publicada | ¿La plantilla o el conector gestionan las páginas previstas? |
| Cargador | URL del script, estado de solicitud y mensaje pertinente de consola | ¿Se solicitó el cargador, se bloqueó o no pudo cargar? |
| Configuración | Solicitud de configuración y respuesta observable | ¿Llegó al servicio esperado y está listo el estado documentado? |
| Solicitud de respuesta | Qué ocurre al enviar una pregunta pública de prueba | ¿Está bloqueada, rechazada o devuelve una respuesta utilizable? |
| Interfaz montada | Controles visibles y elementos ocultos o desplazados | ¿El widget se montó pero no aparece donde se esperaba? |
| Secuencia de consentimiento | Observaciones en visita nueva, rechazo, aceptación y retorno | ¿El retraso es intencional y funciona la secuencia aprobada? |
Mantén desconocido un campo desconocido. «No se observó ninguna solicitud» y «solicitud rechazada» son registros diferentes. Captura un mensaje concreto de consola o resultado de solicitud cuando exista, en lugar de convertir cualquier fallo en «CORS».
Añade una condición de aceptación junto a la fila fallida. Por ejemplo, «tras la elección de consentimiento aprobada, la solicitud documentada de configuración llega al servicio previsto» es más útil que «hacer aparecer el bot». Para una interfaz oculta, la condición puede identificar la página publicada concreta y la ubicación prevista del control. Ambos son criterios propuestos, no comprobaciones terminadas.
Asigna la fila al responsable de esa capa. Un problema de plantilla corresponde al encargado del sitio; una exigencia discutida de la política, al responsable de seguridad; un retraso intencional, al responsable del consentimiento. Puede que el soporte del proveedor deba aclarar un requisito documentado. Evita cambiar otra capa solo porque sea más fácil acceder a sus ajustes.
Identifica también el mecanismo de integración. El conector WordPress y el módulo Drupal de Achla usan su propio cargador en vez de una etiqueta /w.js pegada directamente. Sus instrucciones actuales de instalación explican la distinción. La ausencia de esa etiqueta concreta no demuestra por sí sola que el conector haya fallado.
Usa una pregunta pública controlada al comprobar la etapa de respuesta. La tarea aquí es saber si funciona el recorrido de la solicitud, no crear una nueva comparativa de calidad. No incluyas datos sensibles de cuentas en entradas de prueba o registros de diagnóstico.
Lee el error de política del navegador antes de cambiar una directiva
Content Security Policy es una política de recursos del navegador. La guía CSP de MDN explica cómo limita el contenido que una página puede cargar o ejecutar. Un widget puede depender de más recursos que el script inicial; por eso una carga correcta puede ir seguida de una solicitud de configuración o de estilos bloqueados.
La documentación de script-src trata de fuentes y ejecución de scripts. La documentación de connect-src trata de conexiones mediante interfaces como fetch. Estilos y marcos tienen sus propias consideraciones. Relaciona el mensaje real del navegador con el recurso y la directiva que nombra.
Crea un registro breve del recurso: URL solicitada, proveedor esperado, tipo de recurso, directiva indicada, resultado observado y responsable de mantener la política. Comprueba los requisitos documentados actuales del proveedor. No deduzcas orígenes a partir del ejemplo de otro vendedor ni apruebes un comodín amplio solo para hacer desaparecer el aviso.
La página de Intercom para errores CSP describe recursos y diagnóstico de políticas de Intercom. Las orientaciones de tawk.to sobre imágenes ausentes del widget describen sus propios síntomas de recursos. Estas páginas ilustran por qué una interfaz parcialmente visible puede tener un problema específico de recursos; no son recetas de configuración para Achla.
Si el responsable de seguridad usa una política de solo informe para observar, mantenla separada de la política aplicada. MDN distingue informes y aplicación. Una observación de solo informe no demuestra que la política aplicada permita el widget, y añadirla no autoriza a quitar protecciones existentes.
Trata el consentimiento como una secuencia de estados
Un retraso de carga puede ser intencional. Antes de diagnosticar un script ausente como defecto, establece el comportamiento aprobado del sitio y quién gestiona su configuración de consentimiento.
La documentación de ChatLab sobre carga tras consentimiento describe un enfoque explícito para ChatLab. No demuestra una integración automática con todos los gestores de consentimiento ni que otro proveedor siga la misma secuencia. El responsable del sitio debe determinar la clasificación y los requisitos aplicables.
Usa un registro independiente para cada estado previsto:
| Estado del visitante | Qué observar | Qué no debe dar por hecho el registro |
|---|---|---|
| Visitante nuevo | Si se solicita el cargador antes de elegir | Que todo chatbot deba cargar inmediatamente |
| Rechazo | Si se conserva el comportamiento aprobado al rechazar | Que la ausencia del widget sea automáticamente un defecto |
| Aceptación | Si empieza y termina la secuencia de carga esperada | Que un script correcto pruebe toda la interacción |
| Regreso | Si las elecciones guardadas producen el comportamiento previsto | Que la sesión del editor represente a todos los visitantes |
Son indicaciones de observación, no conclusiones legales ni resultados declarados de pruebas. Si lo esperado y lo observado no coinciden, registra el estado y entrega un problema reproducible al responsable del consentimiento. No eludas el mecanismo como atajo genérico de solución de problemas.
Una herramienta de consentimiento puede controlar la carga del script mientras una política del navegador controla una solicitud posterior. Registra ambos factores en vez de elegir una explicación antes de tiempo. Un estado puede revelar más de un problema independiente.
¿Y si una política estricta de estilos no es compatible con el widget?
A veces la conclusión correcta es que los requisitos documentados del widget no encajan con la política del sitio.
La guía actual de instalación de Achla indica que el widget inyecta su hoja de estilos como elemento style e incluye permitir estilos en línea entre sus requisitos CSP. Es un hecho de compatibilidad que revisar con el responsable de seguridad, no una recomendación de conceder una excepción general unsafe-inline. La documentación examinada no demuestra una API Achla de integración con nonce o hash.
Otro proveedor puede documentar un mecanismo diferente. El registro de cambios CSP de SiteSpeakAI describe compatibilidad con nonce para su propio widget. Esa declaración no demuestra una compatibilidad equivalente en Achla ni justifica copiar el atributo a otro script.
Si el sitio exige una política estricta de nonce o hash, suspende la integración hasta verificar un comportamiento compatible. Solicita pruebas actuales al proveedor o evalúa una alternativa cuyos requisitos documentados cumplan la política. Mantén implicado al responsable: un botón visualmente funcional no supone aceptar un límite de seguridad modificado.
Las orientaciones de BoldDesk para problemas CSP también tratan los requisitos de su propio widget de chat en vivo. Usa la documentación específica de cada proveedor para plantear preguntas, no para combinar excepciones de varios en una política permisiva.
Prepara un paquete de diagnóstico sin información privada
Una entrega útil permite al encargado del sitio, al responsable del consentimiento o al proveedor reproducir el problema sin recibir información privada.
Incluye página pública, fecha de observación, mecanismo de integración, ubicación prevista, estado de consentimiento y etapa fallida de la matriz. Añade el origen del recurso afectado, el resultado de la solicitud y el mensaje de consola. Indica si la interfaz estaba ausente, oculta, configurada pero sin poder responder o esperando una elección prevista de consentimiento.
Por ejemplo, un registro hipotético podría decir: «Página de políticas publicada; sesión anónima nueva; aceptación elegida; cargador solicitado; solicitud de configuración bloqueada por la directiva de conexión indicada; todavía no hay solicitud de respuesta». Delimita la investigación sin afirmar que un cliente real vivió esa secuencia.
Oculta credenciales, claves privadas, identificadores de sesión, mensajes personales y datos de cuentas. Un paquete no debe incluir una conversación privada completa ni un archivo de red sin revisar. Registra lo mínimo necesario para distinguir el recurso y estado fallidos, con un responsable identificado para la siguiente decisión.
Repite el mismo estado después de una corrección aprobada
Define la corrección y su responsable antes de aplicarla. Repite después la misma página, estado de visitante y pregunta pública. Registra qué cambió y qué etapa funciona ahora o sigue siendo desconocida. Evita agrupar sustitución del script, cambios de consentimiento y de política en un resultado sin explicación.
Si la consola sigue mostrando una infracción, devuelve al responsable de seguridad la directiva y el origen exactos. Si la respuesta de configuración no está lista, sigue los requisitos documentados del proveedor. Si solo está oculta la interfaz, investiga su ubicación en la página en lugar de modificar permisos de red.
Una repetición correcta del test de carga solo demuestra el comportamiento observado. No certifica accesibilidad, cumplimiento de privacidad, precisión de respuestas o compatibilidad con todos los navegadores y páginas. Los fallos ambiguos deben permanecer abiertos con una solicitud de pruebas en lugar de recibir una solución no verificada de otro proveedor.
Evalúa los requisitos actuales de Achla antes de conectar
Usa la matriz completada como lista de compatibilidad: ¿la instalación documentada, la política y los requisitos de contenido público del widget encajan con este sitio concreto? Para vías específicas de CMS, revisa el conector WordPress existente o el módulo Drupal. Un script genérico depende de la capacidad real del sitio para incluirlo y permitirlo; no demuestra una integración dedicada con otro CMS.
Una vez comprendidos interfaz y recorrido de solicitudes, usa por separado la guía del chatbot basado en contenido del sitio para decidir sobre fuentes y la hoja de evaluación de respuestas fundamentadas para su respaldo. Si el alcance documentado encaja, inicia el proceso de incorporación existente. Mantén suspendida la incompatibilidad con políticas estrictas hasta resolverla con pruebas. El resultado útil es una decisión verificable sobre tu sitio, cuyas protecciones permanecen intactas y bajo responsabilidad definida.
