An AI chatbot on your site can answer common questions, qualify leads, and take the first pass at support around the clock. On your Ultra Web Hosting account you have two practical ways to add one: drop in a hosted third-party widget that runs entirely in someone else's dashboard, or build your own bot that calls an LLM API from a small backend you host with us. This guide covers both, the security rule that separates a working custom bot from a leaked API key, and the privacy and performance details people skip.
- What an AI Chatbot Can Do and the Two Approaches
- Approach A: A Hosted Third-Party Widget
- Add the Widget to a Plain HTML Site
- Add the Widget to WordPress
- Approach B: Build Your Own With an LLM API
- The One Security Rule: Keep the API Key Server-Side
- Train the Bot on Your Own Content
- Cost, Rate Limits, and Caching
- Privacy, Disclosure, and Performance
Widget for Speed, API for Control
Most sites want a hosted widget: sign up with a chatbot service, configure the bot in their dashboard, and paste one script tag into your pages. If you need the bot tied deep into your own data or product, build it yourself against an LLM API from a backend you host here.
- Hosted widget: one script snippet, no code, live in minutes
- Custom bot: full control, your data, your logic, more work
- Either way, run the site over HTTPS so the chat is secure
- If you build your own, the API key never touches the browser
Your API Key Stays on the Server
The fastest way to run up a surprise bill is to put an OpenAI or Anthropic API key in front-end JavaScript. Anyone can open the browser dev tools, read the key, and spend against your account. A custom bot always routes chat requests through a server endpoint you host, and the key lives only in server-side configuration. Section 06 shows the pattern.
- Symptom: an unexplained spike in API usage and cost
- Cause: an API key shipped in client-side code, scraped by a bot
- Fix: proxy every request through your own server endpoint
01. What an AI Chatbot Can Do and the Two Approaches
A chatbot on your site is not just a novelty box in the corner. Done well, it earns its place by doing real work:
- Answer FAQs instantly, so visitors do not bounce looking for shipping times, pricing, or hours.
- Qualify leads by asking a few questions and routing serious prospects to a form or a human.
- Triage support, handling the easy tickets and collecting details on the hard ones before a person ever reads them.
There are two broad ways to get one running on a site hosted with us, and they trade off effort against control:
Hosted Widget
A third-party service runs the bot. You configure it in their dashboard and paste a script snippet into your site.
- Live in minutes, little or no code
- They handle the model, hosting, and updates
- You are bound to their features and pricing
Custom API Bot
You call an LLM API from a small backend you host with us and build the chat interface yourself.
- Total control over behavior and data
- Your content, your logic, your branding
- You own the security, cost, and maintenance
02. Approach A: A Hosted Third-Party Widget
This is the right choice for most sites. A hosted chatbot service does the heavy lifting: it runs the model, stores the conversations, and gives you a dashboard to shape the bot's answers. Popular options include Tidio, Intercom, Crisp, and Chatbase, along with a growing number of SaaS tools built on the OpenAI or Anthropic models. You never see an API key, because the key is theirs, not yours.
The workflow is the same across nearly all of them:
- Sign up with the service and create a workspace or project for your site.
- Configure the bot in their dashboard: set its greeting, upload your FAQ or docs, choose when it hands off to a human, and pick where the widget appears.
- Copy the install snippet they give you. It is a small block of JavaScript, unique to your account, that loads the widget.
- Paste that snippet into your site just before the closing body tag, then save and reload. The chat bubble appears.
With a hosted widget, all the model configuration happens in the provider's dashboard, not in your site files. The only thing you add to your own site is the loader snippet. That keeps your account free of any API keys, which is exactly why this approach is lower-risk for most people.
03. Add the Widget to a Plain HTML Site
If your site is static HTML, you add the widget snippet through cPanel File Manager. The rule is simple: paste it right before the closing </body> tag so the rest of the page loads first.
- Log in to cPanel and open File Manager (under the Files section).
- Navigate to
public_htmland find the page file, usuallyindex.html. - Select the file and click Edit in the top toolbar. Confirm the encoding prompt if it appears.
- Scroll to the bottom and place your cursor just before
</body>. - Paste the provider's snippet. It looks like the example below (yours will have a real script source and account ID).
- Click Save Changes, then reload the page in a browser to confirm the chat bubble loads.
A typical hosted-widget snippet looks like this, with the closing tags escaped so you can see the full structure:
<!-- Paste immediately before </body> -->
<script>
window.chatbotSettings = { accountId: "YOUR_ACCOUNT_ID" };
</script>
<script async src="https://cdn.example-chat.com/widget.js"></script>
<!-- end chatbot widget -->
If your site has more than one HTML page, the widget needs to be on every page you want the bubble to appear on. Rather than editing each file by hand, that is a good reason to keep shared markup in an include or to move to a system with a shared footer. For a lightweight way to carry data across static pages, see article #350 on passing variables between HTML pages.
04. Add the Widget to WordPress
On WordPress you have three clean ways to add the snippet, in rough order of ease:
- Official plugin. Most major chat services publish a WordPress plugin. Install it, paste your account ID or connect the account, and the widget loads on every page with no theme edits. This is the easiest and most upgrade-safe path.
- A headers-and-footers plugin. If the service only gives you a raw snippet, install a plugin such as one that inserts code into the header or footer, then paste the snippet into the footer box. It survives theme updates because it lives in the plugin, not the theme.
- Theme footer or header hooks. If you run a child theme, you can add the snippet to the theme's footer template or hook it in through
wp_footer. Only do this in a child theme so a parent-theme update does not wipe it out.
Pasting the snippet straight into a parent theme's footer.php works until the next theme update overwrites the file and takes your widget with it. Use a plugin or a child theme so the change persists.
05. Approach B: Build Your Own With an LLM API
If you want a bot that is wired into your own data, product, or business logic, you build it against an LLM API directly. You call the OpenAI or Anthropic API from a small backend, and your front end talks only to that backend, never to the model provider. The reason for the backend is not style, it is security: your API key must stay server-side and can never appear in front-end JavaScript, which anyone can read.
You host that backend right here. Two common shapes:
- A Node.js service that exposes a single chat endpoint. Your page posts the user's message to it, the service calls the model with your key, and returns the reply. See article #487 for getting started with Node.js on your account.
- A Next.js or React app where the API route (a server function) holds the key and the React front end calls that route. See article #488 on deploying Next.js and React dashboards.
Whichever framework you choose, the shape is the same: browser talks to your server, your server talks to the model. The model provider's API key lives only in server-side environment variables. Keep it out of your Git repository and out of anything the browser downloads.
06. The One Security Rule: Keep the API Key Server-Side
This is the rule that matters more than any other in this guide. An LLM API key is a billing credential. If it is in code the browser downloads, it is public, and automated scanners find exposed keys within minutes. The fix is a thin proxy: your front end sends the user's message to your own server endpoint, and only that server, holding the key in an environment variable, calls the model.
The wrong way and the right way, side by side:
Key in the Browser
Front-end JavaScript calls the model API directly with the key embedded. The key is visible in dev tools and page source.
- Anyone can copy the key
- They spend against your account
- You find out on the invoice
Key on the Server
The browser calls your endpoint. Your server holds the key and calls the model, then returns only the reply.
- Key stays in server config
- You can rate-limit and log requests
- The browser never sees the key
The pattern in words, no key ever leaving the server:
Browser --POST /api/chat {message}--> Your server endpoint
Your server --calls model with API key--> OpenAI / Anthropic
Your server <--reply-- model
Browser <--reply only-- Your server endpoint
There is no safe way to put an LLM API key in client-side code, not even "temporarily" or "just for testing" on a live domain. If a key is ever exposed, treat it as compromised: revoke it in the provider dashboard and issue a new one. Store the replacement in a server-side environment variable that the browser cannot reach.
07. Train the Bot on Your Own Content
A generic bot gives generic answers. To make it useful, ground it in your own material so it answers from your content instead of guessing. There are two common ways:
- Upload your docs and FAQ. Most hosted services and many custom setups let you feed in help articles, product pages, and a FAQ. The bot then answers from that source. This is retrieval: the bot looks up relevant passages and uses them to build its reply.
- Point a retrieval bot at your site. Some tools crawl your public pages and keep an index, so the bot's answers track your site as it changes.
Structuring your content so a retrieval bot can use it is the same work that makes your site quotable by AI search engines. Clear headings, direct answers, and a real FAQ help both. For the search-visibility side of that, see our guide How to Get Your Site Cited by ChatGPT and AI Search.
08. Cost, Rate Limits, and Caching
A hosted widget usually bills a flat monthly fee. A custom API bot bills differently: LLM API usage is metered per request and per token, so an unattended or abused bot can get expensive. Three habits keep it under control:
- Set a spend limit in the provider dashboard. Both OpenAI and Anthropic let you cap monthly usage so a runaway loop or a scraper cannot drain the account.
- Rate-limit your own endpoint. Because every request goes through your server, you can cap how many messages a single visitor sends per minute. This also blocks the abuse that a browser-side key would have made trivial.
- Cache common answers. If the same handful of questions come up constantly, cache the replies so you are not paying the model to answer the same thing over and over. A short server-side cache pays for itself fast.
Spend limits and rate limits are only possible because the requests flow through your own server. This is another reason the proxy pattern in Section 06 is not just about secrecy: it is the only place you can enforce limits, log usage, and cache.
09. Privacy, Disclosure, and Performance
Two last areas that separate a professional deployment from a sloppy one: being honest with users, and not slowing down your page.
Privacy and Disclosure
- Tell users they are talking to a bot. A short line in the greeting is enough and it sets expectations honestly.
- Mind what you collect. If the chat gathers names, emails, or order details, that is personal data. Cover it in your privacy policy and get consent where the law requires it, such as under GDPR.
- Do not send sensitive data to third parties. Passwords, payment details, and health or financial information should never be pasted into a chatbot that forwards to an outside service. Say so in the interface if needed.
Performance
Load the widget asynchronously so it does not block the rest of the page. That is what the async attribute on the script tag in Section 03 is for: the browser keeps rendering your content while the chat script loads in the background. A chat bubble is never worth a slow page.
Both the widget and any calls to your own chat endpoint should travel over HTTPS, so the conversation and any data in it are encrypted in transit. Modern browsers also block or downgrade some scripts on plain HTTP pages. If your site is not yet on HTTPS, fix that first: see article #68 on SSL and HTTPS.
Want a Hand Wiring It Up?
Whether you are pasting a hosted widget snippet into File Manager or standing up a Node.js backend for a custom bot, our team can help you get it deployed and locked down. We support static sites, WordPress, and Node.js apps on shared, VPS, and dedicated plans.
Open a Support TicketQuick Recap: Adding an AI Chatbot
If you only take six things from this guide, take these:
- Pick your approach: a hosted widget for speed, or a custom API bot for control over your data and logic.
- For a widget, configure the bot in the provider's dashboard and paste their snippet just before
</body>on a plain HTML site, or via a plugin on WordPress. - For a custom bot, host a small Node.js or Next.js backend with us that calls the LLM API.
- Keep the API key server-side. Never put it in browser code. Proxy every request through your own endpoint.
- Train the bot on your own content and set spend limits, rate limits, and caching to control cost.
- Disclose the bot, mind privacy, load it asynchronously, and serve the site over HTTPS.
Last updated July 2026 · Browse all Website Tools & SEO articles
