Most “add a chatbot to WordPress” guides stop at installing the plugin. That is the easy part. The work that decides whether the bot helps or embarrasses you happens afterwards — what it knows, what it is allowed to say, what it does with visitor data, and what it costs you in page speed.
Plugin or script embed?
Both routes are no-code. The difference matters more than it looks.
- Plugin — installs from the WordPress admin, adds a settings page, and usually lets you control placement per page or post type. The cost is maintenance: another plugin to update, and another dependency that can break on a WordPress core release.
- Script embed — one tag pasted into your header, typically via your theme options or a header-and-footer plugin you probably already have. It is lighter, does not care about WordPress versions, and is easier to remove cleanly.
If your plugin list is already long, embed the script. If you want per-page control without touching anything technical, use the plugin.
Ground it in your own content — this is the whole game
A chatbot running on general model knowledge will confidently describe services you do not offer and prices you never set. The fix is grounding: the bot indexes your actual pages, posts and documents, and answers from those.
In practice that means pointing the crawler at your site, then deliberately adding the material that is not on your public pages but that customers ask about — delivery timescales, what is included in a quote, which areas you cover. The gaps in your website become the gaps in your bot.
Re-crawl after significant publishing. A bot quoting last season's pricing is worse than no bot, because visitors treat it as authoritative.
Set the boundaries before you go live
Decide explicitly what the bot must never do. At minimum:
- Never quote a firm price if your pricing depends on scope — have it collect requirements and hand off instead.
- Never give advice in regulated areas (medical, legal, financial) if that is not your business.
- Never claim availability, stock or lead times it cannot verify.
- Always offer a route to a human, and never bury it.
The escalation path deserves real design attention rather than being left on defaults — we covered the detail in our guide to chatbot human handoff.
Privacy settings you actually have to configure
The moment a visitor types their name or email into your chat widget, you are processing personal data. On a WordPress site aimed at UK or EU visitors that means you need a lawful basis, a retention period, and a processor agreement with whoever runs the chatbot.
Practical steps: turn transcript retention down to what you genuinely need, check whether the provider trains on your conversations and opt out if so, add the widget to your cookie or consent tooling if it sets anything before consent, and mention it in your privacy policy. Our chatbot privacy and GDPR guide goes through the obligations properly.
Protect your page speed
Chat widgets are a common cause of quiet Core Web Vitals regressions. Two things to insist on: the script loads asynchronously, and the heavy chat bundle only loads when someone clicks the launcher rather than on every page view.
Run PageSpeed Insights on a key landing page before you install and again afterwards. Watch Interaction to Next Paint alongside the loading metrics — a widget that blocks the main thread hurts responsiveness even when the loading scores look fine. If the numbers move materially, restrict the widget to the pages where it earns its place.
Where to show it — and where not to
Sitewide is the default and rarely the best choice. Put the bot where it has a job: service pages, pricing, contact, and high-traffic blog posts that attract question-shaped searches. Keep it off checkout and form pages where it competes with the action you actually want.
Test with real questions before launch
Pull twenty genuine questions from your inbox, contact form or phone notes, and run them through the bot. Grade each answer as correct, incomplete or wrong. Anything wrong is a content gap to fix before visitors see it, not after.
Then check the awkward cases deliberately: a pricing question, an angry complaint, a request for a human, and something entirely outside your business. How it handles those four tells you more than a hundred easy queries.
After launch, read the transcripts
The transcripts are the most useful output. They tell you what visitors actually want to know, in their own words — which is both a content roadmap for your site and a list of the questions your sales process is failing to answer. Set a weekly reminder to read them for the first month.
If the bot is meant to generate enquiries rather than just answer questions, the design differs; our guide to chatbots for lead generation covers that side. And for the wider decision about hosted versus custom, see our AI chatbot development work.
Want it done properly the first time?
SpiderHunts Technologies sets up WordPress chatbots grounded in your own content, with consent and handoff configured correctly. Book a free consultation and we will review your site first.
Book a Free Call WhatsApp Us