WordPress AI Chatbot: Setup and Testing Guide

A WordPress AI chatbot is a chat tool added to a WordPress site that can answer visitor questions. Some use your support pages and documents to draft answers; others follow scripted paths or help create website content instead. For store support, the key checks are what knowledge the bot uses, what it does when it is unsure, and how usage is billed.

What a WordPress AI chatbot does—and what it is not

A support chatbot answers visitor questions in a chat window, often by drawing on help content your business provides. That differs from a rule-based flow, which follows paths you set in advance, and from a WordPress AI tool designed to create posts, code, or site components rather than handle support conversations.

Those categories can overlap, so start by asking what problem you want solved. If customers repeatedly ask about delivery windows or return conditions, a bot needs access to accurate support information and a way to deal with questions that the information cannot settle. A tool that generates website copy may use AI but not provide that support workflow.

A content-grounded chatbot retrieves relevant information from supplied sources and uses it to draft a response. The source might be a website, help article, uploaded document, or question-and-answer pair. A scripted bot instead uses decision trees or fixed responses. A scripted flow can be useful when you need a predictable sequence, such as asking a visitor which topic they need help with. It can become brittle when customers phrase questions in unexpected ways.

When comparing options, assess four things:

Knowledge source: Can you supply the pages and documents that contain your current policies? Can you choose or remove sources?
Model choice: Is the model selected for you, or does the product let you choose how the AI is powered?
Escalation: What does the visitor see when the answer is missing or uncertain? Can a human take over the same conversation?
Operating limits: Does the plan limit conversations, AI replies, credits, users, or another unit?

Also distinguish support chatbots from AI tools that help build a WordPress site. Those tools can generate content or code, but that does not by itself mean they answer visitor questions from approved support material or pass unresolved cases to your team.

Avoid treating labels such as “AI-powered” as a description of the support workflow. Ask what the bot is allowed to use, how it handles gaps, and what a teammate sees after a handoff. A credible setup should make those steps easy to inspect before you put it in front of customers.

How to integrate an AI chatbot in a WordPress website without custom code

You can add a chatbot through a WordPress plugin or by placing a hosted service’s embed script on your site. Which route applies depends on the tool. Before installing anything, confirm the actual installation method, whether an account or model API key is needed, and how to remove the widget if you decide not to use it.

A plugin is managed through the WordPress dashboard. A hosted widget may instead be configured in a separate account and added to your site with a script. In either case, installation is only one part of setup: you still need to configure the widget, supply trustworthy support content, and test the visitor experience.

A practical setup sequence:

Choose the support job. List the questions the chatbot should handle, such as published shipping estimates, product details, or return conditions. Keep customer-specific requests, exceptions, and account access out of scope unless you have a verified way to handle them.
Check how installation works. Confirm whether you need a plugin, an embed script, or both. Check whether an API key is required and who will manage it. Do not assume that a free plugin includes free model usage.
Connect the right account. Make sure the site, widget, and knowledge settings belong to the correct business account. If a tool uses a key you provide, follow its instructions for storing and rotating that key.
Configure the visitor experience. Set a clear greeting, support topics, and a route to a person. Keep the wording honest: do not tell customers that the bot can check an order or make a refund if it cannot.
Preview across the site. Check important pages, mobile display, and whether the widget covers buttons or other content. Load a few pages with and without the widget so you can spot obvious display or performance problems.
Test as a visitor. Ask a question using ordinary customer wording, then try a question the bot should not answer. Confirm the final response and handoff route, not just the setup screen.

For a hosted widget, a script tag can be a straightforward way to add chat without building a custom integration. For more on choosing this route, see our live chat plugin guide. For example, the hosted version lets a business add one script tag to its website; it can answer from the business’s own content and route uncertain questions to a shared helpdesk inbox. The website widget is available on every plan, including Free.

Do not take a successful installation as proof that the bot is ready. A widget that appears on the homepage may be missing from product or policy pages. A connected source may contain old content. A chat may open correctly but leave the visitor without a clear path to a person. Check each part of the workflow separately.

Prepare store content for product, shipping, and returns questions

A chatbot can only give dependable support from information your business has supplied and kept current. Before connecting sources, gather the approved product details, shipping terms, and return conditions that visitors are allowed to rely on. Remove stale or conflicting copies, and keep customer-specific order questions out of scope unless a verified integration supports them.

