One script tag, three places you can put it. It trains on your own pages, posts, PDFs and WooCommerce products, answers in 95+ languages, and uninstalls by deleting a line.
<script src="https://customerbot.co/script.js" data-bot-id="YOUR_BOT_ID"></script>A WordPress chatbot is a chat widget on your site that answers visitor questions automatically instead of sending them to a contact form. The useful kind is trained on your own posts, pages and PDFs, so it replies with your shipping policy and your pricing rather than a generic guess — captures a lead when someone is interested, and passes the conversation to a person when it should.
Most are sold as plugins. That is a habit rather than a requirement: the widget itself is client-side JavaScript, so a plugin is just a settings screen wrapped around a script tag you could paste yourself.
How training and retrieval actually workFive steps, about five minutes. The detail for step four is further down.
Create the assistant and crawl your site
Sign up, paste your WordPress domain, and let it fetch the reachable URLs. You get the list back before anything is trained.
Pick what it learns from
Tick the pages, posts and PDFs worth training on. A ten-year archive is mostly noise; twenty good pages beat two thousand mediocre ones.
Copy your script tag
The snippet comes with your own bot ID already filled in. There is nothing to configure by hand and no API key to paste.
Paste it into WordPress
A footer-script field, a wp_footer hook in your child theme, or a shortcode block on a single page. All three load the same widget.
Purge the cache and reload
Clear your caching plugin and your host CDN, then hard-reload. The launcher appears in the corner you configured.
Because nothing is installed, the compatibility list is short and boring — which is the point.
WordPress 5.0 and up
Classic editor, block editor, full-site editing
Any PHP version
The widget is client-side, so your PHP build is irrelevant
Elementor, Divi, Bricks, Beaver
Anything that calls wp_footer, which is all of them
WooCommerce
Product, shipping and returns pages crawl like any other
Multisite
One bot per site, or one shared bot across the network
WPML and Polylang
Replies follow the visitor’s language, not the URL prefix
They all load the same widget. The difference is where the line lives and what survives your next theme update.
Best for most sites
If you already run something like a header-and-footer code plugin, paste the tag into the footer field and save. It survives theme updates, needs no code access at all, and is the route to take if someone else maintains the theme.
Best for a child theme you control
Hooking wp_footer loads the widget site-wide with no plugin at all — nothing to update, nothing to abandon. Put it in a child theme so a parent-theme update does not wipe it.
add_action('wp_footer', function () {
?>
<script src="https://customerbot.co/script.js" data-bot-id="YOUR_BOT_ID"></script>
<?php
});Best for a single landing page
When you only want the assistant on the pricing page or one campaign landing page, drop the shortcode into a Shortcode block instead of loading it site-wide.
[customerbot bot-id="YOUR_BOT_ID"]
WordPress sites tend to have far more content than a support assistant needs. Being selective is the difference between sharp answers and vague ones.
Paste your domain and CustomerBot fetches the reachable URLs, shows you the list, and lets you pick which ones to train on. Bulk-train the whole set in one pass or start with ten that matter.
A ten-year blog archive is mostly noise for a support assistant. Train on the evergreen guides and skip the news posts — you can add more later once analytics tell you what people ask.
Price lists, spec sheets, terms. Uploaded, parsed and indexed alongside your pages, with text pulled out of image-heavy pages rather than skipped.
The answers you retype every week. Stored verbatim so the phrasing you have refined over years is what gets repeated.
A crawl reads your storefront the way a shopper does, which covers most of what people ask before they buy. The line worth understanding is the one between content and live data: anything that changes by the minute needs an API tool rather than a crawl, and the assistant calls it during the conversation.
Connecting your own endpointsShipping times, zones and costs
From your shipping policy page
Returns window and who pays postage
From your refunds page
Materials, sizing, care, compatibility
From crawled product pages
Which variant suits a described use
From product copy and your Q&A pairs
“Where is my order?”
Needs an API tool pointed at your order endpoint
Live stock for a specific SKU
Needs an API tool — a crawl is a snapshot, not a feed
The plugin directory has dozens of these and the screenshots all look alike. These are the questions that separate them, in the order they will bite you.
A scripted flow can only say what someone typed into a builder. A generic model will invent a returns policy. The third option — retrieval over your own pages — is the only one that answers a question nobody anticipated and still gets it right.
A plugin is code in your install: it needs updating, it can conflict, and if the author walks away you inherit a security liability. A script tag is one line that cannot break your admin.
Ask where the script loads and whether it is render-blocking. Loaded at the end of the body from a CDN, a chat widget should not move LCP at all. Anything injected in the head will.
The honest behaviour is to say so and offer a person, not to guess. Check that handover exists, that it collects an email when nobody is on, and that the transcript follows the conversation across.
Unanswered questions are the most valuable output of the first month. If the tool will not show you full transcripts and the questions it fumbled, you cannot improve it.
Uninstalling should be deleting a line — no orphaned database tables, no leftover options rows, no cron jobs still firing six months later.
In practice, a handful of things account for nearly every “it is not working” on WordPress. All of them have a one-line fix.
| Symptom | Almost always because | Fix |
|---|---|---|
| The bubble does not appear | A caching or optimisation plugin is serving a page generated before the change. | Purge in WP Rocket, LiteSpeed Cache, W3 Total Cache or whatever you run, then purge the host CDN and hard-reload. Check the page source for the script tag before assuming anything else is wrong. |
| It appears on some pages only | The tag went into a template that not every page uses, or into a per-page shortcode. | Use the wp_footer hook or a footer script field instead — both apply to every page the theme renders, including archives and the 404. |
| It vanished after a theme update | The snippet was in the parent theme’s functions.php and was overwritten. | Move it into a child theme, or use a plugin field that lives in the database instead of a file. |
| A JS optimiser breaks it | Deferring, combining or lazy-loading third-party scripts can prevent the widget from initialising. | Add script.js to the optimiser’s exclusion list — Autoptimize, Perfmatters and LiteSpeed all have one, and this is exactly what it is for. |
| It answers, but wrongly | It was trained before you rewrote the page it is quoting. | Re-train that URL. The old passages are replaced rather than added to, so the stale answer stops immediately. |
Training is a deliberate action, not a live mirror of your site. When you publish or substantially rewrite something, re-train that URL from the training screen — the old passages are replaced and the assistant answers from the new text immediately. Make it part of your publishing checklist and it takes ten seconds.
A WordPress chatbot is a chat widget on your site that answers visitor questions automatically instead of sending them to a contact form. The useful kind is trained on your own posts, pages and PDFs, so it replies with your shipping policy and your pricing rather than a generic guess, captures a lead when the visitor is interested, and passes the conversation to a person when it should. It can be added with a plugin or, as here, with a single script tag.
Create the assistant and let it crawl your domain, choose which pages and PDFs it trains on, copy the script tag with your bot ID in it, and paste that tag into a footer-script field, a wp_footer hook in your child theme, or a Shortcode block on one page. Purge your cache and reload, and the launcher appears. It takes about five minutes.
No. The functions.php route needs nothing installed, and a header-and-footer plugin is only a convenience for sites where editing theme files is impractical. There is nothing to keep updated, nothing that can conflict with your other plugins, and nothing that breaks when WordPress or PHP moves a version.
Yes — the free plan crawls a real site, trains an assistant and serves it on your WordPress install, so you can interrogate it on your own content before spending anything. Paid plans raise message and training limits and remove the CustomerBot watermark from the widget.
Yes. The tag renders through wp_footer, which every properly built theme calls — page builders and full-site-editing themes included. If your builder has its own custom-code area, that works too.
It is a single small script loaded from a CDN at the end of the body, so it does not block rendering and should not move your LCP. If you run an aggressive optimisation plugin, exclude the script from combining and deferring rather than letting it be mangled.
It reads them the way a visitor does — by crawling the product pages you publish, which covers materials, sizing, compatibility, shipping and returns. Live stock and order status are different: those change by the minute, so you connect the relevant endpoint as an API tool and the assistant calls it mid-conversation.
Yes. Give each site in the network its own bot ID if the content differs, or reuse one bot ID across the network when every site shares a knowledge base. The tag is per-site either way, so a network-wide footer field covers all of them at once.
Both. It collects a name and email inside the conversation rather than behind a separate form, and escalates to a person when the visitor asks or the assistant is out of its depth — with the transcript attached so nobody repeats themselves.
The assistant detects the language of each message and replies in it across 95+ languages, regardless of which translation plugin you run. You can train it on your primary-language content and it will still answer visitors in theirs.
Trained content and transcripts sit in your own workspace and are used to answer your visitors, not to train a public model. Conversations are yours to export or delete, and you can delete the workspace entirely from the account settings.
Delete the line. There is no database table, no orphaned options and no uninstall routine — that is the practical advantage of a script tag over a plugin.
The free plan indexes a real WordPress site and gives you a working assistant to interrogate before you edit a single theme file.
Start free