When a website chatbot is not loading, identify the failed stage before changing settings: the page may not contain its loader, the browser may block a resource, a consent rule may deliberately delay it, configuration may be unavailable, or a mounted interface may be hidden. A visible widget that cannot find an answer is a different problem. Start with the page, visitor state and browser evidence, then give the correct owner a narrowly scoped issue.
This guide provides an original resource-and-state checklist for evaluating a website chat widget. It does not recommend disabling Content Security Policy, copying another provider’s allowlist or declaring a consent setup compliant. A useful diagnosis may end with a compatibility hold rather than an instruction to weaken your site’s policy.
Author: Achla AI, Organization. Reviewed 14 October 2026. The framework combines current browser and provider documentation with inspected Achla installation guidance, prepared with AI assistance. Examples are hypothetical; no customer incident or browser test result was measured. The purpose is to make a loading problem inspectable before a site owner evaluates or changes a widget.
Which part is missing: interface, request or answer source?
Describe what the visitor actually sees. “The chatbot is broken” combines several observations that need different owners and corrections.
If there is no button or inline box, investigate installation, loading and visibility. If the interface appears but cannot obtain its configuration or answer, investigate the relevant request and the server’s documented state. If the interface returns an answer but omits a particular page, investigate source collection and retrieval separately.
Do not change crawl permissions to fix a missing interface. Likewise, a script that loaded successfully does not prove that the answer request succeeded. Achla’s installation documentation distinguishes placement and verification, while its troubleshooting guidance separates widget and search problems. Start at the layer supported by your observation.
Record the exact public page and the state in which the problem occurs. A logged-in editor preview is not evidence of the anonymous visitor experience. Note whether the same page was newly opened, revisited or reached after a consent choice.
Follow the resource-and-state matrix
Use this original worksheet to record evidence rather than guess a fix. Its rows describe possible conditions, not measurements from a real incident.
| Stage | Evidence to record | Question for the owner |
|---|---|---|
| Page markup | Expected integration present or absent on the published page | Does this template or connector own the intended page scope? |
| Loader | Script URL, request status and relevant console message | Was the loader requested, blocked or unable to load? |
| Configuration | Configuration request and observable response | Did it reach the expected service, and is the documented state ready? |
| Answer request | What happens after submitting a public test question | Is the request blocked, rejected or returning a usable response? |
| Mounted interface | Visible controls and any hidden or displaced element | Did the widget mount but fail to appear where expected? |
| Consent sequence | New, deny, accept and revisit observations | Is delayed loading intended, and does the approved sequence work? |
Keep an unknown field unknown. “No request observed” and “request rejected” are different records. Capture a specific console message or request result if available, rather than translating every failure into “CORS.”
Add an acceptance condition beside the failed row. For example, “after the approved consent choice, the documented configuration request reaches its intended service” is more useful than “make the bot appear.” For a hidden interface, the condition might identify the particular published page and the intended control location. Both are proposed criteria, not completed checks.
Assign the row to the owner of that layer. A template problem belongs with the website maintainer; a disputed policy requirement belongs with the security owner; an intentional delay belongs with the consent owner. Provider support may need to clarify a documented prerequisite. Avoid changing a different layer simply because its settings are easier to reach.
Also identify the integration mechanism. Achla’s WordPress connector and Drupal module use their own loader rather than a directly pasted /w.js tag. Its current installation instructions describe that distinction. Absence of that particular script tag alone does not prove the connector failed.
Use one controlled, public question when checking the answer stage. The task here is whether the request path works, not a new answer-quality benchmark. Keep sensitive account details out of test inputs and diagnostic records.
Read the browser policy error before changing a directive
Content Security Policy is a browser resource policy. MDN’s CSP guide explains how it restricts the content a page can load or execute. A widget may depend on more than its initial script, so a loader that succeeds can still be followed by a blocked configuration request or blocked styling.
The script-src documentation concerns script sources and execution. The connect-src documentation concerns connections made by interfaces such as fetch. Styles and frames have their own policy considerations. Match the browser’s actual message to the resource and directive it names.
Create a small resource record: requested URL, expected provider, resource type, named directive, observed result and the owner who maintains the policy. Check the provider’s current documented requirements. Do not infer those origins from an unrelated vendor’s example or approve a broad wildcard to make the warning disappear.
Intercom’s CSP troubleshooting page describes the resources and policy diagnosis for Intercom. tawk.to’s guidance on missing widget images describes its own resource symptoms. These pages illustrate why a partly visible interface can have a resource-specific problem; they are not Achla configuration recipes.
If a security owner uses a report-only policy for observation, keep it separate from the enforced policy. MDN distinguishes reporting from enforcement. A report-only observation does not prove that the enforced policy permits the widget, and adding it does not authorize removing existing protections.
Treat consent as a sequence of states
Delayed loading may be intentional. Before diagnosing a missing script as a defect, establish the site’s approved loading behavior and who owns its consent configuration.
ChatLab’s consent-loading documentation describes an explicit load-after-consent approach for ChatLab. It does not establish automatic integration with every consent manager, nor does it prove that another provider follows the same sequence. The site’s responsible owner must determine the applicable classification and requirements.
Use a separate record for each intended state:
| Visitor state | What to observe | What the record must avoid assuming |
|---|---|---|
| New visitor | Whether the loader is requested before a choice | That every chatbot must load immediately |
| Deny | Whether the approved deny behavior is retained | That absence of the widget is automatically a defect |
| Accept | Whether the expected loading sequence begins and completes | That one successful script proves the whole interaction works |
| Revisit | Whether stored choices produce the intended behavior | That the editor’s session represents every visitor |
These are observation prompts, not legal conclusions or claimed test results. If expected and observed behavior disagree, record the state and give the consent owner a reproducible issue. Do not bypass the consent mechanism as a generic troubleshooting shortcut.
A consent tool may control script loading while a browser policy controls a later request. Record both rather than choosing one explanation prematurely. One state can expose more than one independent problem.
What if a strict style policy and the widget disagree?
Sometimes the correct conclusion is that a widget’s documented requirements do not fit the site’s policy.
Achla’s current install guide says the widget injects its stylesheet as a style element and lists an inline-style allowance among its CSP requirements. That is a compatibility fact to review with your security owner, not a recommendation to grant a blanket unsafe-inline exception. The inspected documentation does not establish an Achla nonce or hash integration API.
A different provider may document another mechanism. SiteSpeakAI’s CSP changelog describes nonce support for its own widget. That statement does not establish equivalent support in Achla or justify copying the attribute into another script.
If the site requires a strict nonce or hash policy, hold the integration until compatible behavior is verified. Ask the provider for current evidence, or evaluate an alternative whose documented requirements meet the policy. Keep the policy’s owner involved; a visually working button is not acceptance of a changed security boundary.
BoldDesk’s CSP troubleshooting guidance similarly discusses the requirements of its own live-chat widget. Use vendor-specific documentation to frame questions, not to combine several providers’ exceptions into one permissive policy.
Prepare a redacted diagnostic packet
A useful handoff lets the website maintainer, consent owner or provider reproduce the issue without receiving private information.
Include the public page, observation date, integration mechanism, intended placement, visitor consent state and the failed stage from the matrix. Add the relevant resource origin, request outcome and console message. Say whether the interface was absent, hidden, configured but unable to answer, or waiting for an intended consent choice.
For example, a hypothetical record might say: “Published policy page; new anonymous session; accept chosen; loader requested; configuration request blocked by the named connection directive; no answer request yet.” It narrows the investigation without asserting that a real customer experienced this sequence.
Redact credentials, private keys, session identifiers, personal messages and account data. A diagnostic packet should not include a complete private conversation or an unreviewed network archive. Record the minimum information needed to distinguish the failed resource and state, with a named owner for the next decision.
Retest the same state after one approved correction
Define the correction and its owner before applying it. Then repeat the same page, visitor state and public question. Record what changed and which stage now succeeds or remains unknown. Avoid bundling script replacement, consent changes and policy changes into one unexplained result.
If the console still reports a policy violation, return the exact directive and origin to the security owner. If the configuration response is not ready, follow the provider’s documented prerequisites. If only the interface is hidden, investigate its page placement rather than changing network permissions.
A successful loading retest establishes only the observed loading behavior. It does not certify accessibility, privacy compliance, answer accuracy or compatibility across every browser and page. Ambiguous failures should remain open with an evidence request rather than another vendor’s unverified workaround.
Evaluate current Achla requirements before connecting
Use the completed matrix as a compatibility checklist: can the widget’s documented installation, policy and public-content requirements fit this particular website? For CMS-specific paths, review the existing WordPress connector or Drupal module. A generic script path depends on the actual site’s ability to include and permit it; it does not establish a dedicated integration with another CMS.
Once the interface and request path are understood, use the separate website-content chatbot guide for source decisions and grounded-answer evaluation sheet for answer support. If the documented scope fits, start the existing onboarding flow. Keep strict-policy incompatibility held until evidence resolves it. The useful result is an inspectable decision about your site, with its protections still owned and intact.
