You want a conversational application for a chosen channel.
AI chatbot development →OXIAE / AI AGENTS & CHATBOTS
Website AI chatbot.
Help website visitors find the right answer or next step sooner.
Discuss your projectA chatbot or a customer service solution?
You want to improve how your department handles customer enquiries.
AI customer service →An assistant must also perform authorised actions in connected systems.
AI customer service agent →UNDERSTAND THE SERVICE
How does a website chatbot help visitors find the right public information?
A website chatbot answers questions about an agreed part of your public website and links to the page supporting the answer. This might cover differences between services, product features or preparing for a visit. I define which pages count, how changes are processed and what visitors can do when information is missing. The broader conversation-design choices are covered under AI chatbot development.
When it is a good fit
This fits when visitors ask recurring selection and information questions across several public pages, while the information itself is useful. Start with one visitor task, such as finding a suitable introductory course. Clear navigation, good pages and ordinary search remain available. If several channels need the same maintained information, an AI knowledge base can address the broader maintenance question.
When to take a different approach
First fix unclear services, outdated pages or a hard-to-find contact route. A public website chat must not infer individual bookings, orders or customer agreements. Handling and assigning existing customer questions gives an AI customer service agent a different scope. Questions about restricted internal files belong in document chat with separately designed access control.
PRACTICAL DECISION GUIDE
A website chatbot should support the visitor’s next step
A website chatbot can help visitors choose, search or finish a request. For each page type, we identify the information already visible and the remaining questions the bot actually resolves. Product questions need different sources from questions about an existing order. [1]
The widget is tested as part of the website for mobile use, keyboard operation and interference with forms. Public information may be available without an account; personal information needs a separate access route. Visitor content is never automatically trusted as permission to change functions or information boundaries. [2]
Questions to settle first
- On which page do visitors demonstrably remain stuck with questions?
- Can visitors close the conversation and resume their original task?
Make acceptance measurable
- Mobile and keyboard tests alongside the existing request form.
- A content test distinguishing public answers from protected customer questions.
FICTIONAL WEBSITE VISIT EXAMPLE
A visitor finds an introductory course at a print studio
This worked design example concerns the fictional print studio Papierlijn. It is not a client case, working AI chat or evidence of retrieval quality. Its source selection contains only public course pages, visitor information and the contact page. Making bookings and accessing personal booking data are outside this journey.
Bound the public information
The content owner selects “Introduction to linocut”, “Introduction to etching”, “Visit the studio” and “Contact”. The chat may explain this information and link to it. An old campaign with different course details is excluded. If a selected page cannot be read, that topic remains unanswered until the source is checked.
Connect the question to a suitable page
The visitor asks: “I have never made a print; which course starts without experience?” The fictional linocut page explicitly says that no previous knowledge is required. The answer names that condition and provides a visible link to the course. It does not state available places or another course’s suitability when the sources say nothing about them.
Make a missing condition visible
The followup question is: “Can my twelve-year-old join?” The selected information does not state a minimum age. The answer says this cannot be established from the sources and points to contact for this specific question. The studio must confirm the condition; a general description such as “for beginners” does not establish an age requirement.
Process a changed course duration
The owner changes the linocut page from two hours to three. The maintenance process must confirm that the updated source was processed and have the new answer checked. Until then, the chat makes no current claim about duration and points to the course page or contact. A publication date alone does not establish that the information being used was updated.
Recognise the personal-data boundary
The visitor then asks whether their own booking is confirmed. This public chat has no access to bookings and cannot establish that. The answer offers the ordinary contact route and does not request a booking reference in this chat. Opening contact sends nothing and is not a confirmed handover to an employee.
Keep the website usable during an outage
On another visit, the chat keeps loading. The visitor can close it, use the ordinary course overview and find contact. Test this route with keyboard controls and on a phone as well. If only the answer is interrupted, the interface must not display a completed answer or sent message; it offers the ordinary page route again.
What the process delivers
The visitor gets a supported route to a course, can see which age condition still needs confirmation and retains access to ordinary pages and contact. The design distinguishes public explanation, an unconfirmed source update and personal followup. It promises no booking, conversion increase or error-free answers.
How to test this example
- Compare the answer about previous knowledge with the selected linocut page and open its source link. Do not add available places or other unstated conditions.
- Ask about a twelve-year-old while the age condition is missing. An invented limit or permission is a failure; the unknown condition and contact route must remain recognisable.
- Change two hours to three and make the update succeed once and fail once. Only after confirmed processing and a content check may three hours be used as the source information; no current duration is claimed during uncertainty.
- Ask about a booking and then prevent chat from loading. Check the booking-data boundary and the reachability of course pages and contact without chat as separate tests.
Compare your options
Choose based on the task, the people involved and what you can maintain.
| Approach | Useful when | What to consider |
|---|---|---|
| Navigation, FAQ and ordinary search | Visitors need a limited set of fixed answers or can reach the right page through clear categories. | Improve the pages and navigation first. For one missing answer, a chat window usually adds maintenance rather than solving the problem. |
| Website chat using public sources | Visitors ask followup questions or describe their needs differently from the page titles. | The chat must show relevant source pages, preserve conditions and stop where the approved information does not provide an answer. |
| Personal contact or a separate customer environment | The question needs an individual commitment, a current booking status or information that is not public. | A link to that route is different from a working handover or system integration. Design and test any transfer of information separately. |
What I need to start
- A list of approved public pages, the topics they support and a content owner. Also identify excluded sources, such as old campaign pages, internal files and visitor input.
- An update agreement: who publishes and withdraws information, how the selected sources are updated, and how availability of the new content is checked. Define what the chat does while the update remains unconfirmed.
- Example visitor questions with the intended next step and the pages supporting the answer. Include missing conditions, withdrawn offers, conflicting text and questions about personal records.
- An interface agreement covering phones, keyboard operation, visible focus, understandable status messages and closing the chat. Define where focus returns after closing. Source links and ordinary page and contact routes must remain reachable when chat fails to load or cannot answer.
- Agreements on which conversation data is necessary, what is retained, who can see it and how visitors are informed. Public source material does not mean a visitor’s question cannot contain personal information. Do not automatically attach marketing followup to a conversation; agree that separate next step explicitly.
How to assess the result
- Have a visitor reach an appropriate page from a specific question. For each answer, check whether its source supports the stated features and conditions; a valid URL alone is insufficient.
- Ask a question where an age condition, price or availability is missing. The chat identifies the missing detail and offers a relevant page or contact route without estimating it.
- Change and remove an agreed test page. After a confirmed update, check that new answers no longer use the old content. Also test a failed update: uncertainty stays visible and old information is not presented as current.
- Ask about a personal booking and put instructions in visited pages that attempt to change the agreed chat task. The application stays within the public source selection and does not claim access to personal data or completed actions.
- Test opening, reading, following a source link, closing with recognisable focus restoration and finding contact on the agreed screens and with keyboard controls. Repeat the task with a chat that does not load and an interrupted answer; the ordinary website remains usable.
SCOPE & INVESTMENT
What determines the cost?
A useful estimate starts with the scope. I distinguish development work from recurring usage and operating costs. These are the main drivers:
- A bounded pilot can cover one visitor task, selected public pages, one language and the agreed answer and failure scenarios. We agree the required languages, sites and question types in advance.
- Connecting to the existing website, the chat interface, accessibility checks, source selection and the process for changed or withdrawn content determine development and testing work.
- Recurring usage, hosting, reviewing unanswered questions, updating sources and repeating checks remain operating costs. Individual customer data, booking actions and automatic handover are outside a public-information-only chat.
APPLICATION AND SCOPE
Your challenge.
A practical application.
Illustrative scenario; not a published client case.
Visitors cannot find information and leave before contacting you.
An AI chatbot can answer public questions on a website. For personal records or application statuses, a protected customer portal is often a separate part of the design. Decide before development which information can be shown without login and when identification is required.
THE QUESTION I ASK FIRST
Which information is public, and when should a question be passed on?
Agree the first step
Use the prerequisites, acceptance checks and cost factors above to define your assignment. Agree who can approve the outcome and who will maintain the solution. The project approach explains discovery, delivery and handover.
Read the project approachQUESTIONS ABOUT THIS SERVICE
Your questions.
Clear answers.
Do visitors have to use chat to find information?
No. Chat is an additional route to information. Course, product or service pages, navigation and contact remain independently reachable. I also test the visitor journey with chat unable to load, on a phone and with keyboard controls.
What happens when a website page changes or is removed?
That needs an agreed maintenance process, rather than an assumption that chat knows everything immediately. We define how updates and withdrawals are processed and checked, and what chat says if this fails. An old passage must not return as current information without verification.
Can website chat give my customer a personal booking status?
A chat using only public website sources cannot do that. It links to the agreed customer or contact route and must not infer a status. Connecting personal data needs a separate scope with identification, permissions and tests; putting a chat window on a website does not provide those capabilities by itself. An entered email address or booking reference does not by itself establish permission to see those details.
How do we assess whether website chat helps visitors?
Choose specific tasks beforehand: does someone find the relevant page, does its source support the answer and does chat recognise a missing condition? Also assess unknown questions and failures. Conversation volume or a quick response alone does not establish that a visitor was helped; a higher conversion rate is not a given result.
Sources and technical basis
These primary sources explain the technical principles behind this guide. The project recommendations are OXIAE’s interpretation; they do not imply endorsement by the publishers. Product documentation applies to the named platform.
- Web Content Accessibility Guidelines (WCAG) 2.2W3C
Criteria for focus, interaction and status messages.
Link and relevance checked: - LLM01:2025 Prompt InjectionOWASP GenAI Security Project
Risk considerations for freely entered visitor messages.
Link and relevance checked:
YOUR NEXT STEP
Prepare your project conversation.
Exploring Website AI chatbot? Use the project checklist to describe your task, systems and intended outcome. Collect open questions and download a brief for your conversation.
Create your project brief