How to implement BetterCX on any website using HTML and JavaScript?

How do I implement BetterCX on any website?

If your website runs on plain HTML, CSS, and JavaScript or on a simple CMS that allows you to paste your own code, you can implement BetterCX without a framework, without a plugin, and without rewriting your site. In practice, all you need is a project in BetterCX, a public key pk_, a domain added to the allowed origins, and two code snippets: one in head, the other at the bottom body.

This is the simplest path for company websites, landing pages, custom CMSs, and website builders where you don’t use React, Next.js, or WordPress. From a business perspective, this is important because you can launch the AI chat quickly, start receiving questions and leads 24/7, and handle all subsequent configuration of responses, widget appearance, and conversation management directly within BetterCX.

When HTML/JS integration makes the most sense

Integration via HTML/JS is best when you have a standard website or system where you can paste your own code globally. This is the most common scenario for simple sales pages, landing pages, custom CMS panels, and solutions that don’t have a dedicated plugin but allow you to add a snippet to the entire site.

It’s also a good approach if you don’t want to tie the implementation to a specific tech stack. BetterCX has separate paths for WordPress, React, and Next.js, but for a standard HTML website or any CMS, the instructions rely on a script tag and a component bettercx-widget.

For a business owner, this means one simple thing: you don’t need to commission a separate integration to launch a chat on your site. Just paste the correct code once, and then develop your knowledge base, content, and conversation scenarios directly within BetterCX.

What to prepare before you start

Before pasting the code, set up a BetterCX account, create a project for your specific website, and obtain the widget’s public key starting with pk_. You can retrieve this key from the BetterCX widget section, and it’s what connects the embedded widget to your project.

The second thing is the website domain added to the allowed domains. If you’re testing the implementation separately on staging and separately on production, add both addresses separately, because the absence of the correct domain is one of the most common reasons why the widget doesn’t launch correctly on the target page.

The third requirement is HTTPS. Without a valid HTTPS connection, the deployment may be blocked or function incorrectly, so it’s worth treating this as part of your basic pre-launch checklist.

Step 1: Create a project and copy the public key

Start from the BetterCX dashboard. Create a project for the website where the chatbot will run, then go to the widget section and copy the public key pk_.

At this same stage, add your website’s domain to the allowed domains. If you have a separate staging environment, add it as a separate origin, because the test and production environments should be configured separately.

This is a simple step, but a very important one. In practice, many implementation issues do not stem from the code itself, but from the fact that an old key or a test key was used on the production site, or the domain was not previously added to the list of allowed sources.

Step 2: Add the widget loader to the head section

To get the BetterCX widget running on your site, you first need to load its script. Add this snippet once, globally, in the main page document—preferably in the head section. This ensures the widget is available across the entire site, not just on a single subpage.

<script
  type="module"
  src="https://unpkg.com/bettercx-widget@latest/dist/bettercx-widget-bundle.js"
></script>

If your site uses multiple templates or different layouts, make sure this script is loaded globally for the entire site. This is important because if the code is only loaded on one view, the chatbot will only work on some subpages, which later looks like a random implementation error.

In practice, the safest place to add it is where you embed other global scripts, such as analytics, pixels, or site management tools. If you use a CMS or a website builder, look for sections like Head code, Custom code, or Global scripts, because that’s exactly where this loader should go.

Chatbot documentation: BetterCX Widget on npm

Step 3: Add the widget to the very bottom of the body

After loading the script in the head , you can embed the widget itself on the page. It’s best to paste it at the very bottom body, just before the closing </body>. To praktyczny układ, bo najpierw ładuje się skrypt odpowiedzialny za widget, a sam komponent pojawia się na końcu dokumentu. This is a practical approach because the script that powers the widget loads first, while the widget itself appears at the end of the document.

Step 4: Check the CSP if the widget isn't loading

If your website uses a Content Security Policy (CSP), the widget may not work properly right away. A CSP specifies which sources a website can load scripts from and make network connections to, so if the policy is too restrictive, the browser may simply block the resources needed for BetterCX to function.

In practice, when implementing BetterCX, start by reviewing these guidelines first:

• script-src
• connect-src

• worker-src

These are the elements that BetterCX identifies as the foundation for a CSP policy with strict restrictions on widgets embedded via HTML/JS.

Important: This refers to connect-src, not content-src. The connect-src directive controls connections made by fetch, XMLHttpRequest, WebSocket, and similar mechanisms, so if you don’t set it or if it’s too restrictive, the widget may not be able to connect to the API or the BetterCX chat.

Example:

Content-Security-Policy:
  script-src 'self' https://unpkg.com;
  connect-src 'self' https://api.bettercx.ai https://chat.bettercx.ai;
  worker-src 'self' blob:;

This is the safest starting point that BetterCX recommends in its documentation for HTML/JS integration: the script loads from unpkg.com, and the widget’s requests go to api.bettercx.ai and chat.bettercx.ai.

If the widget still doesn’t load after adding this policy, open DevTools → Console and check the exact blocking message. In practice, the browser will show the specific host that was rejected by the CSP, and you should then add that exact origin to the appropriate directive, rather than opening the policy broadly to *.

It’s also a good practice to specify specific HTTPS hosts rather than general exceptions. This is a more secure approach than setting a policy that’s too broad, and this is exactly how a CSP for external widgets should be implemented.

If you’re using other security restrictions on your site, it’s also worth checking whether the issue stems from a fallback to default-src. When connect-src isn’t explicitly set, the browser may usedefault-src as a fallback, thereby blocking the widget’s connections even if the script itself loaded correctly.

So, the simplest rule for readers is this:

• if the widget isn't rendering, check script-src,

• if the widget is rendering but isn't working properly, check connect-src,

