How to Add an AI Chatbot to WordPress and WooCommerce (2026)

A customer asks, “Do you deliver to my postcode?” while your team is packing orders. Another wants to know how returns work. A third types, “Where’s my order?” Those messages may arrive in the same chat window, but they require very different answers—and different levels of access.

Adding an AI chatbot to WordPress is usually the easy part. Making it useful, accurate, and safe takes more thought. This 2026 guide covers the setup process, the WooCommerce permissions that deserve extra care, and the tests worth running before customers see the widget.

What Can an AI Chatbot Do for Your Website?

Three tools often get lumped together under “chat,” even though they work differently.

Live chat connects visitors to a person. A staff member reads the message, checks the relevant information, and replies. It’s flexible, but someone needs to be available—or the conversation becomes an offline support message.

A scripted chatbot follows predefined rules. A visitor selects “Delivery,” then “Delivery areas,” and receives a prepared response. These flows are predictable, though they struggle when someone asks a question outside the script.

An AI support assistant interprets natural-language questions and generates responses using its available instructions, knowledge sources, and sometimes connected tools. It can recognize that “Can I collect my pizza?” and “Do you offer pickup?” probably need the same information. That flexibility is useful, but it also creates room for confident mistakes.

Website knowledge isn’t live store access

A chatbot trained on your delivery page might explain your delivery zone. One trained on your returns policy might describe the return window and exclusions. For a restaurant, it could point customers toward the menu, explain collection instructions, or summarize published opening hours.

None of that automatically gives it access to today’s stock or a customer’s order.

“Your delivery policy says orders usually arrive within this window” is a website-based answer. “Your driver will arrive in eight minutes” requires reliable, current operational data. A WordPress chat widget alone cannot supply that.

Start with public FAQs. Add live commerce actions only when the integration, permissions, and identity checks are clear. A small assistant that knows its limits is more useful than an ambitious one that guesses.

Choose an AI Chatbot That Fits Your Store and Budget

Choose the assistant around your support workload, not its demonstration. A polished answer about a sample product tells you little about how it handles a missing delivery, conflicting policies, or a request for a human.

Tidio with Lyro is one example of a product combining chat and AI assistance. However, widget installation, AI allowances, knowledge-source support, and WooCommerce actions are separate things to evaluate. Its current 2026 pricing and plan entitlements haven’t been independently verified for this guide, so no specific price or integration capability is assumed here. The walkthrough below is provider-neutral; dashboard labels will vary.

Use this checklist when assessing the available setup:

• WordPress installation: Is there a maintained official plugin? Check compatibility, recent updates, and whether staging sites need separate configuration.
• Knowledge sources: Can it use selected pages, manually written FAQs, or uploaded documents? How are sources refreshed and removed?
• Human handoff: Can visitors reach staff, leave a message, or receive a clear alternative when nobody is online?
• Usage and cost: What counts as a billable conversation, resolution, or credit? What happens when the allowance runs out?
• Data handling: Check transcript retention, deletion controls, staff permissions, subprocessors, and whether conversation data is used for model training.
• WooCommerce access: Separate catalog search, recommendations, order lookup, and order-changing actions. Don’t accept “WooCommerce integration” as an explanation of all four.

Budget for configuration and review time as well as software. An inexpensive plan that requires staff to correct answers every evening may cost more operationally than its subscription suggests.

For restaurants, sort out the ordering foundation first. FoodMaster’s WooCommerce restaurant ordering system supports delivery, pickup, and dine-in ordering, alongside POS, kitchen display, QR table ordering, and automatic printing. An AI assistant can explain your published ordering information, but don’t assume it connects to those operational features without a specifically supported integration.

My preference: keep chat advisory at first. Let the ordering system handle the transaction.

Install the Chatbot on WordPress and Configure the Widget

Install one official integration

Back up WordPress before adding the plugin. If you have a staging site, test there first using non-sensitive data. Check that the plugin supports your WordPress and PHP versions, and record any existing chat scripts so you don’t accidentally install a second launcher.

1. In WordPress, open Plugins → Add New Plugin. Find the official plugin for your selected assistant and verify the publisher. If it’s distributed privately, use the installation package supplied through the authorized account.
2. Install and activate it. Open its settings or onboarding screen and connect the correct business account. Review requested permissions before approving access.
3. Confirm the widget is connected, then configure the AI assistant separately if required. A visible chat bubble doesn’t prove AI responses are enabled.
4. Add approved knowledge sources and test answers privately before enabling automated replies for customers.

