kakinang INSIGHTS · 2026-09-17

Is an AI chat alone enough for a website, and what must stay on public pages?

AI I want to separate facts that belong on public pages from questions the website AI should clarify. chat can handle an individual visitor's question, but it should not be the website's only information entrance. Some people want to scan services and costs; others browse with a keyboard or assistive technology or land directly on a page from search. If every answer requires opening a widget and asking a question, comparison becomes harder and public promises harder to maintain. Pages provide shared facts that can be read and updated directly. Chat clarifies uncertain personal circumstances and hands visitors to a next step.

Illustrative shop owner reviewing public information on paper and a tablet
Illustrative scene, not a product screenshot or real customer record

Publish shared facts visitors can judge themselves

Think of the home page as the front door, service pages as shelf labels and AI chat as a receptionist. On arrival, visitors should learn what is offered, service areas, hours, how common charges work, how to contact or book, how to cancel and who decides exceptions. Hiding all of that in conversation makes each person ask the same opening questions and prevents sharing a direct link with family or colleagues. A small business needs at least service scope, pricing or quote method, contact hours and privacy information appropriate to the data it collects. Pages may be short, but conditions must be more than slogans.

Consider a hypothetical plumbing and electrical repair shop. The home page names service areas and work types; a service page says whether a callout charge includes inspection, which materials cost extra, which high-risk work it will not accept and whether evening rates apply. These are quote rules, not an invented fixed quote. If each job requires a site photo before estimation, say “provide location and fault description, then a technician checks whether we can take the job and estimates cost”. AI must not turn a website starting price into a final bill. A household's exact address and phone do not belong on a public page; collect only what a response requires.

FAQ can cover repeated common questions such as travel, cancellations and preparation. Give a short answer, then its scope and exceptions. An individual's warranty, medical or legal responsibility, or complex procurement case should not receive a presumed personal conclusion from a public page. Separating self-service facts from human decisions reduces AI errors and tells staff when to step in. Give public content an approver; an exception mentioned verbally by reception does not become an approved discount or policy.

Google's guide to generative AI search discusses publicly accessible, crawlable website content as a basis for outside search. That is not a reason to expose secrets for visibility. Publish only what can be said to every visitor, and verify the page is readable; then let on-site AI ask for individual conditions. Pages permit a first decision without chat while conversation helps with nuance. Both need the same approved version. Neither one's existence proves the other is up to date.

Google Search Central

Make pages readable on phones, in search and with assistive tools

A reachable URL alone does not mean the page is usable. Give it a clear title, ordered headings, readable text and meaningful link names. Tiny lettering inside an image must not carry the only price or condition. W3C's page-structure tutorial explains how headings and sections support navigation for people and assistive technology. Ask a friend to find service area, cost rules and cancellation on a phone without zooming, then move through the main links by keyboard. A poster image can be hard to read and costly to update for one changed price; text and descriptive imagery work together.

Even with a polished floating chat widget, check that the service text appears in the actual rendered page. Google's JavaScript SEO documentation warns that content absent from rendered HTML cannot be indexed, and JavaScript-heavy sites add rendering steps. Shops need not guess an algorithm. Use a browser and Search Console to see whether important pages are readable, unblocked and linked from the home page. On-site knowledge, chat logs and staff-only documents have other jobs; they are not the body of a public service page.

Create a minimum page inventory: a home page sentence naming the service and audience; service scope, conditions and process; fixed or starting price or quote method; contact channels, hours and reply expectations; common FAQ; and a privacy explanation for lead information. A sole freelancer with one service can combine these in one clearly sectioned page. Do not create many thin pages just for SEO. A business with several products or areas should provide direct service links, instead of making visitors discover each one through chat.

Give a content owner a monthly check for changed hours, locations, prices, service list, contacts and ended promotions. Record every place that needs updating and who owns it. A public edit may also require FAQ, on-site knowledge and booking text changes; old search snippets may take time to refresh. Outside crawling and indexing are not under the shop's immediate control. The shop can correct its own page now, update AI knowledge through its process and test. A person should remedy any wrong public promise already given rather than merely waiting for an index change.

Illustrative paper wireframe of a public website
Illustration: service scope, price conditions and contact methods should be readable on the public page; not a product screenshot.

W3C Web Accessibility Initiative

Use chat for clarification and handoff, not as the only counter

Within configured agents, knowledge and business flows, kakinang's website AI can answer and ask follow-up questions, then offer enabled lead, booking or human routes. Before launch, test ten questions against public pages: hours, price exceptions, cancellation deadline, areas not served and matters requiring judgement. Record page text, AI answer, source and next step for each. When asked about an unpublished discount or personal suitability, saying “I don't know” and referring to a person may be correct. Repeat these tests after information changes; the first pass is not permanent proof.

For an individual quote, chat may explain the process and request an area, brief need and usable contact method. Photos or further details should depend on actual necessity, data care and staff process. Say why lead fields are collected and how follow-up works, and obtain explicit consent; more fields do not automatically improve quality. Live human takeover differs from an asynchronous lead. Both page and chat should say whether anyone is on duty, when an unattended request will be read and by whom. A successfully sent notification is not an answer to the customer.

Use a hypothetical Sunday test: someone asks for a Monday home visit. The public page says Sunday is closed and Monday availability needs checking. AI should cite those conditions, not promise 10 am. It can record the need, explain that a person will check on Monday and request a suitable contact method. On Monday a staff member must understand the summary, verify conditions and respond. Someone asking only for the basic service area should get that public answer without first surrendering a phone number. This is a process illustration, not a customer record or measured outcome.

Weekly, sample a few conversations and page paths. Which visitors opened chat to ask an answer already on a page? Which contacted the shop without chat? Which leads got no human response? Fix page navigation when existing answers cannot be found; repair knowledge source and enablement for stale AI citations; repair ownership and staffing when leads go unanswered. More conversations do not prove the page succeeded, and a visitor who leaves no lead does not automatically signal AI failure. The aim is trustworthy shared facts plus a reasonable path for exceptions.

Illustrative customer reading a printed service information booklet in a shop
Illustration: customers can understand shared service conditions without opening chat; not a real customer record.

Questions teams ask

Can a knowledge base replace a service page?

No. Knowledge can support the website AI, but visitors who never open chat still need public scope, conditions, pricing explanation and contact information. Outside search uses pages it can access. Imported on-site knowledge does not mean a public page has been indexed.

Must every detail be public?

No. Publish common facts people need for an initial decision. Client records, internal floor prices, private staff contacts and unapproved personal judgements must stay out. When private information is needed, explain its purpose, ask only for necessary fields and route it to authorised staff.

What if the page and AI disagree?

Pause the contradictory advice. Have the content owner verify the latest approved condition, update both page and knowledge, check successful source processing, enablement and duplicate old documents, then retest. A person should clarify any wrong promise already given to a visitor.

Does having chat imply live human service?

No. Live takeover requires enabled functionality and actual staffing. An asynchronous lead needs a realistic human reply expectation. An automated greeting is not a human takeover and a submitted lead is not completed handling. State service hours and contact expectations on the page.

Sources and further reading

  1. Optimizing your website for generative AI features on Google Search — Google Search Central
  2. Page Structure Tutorial — W3C Web Accessibility Initiative
  3. Understand the JavaScript SEO basics — Google Search Central