How to Add an AI Chatbot to a Website: Embed vs Support Agent

A visitor asks about a plan limit described on a help page, then asks whether that limit applies to their own account. A website widget can display both questions; answering them reliably requires approved documentation, and the account-specific answer may also require identity checks and customer data.

To add an AI chatbot to a website, choose an installation route that fits the site, connect approved content, set boundaries, and test the support workflow before publishing. A no-code embed is often the fastest deployment option; a CMS integration or code install may fit a particular site better. None of these routes, by itself, makes answers grounded or actions safe.

Choose the right way to add an AI chatbot to your website

The right installation route is the one that matches how the website is built and maintained. A site owner who can add a script through a builder may not need a developer. A SaaS app with a React interface and a release review process may be better served by a developer adding the widget to a shared layout. Both routes can display the same kind of chat interface.

A WordPress site might use a plugin or add code through its theme or site settings. A Webflow site might use a supported integration or custom-code setting. Those are installation patterns, not guarantees that a particular chatbot supports every platform method. Google Sites-style builders have their own embed options, so the relevant question is whether the platform accepts the kind of widget code the provider supplies.

A developer may add a widget to a React, Vue, or Angular application when that fits the provider’s integration method. The useful distinction is not “code is better” versus “no code is better.” It is whether the installation can be maintained, tested on the right pages, and changed through the team’s normal publishing process.

The task matters as much as the site. A lead-capture bot may mainly collect contact information. A support agent must handle product questions, set expectations about uncertainty, and route cases it cannot resolve. Some SaaS questions also require customer-specific context or an approved action. Those requirements are separate from the choice of embed; see how SaaS teams can add AI support without unsafe automation.

What to compare in website chatbot options

A widget’s appearance says little about the support work it can perform. Compare the agent behind the widget on its documentation sources, access to customer context, permitted actions, and human handoff. The products named in this comparison share an AI-support orientation, but their public positioning and the detailed, comparable product information available here are not identical.

For the three competing products, the linked pages establish a useful high-level comparison: AssistLoop presents AI support, PeopleLoop presents support features and describes a specific onboarding flow, and LoopReply presents SaaS support use cases. The cited descriptions do not create a like-for-like table of prices, conversation caps, data-access permissions, or action limits. A buyer should compare those details against the team’s actual use cases rather than infer that differently positioned products work identically.

The more precise support-capability questions are:

• Grounding: Does the agent answer from the company’s approved content, and can the support team see the sources behind an answer?
• Source types: Does its content workflow handle the team’s relevant webpages and documents, including PDFs where needed?
• Customer context: Can it look up an account without confusing one visitor with another or exposing data to an unauthenticated visitor?
• Actions: Can the team constrain what the agent may do and test the conditions that must be met before an action runs?
• Escalation: Is there a path to a person for unresolved questions or sensitive requests?
• Review: Can the team examine unanswered questions and improve the underlying content or instructions?

A help-center answer and an account-specific answer are different workloads. A public article may explain how to change a plan, while a customer lookup may be needed to say which plan a particular visitor has. Changing that plan is a further step: it is an action, and it needs its own permission and safeguards. Documentation bots and guarded support agents address this distinction in more detail.

Prepare the chatbot’s knowledge and support boundaries

Start with a small set of approved sources that answer common customer questions. Typical candidates include setup instructions, troubleshooting pages, billing explanations, product limitations, and current policies. Include PDFs when they contain customer-safe information and the selected agent supports them. A large archive is not automatically better than a smaller set of accurate, current material.

PeopleLoop’s getting-started guide describes website or help-center URLs, uploaded documents such as PDFs and Word files, and structured knowledge as inputs for its agent. It recommends beginning with documents customers ask about most, refreshing content when products or policies change, and avoiding duplicate or outdated sources. Those details point to a general preparation task for any provider: decide which source is authoritative before connecting it.

A source inventory can be as simple as a shared list with four fields: source name, customer-facing or internal, owner, and last review. For example, a team might approve its current public plan guide and password-reset article, while excluding an internal incident report. The inventory gives the team a concrete way to spot a stale policy or a document that should not inform a visitor-facing answer.

Define what the agent should not answer as carefully as what it should answer. “Use our own content” does not tell the agent what to do when the content is silent, contradictory, or out of date. Specify whether it may use general knowledge, what to do when a source does not support an answer, and which subjects require a person. The answer should match the company’s actual support policy, not an assumed capability of the model.

For example, a public article may explain how account recovery works. The agent can summarize those documented steps, but it should not claim that a particular account has been recovered unless the appropriate account state has been checked. The content boundary determines what the agent may explain; identity rules determine whose account it may access; action rules determine what it may change. Keeping those boundaries distinct makes testing more useful.

