AI Chatbot WordPress Integration: Built Into Your Site, Not Bolted On

Three ways a chatbot can connect to WordPress

Adding a chatbot to WordPress can mean very different builds. The right one depends on where the bot’s reasoning runs, where its knowledge comes from, and where conversations end up.

We usually recommend the third pattern. It keeps the web server doing what it does well, serving pages, and lets the bot wait on slow external services without holding a PHP process open. The second is reasonable for a low-traffic site that must keep everything on one server. The first is fine for a trial, but it is a vendor product rather than an integration.

Why we ship a small plugin instead of editing the theme

Code pasted into a theme’s footer.php or a header-injection box disappears when the theme updates or someone switches themes, and nobody can tell from wp-admin that it was ever there. We package the integration as a small, single-purpose plugin that:

• Enqueues the widget with wp_enqueue_script using the defer loading strategy WordPress introduced in version 6.3, so the browser never waits on chat before rendering your page.
• Adds a settings screen for the few things staff should control: which pages show the launcher, office hours, greeting text and an on-off switch.
• Registers the REST routes the widget needs under its own namespace, each with an explicit permission_callback, which WordPress expects on every route.
• Keeps secrets as constants in wp-config.php or in the external backend’s environment, not in the options table, where every administrator account and any plugin with a database flaw can read them.
• Cleans up through an uninstall routine, so removing it leaves no orphaned options or scheduled events behind.

It behaves the same on block themes and classic themes because it hooks into WordPress rather than into template files. On a multisite network it can be activated per site with separate settings, or network-wide with one bot that knows which site a visitor is on.

Teaching the bot what your pages, posts and custom types say

A bot that answers from your site is only as good as its copy of your content. We build that copy from the WordPress REST API rather than by scraping HTML wherever the API gives a faithful version:

• Initial import. Published pages, posts and custom post types, such as services, locations, team members or FAQs, are pulled from /wp-json/wp/v2/. A custom type appears there only if it was registered with show_in_rest; when a theme or plugin left that off, we add a small filter instead of editing someone else’s plugin.
• Change detection. The plugin notifies the backend when a post is published, updated, trashed or made private, using the transition_post_status hook. As a safety net, the backend periodically asks the REST API for anything with a modified_after date later than its last successful sync.
• Chunking by structure. Content is split along headings, so an answer can point to the exact section of the page it came from and link straight to it.
• Exclusions. Drafts, private posts, password-protected pages and members-only content stay out unless you decide otherwise. A bot quoting a draft price change before it is announced is a real risk, not a hypothetical one.

Page builders need a check. Some keep layout in post meta and leave the standard content field sparse or full of builder markup, so what the REST API returns may not match what visitors see. During scoping we compare the API output with the rendered page for your key pages and, where they differ, index the rendered HTML instead.

Multilingual sites running a translation plugin get one index per language, and the widget passes the visitor’s current language so a Spanish-speaking visitor gets answers from the Spanish pages.

Where conversations land inside wp-admin

Plenty of WordPress owners live in wp-admin, not in a CRM. For them we store chat leads as a private custom post type with its own menu item, so each lead sits next to pages and posts with the visitor’s name, contact details, the question asked, the page where the chat started, and the full transcript.

• Custom capabilities. Reading chat leads is a separate capability from editing content, so an office manager can review leads without being able to change the site, and a content editor cannot browse customer conversations.
• Alerts through your mail setup. Notifications go through wp_mail, so they use whatever SMTP plugin the site already runs. If none is configured, alerts sent by the host’s default mailer often land in spam, and we fix that as part of the job.
• A form plugin as the destination. When your lead routing already lives inside a form plugin, the bot can submit into that form instead, as described on our Gravity Forms chatbot integration page.
• Onward to a CRM. Where a CRM is the system of record, WordPress keeps a copy and the backend pushes the lead onward, so a CRM outage never loses a lead.

Keeping the widget from costing you page speed

A chat widget is a script on every page, and it is a frequent reason a WordPress site’s mobile performance score drops after what looked like a small change. Our rules:

• Pages load only a tiny launcher: a button and a few lines of script. The full chat interface loads when someone opens it or after the page has gone idle.
• No extra fonts, frameworks or tracking pixels ride along with the widget.
• The launcher reserves its space, so it never shifts the layout when it appears.
• Representative pages are measured before and after with the same tool, and you see both results.

Optimization plugins need attention too. Features that combine, minify or delay JavaScript until a user interacts can break a widget or hold it back indefinitely. We set exclusions in whichever optimization plugin you run and confirm the widget behaves on a cached, logged-out page view, which is what real visitors get and what administrators testing while logged in never see.

What the browser, WordPress and the bot may each touch

Three boundaries keep a chatbot from becoming a hole in the site:

1. No model keys in the browser. The widget talks to your REST route or to our backend; the provider key never appears in page source, where anyone could copy it and run their own traffic on your account.
2. Least-privilege access to WordPress. The backend reads published content through public REST endpoints that need no credentials at all. Where it must write, for example creating a lead record, it uses an Application Password on a dedicated user holding only the capability that job requires, never an administrator account.
3. Abuse controls on the public route. The chat endpoint is open to anonymous visitors, so it gets per-IP and per-session rate limits, a message length cap and basic bot filtering. Without them, anyone can script thousands of requests against your model account through your own website.

Prompt injection gets a practical answer instead of a promise: the bot has no tool that can change site content, so a visitor who talks it into ignoring its instructions still cannot publish, delete or read anything private.

Privacy requests, retention and the tools WordPress already has

WordPress ships personal data export and erasure tools under the Tools menu, and plugins can register their own exporters and erasers into them. Ours does, so when someone asks what you hold about them, chat transcripts and leads tied to their email address come out in the same export as their comments and other stored data, and an erasure request removes or anonymizes them.

• A retention period you choose, after which transcripts are deleted by a scheduled task while the lead record you actually need remains.
• A short notice in the chat window saying it is an automated assistant, with a link to your privacy policy. We draft suggested wording for the chat section of that policy, and your counsel approves it; legal review is theirs, not ours.
• No raw transcripts sent to analytics tools. Reporting uses counts and topics, never conversation text.

From consultation to a live widget: EVOTECH’s steps

1. Talk it through, free. We spend a phone or video call learning what visitors ask, which pages hold the answers, and where leads should go.
2. Review the site: WordPress and PHP versions, theme type, page builder, caching and optimization plugins, custom post types, forms, SMTP, and any multisite or multilingual setup.
3. Agree a fixed scope. Our written quote names the integration pattern, the content sources, the lead destination, and everything left out on purpose.
4. Build and test on a staging clone of the site with your real plugin set, checked with debugging on for PHP notices, logged-out cache behavior, the privacy tools, and speed before and after.
5. Launch and tune. Early transcripts are reviewed with you, and unanswered questions become fixes to the site’s content as well as to the bot.

With 20+ years behind the business and a 5.0 rating on Google, EVOTECH works with WordPress owners anywhere in the United States from its Houston-area base. Running a store on the same site? Product and order questions use a different set of APIs, covered on our WooCommerce chatbot integration page. For the design of the assistant itself, see AI chatbot development, and if the site needs rework first, start with web design.

Related services

Frequently asked questions