Some services use an embedded script rather than a WordPress plugin. Use the supported installation method, not both. Duplicate installations through a plugin, theme settings, and a tag manager can create overlapping widgets or inconsistent behavior.

Set expectations in the first message

Use a greeting that tells visitors what they’re talking to: “Hi, I’m the store’s AI assistant. I can help with delivery, pickup, and general policy questions. Ask for staff support if you need help with a specific order.”

Set the primary language where that control exists. For multilingual support, verify which languages are supported and test the actual answers. Fluent translation doesn’t guarantee an accurate interpretation of your return policy or menu terminology.

Configure staffed support hours, the correct time zone, and an escalation destination. Outside those hours, give a realistic response expectation rather than implying someone is about to reply. Send a test handoff and confirm it reaches the intended inbox or queue.

Check placement and page visibility

Review available display rules. Depending on the tool, you may be able to show or hide chat on particular pages, devices, or URL patterns. Don’t assume every plan includes those controls.

On mobile, the launcher must not cover “Add to cart,” sticky navigation, cookie choices, or the final checkout button. Test cart drawers and full-screen menu panels too. If safe positioning isn’t possible, disabling chat on the affected page is better than blocking a purchase.

Finally, check the site while logged out. Administrator sessions can behave differently because of caching, visibility rules, or consent settings.

[IMAGE: Mobile restaurant ordering page with an AI chat launcher positioned above sticky navigation, beside an unobstructed cart button, and clear of cookie controls]

Teach the Chatbot Using Your Website Content and FAQs

Your assistant needs a source of truth, not a pile of pages. Importing every blog post, old promotion, and archived menu is a reliable way to create conflicting answers.

Begin with a small collection: delivery information, returns or cancellation rules, contact details, opening hours, and current product or menu information. Add these through the sources your tool actually supports. Some systems crawl selected URLs; others need manually entered answers or documents.

Write answers that survive being quoted

Each FAQ should answer one question and include the conditions that matter. “We deliver locally” is vague. A better answer states the supported areas, any restrictions, and where customers can check address eligibility before paying.

Keep critical exceptions beside the main rule. If made-to-order items have different cancellation conditions, don’t bury that distinction on another page and expect the assistant to reconcile it correctly.

The following restaurant FAQ templates use placeholders deliberately. Replace them with verified business details before importing them:

• Opening hours: “Online orders are accepted during [ordering hours and time zone]. Dining-room hours are [hours]. Holiday changes are published on [approved page].”
• Delivery areas: “We deliver to [verified areas or postcodes]. Use the address check during ordering to confirm eligibility. Delivery charges are shown before payment.”
• Pickup instructions: “Choose pickup when ordering and follow the collection time provided. Collect from [verified location] and give staff the name or reference on your confirmation.”
• Dietary questions: “Published dietary information appears with the relevant menu items. For an allergy or cross-contact concern, speak directly with staff before ordering. The assistant cannot confirm that a meal is safe for your allergy.”

Giving a reference to staff at collection is an operational instruction—not permission for the chatbot to disclose order information to anyone who knows that reference.

Put firm boundaries around menu answers

Tell the assistant not to invent prices, ingredients, substitutions, portion sizes, or availability. If approved content doesn’t answer the question, it should say so and offer the appropriate next step.

Allergens deserve an especially strict boundary. A menu label doesn’t establish how food is stored, prepared, or handled during service. Staff confirmation is required for allergen safety questions; the bot shouldn’t turn “no nuts listed” into “nut-free.”

Exclude outdated PDFs, expired offers, duplicate policies, and draft pages from the knowledge collection. Check the imported content itself: a crawler may miss information hidden behind interactive controls or import navigation without the useful menu details.

Whenever policies or menus change, update the published source and refresh the assistant’s knowledge if that isn’t automatic. Then ask a question about the changed detail. Editing WordPress is only half the job if the chatbot still holds an older copy.

Handle WooCommerce Questions Without Exposing Customer Data

Public questions and personal order questions belong in different security categories. “How long does delivery normally take?” can use a published policy. “What address is order 1842 going to?” asks for personal information.