• if a worker-related error appears in the console, check worker-src and blob.

There’s no need to include a long list of every possible directive in the configuration file right away. It’s better to start with the bare minimum required for BetterCX and add additional hosts only if they actually appear in the console errors during deployment.

Step 5: Teach the chatbot what it's actually supposed to say

Simply embedding the widget is just the beginning. If you want the chatbot to truly help customers and support sales, you need to populate it with content that describes your offerings, the collaboration process, and the most frequently asked questions.

The best sources of information are usually:

• service pages,

• product pages,

• FAQs,

• blog posts,

• product descriptions,
• delivery and return policies,
• responses your team regularly sends to customers.

It’s worth adding these materials to the knowledge base. This ensures that the chatbot doesn’t give vague answers, but instead draws on your company’s actual expertise. This stage determines whether the chatbot will be just a flashy gimmick or will actually start to lighten the team’s workload and boost conversion rates.

If you run a service-based business, the chatbot should know the answers to questions such as:

• how much does implementation cost,
• how long does it take,
• for which companies is this solution a good fit,
• what does the offer include,
• what does the initial contact look like.

If you work in e-commerce, the following information will be more important:

• delivery,
• returns,
• availability,
• product variants,
• order fulfillment time.

The better you prepare the knowledge base, the more natural and specific the AI's responses will be.

Step 6: Customize the widget’s appearance to match your brand

Once the chatbot is up and running, it’s time to make sure it looks like a natural part of your website, not like a foreign tool tacked onto the side.

In the widget settings, configure the following:

• colors consistent with the brand identity,
• welcome text,
• light, dark, or automatic theme,
• widget position,
• the first message encouraging users to get in touch.

A well-crafted greeting makes a big difference. Instead of a neutral “How can I help you?”, it’s better to use a message that aligns with the website’s purpose, such as:

• “Have questions about our services? Contact us, and we’ll help you choose the best option.”
• “Want to implement an AI chatbot on your website faster? Contact us.”
• “Need a quote or consultation? Start a conversation here.”

A message like this immediately sets the conversation on the right track and increases the likelihood that the visitor will take a specific action.

Step 7: Plan when to hand the conversation over to a human

Not every conversation should end entirely on the AI’s side. A good chatbot doesn’t try to forcefully answer everything. At the right moment, it should hand the conversation over to a sales representative, support agent, or the person responsible for the interaction.

It’s a good idea to establish simple rules for handing off the conversation right away, for example when:

• the customer asks for a custom quote,
• the matter involves a non-standard implementation,
• the user wants to schedule a demo,
• the topic requires a sales decision,
• the conversation concerns a complaint or a more sensitive case.

This way, the chatbot doesn’t block the sales process - it speeds it up. First, it gathers context, and then it forwards the conversation with specific information already included.

This is a major advantage over a standard contact form. Instead of a vague request like “please contact me,” your team gets a more complete picture of the situation and can engage in the conversation more quickly and effectively.

Step 8: Follow up on conversations and leads

Implementing a chatbot makes sense only if the conversations can be leveraged for sales and customer service. The chat itself doesn’t end the process - it starts it.

In practice, it’s a good idea to separate the work into two stages:

• Chats - where the team can view conversations and take over them,
• Leads - where you organize valuable contacts and follow up on them for sales purposes.

This is especially important when the chatbot isn’t meant to be just a “question-and-answer window,” but an actual tool that supports the sales funnel. If a user shows an intention to buy, asks for an offer, or leaves their contact information, that conversation should become more than just a single chat thread.

That’s why, from the very beginning, it’s worth thinking of the chatbot not as an add-on to the website, but as the first point of entry into the sales process.

What mistakes most often ruin such an implementation?

Adding the script and widget is simple, but a few mistakes can reduce the business impact to virtually zero.

The most common problems are:

• a lack of a meaningful knowledge base,
• a welcome message that’s too generic,
• no clear goal for the chatbot,
• failure to route conversations to the team,
• incorrectly configured CSP that blocks the script or widget connections,
• treating the widget as a decoration rather than a conversion tool.

If the chatbot knows nothing about your offering, it will respond too broadly and too vaguely. If you don’t set a meaningful CTA, the user won’t know why they should start a conversation. And if the team lacks a workflow for conversations and leads, some sales opportunities will simply slip away.

That’s why implementation should be treated as a business project, not just a technical improvement.

When HTML/JS is the best option

Embedding BetterCX via HTML/JS is a particularly good option when:

• you have your own website without WordPress,
• you use a website builder that supports code pasting,
• you want to quickly embed a chat on your landing page,
• you don’t need a separate plugin,
• you want a simple, universal implementation.

To rozwiązanie sprawdza się zarówno na małych stronach firmowych, jak i This solution works well for both small company websites and larger sites if you want to maintain full control over where the code is embedded. For many companies, this is the fastest way to launch an AI chat without rebuilding the website.

Frequently Asked Questions

Do I need to know JavaScript to add BetterCX to my website?

No. In the basic scenario, all you need to do is paste the script into the head section and the widget component at the end of the body. The whole process is easy to implement, even with just a basic knowledge of HTML.

Where exactly should I place the widget?

Ideally, at the very bottom of the body section, right before the /body tag. This is the most practical and clearest layout.

Can I change the widget's position?

Yes. You can control its position using configuration attributes, such as placing it on the right side of the screen.

Do I need to republish the page after changing the colors and the welcome message?

Not always. If the changes involve the widget configuration on the BetterCX side, you usually don’t need to edit the page code again.

What if I have multiple domains or a staging site?

It's best to add each environment separately to the allowed domains. This makes testing easier and prevents issues with loading the widget.

Related guides

React, Next.js, WordPress plugin.