Chatbots

3 Best WordPress chatbot options in 2026

Laptop and a pencil beside a blank notebook

Last updated · A-Widget

On this page7

Our top 3 picks

Compare intended use, documented scope and trade-offs
DecisionTidioChatBotHubSpot
Best forAn owner who wants a human queue with a defined automation taskA WordPress owner with a defined bot workflow and fallbackA business already using HubSpot for contact follow-up
Documented scopeLive chat and help desk; Lyro AI and Flows have distinct usage units; Published free tier has finite allowancesHosted chatbot product; Website integration documentation; Subscription is separate from LiveChatWebsite live chat and CRM route; Chatflows and account-based management; Advanced capabilities depend on entitlement
Trade-offThe plugin does not merge human, Lyro and Flows allowancesA separate human-support service may be neededBasic chat and advanced automation may have different entitlements
Next stepRead Tidio analysisRead ChatBot analysisRead HubSpot analysis
  1. Tidio

    Best for
    An owner who wants a human queue with a defined automation task
    Documented scope
    Live chat and help desk; Lyro AI and Flows have distinct usage units; Published free tier has finite allowances
    Trade-off
    The plugin does not merge human, Lyro and Flows allowances
    Read Tidio analysis
  2. ChatBot

    Best for
    A WordPress owner with a defined bot workflow and fallback
    Documented scope
    Hosted chatbot product; Website integration documentation; Subscription is separate from LiveChat
    Trade-off
    A separate human-support service may be needed
    Read ChatBot analysis
  3. HubSpot

    Best for
    A business already using HubSpot for contact follow-up
    Documented scope
    Website live chat and CRM route; Chatflows and account-based management; Advanced capabilities depend on entitlement
    Trade-off
    Basic chat and advanced automation may have different entitlements
    Read HubSpot analysis

This is a research-based comparison of current official sources. It does not claim that a paid account was tested or that a plugin guarantees accurate answers. Keep public knowledge, private account actions and human follow-up as separate parts of the workflow.

1. Tidio: a WordPress chatbot with human chat

Tidio

Our verdict:

Mixed support on WordPress

Best for An owner who wants a human queue with a defined automation task

  • Live chat and help desk
  • Lyro AI and Flows have distinct usage units
  • Published free tier has finite allowances

Keep in mind: The plugin does not merge human, Lyro and Flows allowances

Tidio is a candidate when the WordPress site needs human chat and a route into automation. Its current materials distinguish human conversations, Lyro and Flows. Installing the plugin does not turn those into one unlimited service.

Use the official Tidio WordPress listing and current vendor help to check ownership and supported setup. Match the chosen account and site identifier. Do not connect users to a developer's unrelated account or an expired trial.

Define what the bot may answer

Choose current public pages that establish the needed facts. For a fictional service site, those might explain the available services and normal contact route. A bot reading those pages should not infer a confirmed booking or an exception to a policy.

Keep an answer outside the source explicitly unsupported. A clear “I cannot prove that” response with a contact path is more useful than a confident guess. Decide when the question needs a person before enabling the bot publicly.

The Tidio pricing guide distinguishes human conversations, AI use and automation allowances. A one-off AI allocation is not the same as an ongoing monthly plan. Check the real account state after a trial.

Why choose or pass

Choose this route when the current combination of human chat and automation fits a real task. Pass when the site only needs a simple form or an occasional human message. The plugin should support the process rather than create a reason to use every available product.

The main trade-off is managing the product boundaries and the source. A larger quota does not fix stale public content, missing staff coverage or an unclear handoff. Those remain business tasks.

2. ChatBot: a dedicated bot connected to the site

ChatBot

Our verdict:

Dedicated conversation task

Best for A WordPress owner with a defined bot workflow and fallback

  • Hosted chatbot product
  • Website integration documentation
  • Subscription is separate from LiveChat

Keep in mind: A separate human-support service may be needed

ChatBot is a dedicated product candidate for a website bot task. Its current help centre is the source for the supported WordPress or website installation. Use the route described for the real account and product.

Keep ChatBot distinct from LiveChat. The products have related names but separate plans and scope. A bot connection does not prove that a staffed human queue is included or available at every hour.

Keep the conversation small enough to inspect

Write the main question, the supported response and the no-match path. A short routing task may use clear choices. An AI task needs a source boundary and a way to decline unsupported requests.

For a fictional booking inquiry, the bot can explain service choices or direct the user to the supported scheduler. It should not declare a time reserved without the scheduler's real result. A preference typed into chat is not a booking record.

