Jak wdrożyć BetterCX na dowolnej stronie internetowej używając HTML i JavaScript?

Jak wdrożyć BetterCX na dowolnej stronie internetowej?

Jeśli Twoja strona działa na czystym HTML, CSS i JavaScript albo na prostym CMS-ie z możliwością wklejenia własnego kodu, BetterCX wdrożysz bez frameworka, bez wtyczki i bez przepisywania serwisu. W praktyce potrzebujesz tylko projektu w BetterCX, publicznego klucza pk_, dodanej domeny w allowed origins i dwóch fragmentów kodu: jednego w head, drugiego na dole body.

To jest najprostsza ścieżka dla stron firmowych, landing page’y, autorskich CMS-ów i builderów, gdzie nie korzystasz z Reacta, Next.js ani WordPressa. Z punktu widzenia biznesu to ważne, bo możesz uruchomić chat AI szybko, zacząć odbierać pytania i leady 24/7, a całą późniejszą konfigurację odpowiedzi, wyglądu widgetu i pracy na rozmowach prowadzić już po stronie BetterCX.

Kiedy wdrożenie przez HTML/JS ma najwięcej sensu

Integracja przez HTML/JS jest najlepsza wtedy, gdy masz zwykłą stronę lub system, w którym możesz wkleić własny kod globalnie. To najczęstszy scenariusz przy prostych stronach sprzedażowych, landing page’ach, autorskich panelach CMS i rozwiązaniach, które nie mają dedykowanej wtyczki, ale pozwalają dodać snippet do całego serwisu.

To też dobra droga, jeśli nie chcesz uzależniać wdrożenia od stacku technologicznego. BetterCX ma osobne ścieżki dla WordPressa, Reacta i Next.js, ale dla zwykłej strony HTML lub dowolnego CMS-a instrukcja opiera się właśnie na script tagu i komponencie bettercx-widget.

Dla właściciela firmy oznacza to prostą rzecz: nie musisz zlecać budowy osobnej integracji, żeby uruchomić chat na stronie. Wystarczy wkleić poprawny kod raz, a potem rozwijać bazę wiedzy, treści i scenariusze rozmów już z poziomu BetterCX.

Co przygotować przed startem

Przed wklejeniem kodu przygotuj konto BetterCX, projekt dla konkretnej strony oraz publiczny klucz widgetu zaczynający się od pk_. Ten klucz pobierasz z sekcji widgetu BetterCX i to on łączy osadzony widget z Twoim projektem.

Druga rzecz to domena strony dodana do dozwolonych domen. Jeśli testujesz wdrożenie osobno na stagingu i osobno na produkcji, dodaj oba adresy oddzielnie, bo brak właściwej domeny jest jedną z najczęstszych przyczyn, przez które widget nie uruchamia się poprawnie na docelowej stronie.

Trzeci warunek to HTTPS. Bez poprawnego połączenia HTTPS wdrożenie może być blokowane albo działać nieprawidłowo, dlatego warto potraktować to jako element podstawowej checklisty przed publikacją.

Krok 1: utwórz projekt i skopiuj klucz publiczny

Zacznij od panelu BetterCX. Załóż projekt dla strony, na której ma działać chatbot, a następnie przejdź do sekcji widgetu i skopiuj publiczny klucz pk_.

Na tym samym etapie dodaj domenę swojej strony do dozwolonych domen. Jeśli masz osobny staging, dodaj go jako oddzielny origin, bo środowisko testowe i produkcyjne powinny być skonfigurowane osobno.

To prosty krok, ale bardzo ważny. W praktyce sporo problemów z wdrożeniem nie wynika z samego kodu, tylko z tego, że na stronie produkcyjnej został użyty stary klucz, testowy klucz albo domena nie została wcześniej dopisana do listy dozwolonych źródeł.

Krok 2: dodaj loader widgetu do sekcji head

Żeby widget BetterCX mógł się uruchomić na stronie, najpierw musisz załadować jego skrypt. Ten fragment dodajesz raz, globalnie, w głównym dokumencie strony - najlepiej w sekcji head. Dzięki temu widget będzie dostępny w całym serwisie, a nie tylko na jednej podstronie.

Wklej do head taki kod:

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

