Adding an assistant to a WordPress site

There are three common ways to add a widget script to WordPress, and the difference between them matters more than it appears, because two of them can silently lose your code.

Option 1: theme footer.php, avoid

Editing footer.php directly works until the theme updates, at which point your change is overwritten. If someone has done this and the widget disappeared after a theme update, this is why. Use a child theme if you must edit template files at all.

Option 2: a header and footer script plugin, usually right

A small plugin whose only job is injecting scripts into the head or footer is the pragmatic choice for most sites. It survives theme updates, it is visible to whoever inherits the site, and it can be removed cleanly.

Option 3: enqueue properly in a child theme functions.php, best for developers

Using wp_enqueue_script with the correct hook is the technically correct approach. It participates in dependency ordering and can be conditionally loaded per template.

add_action('wp_enqueue_scripts', function () {
  wp_enqueue_script(
    'site-assistant',
    'https://example.com/widget.js',
    array(),
    null,
    true          // load in footer
  );
});

The final true is the important argument. It puts the script in the footer rather than the head.

Caching will hide your change

This is the single most common WordPress support issue with any embed. Page caching plugins and CDN layers will serve the old HTML without your script for anywhere from minutes to hours. Before concluding the embed failed:

• Purge the page cache plugin.
• Purge the CDN cache if one is in front.
• Test in a private window, since your logged in view often bypasses cache and shows a different result from what visitors see.

That third point causes real confusion, because the site owner sees the widget and the visitor does not, or the reverse.

Consent plugins and script blocking

Many WordPress sites run a consent management plugin that blocks third party scripts until consent is given. These plugins often categorise unknown scripts as marketing or analytics by default, which means the widget will not load for anyone who has not accepted that category.

This is not a bug, and it may well be the behaviour you want. But decide it deliberately: is a support widget functional or marketing under your own consent model? Then configure the plugin to match, rather than discovering by accident that the widget only loads for some visitors.

Training sources

WordPress sites usually expose a sitemap, either from the core or from an SEO plugin. Exclude tag archives, author archives, date archives and paginated listing pages. These are structural pages with little prose and they add noise without adding answers.