Inspect the current package for knowledge inputs, usage and handoff. If the help does not prove a required behavior, mark it not checked. A demo built by the vendor may use a distinct package or source from the one you plan to install.

Why choose or pass

Choose a dedicated bot route when the task and acceptance cases are defined. Pass when the business expects the software to invent missing policies or remove all staff involvement. People still maintain the source and handle exceptions.

The main trade-off is connecting the wider process. WordPress placement is one step. The receiving inbox, staff hours and data handling need their own supported setup and clear owner.

3. HubSpot: chatflow in a CRM setting

HubSpot

Our verdict:

CRM-linked WordPress workflow

Best for A business already using HubSpot for contact follow-up

  • Website live chat and CRM route
  • Chatflows and account-based management
  • Advanced capabilities depend on entitlement

Keep in mind: Basic chat and advanced automation may have different entitlements

HubSpot is a candidate when the bot or chatflow should support an existing CRM process. Its knowledge base and current WordPress connection material establish the supported route. Check the exact product and account rather than assuming all automation is included in free chat.

The useful question is what staff should do with the resulting record. A user may ask a general question, request a quote or need support. Those are distinct intents and should not all become the same sales record by default.

Keep contact collection proportionate

Ask for the detail needed to handle the request. A reply address can be useful when the user wants follow-up. A long pre-chat form can be unnecessary when the question is a simple public fact.

Keep uncertain values open. A missing budget is not zero, and a general inquiry is not by itself a qualified lead. Use a human review route where the user's request does not fit the available categories.

Inspect the site's real tracking and connected data when installing the route. The website policy should describe what loads and which service receives conversation and contact details. A broad CRM feature list is not a privacy inventory for your site.

Why choose or pass

Choose this route when the business already needs the wider CRM process and the current plan scope fits. Pass when adopting that system would create more work than the conversation needs. A narrow human chat or form may be more manageable.

The trade-off is the scope around the widget. Staff need suitable access and a maintained follow-up process. A new contact record has value only when someone uses it correctly.

Factors to consider when choosing a WordPress chatbot

WordPress account and hosting route

Self-hosted WordPress and WordPress.com have distinct plugin and code permissions. Check the real hosting route first. A tutorial for a self-hosted administrator may not apply to a hosted account's current plan.

Use WordPress.com plugin support for the hosted route and WordPress help for the theme, block and script controls. Keep the vendor's own guide alongside the platform's permissions.

Plugin ownership and maintenance

Open the official listing and verify the publisher, current update details and supported site versions. A familiar name alone does not prove an unofficial connector is maintained by the vendor. Follow the vendor's current link to the correct route.

Use a safe site copy or a controlled change with a rollback. Other plugins, a theme and optimisation settings can affect scripts. The vendor's documented compatibility does not prove the condition of every installation.

Knowledge access

Decide which pages or documents the bot may use. Keep public service answers separate from private records. More source material is not by itself better if it contains old or conflicting instructions.

Assign an update owner. When a page changes, check whether the bot's source needs a separate refresh. A listed website edit does not prove that every external knowledge copy has changed.

Human fallback

Name the trigger and destination for escalation. A request for a person, a no-answer state and a sensitive task may need the same contact route or distinct ones. The user should understand which path they are using.

Confirm staff hours. A bot can run while a person is away, but it should not promise a live transfer then. A later-message route needs an owner and a clear expectation.

Cost and limits

Compare the current service plan, not just the plugin's install price. Human seats, conversations and AI use can have separate units. Record the real package and billing period for the needed task.

Do not turn an unknown charge into zero. Do not assume a free chat tier includes a paid AI product. Inspect the post-trial state before making a continuing support promise.

Install and confirm handoff

Prepare the existing site

Record any current chat or bot route in plugins, theme code and site-wide injection. Keep one planned source of installation. A new plugin can overlap an old pasted snippet and make diagnosis harder.

Back up the site before installing the plugin, and keep ordinary contact details visible. Use fictional questions and test records. Do not copy user conversation history into a new bot just to see whether it can read it.

Connect the correct account

Follow the vendor's current WordPress route. Verify the business account and widget identifier before publishing. A developer's temporary setup should not become the only place where user messages arrive.

Keep secrets out of public page source. A site identifier used by a supported snippet is distinct from an API credential. If the instructions are unclear, inspect the official guide rather than guessing which value belongs in the browser.

Check meaningful questions

Ask a question that the approved source can answer. Then ask a related question it cannot answer. Inspect the difference. The second should produce the planned limit and fallback, not a made-up service or policy.

Ask for a person directly. Check what appears in the receiving staff system and what the user sees. Repeat the handoff check in the offline state so the bot does not imply an immediate response when none is available.