A practical first source set could include three maintained help pages: onboarding, billing, and troubleshooting. For each one, the team should ask a representative question and confirm that the answer follows the current page. If the bot cannot answer a policy question because the policy is not documented, the right fix may be a content update—not a broader instruction to guess.

How to add an AI chatbot to a website without code

A no-code setup usually has five parts: create the agent, connect approved sources, set its boundaries, configure the widget, and add the generated embed to the website. Exact screens vary by provider, but these steps help separate support configuration from simply pasting code.

1. Create the agent. Set a defined purpose, such as answering product setup and billing questions. A narrow scope makes it easier to prepare relevant content and design tests.
2. Connect approved content. Add the supported webpages and files selected for customer-facing use. Start with current, relevant sources rather than every document the company owns.
3. Set response and handoff behavior. Define what happens when a source does not support an answer, when the visitor needs account-specific help, and when the issue belongs with a person.
4. Configure the widget. Set its name, greeting, placement, and appearance. The greeting should describe what the agent can actually do, not promise a service it cannot provide.
5. Add the embed and publish. Copy the provider’s snippet into the site’s recommended integration point, publish the website, and test the result on a live page.

Zealoop describes its quickstart as a 20-minute setup and says its embed uses an asynchronous script tag that does not block the page. That gives a concrete installation expectation for teams evaluating its flow: the script is a deployment step, while connecting content and deciding support boundaries remain separate setup work. Its website also describes a free plan without a credit card, so a team can evaluate the documentation-answering agent without treating a time-limited demo as the same thing as permanent free use.

When adding an AI chatbot to a website for free, distinguish three different offers: a permanent free plan, a trial that expires, and an evaluation that requires a payment method. Zealoop’s pricing page describes Free as $0 forever with 50 conversations per month and 3 knowledge sources. Those limits are product-specific; a free plan from another vendor may have a different scope.

No-code describes who performs the installation, not how much support work the product can do. A widget pasted by a site administrator may offer only general answers, or it may be part of a broader support workflow. Content grounding, customer-data access, actions, and escalation must be evaluated independently of whether code was required to install the bubble.

Install a chatbot with a platform integration or code

A platform integration may fit an existing site-management workflow; manual code may fit a custom app or a controlled release process. Use the selected provider’s installation method rather than assuming snippets or framework components are interchangeable. The examples below describe routes, not claims that every provider supports every route.

WordPress, Webflow, and Google Sites-style builders

For WordPress, the installation may use a provider-supported plugin or an approved site-wide code setting. A plugin can place configuration inside the CMS workflow. A script-based approach can be useful when no suitable plugin exists, but the team should account for whether the code persists through theme or site changes. In either case, test the widget on the templates where it is meant to appear.

For Webflow, a supported integration or the site’s custom-code options may provide the installation path. Publish a change before judging it on the live site; an editor preview may not represent the published page’s script behavior. The right location for a snippet depends on the provider’s instructions and the way the site is organized.

Google Sites-style tutorials are useful as platform-specific guidance, but a platform’s embed field may accept only certain forms of content. A JavaScript widget and an ordinary embedded page are not necessarily installed the same way. The site owner should match the provider’s instructions to the editor’s available controls before planning a launch around that route.

Google Tag Manager and manual HTML

Google Tag Manager (GTM) can be a deployment route when the organization already manages site tags there. A chatbot script added through GTM still needs a container change and publication; GTM does not connect the agent to support documentation or define its permissions. Previewing the tag before publishing is a sensible way to catch placement or loading errors.

On a conventional HTML site, a provider may supply a JavaScript snippet to add to a shared template or selected pages. A developer can control where it loads and include the change in the team’s normal release review. The team should avoid adding the same widget twice, especially if both a platform integration and a manually added snippet are active.

React, Vue, and Angular applications

For a React, Vue, or Angular app, a developer may add a supported component or script to the shared application layout, or limit it to routes where support is relevant. That approach makes the widget part of the app’s deployment process. The installation details depend on the chosen provider; the important implementation decision is which views should display the chat entry point and who reviews changes to it.

Code access is useful when a team needs page-specific behavior or a developer-reviewed release. It does not improve answer quality by itself. A carefully deployed script can still rely on stale content, while a platform integration can be the delivery method for an agent with carefully maintained sources and tested handoffs.

Customize the widget and test it before publishing

Customize the visitor-facing experience after choosing the installation route. Set a greeting that accurately describes the agent’s role, choose a placement that does not cover navigation or a primary action, and inspect the display on desktop and mobile. For instance, a floating button that covers a mobile account menu is a layout problem even if the answer quality is strong.