Jeśli Twoja strona korzysta z kilku szablonów albo różnych layoutów, dopilnuj, żeby ten skrypt był ładowany globalnie dla całej witryny. To ważne, bo gdy kod trafia tylko do jednego widoku, chatbot potrafi działać wyłącznie na części podstron, co później wygląda jak losowy błąd wdrożenia.

W praktyce najbezpieczniej dodać go tam, gdzie osadzasz inne globalne skrypty, na przykład analitykę, pixel albo narzędzia do obsługi strony. Jeśli korzystasz z CMS-a albo buildera stron, szukaj sekcji typu Head code, Custom code albo Global scripts, bo właśnie tam taki loader powinien trafić.

Dokumentacja chatbota: BetterCX Widget w npm

Krok 3: dodaj widget na sam dół body

Po załadowaniu skryptu w sekcji head możesz osadzić sam widget na stronie. Najlepiej wkleić go na samym dole body, tuż przed zamknięciem </body>. To praktyczny układ, bo najpierw ładuje się skrypt odpowiedzialny za widget, a sam komponent pojawia się na końcu dokumentu.

Na dole body wklej taki kod:

<bettercx-widget
  id="chat-api"
  public-key="pk_TWÓJ_KLUCZ"
  theme="auto"
  position="right"
></bettercx-widget>

Podmień pk_TWÓJ_KLUCZ na własny klucz publiczny z BetterCX. Jeśli masz na stronie własne przyciski typu „Otwórz czat”, warto zostawić id="chat-api", bo dzięki temu łatwiej odwołać się do widgetu z poziomu własnego JavaScriptu.

Atrybut theme="auto" sprawia, że widget automatycznie dopasowuje się do motywu strony, a position="right" ustawia go po prawej stronie ekranu, co jest najczęstszym i najbardziej naturalnym wariantem dla stron firmowych i landing page’y.

Jeśli korzystasz z CMS-a albo buildera stron, szukaj miejsca typu Footer code, Before </body> albo Body end code. Najważniejsze jest to, żeby widget był osadzony globalnie dla całej strony, a nie tylko na jednej podstronie, bo inaczej użytkownicy będą widzieć chat tylko w części serwisu.

Krok 4: sprawdź CSP, jeśli widget się nie ładuje

Jeśli Twoja strona korzysta z Content Security Policy (CSP), widget może nie uruchomić się poprawnie od razu. CSP określa, z jakich źródeł strona może ładować skrypty i wykonywać połączenia sieciowe, więc przy bardziej restrykcyjnej polityce przeglądarka może po prostu zablokować zasoby potrzebne do działania BetterCX.

W praktyce przy wdrożeniu BetterCX zacznij od sprawdzenia przede wszystkim tych dyrektyw:

• script-src
• connect-src

• worker-src

To właśnie te elementy BetterCX wskazuje jako podstawę przy restrykcyjnej polityce CSP dla widgetu osadzanego przez HTML/JS.

Ważne: w tym miejscu chodzi o connect-src, a nie content-src. Dyrektywa connect-src odpowiada za połączenia wykonywane przez fetch, XMLHttpRequest, WebSocket i podobne mechanizmy, więc jeśli jej nie ustawisz albo będzie zbyt restrykcyjna, widget może nie połączyć się z API lub chatem BetterCX.

Przykład:

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

To jest najbezpieczniejszy punkt wyjścia, który BetterCX pokazuje w swoich materiałach dla integracji HTML/JS: skrypt ładuje się z unpkg.com, a połączenia widgetu idą do api.bettercx.ai i chat.bettercx.ai.

Jeśli po dodaniu tej polityki widget nadal się nie ładuje, otwórz DevTools → Console i sprawdź dokładny komunikat o blokadzie. W praktyce przeglądarka pokaże tam konkretny host, który został odrzucony przez CSP, a wtedy należy dopisać właśnie ten origin do odpowiedniej dyrektywy, zamiast otwierać politykę szeroko na *.

Dobrą zasadą jest też dopisywanie konkretnych hostów HTTPS, a nie ogólnych wyjątków. To bezpieczniejsze podejście niż ustawianie zbyt szerokiej polityki i dokładnie tak powinno się rozwijać CSP dla zewnętrznych widgetów.

Jeżeli na stronie używasz jeszcze innych ograniczeń bezpieczeństwa, warto sprawdzić również, czy problem nie wynika z fallbacku do default-src. Gdy connect-src nie jest jawnie ustawione, przeglądarka może użyć default-src jako zastępstwa i przez to zablokować połączenia widgetu, nawet jeśli sam skrypt został poprawnie załadowany.