Check the published page

Open the site while signed out, then use a narrow screen. Read the whole reply and error text. The panel should not cover key controls or require sideways scrolling to reach its close button.

Move through the widget with a keyboard. Check focus when it opens, when a message is sent and when it closes. A visually correct panel can still be difficult to leave if focus is trapped.

If the bot does not load, check the known installation, account state and publication first. Then inspect whether caching, delayed scripts or consent rules affect it. Change one verified cause at a time.

Do not disable unrelated site protections merely to make the launcher appear. Use the vendor's documented route for an exact script conflict. Confirm the public result after each targeted change.

Keep the baseline useful

Block the external request in a safe preview or use the vendor's supported failure test. The main page, service facts and contact route should still work. A bot should not become the only place a user can find key details.

If the bot gives an unsafe answer, disable the known route while correcting its source or settings. Removing website code is separate from closing a plan or deleting data. Handle those through the vendor's real controls.

Maintain the bot after launch

Review unresolved questions to find source gaps. Do not add a broad answer merely to reduce the no-answer count. Some tasks should continue going to a person or a secure account route.

Recheck the source after changes to services, pricing or policies. Recheck placement after a theme or plugin change. Keep the installation and removal location in a short owner record.

Compare the small-business chatbot choices for the wider product decision. Use the readiness guide if the task or source still needs definition.

Review the allowed content after a site restructure

When WordPress pages are moved, archived or replaced, inspect the bot's source list too. A working web redirect does not prove that a separate knowledge copy has changed. Use the chosen vendor's refresh controls and inspect a question affected by the move.

Keep drafts and private business material outside the public answer source. If the bot's source cannot be traced to current approved content, narrow its scope until that record is clear. A smaller known source is easier to correct than an unexplained mix of old pages.

Keep the answer source separate from the theme

WordPress page content, reusable template parts and a hosted chatbot knowledge copy can change independently. A theme change may move the launcher without changing a single bot answer. Editing a policy page may change the website while leaving an imported document untouched. Identify which source your chosen bot actually reads before deciding how to maintain it.

For a public service FAQ, nominate the published page as the editorial source. If the vendor imports it, record the supported refresh operation and who performs it. Where several pages repeat the same policy, resolve conflicting wording at the source rather than adding instructions that ask the bot to choose between them. Do not include private drafts merely because they sit in the same WordPress installation.

Diagnose the symptom before changing plugins

If no launcher appears, start with the website layer: whether the plugin is enabled, the intended page is published and one supported installation loads. A launcher that opens but cannot answer points to a different layer, such as its account, source or service state. A correct answer followed by no staff task points to the receiving workflow. These symptoms should lead to different changes.

Use a simple worksheet with the observed symptom, the relevant system and the next reversible action. For example, a duplicate launcher calls for inspecting known snippet locations. A stale opening-hours answer calls for comparing the bot’s allowed source with the current hours page. A lost follow-up calls for checking the staff queue and configured recipient. Reinstalling WordPress code is unlikely to correct an obsolete knowledge document.

Assign ownership across an agency handover

When an agency installs the bot, ensure the business controls the service account and knows how to grant and remove staff access through the supported roles. The public site identifier can be copied into the approved installation; ownership of the receiving account cannot be inferred from that identifier.

List the people responsible for three separate jobs: editing public service facts, refreshing the bot’s source when required and handling conversations. One person may do all three, but the responsibilities still differ. Keep billing and account recovery with the business’s authorised account owner. When an agency’s access ends, review these roles before assuming the website handover is complete.

For a future theme replacement, take the installation inventory to the new editor. It should state whether the launcher comes from the plugin, a template snippet or the vendor’s supported alternative. That lets the editor preserve one installation without carrying forward a second hidden copy. The same inventory makes a deliberate rollback possible if the new theme obstructs the widget.

Continue with the right task

FAQ

Does a free plugin include free AI?

Not by itself. The plugin connects the website to a service whose current plan controls AI, chat and other usage. Check the real account and ongoing offer. Trial access or a first allocation can differ from a recurring free allowance.

Does connecting every page improve answers?

Not necessarily. Old, conflicting or irrelevant content can make the source harder to trust. Start with approved current material for a narrow task. Keep unsupported questions on a clear fallback route rather than asking the bot to infer a policy from unrelated pages.

Can I remove the bot by deleting its plugin?

That can remove the plugin route, but check for a separate manual snippet or app connection. Inspect the live page after the change. Account billing, stored messages and staff access are separate from the visible website installation and need their own supported handling.