WordPress Zendesk Chat, Installed Properly

WordPress Zendesk Chat is one script tag. The interesting part is where you put it, and which of your other plugins is going to eat it.

Two routes to WordPress Zendesk Chat, and they're not equivalent

The Zendesk chat widget is a single JavaScript snippet with a key that identifies your account and brand. WordPress doesn't need to know anything about Zendesk for it to work.

Paste the script. Zero dependencies, nothing to update, works on every template including ones you have not built yet.
Install a plugin. Gives you a settings screen, per-page visibility rules without code, and sometimes a native ticket form via shortcode. More convenience, one more thing that can go stale.

For chat specifically, the script route wins more often than people expect. The plugin route earns its keep when you need a form on your own domain, which is a different problem covered in the Zendesk and WordPress guide.

Pasting the script properly

Never paste it into a theme file. The next theme update overwrites it and nobody notices for six weeks.

Three acceptable homes, in rough order of preference.

A child theme, enqueued through `wp_enqueue_script`. The correct answer. It survives updates, respects dependencies, and you can wrap it in a conditional so it only loads where you want it.
A header and footer snippet plugin. Fine, widely used, one line of maintenance. Pick one that's actively maintained, since it now sits in the critical path of every page you serve.
Google Tag Manager. Convenient, gives marketing control over placement, and carries a caveat covered below.

Load it in the footer rather than the head. The widget isn't needed for first paint, and putting it in the head is a measurable hit to your page speed scores for no benefit whatsoever.

Loading it only where it belongs

A chat widget on every page of a WordPress site includes your blog archive from 2019 and your privacy policy. Neither generates a conversation you want, and both generate ones you'll have to answer.

Conditional loading is a few lines. Something like this, inside the child theme functions file, keeps it on the pages where a conversation is worth having:

function my_zendesk_widget() {
  if ( is_page( array( 'pricing', 'contact', 'support' ) ) ) {
    wp_enqueue_script( 'zendesk-widget', 'https://static.zdassets.com/ekr/snippet.js?key=YOUR_KEY', array(), null, true );
  }
}
add_action( 'wp_enqueue_scripts', 'my_zendesk_widget' );

Confirm the current snippet URL from your own admin rather than copying it from here, since the host and the parameters have changed before and will again.

What breaks it

This is the section you came for, whether you knew it or not. Four culprits, and it's nearly always one of them.

Caching plugins. A full page cache serves the same HTML to everyone, which is fine for a static snippet and fatal for anything conditional on a logged-in user. Check the widget appears for a signed-out visitor on a cached page, not just for you.
JavaScript minifiers and combiners. Aggressive concatenation frequently mangles third-party snippets. If the widget vanished the day you enabled an optimisation plugin, exclude the script from combining and move on with your life.
Consent and cookie banners. If chat loads through a tag manager, it inherits your consent rules. A support widget is arguably functional rather than marketing, so decide deliberately whether it should load for people who declined analytics, and write that decision down somewhere.
Lazy-load everything plugins. Some defer all scripts until the first interaction. Your chat widget then appears only after the visitor scrolls or clicks, which rather defeats the point of it.

WooCommerce, specifically

Chat on a checkout page is the highest value placement there is, and it's also the one most likely to cause a support ticket of its own.

On mobile the widget takes over most of the screen when open. If your pay button is fixed to the bottom, it's now underneath the chat panel. Test an actual purchase on an actual phone before you celebrate, because this bug reads as a broken checkout rather than a widget problem.

The other thing worth doing: pass the order number into the conversation where you can. Anything the customer has to retype is a place where the conversation gets slower and the customer gets crosser, and on a checkout page you're measuring that in abandoned carts.

Before you call it done

Five minutes of testing saves a fortnight of confusion. Check it in a private window, on a phone, on a cached page, with the cookie banner not yet accepted, and on one page where you expect it to be hidden.

If your site has a login area, check both states. And if you run a multilingual site, confirm the widget locale follows the page rather than the browser, because a German page with an English chat panel looks careless in a way customers remember.

FAQ

Frequently asked questions

Does Zendesk live chat work on WordPress without a plugin?

Yes. Zendesk live chat WordPress installs are just the widget snippet in the footer, and the plugin only exists to put that snippet there for you.

Do I need a plugin to add Zendesk chat to WordPress?

No. It is a single script tag. A plugin buys you a settings screen and per-page rules without code, which is convenience rather than capability.

Where should the Zendesk script go?

Enqueued from a child theme, loading in the footer. Pasting it into a parent theme file means losing it at the next update.

Why did my chat widget disappear?

Check your caching plugin, your JavaScript minifier and your consent banner, in that order. It is almost always one of those three.

Can the widget only show on some pages?

Yes, with a conditional around the enqueue, or through page rules in a tag manager or plugin. Worth doing rather than running it everywhere.

One site, two ways to reach you

Widget plus contact form on the same WordPress site means the same person arrives twice. Ticket Merger handles the overlap.

Start free trial

14-day free trial. No credit card required.