Test the published site, not only an editor preview. Confirm that the widget appears on the intended page templates, opens, accepts a message, and does not appear twice. If it does not load, likely areas to inspect include the snippet placement, site publishing state, browser console, content security policy, and browser extensions. PeopleLoop’s guide specifically lists ad blockers, CSP rules, and HTTPS as troubleshooting considerations for its widget.

A useful test set includes both questions with clear answers and requests the agent should not resolve:

• Grounded answer: Ask, “How do I invite a teammate?” when the current help page documents the process. Compare the response with that page, including any eligibility conditions.
• Documented file: Ask a question answered by a supported PDF, then confirm that the response reflects the approved document rather than conflicting material.
• Unknown topic: Ask about a feature or policy absent from the source set. The expected result is the configured fallback, not an invented company policy.
• Customer identity: Ask an account-specific question without the approved identity context, then test the permitted signed-in flow separately.
• Action boundary: If the agent can take an action, test a valid case and a case with missing or invalid information. Confirm that configured checks prevent an unintended change.
• Human handoff: Ask for help with a request the agent should not resolve and confirm that the conversation reaches the intended support route.
• Widget behavior: Load the published page on desktop and mobile, open and close the chat, and check for duplicate widgets or blocked controls.

Zealoop says it validates answers for grounding before sending them. If validation fails, the answer becomes an abstention; it also describes abstaining when no source clears its confidence threshold and allowing a query to be filed as a content gap. A sample test trace might look like this: visitor asks about an undocumented export limit; no source meets the threshold; the agent abstains instead of inventing a number; the question is recorded as a content gap for the team to review. That sequence is a useful acceptance test for any support workflow: the team needs to know not only whether the agent answers, but what it does when evidence is missing.

Compare chatbot options for a small SaaS support team

Small teams need to compare both the monthly plan and the workload each product leaves for support staff. A low-cost widget may be sufficient for public FAQs. An agent that can look up customer data or take actions has a different evaluation burden: the team must define identity, permissions, failure behavior, and a human fallback.

The competitor descriptions above are intentionally limited to the cited pages: they establish product positioning and, for PeopleLoop, particular setup and source details. They do not establish identical plans or feature sets. A fair evaluation should use a team’s own test questions and request comparable plan information for its expected volume and needed capabilities rather than extrapolate from page titles.

Zealoop’s pricing page gives concrete tiers for a small SaaS team to size against:

The pricing page defines a conversation as one thread with one visitor, regardless of how many messages it contains. That definition matters when estimating use. A team with 12 visitor threads per workday over 25 workdays would use 300 conversations in that month, even if some threads contain several follow-up messages. That is the Starter plan’s listed monthly conversation allowance; it is not a count of individual messages.

For example, a three-person SaaS team that needs several help sources and a limited set of account actions can compare Starter’s $29 monthly price, 300 conversations, 25 sources, 5 actions, 3 tables, and 3 seats with its actual needs. If the team expects 400 visitor threads in the month, Starter’s listed 300-conversation amount would not match that forecast. Growth lists 1,200 conversations and 25 actions for $99 per month. The example is a sizing comparison, not a claim about fees or behavior beyond the published plan limits.

Scale lists 6,000 monthly conversations for $299 and unlimited sources, actions, tables, and seats. Its plan also includes Copilot, a public API, priority support, and an SLA. That makes Scale worth evaluating when those listed capabilities align with a team’s operational requirements; the higher tier is not automatically appropriate for a team with modest volume or no need for those features.

Zealoop’s Free plan also lists answers with citations, signed identity using HMAC, an escalation inbox, human replies, and turn-level traces. HMAC is relevant to a support installation because identity should be provided through a signed mechanism rather than treated as a name typed into a chat field. The precise implementation belongs in the product’s identity instructions; teams should test that the expected identity is present before asking the agent to retrieve customer-specific data.

Zealoop is a strong candidate to evaluate when a small SaaS team wants documentation answers, customer-context lookups, guarded actions, and a human escalation workflow in one support-agent product. It may be a poor fit when the only requirement is a decorative lead-capture bubble, when a team does not need customer-support automation, or when its published conversation and source limits do not match expected usage. For teams comparing support systems more broadly, case-deflection metrics across knowledge bases, chatbots, and AI agents can help frame what to measure.

Launch, monitor, and improve the chatbot

After publication, review conversations for three types of signal: questions the agent could not answer, answers visitors found unclear, and cases that should have been handed to a person. Each signal points to a different fix. A missing answer may call for a new help page; an unclear answer may need better source wording; a risky request may need a tighter boundary or an earlier handoff.

