Answers about the current page

The page path sent with a question#

The official widget sends location.pathname + location.search at conversation bootstrap and with each visitor message. /products/leather-bag?color=tan therefore includes the path and query. A fragment such as #delivery is not included and cannot distinguish a hash-only view.

This value helps retrieve relevant Knowledge and identify what the visitor is discussing. It does not automatically transmit the full rendered DOM, browser tabs, clipboard or a screen image. A path is a relevance hint, not customer authentication or permission to disclose a private record.

A path needs useful Knowledge#

Make sure the relevant page facts exist in enabled, prepared Knowledge. A path cannot supply a newly changed price, client-rendered detail or member-only content that the source does not contain. After editing an important public page, review its Knowledge and request a fresh crawl where appropriate.

If a page cannot be retrieved or lacks a useful fact, add a clear supported source. Use an authorized live Action for current availability, order state or customer-specific information when required. Installing the loader does not make every visible page value an authoritative live answer source.

Navigation and single-page applications#

Each message reads the current browser pathname and query. A retained widget in a single-page application can therefore reference a new ordinary route without reinstalling. There is no documented page-change callback or access to private router state. A content swap under the same URL cannot be inferred from the path alone.

For full document navigation, the destination layout must include the official loader. Avoid injecting it on every route-component render. If you need a public configured context hint, check its separate first-bootstrap limitation in the browser-context guide; it is not automatically refreshed with each message.

Keep sensitive data out of page URLs#

Review query strings before enabling support on sensitive routes. Widget requests can include them, so keep passwords, bearer credentials, reset codes, payment authorization values and unnecessary personal details out of customer-facing URLs. Use your application's secure session mechanisms instead.

The marketing analytics URL sanitizer is a separate implementation and does not sanitize this conversation contract. A customer ID in the address bar is not permission to read that account. Private Actions and server integrations must still establish the required identity and record authorization.

Verify relevance without overclaiming#

Ask the same question on two products with deliberately different facts, then ask an unknown-detail question. Compare each answer with the page and enabled source. Relevance includes acknowledging missing information; a confident specification borrowed from another product is a failure even when the request succeeded.

Use the public widget for this test. Private test previews Knowledge but does not reproduce the current visitor path. Keep the exact public URL, website, question and time for diagnostics, redacting any private query values before sharing them.

Worked example: product question followed by a policy question#

A visitor starts on /products/leather-bag and asks, “What is this made of?” The useful answer should be grounded in the product information available for that page. They then navigate to /delivery and ask, “How long does this take?” The widget supplies the current path with that later message. The business still needs reliable product and delivery information in its enabled Knowledge; a URL alone does not supply a missing specification.

Use this sequence to test relevance. Compare the answer with the real public page and the Knowledge source. If the assistant refers to the previous product when the visitor has moved to a policy, record the paths and questions and check that your frontend actually updated the address bar. If the path is correct but the answer lacks detail, fix the source information rather than inserting increasingly elaborate instructions into the URL.

A useful page-context test record#

Keep the two public paths, the final host, the questions asked and the relevant source references. Identify whether navigation reloaded the document or happened within a frontend application. Test a direct entry to the second route as well as navigation from the first. This separates missing layout coverage from a relevance issue inside an already installed widget.

Do not collect private query values in a ticket. Replace customer IDs, checkout tokens, email addresses and session references with redacted placeholders. A public product path is useful evidence; an unredacted checkout URL is not. A fresh browser context can help separate old tab continuity from the current page test. The supported browser API has no general reset-conversation method, so do not automate storage manipulation as part of production page-context handling.

Keep page relevance separate from customer identity#

A path such as /account/orders/1042 can indicate what a visitor is viewing, but it does not prove that the visitor owns order 1042. Browser-provided values can be changed by the person using the browser. Public page context and the browser context map must not replace server authentication or the Action email-verification and ownership checks required for private records.

For public products, use the path to keep the conversation about the item in front of the customer. For private account data, connect an authorized backend and enforce the relationship between the authenticated customer and the record at that backend. Your service must not disclose another person’s order merely because its number appears in a URL or a chat message.

Customer-context fields and trusted server context are separate integration surfaces. They need website-scoped definitions and a complete supported conversation lifecycle. The current stock widget does not expose a public conversation-ID callback. If your application needs that lifecycle, commission it explicitly instead of scraping private DOM or session storage and treating those details as a stable API.

Audit route coverage before launch#

List the routes where support should appear: your homepage, a product or service, a policy, a contact page and any application view you explicitly want to support. Identify the layout that renders each route. A shared footer may cover the marketing pages while a separate application shell covers account pages. Include the official script once in each intended document shell, and keep excluded routes deliberate.

For each route, open its public URL directly in a clean browser context and check the final hostname and loader. Then navigate between two routes using the site’s normal links. Compare direct entry with client-side navigation, including mobile. If support appears only after starting from the homepage, a direct-route installation or document-shell problem is likely.

Review the address used for each test. Hash-based routes and content swaps under a fixed URL need more planning than ordinary paths. Do not promise automatic recognition of every visible component. Document what the current path actually communicates and use a separate configured context field or live Action only when it solves a specific need.