kakinang INSIGHTS · 2026-09-17
網站只有 AI 聊天室夠嗎，哪些資訊仍要放在公開頁面？
AI 我想分清哪些資料應公開寫在網頁，哪些適合由 AI 接待補問。 聊天室可以接住訪客的個別問題，卻不該成為網站唯一的資訊入口。有人想先掃一眼服務與費用，有人用鍵盤或輔助科技瀏覽，也有人從搜尋結果進入特定頁面。若每個答案都得先開視窗、輸入問題、等待生成，顧客無法快速比對條件，店家也很難維護公開承諾。公開頁面與聊天各有工作：前者提供可直接閱讀、引用、更新的共同事實，後者釐清尚未確定的個案並帶到下一步。
先公布顧客能自己判斷的共同事實
把網站首頁想成商店門口，服務頁想成貨架標示，AI 聊天則像接待人員。訪客進門應先能知道賣什麼、服務哪些地區、何時營業、常見費用如何計算、如何聯絡、預約或取消，以及遇到例外由誰判斷。若這些資料全藏在對話裡，顧客每次都得問同一輪問題，也無法把連結分享給共同決策的家人或同事。小企業至少準備一頁服務範圍、一頁價格或報價方式、一頁聯絡與時段，以及與個資蒐集相稱的隱私說明。篇幅可短，但條件不能只剩口號。
以假設的水電維修小店為例，首頁可說服務縣市和可處理的類型，服務頁列出上門費是否包含檢查、哪些材料另計、無法承接的高風險工作、夜間加價是否存在。這不是虛構固定報價，而是清楚界定報價方式。若每一案都需看現場照片再估價，就寫「先提供地點與故障描述，由師傅確認可否接案與預估費用」，不要讓 AI 將網頁上的起價自動承諾為最後帳單。個別門牌或住戶電話不必寫在公開頁，詢問時也只收判斷與回聯所需的最少資料。
FAQ 適合處理反覆出現的共同疑問，例如交通、取消政策、需要準備的物品。每一題先給短答，再交代適用範圍和例外。若顧客問的是個人的保固、醫療或法律責任、複雜採購條件，就不該由公開頁推定個案結果。把「可自助理解」與「需人決定」分清，不只降低 AI 答錯的機會，也讓人員比較容易知道何時該接手。公開內容須有審核者；不能因為接待經常口頭說某個例外，就把尚未核准的折扣或承諾當作政策。
Google 的生成式 AI 搜尋指南談到公開且可爬取的網站內容仍是外部搜尋理解來源的基礎。這並非建議把機密資料公開換曝光。店家應只放可以對所有人說的事，並核對頁面是否真的可讀；再用網站 AI 補問個別條件。公開頁讓顧客不靠聊天也能作第一步判斷，聊天則讓需要釐清的人不必在複雜表格裡猜答案。兩者以相同已核准版本為準，不能把其中一方的存在當成另一方更新的證明。
讓頁面在手機、搜尋與輔助工具都能閱讀
公開不只代表網址能開。頁面要有明確標題、依層級排列的段落、可讀的文字和有意義的連結名稱；圖片上的小字不能承擔唯一的價格或條件。W3C 的網頁結構教學指出，標題與區塊結構幫助人和輔助科技在頁內導覽。小店可請朋友用手機不放大畫面，找出服務區域、費用條件和取消方式；再用鍵盤走一次主要連結。若只靠海報圖片，文字可能難讀，更新一個價錢還需重做整張圖。文字、清楚圖片說明與易懂連結可互補。
即使網站有漂亮的聊天浮層，也要檢查服務頁的本文是否在實際渲染頁面出現。Google 的 JavaScript SEO 文件提醒，若內容沒有進入渲染後的 HTML，搜尋系統無法索引它；需要執行 JavaScript 的網站也有額外處理步驟。對店家來說，測試方式不是猜演算法，而是用瀏覽器和 Search Console 檢查重要頁面是否可讀、有沒有阻擋，以及連結是否能從首頁找到。站內知識、對話紀錄、登入後文件各有用途，不等於公開服務頁的正文。
訂一份最小頁面清單：首頁一句說明服務與對象；服務頁列範圍、條件、流程；費用頁交代固定價、起價或估價方法；聯絡頁列時間、通道、多久回覆；FAQ 回答共同問題；隱私說明解釋留單資料用途。對只有一項服務的獨立工作者，這些可以整合成一頁明確分段，不必為了 SEO 生出很多薄頁。對多地區、多商品的企業則應提供能直接到達的各服務連結，而不是要求訪客在聊天室逐一探索。
安排每月一次由內容負責人檢查變動：營業時間、地點、價格、服務名單、聯絡人、停辦活動。每一項註明更新位置與人。若改了公開頁，還要看 FAQ、站內知識、預約提示和搜尋結果中的舊摘要可能需要時間刷新。外部搜尋的爬取、收錄與更新不受店家即時控制；網站自己則可以即刻修正顧客看到的頁面，再依現有機制更新 AI 知識並測試。若已經公開錯誤承諾，人員應處理受影響個案，不只等待索引變動。
W3C Web Accessibility Initiative
把聊天設成補問與交接，而非唯一櫃檯
kakinang 的網站 AI 可在已設定的 agent、知識與業務流程內回答、補問需求，並依啟用情況走向留單、預約或人工接手。啟用之前先從公開頁選十個問題測試：問營業時間、價格例外、取消期限、無服務地區、需人判斷事項。對每題記下頁面原文、AI 回答、來源與下一步。若問到未公布的折扣或個人適用性，正確做法可能是承認未知並交由人確認，而非編一個流暢答案。這種測試要在資訊變更後重跑，不能把第一次通過當永久正確。
若訪客需要個別報價，聊天可先解釋流程，再詢問地區、需求摘要與可用聯絡方式；是否要照片或更多資料，須看實際必要性、資料保護和人員處理流程。留單欄位旁說明用途與後續聯繫方式，取得明確同意；不要把「多收資料」當成提高品質。即時真人接手與非同步留單不同，公開頁及聊天都應清楚說明目前是否有人值班、若無人要等多久、誰會查看。業務收到通知後還要有人回覆；平台成功寄送通知不是顧客已得到答案。
用假設案例驗收：週日有人問週一是否可到府，公開頁寫週日不營業且週一名額須確認。AI 應引用這些條件，不能承諾週一十點一定有位；它可收下需求，告知週一由人確認並留下合適聯絡方式。週一人員要能看懂摘要、核對條件、主動答覆。若顧客本來只想找基本服務範圍，公開頁應先回答，不必先要求他留下電話。這些是流程示意，不是實際客戶紀錄或成效。
每週抽查少數對話與頁面造訪路徑：哪些人開了聊天仍問公開頁已有的事，哪些人未開聊天卻能完成聯絡，哪些留言沒有被接手。對已公開但找不到的答案，修頁面導航；對 AI 誤引舊資料，修知識來源與啟用狀態；對留單沒人回，修責任與值班。不要用「對話量上升」宣稱公開頁成功，也不要因有人沒留單就判斷 AI 失敗。目標是每位訪客都看得到可信的共同事實，遇到例外時知道合理的下一步。
團隊常問的問題
把服務內容都放進知識庫就能省去服務頁嗎？
不能。知識庫能幫網站 AI 回答，但訪客若不開聊天，仍要能在公開頁看到範圍、條件、價格說明與聯絡方式。外部搜尋依自己可存取的頁面運作，不能把站內知識已匯入當成公開頁已被索引。
每一項細節都要公開嗎？
不必。公開頁寫任何顧客做初步決定需要的共通事實；含客戶資料、內部底價、員工私聯或尚未核准的個案判斷不應公開。需要私人資料時，說明目的、只收必要欄位，交由有權人員處理。
公開頁與 AI 回答衝突時信哪邊？
先停止讓矛盾繼續影響顧客，由內容負責人核對最新已核准條件，再同步更新公開頁和站內知識。檢查來源處理成功、啟用與重複舊文件，重新測試。對已收到錯誤承諾的個案由人主動澄清。
有聊天就一定要提供即時真人服務嗎？
不一定。即時接手需要實際值班和功能設定；非同步留單則要告知何時由人回覆。不能把 AI 自動招呼稱為真人已接手，也不能把送出留單說成業務已完成處理。公開頁應列清楚服務時間與聯絡期待。
來源與延伸閱讀
- Optimizing your website for generative AI features on Google Search — Google Search Central
- Page Structure Tutorial — W3C Web Accessibility Initiative
- Understand the JavaScript SEO basics — Google Search Central