A lightweight review can use a shared support log with the customer question, outcome, relevant source, and next owner. If the same question appears several times, the team can distinguish a content gap from a one-off request. PeopleLoop’s getting-started guide describes reviewing conversations and analytics, then adjusting knowledge when issues recur; the specific analytics available depend on the product being used.

Set ownership for the content that feeds the bot. If a pricing page changes, the person responsible for pricing should ensure the approved source reflects the change. If a troubleshooting procedure changes, the support or product owner should update the relevant documentation. A chatbot cannot keep an answer current when its underlying source has become stale.

Repeat the relevant tests after meaningful changes. A revised billing policy should trigger a test of the plan explanation and its escalation boundary. A change to account access should trigger a test of identity handling and the customer lookup. A widget update should trigger a quick check on the live page. This keeps maintenance tied to the change rather than relying on a vague periodic review.

For a small support team, a monthly review of unresolved threads can be a practical starting point, with additional review after significant policy or product changes. The review should look at evidence and outcomes, not just how many conversations the bot handled. A bot that answers many questions from the wrong policy is not performing well because its conversation count is high.

Which should you choose

Choose a no-code embed when the site accepts the provider’s snippet, a standard widget is sufficient, and the team wants a non-developer to publish the installation. Choose a CMS or builder route when it fits the publishing workflow and the provider documents that route. Choose manual code or a framework integration when the application is custom, page-level behavior matters, or changes need developer review.

For the support product itself, the choice depends on what visitors ask:

• Choose a basic website widget or FAQ bot when visitors mainly need stable public information and there is no meaningful account-specific workflow.
• Compare AssistLoop, PeopleLoop, and LoopReply when their AI-support or SaaS-support positioning matches the team’s use case. Compare their current plans and capabilities directly; the public positioning cited here is not a substitute for a like-for-like feature and price evaluation.
• Evaluate Zealoop when the team needs documentation-grounded support and wants to assess customer-data lookups, guarded actions, signed identity, and human escalation alongside its embed. Its published tiers give concrete volume and resource limits for that evaluation.
• Do not choose a tool based only on the widget preview when the bot may use private customer information or change account data. Test identity and action boundaries before enabling those workflows.
• Start with a narrow knowledge set when the documentation is inconsistent or ownership is unclear. Improve the source of truth before connecting a large archive.

Zealoop wins when the desired system is a support agent—not merely a chat launcher—and its listed features and plan limits fit the team. It loses as a choice when the team wants only a simple lead form, does not need its support workflows, or needs a volume or capability that its selected plan does not provide. The installation decision should then follow the site’s actual publishing constraints.

Verdict: The embed gets a chatbot onto the website; the support design determines whether it can help customers responsibly. Select the install route for the site, compare vendors on documented support behavior and usable plan limits, and test grounded answers, identity, actions, and handoff before launch.

FAQ

How do I embed a chatbot on WordPress, Webflow, or Google Sites?

Use the chatbot provider’s documented method for the platform: a supported WordPress plugin, a Webflow integration or custom-code setting, or an embed option available in the site builder. A platform may accept some embed types but not others. Publish the change and test the live page, including the templates where the widget should appear.

Can I add an AI chatbot to my website for free?

Yes. Some products offer permanent free plans, while others offer a time-limited trial or a free evaluation with different terms. Zealoop’s pricing page lists Free at $0 forever with 50 conversations per month and 3 knowledge sources. A team should compare the included usage and support capabilities with its expected workload, not just the word “free.”

How should a team estimate chatbot conversation usage?

Count visitor threads rather than individual messages when the provider defines usage that way. Zealoop defines a conversation as one thread with one visitor, regardless of message count. For example, 12 new visitor threads per workday across 25 workdays equal 300 conversations for the month under that definition, even if some visitors send several messages.

When should a SaaS team move from an FAQ bot to a support agent?

Consider a support agent when recurring requests depend on a customer’s account, require a guarded operation, or need a reliable route to a human. Review unresolved threads to find the reason: missing public information may call for better documentation, while account-specific work calls for identity and permission controls. The added capability is worthwhile only if the team can test and maintain it.

Sources

• assistloop.ai/features/ai-support
• peopleloop.io/features
• peopleloop.io/docs/getting-started
• loopreply.com/use-cases/saas
• www.zealoop.com
• www.zealoop.com/pricing
• www.zealoop.com/blog/add-ai-support-saas-website
• www.zealoop.com/compare/ai-customer-support-chatbot-docs-vs-agents
• www.zealoop.com/compare/case-deflection-metrics-knowledge-base-chatbot-ai-agent