Najprostsza zasada dla czytelnika jest więc taka:

• jeśli widget się nie renderuje, sprawdź script-src,

• jeśli widget się renderuje, ale nie działa poprawnie, sprawdź connect-src,

• jeśli w konsoli pojawia się błąd związany z workerem, sprawdź worker-src i blob.

Nie ma potrzeby od razu wrzucać do wpisu długiej listy wszystkich możliwych dyrektyw. Lepiej zacząć od realnego minimum dla BetterCX, a dodatkowe hosty dopisywać tylko wtedy, gdy rzeczywiście pokażą się w błędach konsoli podczas wdrożenia.

Krok 5: naucz chatbota tego, co naprawdę ma mówić

Samo osadzenie widgetu to dopiero początek. Jeśli chcesz, żeby chatbot realnie pomagał klientom i wspierał sprzedaż, musisz zasilić go treściami, które opisują Twoją ofertę, proces współpracy i najczęstsze pytania.

Najlepsze źródła wiedzy to zwykle:

• strony usług,

• podstrony ofertowe,

• FAQ,

• artykuły blogowe,

• opisy produktów,

• polityka dostawy i zwrotów,

• odpowiedzi, które Twój zespół regularnie wysyła klientom.

Te materiały warto dodać do bazy wiedzy. Dzięki temu chatbot nie odpowiada ogólnikowo, tylko korzysta z realnej wiedzy Twojej firmy. To właśnie ten etap decyduje o tym, czy chat będzie tylko efektownym dodatkiem, czy faktycznie zacznie odciążać zespół i podnosić konwersję.

Jeśli prowadzisz firmę usługową, chatbot powinien znać odpowiedzi na pytania takie jak:

• ile kosztuje wdrożenie,
• ile trwa realizacja,
• dla jakich firm to rozwiązanie ma sens,
• co obejmuje oferta,
• jak wygląda pierwszy kontakt.

Jeśli działasz w e-commerce, ważniejsze będą informacje o:

• dostawie,
• zwrotach,
• dostępności,
• wariantach produktów,
• czasie realizacji zamówienia.

Im lepiej przygotujesz bazę wiedzy, tym bardziej naturalne i konkretne będą odpowiedzi AI.

Krok 6: ustaw wygląd widgetu pod swoją markę

Kiedy chatbot już działa technicznie, czas zadbać o to, żeby wyglądał jak część Twojej strony, a nie obce narzędzie doklejone z boku.

W konfiguracji widgetu ustaw:

• kolory zgodne z identyfikacją wizualną,
• tekst powitalny,
• styl jasny, ciemny lub automatyczny,
• pozycję widgetu,
• pierwszą wiadomość zachęcającą do kontaktu.

Dobrze ustawione powitanie robi dużą różnicę. Zamiast neutralnego „W czym mogę pomóc?” lepiej użyć komunikatu powiązanego z celem strony, na przykład:

• „Masz pytania o ofertę? Napisz, a pomożemy wybrać najlepszą opcję.”
• „Chcesz szybciej wdrożyć chatbota AI na swojej stronie? Napisz do nas.”
• „Potrzebujesz wyceny lub konsultacji? Zacznij rozmowę tutaj.”

Taki komunikat od razu ustawia rozmowę na właściwe tory i zwiększa szansę, że odwiedzający wykona konkretny krok.

Krok 7: zaplanuj, kiedy rozmowę ma przejąć człowiek

Nie każda rozmowa powinna kończyć się całkowicie po stronie AI. Dobry chatbot nie próbuje na siłę odpowiadać na wszystko. W odpowiednim momencie powinien przekazać rozmowę do handlowca, supportu albo osoby odpowiedzialnej za kontakt.

Warto od razu ustalić proste zasady przejęcia rozmowy, na przykład gdy:

• klient pyta o indywidualną wycenę,
• sprawa dotyczy niestandardowego wdrożenia,
• użytkownik chce umówić demo,
• temat wymaga decyzji handlowej,
• rozmowa dotyczy reklamacji lub bardziej wrażliwego case’u.

Dzięki temu chatbot nie blokuje procesu sprzedaży, tylko go przyspiesza. Najpierw zbiera kontekst, a potem przekazuje rozmowę dalej już z konkretnymi informacjami.

