Open almost any company website built in the last two years and a little circle pops up in the bottom-right corner. "Hi! How can I help you today?"
You already know how this goes. You type a real question, the bot hands back a help-center link you'd already found, and you end up emailing support anyway.
We've collectively decided that every website needs a chatbot. I think we added them for the wrong reason — and the reason is more interesting than the complaint.
The generic site bot has three problems, and they're structural, not cosmetic.
It only knows your site. It was trained or indexed on a narrow slice of your own content, so the moment a question steps outside that slice, it has nothing. Ask it something a human support agent would answer in one sentence by combining two facts, and it stalls.
It has no real capability. It can't check your actual order, can't see live stock, can't do the thing you came to do. It retrieves text and reformats it.
And it interrupts. It's a layer between you and the page, and most of the time you'd rather just read the page.
None of this is a knock on any particular vendor. The bots behave this way because of what they fundamentally are. Which is the part worth examining.
Here's my claim: chatbots spread across the web not because users wanted them, but because they were the only way we had to put "AI" on a website.
Think about the actual sequence of events. A company decides it needs an AI story. The available, off-the-shelf, drop-in-a-script-tag option is a chatbot widget. So a chatbot widget is what gets installed. The technology answered a marketing question — "how do we show we have AI?" — not a user question — "how do I get my answer faster?"
That's the definition of a workaround: a thing you reach for because it's available, not because it's right.
I recently asked a popular chatbot vendor — through their normal support channel — to explain in detail how their system ingests and answers from a website's data. The reply was polite, professional, and genuinely illuminating. I'll keep it anonymous, because the point isn't to single anyone out; this is how the whole category works today.
Three things stood out.
It answers from a snapshot, not from your live site. When a user asks a question, the bot does not read your website at that moment. It reads a copy it indexed earlier — refreshed on a schedule, daily, weekly, or monthly. For a blog that's fine. For anything that changes — prices, availability, terms — it means the bot can confidently cite information that's weeks stale, with no signal to the user that it's looking at an old photograph.
It can't follow a paginated feed. I asked how it walks through a structured catalog with multiple pages. It doesn't. The recommended workaround was to flatten everything into a list of separate static URLs and hand it an XML sitemap. In other words: to ingest a modern structured source, go back to the one-document-per-page model from twenty years ago, because the ingester can't traverse a feed.
The capabilities you'd need are upsells. Things like preserving query-string URLs, ingesting paginated feeds, and handling structured catalogs properly weren't standard. They were described as things they'd consider building for customers on a paid plan.
Sit with that. The entire architecture is designed around not looking at the live source. Snapshot, scheduled recrawl, flattened sitemap — every piece exists to avoid reading your site at the moment the question is asked. The bot doesn't read your website. It keeps a faded photocopy and answers from that.
Step back to the person typing the question. They never wanted an assistant living inside your website. They wanted an answer. And increasingly they're getting it somewhere else entirely — by asking the assistant they already have open, before they ever land on your page.
That's the shift the chatbot misses completely. The chatbot assumes the AI should live on your site. But the AI users actually rely on doesn't live on anyone's site. It's the general assistant in their pocket — and it's perfectly capable of reading and reasoning over real, current information if the information is exposed in a way it can read.
This is the reframing I think matters.
The chatbot approach brings a weak, sandboxed AI into your page. The opposite approach makes your content legible to the strong, general AI the user already uses. One traps a bad assistant on your site; the other frees your content to be read by a good one.
And the second one is where the platforms are quietly heading. Structured, machine-readable content. Standard protocols for agents to discover and read what a site offers. The shift is from optimizing a page for a human eye (and a search crawler) to also making it readable by an agent acting on a person's behalf — reading the current data, following the actual structure, reasoning over what's really there rather than a month-old copy.
That's the exact inverse of the snapshot-and-sitemap model. The agent reads the source, now. No photocopy.
I don't want to pretend the readable-to-agents direction is pure upside. It moves the hard problems rather than removing them, and two of them are worth naming honestly.
The first is the business model. If a customer's assistant reads your data and resolves the question — or even completes a purchase — without the customer ever landing on your page, what happens to everything that page was doing? The cross-sell, the brand experience, the related products, the ad you were going to show. Search engines already started this with zero-click answers; agents push it further. Making your content legible to an external assistant solves the information problem and sharpens a monetization problem that nobody has a clean answer to yet.
The second is liability. If an assistant misreads your data — even data you structured carefully and exposed correctly — and tells the user something wrong, who's responsible? The site that published it, the assistant that interpreted it, or the vendor behind the assistant? There's no settled answer, legally or in practice.
I'm not going to resolve those here, and I'd be suspicious of anyone who claims to. But notice they don't rescue the chatbot. A bot answering from a stale snapshot has the same exposure problems with worse information. The hard questions are real — they're just the hard questions of the right direction instead of the wrong one.
If you're responsible for a website and you're thinking about AI, the instinct is to add a chatbot. I'd push back on that instinct. A bot trapped on your page, answering from a stale copy of your own content, is solving a problem your users don't have. The problem they actually have is that the assistant they're already talking to can't yet read your site clearly.
So the question isn't "which chatbot should I install?" It's "is my content readable by the agents people already use?"
Stop optimizing for a chatbot stuck in the corner of your page. Start making your content legible to the agents people bring with them.