Make a source list before you connect a whole website. Include the current policy pages and the product information you want customers to receive. If a policy exists in several places, decide which copy is authoritative and remove or exclude the others. A bot may otherwise retrieve a snippet from an old page that contradicts your current terms.

A useful content inventory can include:

Shipping: published processing times, delivery estimates, shipping destinations, and any stated limits or exceptions.
Returns: the return window, eligibility conditions, and the steps customers must follow.
Products: accurate descriptions, sizing or compatibility details, care instructions, and known limitations.
Contact and support: the appropriate route for a case that needs a person, plus any information you ask the customer to provide.
Frequently asked questions: short, approved answers to recurring questions that are not clearly covered elsewhere.

Use plain, direct wording. If delivery estimates depend on destination, say that. If a product detail applies only to a particular model, make the model clear. Avoid writing policy material in a way that relies on internal shorthand or assumes a customer knows your process.

Audit sources before and after connecting them. A website crawl can include pages that are irrelevant to support, outdated promotions, duplicate policy copies, or drafts that should not be public. Review which pages the tool has access to, and remove material that could change an answer in the wrong direction. A crawl of a domain is not the same thing as a curated support library.

Treat order status as a separate problem from general shipping guidance. A page that describes the delivery estimate cannot tell the bot whether an individual parcel has shipped or when that customer’s order will arrive. Do not promise live tracking, a delivery date, an exception, or an order change unless a verified integration and source actually support that action.

This distinction matters in ecommerce because customers often ask a general question using personal details: “Will my order arrive before Friday?” The published policy may support a general estimate, but the bot may not have the customer’s order, destination, or tracking state. A safe answer gives only what the published policy supports and offers a person for the order-specific part.

Test answers, citations, and human escalation before launch

Test the bot against the exact content you have approved, not against questions you expect it to answer in theory. Check whether the response reflects the source, whether the visitor can see citations when the product provides them, and what happens when information is missing. Then test the handoff from the visitor’s view through to the team inbox.

Create a small test set from real customer questions. Include straightforward questions, alternate phrasings, and questions that combine two topics. For each, record the answer you expect based on the current policy and the source that supports it. This gives the support team a practical way to spot an answer that sounds plausible but changes the meaning.

Include tests such as:

“How long does shipping take?” when the policy gives a general estimate.
“Can I return this if I opened it?” when the conditions are specific.
“Does this fit model X?” when the product page gives a compatibility list.
“Where is my order?” when the bot has no customer-specific tracking access.
A question about a product or policy that is not in the connected sources.

For every answer, compare the bot’s wording with the supporting passage. Watch for added conditions, missing exceptions, or a firm promise where the policy is qualified. If citations are part of the product, check that they point to relevant content; a citation should help the visitor or teammate verify the claim, not merely look reassuring.

Then test questions with no answer. The important outcome is not that every question gets a reply. It is that the chatbot does not confidently fill a gap with an invented policy. Set a clear expectation for uncertainty and make sure the visitor can reach a human when needed.

Finally, test the handoff end to end. Ask what details the form collects, whether a teammate can see the conversation, and whether the visitor understands what happens next. Try taking over a live conversation if the product supports it. Confirm that the team can find the unresolved question and respond without asking the customer to repeat everything.

The support workflow retrieves passages from a business’s own knowledge, drafts a response, and checks that draft against those sources. When it is confident, the answer goes out with citations; when it is not, the visitor is told it is unsure and a ticket is opened for the team. Teammates can take over conversations live, and a human answer can be saved as approved knowledge. That workflow is useful to evaluate, but test it against your own policies before launch.

Use a handoff checklist: what information do you need, where does the ticket appear, who owns the reply, and how will the visitor know a person is taking over? A handoff that loses the original question or leaves the customer without a next step can create more work rather than less. For a practical structure, see this support handoff guide.

Worked example: answer a shipping question without overpromising

Suppose a visitor asks, “Will my order arrive by Friday?” Start with the published shipping estimate and check whether it supports an answer for that visitor’s destination and order. If the chatbot cannot verify individual tracking or an exception, it should give only the general guidance the policy supports and send the customer-specific question to a person.

Imagine your policy says that orders are processed within a stated window and delivery estimates depend on destination. The chatbot can explain those published terms, but it cannot infer that a particular order will arrive by a particular date without the necessary order and carrier information. A confident-sounding date would turn a general estimate into a promise.