To duża przewaga nad zwykłym formularzem kontaktowym. Zamiast pustego zgłoszenia typu „proszę o kontakt”, Twój zespół dostaje pełniejszy obraz sytuacji i może wejść w rozmowę szybciej i sensowniej.

Krok 8: pracuj dalej na rozmowach i leadach

Wdrożenie chatbota ma sens wtedy, gdy rozmowy da się dalej wykorzystać w sprzedaży i obsłudze klienta. Sam czat nie kończy procesu - on go zaczyna.

W praktyce warto rozdzielić dwa poziomy pracy:

• Chaty - miejsce, w którym zespół widzi rozmowy i może je przejmować,
• Leady - miejsce, w którym porządkujesz wartościowe kontakty i pracujesz na nich sprzedażowo.

To ważne szczególnie wtedy, gdy chatbot nie ma być jedynie “oknem do zadawania pytań”, ale faktycznym narzędziem wspierającym lejek. Jeśli użytkownik wykazuje intencję zakupu, prosi o ofertę albo zostawia dane kontaktowe, taka rozmowa powinna stać się czymś więcej niż pojedynczym wątkiem na czacie.

Dlatego od początku warto myśleć o chatbocie nie jako o dodatku do strony, ale jako o pierwszym punkcie wejścia do procesu sprzedażowego.

Jakie błędy najczęściej psują takie wdrożenie?

Samo dodanie skryptu i widgetu jest proste, ale kilka błędów potrafi obniżyć efekt biznesowy niemal do zera.

Najczęstsze problemy to:

• brak sensownej bazy wiedzy,
• zbyt ogólny tekst powitalny,
• brak jasnego celu dla chatbota,
• brak przekazania rozmów do zespołu,
• źle ustawione CSP, które blokuje skrypt albo połączenia widgetu,
• traktowanie widgetu jak ozdoby, a nie narzędzia do konwersji.

Jeśli chatbot nie wie nic o Twojej ofercie, będzie odpowiadał zbyt szeroko i zbyt miękko. Jeśli nie ustawisz sensownego CTA, użytkownik nie będzie wiedział, po co ma zacząć rozmowę. A jeśli zespół nie ma procesu pracy na rozmowach i leadach, część szans sprzedażowych po prostu się rozmyje.

Dlatego wdrożenie warto traktować jak projekt biznesowy, a nie wyłącznie techniczne usprawnienie.

Kiedy kod HTML/JS to najlepsza opcja

Wstawienie BetterCX przez HTML/JS jest szczególnie dobrą opcją, gdy:

• masz własną stronę bez WordPressa,
• korzystasz z kreatora stron z możliwością wklejania kodu,
• chcesz szybko osadzić chat na landing page’u,
• nie potrzebujesz osobnej wtyczki,
• zależy Ci na prostym, uniwersalnym wdrożeniu.

To rozwiązanie sprawdza się zarówno na małych stronach firmowych, jak i na większych serwisach, jeśli chcesz zachować pełną kontrolę nad miejscem osadzenia kodu. Dla wielu firm to najszybsza droga, żeby uruchomić AI chat bez przebudowy strony.

Często zadawane pytania

Czy muszę znać JavaScript, żeby dodać BetterCX na stronę?

Nie. W podstawowym scenariuszu wystarczy wkleić skrypt do head oraz komponent widgetu na końcu body. Całość jest prosta do wdrożenia nawet przy podstawowej znajomości HTML.

Gdzie dokładnie wkleić widget?

Najlepiej na samym dole sekcji body, tuż przed </body>. To najbardziej praktyczny i najczytelniejszy układ.

Czy mogę zmienić pozycję widgetu?

Tak. Możesz sterować jego pozycją za pomocą atrybutów konfiguracji, np. ustawić go po prawej stronie ekranu.

Czy muszę publikować stronę ponownie po zmianie kolorów i powitania?

Nie zawsze. Jeśli zmiany dotyczą konfiguracji widgetu po stronie BetterCX, zwykle nie musisz ponownie edytować kodu strony.

Co jeśli mam kilka domen albo staging?

Najlepiej dodać każde środowisko osobno w dozwolonych domenach. To ułatwia testy i zapobiega problemom z ładowaniem widgetu.

Powiązane poradniki

React, Next.js, WordPress (wtyczka).