WordPress Live Chat Widget Not Showing? 10 Checks That Find the Cause

The fastest answer: identify the first missing layer

A missing launcher can have several different causes that look identical from the page. The dashboard may be set to Chat Off. The mobile launcher may be disabled. WordPress may be serving an old cached page. A consent or privacy tool may be holding the script. The script may load but fail because another theme or plugin throws a JavaScript error. Testing in a fixed order keeps you from changing several things and losing the evidence.

Use one affected URL, one private browser window, and one clearly recorded result at each step. If the launcher is missing only on a phone, focus on mobile and responsive settings. If it is missing only on one page type, compare that template with a page where it works. If it is gone everywhere and the plugin says disconnected, fix the connection before inspecting CSS.

This guide applies to Yapdesk's core live chat and message mode, which are free with Yapdesk branding. AI-only and Hybrid AI + Agent replies are Pro AI features, but AI is not required for the launcher to appear. A WooCommerce store uses the same public WordPress widget on storefront pages; Yapdesk does not claim a direct WooCommerce data integration.

Check 1: reproduce the missing widget as a real visitor

Open the affected page while signed out of WordPress. Use a private or incognito window so the admin bar, saved preview state, browser extensions, and old local data are less likely to confuse the result. Test the exact public URL, not only the WordPress editor or Yapdesk dashboard preview.

Try a second page and a second browser. WordPress's JavaScript troubleshooting guidance recommends checking more than one browser and notes that extensions, ad blockers, and privacy tools can interfere with scripts. If one clean browser works, the website installation is probably present and the next check belongs to that browser or extension. If every browser fails, continue with the site configuration.

Sources: WordPress handbook: Diagnose JavaScript errors in a browser

Check 2: verify plugin activation and the saved Yapdesk connection

In WordPress, open Plugins and confirm Yapdesk Live Chat is active. Then open the Yapdesk Live Chat admin screen. Connected to Yapdesk means the plugin has the site keys it needs. Use Check Connection to ask for the current site configuration and confirm that the saved relationship still works.

A normal Yapdesk plugin update should preserve the saved connection, so do not reconnect after every update. Reconnect only when the check fails, the site was intentionally moved to another Yapdesk account, or support has confirmed that the keys need replacement. Reconnecting to the wrong account changes where new conversations arrive.

If WordPress reports that the plugin was automatically deactivated or could not activate, capture the full message. WordPress documentation notes that incomplete files, plugin code errors, or missing dependencies can cause activation failures. Resolve that condition before looking for a visitor-side launcher.

Sources: Yapdesk guide: Connect or reconnect WordPress · WordPress documentation: Plugins screen

Check 3: confirm chat status and mobile visibility

Open Yapdesk and inspect Chat Status. Chat Off intentionally hides the widget. Chat Active presents live chat, while Message presents the message workflow for follow-up. Change the status only if it matches the team's real availability, save it, and then reload the public page.

If desktop works but the phone does not, open Chat Settings for the correct connected website. Confirm Show widget on mobile is enabled and review the mobile launcher choice. A separate mobile label or icon can make the phone launcher look different from desktop, so look for the configured control rather than expecting an exact visual copy.

Also inspect the lower corners for overlap. Cookie banners, accessibility controls, sticky purchase bars, and mobile navigation can cover a launcher that technically exists. Temporarily close those public controls and use browser inspection to see whether the chat element is present behind them.

Sources: Yapdesk guide: Change chat status and reply mode · Yapdesk guide: Customize the chat widget

Check 4: make sure Yapdesk is installed only once

Choose one installation method. On WordPress, use the Yapdesk plugin. Do not also paste the Yapdesk embed through the theme, a custom-code plugin, page builder, or tag manager. Two copies can create duplicate launchers, competing configuration, repeated requests, or a script that finds the wrong site key.

Search the theme and site-wide code tools for app.yapdesk.com or widget.js if the site previously used a manual embed. Remove the extra method on staging or after a backup, purge the relevant cache, and retest the public page. Keep the connected website's own key; do not reuse a key copied from another domain.

Sources: Yapdesk guide: Install live chat on WordPress · Yapdesk guide: Add websites and support agents

Check 5: clear the cache layer that still has the old page

A WordPress page can be cached by the browser, a cache plugin, the web server, a hosting platform, or a CDN. Clear the layer affected by the recent change, then request the public page again in a private window. Adding and removing unrelated plugins while an old page is still cached will only make the diagnosis harder.