A careful workflow would be:

Identify what the question needs. The visitor wants a specific arrival date, not just the store’s general shipping policy.
Check the approved source. The published shipping page may explain processing time and estimated delivery, but it may not include current tracking information.
Answer the part the source supports. The chatbot can summarize the published estimate and clarify that it cannot confirm this order’s arrival date from that information alone.
Escalate the individual case. Ask for the details your team needs, such as an order reference, using the handoff process you have chosen.
Keep the conversation together. The teammate should be able to see the question and the earlier response before replying.

The exact customer-facing wording depends on your policy. A suitable pattern is: “Our published shipping information gives an estimate, but I can’t confirm the status of your specific order here. I can pass this to the team so they can check the details.” Do not copy that wording if your team cannot actually check the order; the handoff should promise only an action your process supports.

This example also shows why a knowledge-based bot and an order lookup are different capabilities. Static support content can explain what the store generally does. Customer-specific status requires access to reliable order information. Keep the chatbot’s answer within the first boundary unless you have verified the second.

Boei, Tidio, and ChatBot.com: compare cost and usage carefully

Compare chatbot prices by the unit you will actually consume, not by the headline monthly figure alone. Boei figures in available reviews put Starter at $19 monthly with an AI-credit allowance; Tidio separates billable conversations and Lyro AI conversations; ChatBot.com lists per-user pricing with included AI resolutions. Use these figures to compare how each provider structures usage, while treating the amounts as review-reported figures.

Option	Pricing and usage details in the available figures	What to compare
Boei	Starter is quoted at $19 per month in reviews, with a monthly AI-credit allowance. One AI reply uses one credit. A seven-day free trial is also cited.	Compare the monthly price with the AI-credit allowance and check the trial terms.
Tidio	Listed paid plans start at $24.17 per month; the Lyro AI add-on starts at $32.50 per month. Tidio also presents a billable-conversation measure and a separate Lyro AI conversation measure.	Work out which usage is likely to apply to your expected workflow and what each charge covers.
ChatBot.com	Pricing is listed at $19 per user per month when billed annually for Essential, or $25 per user per month when billed monthly. Growth is listed at $79 per month and includes 200 AI Agent resolutions.	Count the seats your team needs and compare included resolutions with how the plan defines usage.

If you are comparing the best WordPress AI chatbot options for store support, start with how each one counts usage. These figures are not directly interchangeable. An AI credit may be consumed per reply, a billable conversation may count a thread regardless of the number of messages, and a per-seat plan makes team size part of the bill. Before comparing totals, write down your expected number of conversations, AI replies, and agent seats, then map them to the provider’s billing definition.

Tidio distinguishes a billable conversation from a Lyro AI conversation. A conversation that receives a human response or is initiated by a human agent counts as one billable conversation regardless of how many messages are exchanged in that thread. The AI conversation measure is separate. Do not assume those labels describe the same usage or that a human takeover will be counted the same way across products.

Boei’s cited figures describe a monthly credit allowance, but review-quoted prices and limits may not reflect the plan you see when you sign up. Verify the current price, billing period, credit allowance, and what happens when the balance runs out. For ChatBot.com, distinguish the free plugin installation or trial from an ongoing free plan: the listed pricing describes a paid subscription after its trial.

One alternative uses a different plan structure: a flat fee includes a number of AI conversations per month, with no per-resolution fee or credit packs. Plans are priced in euros. The Free plan is EUR 0 with a one-time allowance of 30 AI conversations; paid plans start at EUR 29 per month for Starter, which includes 500 AI conversations per month. An AI conversation can hold up to 25 AI replies on paid plans and up to 10 on Free. Compare those definitions with your expected usage rather than treating the conversation counts as equivalent to another product’s credits or billable conversations.

The useful comparison is the likely bill at your real support volume and team size. A low entry price can still be a poor fit if its included unit does not match how your customers use chat. A plan with more included usage may cost more than a small team needs. Read the billing definition alongside the plan price, and check what happens when you reach the included allowance.

Common setup failures and the next steps after launch

The most common setup problems are poor source hygiene, unclear usage assumptions, and no routine for reviewing unanswered questions. Start with a curated knowledge set, be precise about whether a quota is a trial or ongoing allowance, and review unresolved conversations so you can improve approved content without turning one customer’s exception into a general policy.

