Widget not visible or not detected

Check the real public page#

Begin with the customer's exact entry route and final hostname after redirects. A launcher working on the homepage does not prove that a product page with another layout contains it. Compare a direct visit with navigation from a working page, and distinguish a missing launcher from a launcher that opens but cannot answer. Note whether a cookie dialog, mobile checkout bar or another fixed control covers the corner. On a phone, inspect both the closed launcher and open panel; a keyboard or browser-bar issue is different from a loader that never ran. Keep the original reproduction before testing a second environment.

Confirm that the loader reached the browser#

<script src="https://cdn.reesponder.com/widget/v1/reesponder.js"
  data-site-id="PUBLIC_SITE_ID"
  data-installation-token="CURRENT_GENERATED_TOKEN"
  defer></script>

Copy the current snippet from the correct website's Installation tab. Replace the uppercase placeholders only with its actual generated values, and publish the loader once.

In Developer Tools, search the live Elements tree for the script URL and inspect the attributes. View Source is also useful for server-rendered markup, but a website builder can inject its custom script after the initial source loads. The decisive check is the actual loader request in Network. If it is absent from both the live document and Network, return to the publishing path. If the request exists, read its response or blocked reason. Do not add an extra copy to every page as a guess: identify the shared layout and the installation owner first so the repair remains maintainable.

Exclude stale or altered code#

Compare the snippet in the editor with the one delivered to a fresh public visit. Different tokens or an absent tag can reveal cached HTML or a draft theme rather than an API fault. Clear the relevant page/CDN cache through your platform, then reload with Network visible. Script combining can interfere with the loader reading its own attributes, and delayed execution can make detection wait for interaction. Exclude the official script from those transformations where necessary. If one browser still fails, compare its Console and blocked requests with a normal profile; do not dismiss the report just because your own browser has no extensions.

Inspect the installation check#

A fresh successful detection should advance Last seen. A historic Widget detected label can remain after code replacement, so it is not proof that the new token is live. For a 403, compare the final page hostname with the website's registered hostname and the script's current site/token pair. For a 400, inspect the malformed request or missing origin rather than rotating credentials indiscriminately. A status such as blocked by client or a CSP violation means the browser may have prevented the request entirely. Record the exact safe status and error before trying another browser, so the original failure remains available to investigate.

Respect platform connection state#

With WordPress, confirm the plugin's separate states: active plugin, approved workspace connection and enabled public widget. A theme lacking wp_footer() can prevent the footer script from being published even when the account connection is valid. After a hostname change, reconnect through the plugin rather than altering its stored credentials by hand. With Shopify, confirm the Current theme, saved layout/theme.liquid and public domain. If an existing app embed owns the installation, keep that path until deliberately disconnecting it. Installing a second manual snippet is not a supported repair for a revoked or mismatched app-owned credential.

Send a useful, safe report#

A useful report reads like this: the public product route, final hostname, WordPress plugin installation, Chrome on an Android phone, failure at a particular time, loader loaded successfully, detect rejected with 403, homepage behaves the same. That gives support a reproducible stage and boundary without exposing the token itself. If your business URL contains a private query, redact it before sharing. Do not send an unredacted HAR file by default: it can include cookies, credentials and messages from unrelated requests. Use a synthetic or minimal reproduction and provide the safe status text instead of complete authenticated request headers.

Compare the requested and final hostname#

Write down the URL entered and the URL after redirects. A visitor may start at the bare domain and arrive at www, or reach a country-specific storefront with a different hostname. Compare that final hostname with the registered website. Do the same for preview links: a Shopify editor or draft deployment can use an origin that is intentionally not the public installation domain. A successful test on that preview is not required proof of the published site, and a failure there does not establish that the public domain is broken.

Test the actual public entry routes using a fresh normal profile: homepage, product or service page and another layout. If one redirects elsewhere, include that outcome in the report. Do not attempt to bypass origin checks by pasting a workspace ID, inventing an allowed-domain wildcard or editing provider credentials. If the business genuinely changed domain, use the supported website connection path and publish the appropriate current installation. Distinguish a hostname mismatch from stale HTML: the delivered token may be correct while the final domain is wrong, or the final domain may be correct while an old token remains in a page cache.

Read the browser policy failure at the relevant resource#

The loader is requested from https://cdn.reesponder.com, while its default public requests go to https://api.reesponder.com. Check script-src for the first and connect-src for the second in the actual site policy. The official widget uses a closed Shadow DOM rather than an iframe, so adding a frame-src rule is not a generic remedy for its API request. Read the Console violation and the corresponding Network request before asking the website administrator for a scoped policy change.

The widget also uses inline styles and dynamic style attributes, so sites with strict style policies need compatibility review of the real implementation. There is no universal nonce hook or safe one-line policy supplied by this guide. A configured avatar can require its own permitted HTTPS image origin. Keep the review specific to the required resource and directive; do not remove the entire CSP merely to make one demonstration work. After the intended change, retest the original public route and its open panel. A browser extension blocking a request is separate evidence and should be compared with a controlled normal profile, not concealed by weakening the site policy.

Repair the installation owner instead of adding copies#

For custom sites, identify the shared document or layout that should publish the snippet across the intended routes. For Shopify manual installation, check the saved layout/theme.liquid in the Current theme and code above </body>. For WordPress, check an active plugin, approved workspace connection, enabled widget and a theme that emits wp_footer(). These states are different from an editor containing the correct text. A cache or unpublished theme can prevent that text from reaching visitors.

If an existing Shopify app integration or WordPress connection owns the installation credential, do not add an independent manual loader as a repair. Use its supported controls, or deliberately migrate ownership and update every manual publishing path if appropriate. Check script optimisation too: transformations can remove attributes or prevent the loader from identifying its original element. Exclude the specific loader from an incompatible transformation rather than adding repeated copies. After repair, record the one owner and remove obsolete publishing paths. Fresh detection after the repair and a controlled answer provide evidence that the maintained public path, rather than an accidentally surviving duplicate, is working.

Two similar symptoms, different repairs#

Suppose the theme editor contains the correct new snippet but a fresh public request still shows the old token. The first useful repair is publishing the current theme and clearing the relevant cache, then confirming the delivered HTML and a new Last seen timestamp. Generating yet another token would invalidate the newly prepared code too and make the comparison harder. In a different case, the current loader is present but Console reports a connect-src violation for the API. That calls for review of the specific site policy, not another theme edit. The visible symptom is similar; the request evidence identifies the different cause.

Verify the outcome and keep safe evidence#

After the repair, repeat the original failing route first. Verify loader execution, successful detect response and a Last seen time after the fix, then send one controlled customer question. Check a second layout and an actual mobile browser. Review any optimiser or cache change so the exception is limited to the intended script rather than weakening the whole site. Record the template or plugin that now owns the installation and remove obsolete duplicates. Use the full installation guide as the handover checklist. A fix is complete when public visitors receive the correct code and an operational answer, not merely when an editor saves successfully.