WordPress documents page, browser, object, and server caching as different systems. A plugin cache purge does not necessarily purge a CDN, and clearing browser data does not rebuild a server-cached HTML page. Use the tools supplied by the cache or hosting service and confirm the purge finished.

Sources: WordPress handbook: Cache

Check 6: inspect the page source and Network panel

Open browser Developer Tools, select Network, reload the page, and filter for widget or yapdesk. A request for the Yapdesk widget asset tells you WordPress printed the loader into the public response. Its status and timing tell you whether the browser received it. A failed, blocked, or canceled request is different from no request at all.

If there is no widget request, view the generated page source and search for the plugin's public widget asset. Compare a working page with the failing page. When only one template fails, the theme or page builder may not be printing normal WordPress footer assets on that template, or a page-level optimization rule may exclude them.

If the script succeeds but the launcher is absent, inspect subsequent app.yapdesk.com requests and the page elements. Save the request URL, HTTP status, and any browser message. Do not post a private site secret in a public support forum; the public widget key and secret credential serve different purposes.

Check 7: read the first relevant Console error

Switch to the Console and reload. Start with the earliest error tied to the widget, theme, optimization tool, consent manager, or another script loaded before chat. One earlier exception can prevent later interface code from finishing, even when the widget file itself returned successfully.

Copy the complete error, stack trace, file name, and line number. WordPress recommends including those details, the affected browser, and the action that triggered the error when requesting support. A cropped screenshot that omits the file and message is much harder to diagnose.

Developers can use SCRIPT_DEBUG on staging to load uncompressed WordPress scripts while investigating, but WordPress advises taking a backup or using staging before configuration changes. Turn debugging options off after the test and do not expose sensitive debug output on a public site.

Sources: WordPress handbook: Diagnose JavaScript errors in a browser · WordPress handbook: Debugging in WordPress

Check 8: test consent tools, blockers, and security rules

Consent managers can intentionally delay third-party scripts until a visitor makes a choice. Test the page before consent, after each relevant consent choice, and after reopening the consent control. Confirm that the site's privacy notice and configured categories describe the actual chat workflow instead of moving the script into a category merely to make it load sooner.

Repeat the test in a clean browser without content-blocking extensions. If chat works there, identify which request the extension blocks. Also review Content Security Policy reports, firewall events, and CDN security logs for app.yapdesk.com requests. Change only the narrow rule supported by the evidence; do not disable site security globally.

Check 9: isolate plugin and theme conflicts safely

Use staging when possible and take a backup before changing the active theme or plugin set. First reproduce the missing launcher. Then deactivate one likely conflicting optimization, consent, security, or custom-code plugin, purge the staging cache, and retest. Reactivate it before moving to the next candidate unless the result identifies the conflict.

WordPress's plugin-management documentation recommends verifying activation and deactivating plugins one at a time to locate conflicts. Randomly disabling everything on production can interrupt checkout, forms, security, and other customer workflows while producing a result that is difficult to attribute.

If plugins are not responsible, switch staging temporarily to a maintained default theme and test the same URL or equivalent page. A launcher that returns under the default theme points toward the active theme's templates, JavaScript, CSS stacking, or asset optimization rather than the Yapdesk account.

Sources: WordPress documentation: Manage plugins and troubleshoot conflicts

Check 10: reconnect or reinstall only after collecting evidence

Use Check Connection first. If it fails and the intended account is known, reconnect from the Yapdesk plugin screen and verify the public result. If the plugin files appear incomplete or WordPress reports an activation problem, take a backup, record the current version and connection state, and follow the normal WordPress reinstall process.

After the fix, test the closed launcher, open panel, typing, send action, message mode, phone keyboard, and the correct Yapdesk inbox. A visible bubble is only the first checkpoint; the complete visitor-to-agent path must work.

A support report that gets the issue solved faster

If the widget is still missing, send a compact report instead of a general statement that chat does not work. Remove passwords and secret keys. Include enough evidence for someone else to reproduce the same layer of failure.

• Affected public URL and the date and time of the test
• WordPress, theme, and Yapdesk plugin versions
• Connected status and result of Check Connection
• Chat status plus desktop and mobile visibility settings
• Browsers and devices tested, including a clean private window
• Whether another page, browser, or default theme works
• Widget and app.yapdesk.com Network request statuses
• Complete relevant Console error and stack trace
• Cache, CDN, consent, firewall, and conflict checks already completed
• The last known working time and the change made immediately before failure