A broad site crawl can be convenient, but it may include material that should not guide a support answer. Audit pages before connecting them and revisit the list when policies change. Pay particular attention to duplicate pages, old promotions, and content that contradicts the current returns or shipping terms.

Do not treat these terms as interchangeable:

Free trial: temporary access before the paid subscription begins.
One-time quota: a limited amount of usage that does not renew each month.
Monthly conversation allowance: an amount that resets under a monthly plan.
AI replies or credits: individual AI responses or other units that may be consumed differently from whole conversations.
Human-billable conversation: a conversation counted under the provider’s rules even if a human, rather than the AI, responds.

Once the chatbot is live, check its unanswered questions and escalations regularly. Look for missing source material, ambiguous policy wording, or questions that should always go to a person. Update approved knowledge only after confirming the answer with the person responsible for that policy. Then repeat the relevant tests so the new material does not create a conflict elsewhere.

Keep a simple review routine: identify recurring unanswered topics, decide whether the answer belongs in public support content, update the approved source, and retest the question. A human response should not become general knowledge automatically if it contains a one-off exception or depends on private order details.

Measure whether the workflow helps your support team, not just whether the widget appears active. Notice which topics reach a person, whether teammates have enough context, and whether the answers match your policies. If the bot is creating corrections or confused follow-ups, narrow its scope and improve the source material before encouraging it to handle more questions.

That review loop can include saving a human answer as approved knowledge through the Teach step. Its knowledge can come from a website crawl, PDFs, Word files, plain text, and Q&A pairs. Use that only for material you want the AI to rely on; keep private case details and unapproved exceptions out of the knowledge base.

Frequently asked questions

These questions help separate installation, ongoing cost, and support capability. A WordPress widget can answer general questions from approved content without being able to look up a customer’s order. Before launch, verify the specific tool’s installation route, free usage terms, and escalation behavior.

Is there a free WordPress AI chatbot plugin?

Some WordPress chatbot tools offer a free plugin, a free plan, or a trial; those are different arrangements. A plugin may be free to install while requiring a paid account or separate AI usage. Check what the free option includes, whether it can use your own support content, and whether its allowance renews or is one-time.

A free trial gives temporary access, whereas a lasting free plan has ongoing limits. Read the plan’s definition of usage and check whether the functions you need—such as connecting support sources or handing a question to your team—are included.

Does a WordPress AI chatbot need a plugin, or can I add it with a script?

Either route is possible, depending on the product. Some chatbots are installed as WordPress plugins; some hosted services provide an embed script to add a widget to a site. Check the tool’s setup instructions, whether an account or API key is required, and how you will manage the widget after installation.

A plugin can be convenient when you want to manage setup in WordPress. A script can suit a hosted widget that is configured outside the WordPress dashboard. Neither route, by itself, proves that the bot is trained on the right support content or has a working human handoff.

Can an AI chatbot answer WooCommerce order-status questions?

Only if the chatbot has a verified way to access the relevant order information and is permitted to use it. A shipping policy or product page can support general answers, but it does not establish whether an individual order has shipped or when it will arrive. Do not promise order lookups or order actions based on static support content alone.

Test customer-specific questions explicitly. If the bot cannot securely verify the order details, it should explain that limitation and route the case to a person who can help.

What happens when a WordPress chatbot does not know an answer?

That depends on the product and its configuration. A responsible setup should have a defined fallback: it may say it cannot answer, direct the visitor to a support route, or open a ticket for a teammate. Test this with questions that are not covered by your knowledge base, and make sure the handoff reaches the inbox your team actually uses.

With momo, the visitor is told when the AI is not sure, and a ticket is opened for the team. The inbox is included on every plan, and teammates can take over a conversation live.

How is a Tidio billable conversation different from a Lyro AI conversation?

They refer to separate usage measures. A Tidio billable conversation can count a thread that receives a human response or is initiated by a human agent, regardless of how many messages appear in that thread. A Lyro AI conversation is an AI usage measure. Check both definitions against your expected workflow rather than treating them as the same quota.

Choose a narrow first use case

Start with a small set of common questions that have clear, approved answers, then test the source, response, and human route before expanding the scope. If you want to see how momo handles support knowledge and uncertain questions, you can try momo free.

WordPress AI Chatbot: Setup, Testing, and Pricing Guide