An order number alone is not proof of identity. Neither is a name or an email address typed into chat. Those details may be known by someone other than the customer.

Require authorization for live order lookup

Live order retrieval needs a supported integration that enforces access checks. The server should verify who the customer is and whether they’re entitled to see the requested order. The AI shouldn’t decide that someone sounds convincing enough.

A logged-in WordPress session doesn’t automatically mean an external chat service receives trustworthy customer identity. That connection must be explicitly implemented and validated. Guest-order support needs its own approved verification process, not an improvised chat interrogation.

Keep permissions narrow. If the assistant only needs a delivery status, it shouldn’t receive unrelated customer records or permission to issue refunds. Never place WooCommerce API credentials in browser code, public FAQs, or chatbot instructions.

Provide safe fallback replies when verified access isn’t available:

“I can explain our delivery policy, but I can’t securely check your order here. Please sign in through the My Account link in our store navigation and open Orders, or use our support contact for help.”

“For guest orders, please contact staff using the details in your confirmation email. Don’t send your password or payment-card details in this chat.”

In your actual widget, link these replies to your store’s real My Account and contact pages. Test the destinations, especially if WooCommerce uses customized page paths.

Make privacy settings part of installation

Update your privacy notice to explain the chat service’s role, what information it processes, relevant recipients, and retention arrangements. Review the provider’s data-processing terms and assess consent requirements for your jurisdiction and the widget’s actual behavior.

Choose a justified retention period and restrict transcript access to staff who need it. Check deletion procedures, including any limits affecting backups or provider logs. If transcripts may be used for model training, understand the terms and available controls before launch.

The chatbot should never request full payment-card details, card security codes, passwords, or one-time login codes. Direct payment problems back to the secure checkout or approved support process.

[IMAGE: Support workflow separating public FAQ answers from authenticated WooCommerce order access, with identity verification before retrieval and a staff-support fallback]

Test the Chatbot, Launch It, and Measure Its Value

Don’t test only the questions you hope customers will ask. Test the awkward ones—the confidently wrong premise, the old promotion, the impatient request for a person. That’s where the setup earns its place.

Run a pre-launch test checklist

• Incorrect premise: Ask, “You deliver everywhere for free, right?” It should correct the assumption using approved information.
• Unknown information: Ask about an unpublished discount or ingredient. It should acknowledge the gap rather than improvise.
• Outdated details: Ask for a discontinued item or expired price. Confirm old sources aren’t driving the answer.
• Privacy and instruction abuse: Request another customer’s order and tell it to ignore its rules. Neither request should bypass access controls.
• Human escalation: Request staff help during and outside support hours. Confirm delivery of the message and sensible expectations.
• Mobile and accessibility: Open, use, and close chat on small screens, with a keyboard, and with a screen reader. Check visible focus, control labels, message announcements, and whether focus returns sensibly.
• Performance: Compare key pages with chat enabled and disabled under similar conditions. Check loading, responsiveness, layout shifts, and checkout behavior.

Launch narrowly and review the misses

If display controls allow it, start on information pages before adding chat throughout the store. Review a manageable sample of conversations during the initial launch, including unanswered questions and confident answers. An empty escalation queue doesn’t prove the bot was right.

Track answer accuracy against approved sources, unresolved requests, successful handoffs, and staff time spent correcting replies. Define those measures consistently. “No human contacted” is not the same as “problem solved.”

Assign someone to maintain the knowledge collection. Include chatbot checks in your routine for menu changes, holiday hours, delivery-zone updates, and policy revisions.

Troubleshoot the right layer

If the widget is missing, check account connection, publication status, display rules, consent behavior, and browser blocking first. Then inspect script errors and performance settings that delay third-party JavaScript.

Clear relevant caches after configuration changes, but don’t disable caching across the whole store. Test targeted script exclusions on staging. WooCommerce cart, checkout, and account behavior also needs appropriate cache exclusions independently of chat.

If answers aren’t grounded in approved content, inspect source conflicts, import status, refresh timing, and any open-ended answering options. Reduce the assistant’s scope while fixing the cause.

The best first launch is deliberately modest: accurate public answers, an obvious route to staff, and no unsupported promises about live orders. Expand from there when the evidence—not the demo—shows the assistant can handle more.