You added one line of script to your site and your chatbot came to life. Convenient. But that same line will work on any site that copies it, which means without a guardrail, someone could lift your embed code, paste it on their own page, and run your bot, on your bill, answering with your business's knowledge. Domain restriction is the guardrail that stops that.
If you're running an embeddable widget, this is one of the few settings worth getting right early. Here's what it does, how it works, and how to configure it without accidentally locking out your own staging site.
Why you'd restrict your bot to certain domains
An embed snippet is just JavaScript that loads on a web page. By default, it doesn't care which page. That openness causes problems for a few reasons.
Cost and quota. Most chatbot plans meter usage. If your bot runs on sites you don't control, their traffic burns your message allowance, and you pay for conversations that were never yours.
Brand and accuracy. Your bot speaks with your business's voice and knowledge. On someone else's site, it might answer questions in a context you never intended, and any mistake it makes now wears your name in a place you can't see.
Simple abuse. A scraper or a prankster could embed your widget to hammer it with junk traffic, inflating your usage and muddying your analytics.
Domain restriction closes all of this by telling the widget: only run on pages served from domains I've approved. Anywhere else, refuse to load.
How domain allowlisting actually works
The mechanism is simpler than it sounds. When the widget loads on a page, it can tell which site it's running on, and the server it talks to can check the request's origin. You give the platform a list of approved domains, and it enforces that list on every request.
Two checks usually work together:
- Origin and referrer checks. The browser sends the page's origin with each request. The server compares it against your allowlist and rejects anything not on it.
- Server-side enforcement. The important word is server-side. A check that only happens in the browser can be bypassed by anyone who edits the page, so the real enforcement has to live on the server, where a visitor can't touch it.
That distinction matters. Hiding the widget with front-end code alone isn't security. It's a suggestion. Proper domain restriction rejects unauthorized requests at the server, so copying your snippet elsewhere simply produces a bot that won't respond.
In SpideyChat you configure this in the bot's settings by listing the domains it's allowed to run on. Requests from anywhere else are turned away.
Setting it up step by step
The exact screens vary by platform, but the process is consistent. Here's the general flow.
- List your real domains. Write down every place your bot legitimately needs to run: your main site, your www and non-www versions, any regional domains, your help center if it lives on a separate domain.
- Add them to the allowlist. In your bot's settings, enter each approved domain. Be exact.
example.comandwww.example.comare different origins to a browser. - Decide on subdomains. If your bot needs to run on
shop.example.comandhelp.example.com, add each, or use a wildcard if the platform supports one (more on that below). - Include staging, carefully. Add your staging or preview domain if you test there, but treat it as temporary and review it later.
- Save and deploy. Apply the settings, then load your live site and confirm the bot still works.
- Test the negative case. Try the snippet somewhere off the list and confirm the bot refuses to load. This is the step people skip, and it's the one that proves the restriction works.
That negative test is the whole point. An allowlist you never tested against an unapproved domain is an assumption, not a protection.
The tricky parts: subdomains, staging, and localhost
Most domain-restriction headaches come from a handful of edge cases. Knowing them ahead of time saves an afternoon of confusion.
www vs. non-www. These are technically different origins. If customers reach you at both, allow both, or make sure your site redirects one to the other consistently.
Subdomains. A bot on your blog at blog.example.com won't be covered by an entry for example.com. List each subdomain you use, or check whether the platform supports a wildcard like *.example.com to cover them in one line.
Staging and preview URLs. You'll want the bot working on your test site, but staging domains are often long, auto-generated, and public. Add them when you need them and prune them when you're done, so an old preview URL doesn't become a forgotten hole in your allowlist.
Localhost. Developing on your own machine? You may need to allow localhost or 127.0.0.1 temporarily. Just don't leave it in the production allowlist, since it's not something your real customers use and it's an easy thing to forget.
Here's a quick reference for common situations:
| Situation | What to allow |
|---|---|
| Main marketing site | example.com and www.example.com |
| Blog on a subdomain | blog.example.com |
| Multiple regional sites | each domain explicitly |
| Local development | localhost, removed before launch |
| Staging environment | the staging URL, reviewed regularly |
Testing that it actually works
Configuration without verification is wishful thinking. Two quick tests confirm you've got it right.
First, the positive test. Load your live site and use the bot normally. It should work exactly as before. If it suddenly can't respond, you've probably missed a domain or the www variant, so check the exact origin in your browser's address bar against your allowlist.
Second, the negative test. This is the one that matters. Copy your embed snippet into a plain HTML file or a free code sandbox on a domain you didn't approve, and open it. The bot should refuse to load or respond. If it works there, your restriction isn't active, and the snippet is still portable to anyone who copies it.
Run both tests whenever you change the allowlist. It takes five minutes, and it's the only way to know the setting is doing its job rather than sitting there looking configured.
What this protects, and what it doesn't
Be clear-eyed about the boundaries of this one setting, because it's easy to over-trust.
Domain restriction stops your widget from running on sites you didn't approve. That's real protection against snippet theft, quota drain, and off-brand embedding. Worth doing.
What it doesn't do is secure the content your bot is willing to share. If your bot knows something, anyone chatting with it on your approved site can ask. Domain restriction controls where the bot runs, not what it says, so it's not a substitute for being thoughtful about what you train the bot on and what you'd rather keep out of a public assistant entirely.
It also isn't a perfect defense against a determined attacker forging request headers, though server-side enforcement raises the bar considerably. For the ordinary risks most businesses face, a properly enforced allowlist handles the job well.
A sensible default
If you just want a reasonable starting point, do this: allow your main domain and its www variant, add any subdomains your bot genuinely runs on, keep staging and localhost out of production, and run the negative test after every change.
Set it once, test it honestly, and revisit the list whenever you add a new site or subdomain. It's a small piece of configuration, but it's the difference between a widget that's yours and one anyone can borrow. Lock it to the domains you control, confirm it with a real test, and move on.