← Back to Blog

Chatbot That Knows What Page a User Is On: Dev Guide

A chatbot that knows what page the user is on works by reading page context — at minimum the current route — and sending it with every message. No browser magic involved: the client sends a field, the assistant reads it, and it answers against that instead of opening with "which screen are you looking at?" Route alone resolves a real slice of questions. How much further you go — what tab is open, which record, what plan tier — is a decision you make deliberately, field by field, not something that shows up for free.

Last updated: August 2026

Route gets you further than it sounds like it should

Support chat has spent a decade asking users to do a debugger's job. Screenshot, URL, browser version, what did you click. Just sending the current route with every message — nothing else — already kills a large share of that loop, because "how do I add a teammate" asked from /settings/billing is obviously not the same question as the same words asked from /team. You don't need a rich context model to get that win. You need the route attached to the message, every message, not just when the chat opens.

Richer context — view state, which record is open, account tier — helps further, but it's a second decision with its own cost: more fields to document, more places PII can leak, more things to keep in sync as your app changes. Don't reach for it until route alone stops being enough.

The part that's easy to get wrong: re-sending on route change

The common failure isn't forgetting to send context — it's sending it once. A team attaches the route when the chat widget opens, and never again. The user opens chat on the billing page, clicks into three other screens, then asks a question — and the assistant answers as if they're still on billing. Confidently. That's worse than no context, because a wrong answer delivered with specifics gets believed.

The fix is mechanical: read the route fresh on every message send, not once at widget-open. If you're building this yourself, that means reading window.location.pathname (or your router's current-route value) inside your send function, not caching it in a variable set on mount. It's a one-line difference in where you read from, and it's the difference between context that's true and context that's stale.

If you want more than route: one field, your own format

Beyond route, most support-chat APIs — Total Chat's included — don't hand you a prescribed schema of tabs and object IDs and account tiers. What you typically get is a single freeform field for additional state, sent alongside the route, with the content entirely up to you. For Total Chat specifically: POST /api/conversations/:id/messages accepts the message plus an optional plain-string field that gets woven directly into the assistant's context. There's no required shape — you decide what's worth describing and write it as a short sentence or a compact key:value list, whichever you'll actually keep accurate.

A few rules make that string worth sending:

• Keep it short and current. A one-line description of what's relevant right now beats a dump of everything you could theoretically know. Long stale strings cost tokens and mislead the model exactly like a stale route does.
• Never put values in it. "Billing form has a validation error on card number" is fine. The actual card number is not. Describe state, not content.
• Recompute it on every send, same as the route — for the same reason.

If your own chat implementation (Total Chat's or anyone else's) offers a similar freeform field instead of a fixed schema, treat that as a feature, not a gap — it means you're not waiting on the vendor to add a field for your app's specific concept of "state."

Keep personal data out of whatever you send

Allowlist the fields you send. Never blocklist, because a blocklist loses to the next feature someone ships. Send IDs, not contents. Strip query strings by default and re-add the specific params you need by name. Never read form field values — the field someone is typing into is the one most likely to hold a card number or a password.

Then write down what you send, in your own docs, in plain language. Anyone running a security review will ask, and "we send the route and a short status string we control" ends that conversation quickly — especially if you can also say exactly what you don't send.

The mistake that looks like diligence

A common mistake is deciding that if some context helps, all of it must help — shipping the serialized DOM, the whole Redux store, or the last fifty user events through whatever freeform field is available. It backfires three ways: signal gets buried in noise, the payload costs more on every message, and customer data ends up somewhere your privacy policy doesn't describe. Send the smallest string that changes the answer. If adding something to it doesn't change what a good support engineer would say, it isn't context — it's exhaust.

How to tell it's actually working

Two checks, both doable in five minutes:

• Ask the identical question from two different pages. Different answers, or the route isn't reaching the model.
• If you're sending a custom status string, ask something that only makes sense if that string arrived (reference the exact state you described). A generic answer means check your send path, not your prompt.

For the buyer's-eye version of this same idea — why it matters, not how to wire it — see AI Support Agent That Sees User Screen. For how this fits next to a general-purpose support bot, AI Chatbot for SaaS Applications covers that comparison.

Free-tier workspaces provision instantly — no sales call. Self-serve checkout for paid tiers is finishing its final rollout steps; email [email protected] if you want a paid plan turned on before it's live.

---