AI 搜尋就緒度
三個步驟。它們與內容品質無關（non-commodity-content 負責處理），而是關乎網站能否被機器代表客戶找到、報價並與之交易。
一個網站可以通過所有內容規則，但由於從未發布任何數字，也從未公開機器可讀的預訂端點，因此對代理程式來說仍然不可見。
步驟 1：發布價格範圍
規則。 每個商業網站都應發布其服務的費用。不是價格表，而是範圍，包含兩端以及決定價格變動的因素。
人們不斷向 AI 詢問事物的價格。如果 AI 無法提供報價，就會引導他們前往已發布價格的競爭對手。「請來電詢價」對機器來說是一條死路，對人來說也日益如此。
至少要發布的內容：
- 最低價和最高價，以實際數字呈現
- 決定因素：影響價格在範圍內落點的兩三個變數
- 價格範圍的測量日期，放在數字旁邊
- 每一項固定費用，完整列出：運費、設定費、押金、清潔費、最低消費、罰款
- 即時報價的來源連結
常見異議與解答。 業者拒絕，因為價格會變動，而且他們擔心被舊的數字綁住。這個異議是針對 「一個被當作價格呈現的單一固定價格」。這並非反對價格範圍的論點。標註日期並說明影響因素的範圍，比完全沉默更準確，而且是業者獨一無二能夠提供的資訊。
解決此問題的規則。 永遠不要發布裸價。請發布：
全車隊每晚價格範圍為 106 美元至 175 美元，測量日期為 2026 年 9 月 18 日。最終價格取決於您選擇的露營車和日期。請查詢您的確切日期以獲得準確價格。
而非：
露營車每晚 106 美元起。
切勿將價格輸入兩次。 在建置時，從企業已維護的來源（例如預訂平台的資料串流、POS 系統、已發布的費用表）讀取數字。鍵入頁面的價格，一個月內就會與結帳頁面的價格不一致。如果是從業者自己的頁面解析數字，兩者永遠不會走樣。
如果確實無法發布費率（例如按專案報價，或由第三方設定），頁面仍應提供所有固定的相關資訊：費用表、最低消費、押金、更改預訂的罰款。然後清楚說明費率本身是按報價設定，並指出可取得報價的地點。一個說「我們不發布 X，原因如下，請至以下地點取得，以下是所有不變動的資訊」的頁面，遠勝過一個什麼都不說的頁面。
任何定價頁面的發布前檢查清單：
- 範圍的兩端皆為實際數字，而非「起」
- 已說明影響價格的決定因素
- 測量日期放在數字旁邊
- 每一項固定費用都已完整發布
- 數字在建置時從來源讀取，而非手動輸入
- 結構化資料與內文中的數字一致（請見步驟 2）
- 如果無法對某些項目定價，頁面應說明原因並指向報價來源
步驟 2：可供代理程式使用的排程
規則。 如果客戶的代理程式無法看見如何與日曆交易，該商家對它來說就是隱形的。代理程式預訂功能已存在：助理會預訂餐桌、服務電話、租賃。它會先讀取結構化資料，其次才是 DOM。
三個層級，全部必要。
1. 結構化資料中的優惠。 每個可預訂的項目都應包含一個 Offer，其中包含真實價格或 priceSpecification 範圍、貨幣、庫存狀態，以及與測量日期相符的 priceValidUntil。僅有商家的 priceRange 是不夠的；機器需要的是它被要求預訂的項目上的優惠。
"offers": {
"@type": "Offer",
"priceCurrency": "USD",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"priceCurrency": "USD",
"minPrice": 106,
"maxPrice": 175,
"unitCode": "DAY",
"referenceQuantity": { "@type": "QuantitativeValue", "value": 1, "unitCode": "DAY" }
},
"availability": "https://schema.org/InStock",
"priceValidUntil": "2026-12-31",
"url": "https://example.com/book"
}
2. 動作。 實體應包含一個 potentialAction，命名預訂端點、HTTP 目標及其所需的輸入參數。這是幾乎沒有人發布的部分，但卻是代理程式真正需要的。
"potentialAction": {
"@type": "ReserveAction",
"name": "預訂此露營車",
"target": {
"@type": "EntryPoint",
"urlTemplate": "https://example.com/book?rental_id={rental_id}&from={checkin}&to={checkout}",
"actionPlatform": [
"https://schema.org/DesktopWebPlatform",
"https://schema.org/MobileWebPlatform"
],
"httpMethod": "GET"
},
"result": { "@type": "Reservation", "name": "露營車租賃預訂" },
"object": { "@type": "Product", "name": "2023 Jayco Jay Flight" }
}
選擇與動作相符的類型：預訂或保留用 ReserveAction，預約用 ScheduleAction，購買用 OrderAction，活動用 RsvpAction。
3. 限制條件，以資料而非散文形式呈現。 如果代理程式預訂了商家無法承諾的住宿，就是在浪費大家的時間。請發布會導致預訂失敗的規則：
- 最短和最長停留時間
- 提前預訂時間和截止時間（
availabilityStarts、advanceBookingRequirement） - 資格要求（最低年齡、駕照、押金）
- 服務區域（
areaServed），以及到達每個區域的費用 - 營業或送達時間窗口（如果到達時間受第三方限制）
將這些資訊放入 schema 中存在的屬性裡，並以純文字句子的形式放在頁面上（如果 schema 中沒有對應屬性）。兩者皆需，且必須一致：代理程式讀取一個，人類閱讀另一個。
代理程式可讀取的渲染。 關鍵內容應由伺服器端渲染、使用語意化的 HTML、真實的標題、替代文字、以 <table> 呈現表格。代理程式會讀取 DOM 和無障礙樹。僅在客戶端擷取後才出現的內容，是代理程式沒有看到的內容。
不要偽造功能。 僅針對實際接受預訂的端點發布 ReserveAction。指向聯絡表單的動作是個謊言，代理程式會據此行動，而客戶將在最糟的時刻發現。如果預訂實際上只能透過電話進行，請在 schema 中發布電話號碼，不要發布預訂動作。
協定層級，以及該建置哪一層
存在三個層級。它們不是替代方案，而是疊加的，並且順序很重要，因為較低層級現在就能被讀取，而較高層級大多還不能。
第 1 層：結構化資料（務必優先建置此層）。 如上述的 Offer 加上 potentialAction。這是當今的助理在回答關於商家的問題以及跟隨連結執行操作時實際使用的。它只需要一頁 JSON-LD 即可立即生效。
第 2 層：機器可讀的資料串流。 一個穩定的 JSON URL，包含型錄：可租賃或可銷售的項目、每個項目的價格、限制條件、預訂 URL 以及測量日期。無需協定承諾，無需維護端點，任何代理程式、爬蟲或同類網站都可讀取。成本低廉，而且是讓第 3 層變成未來某個早上就能完成的工作的關鍵。
第 3 層：A2A（Agent2Agent）。 用於代理程式之間任務委派的開放協定：一個位於知名 URL 的代理程式卡，描述代理程式的身分、技能和認證；以及一個透過 HTTPS 使用 JSON-RPC 通訊協定、接受任務並回傳結果的端點。當客戶的助理應該能夠提問並獲得答案，而不僅僅是讀取頁面時，這是正確的解決方案。
誠實看待它的現狀。截至 2026 年底，還沒有消費者助理會定期爬取代理程式卡的註冊中心，因此發布代理程式卡是一種押注於發現機制將會到來的賭注，而非本季度的訂單來源。當商家有某些代理程式真正需要詢問、但靜態資料串流無法回答的資訊時（通常是即時庫存），才建置它。
誠實規則在此處最為嚴格。 代理程式卡宣稱擁有技能，而其他代理程式將會呼叫它們。只宣告端點真正能做到的事。大多數小型業者根本無法完成代理程式對代理程式的預訂，因為付款、保險和租賃合約都位於第三方平台內部。這沒關係，卡片應說明這一點：
{
"name": "範例租賃公司預訂助理",
"description": "回答關於一個車隊的庫存和價格問題。無法處理付款。",
"skills": [
{ "id": "check-availability", "description": "查詢兩個日期之間有哪些車輛可用" },
{ "id": "quote-stay", "description": "查詢特定車輛和日期的總費用，包含送貨到鎮上的費用" }
],
"capabilities": { "streaming": false, "pushNotifications": false }
}
一個聲稱擁有 book-stay 技能但最終只會重新導向的卡片，與指向聯絡表單的 ReserveAction 是同樣的失敗，只是另一端是機器而不是人。
付款。 代理程式付款軌道（作為 A2A 擴展的 AP2，以及其他競爭中的代理程式商務規格）正在快速發展，而且大多數預訂平台尚未支援。不要圍繞它們設計結帳流程。將流程導向平台自己的結帳頁面，並在卡片中說明。
任何可預訂頁面的發布前檢查清單：
-
Offer包含價格或價格範圍、貨幣、庫存狀態、priceValidUntil -
potentialAction包含真實的EntryPoint，代理程式可以呼叫 - 動作的 URL 模板參數是預訂系統實際接受的參數
- 最低消費、提前預訂時間、資格要求和服務區域已作為資料和純文字發布
- Schema 中的每個數字都與文案中的數字相符
- 頁面的預訂資訊由伺服器端渲染
- 沒有為不存在的功能發布動作
步驟 3：來自真實問題的內容
規則。 客戶實際提出的問題就是內容。每一通電話、每一封電子郵件、每一個「預訂前」的問題，都應成為一個頁面或一個章節，以客戶自己的說法公開回答。
Google 自己的指引表示，通用的建議內容（例如「夏季玩水 7 個小技巧」）並不會勝出。勝出的是高度特定且真實的內容。今天早上客戶提出的問題，本身就同時具備這兩個特質，因為從公開來源寫作的競爭對手並不知道這個問題曾被提出。
運作習慣：
- 逐字記錄問題。 使用客戶的措辭，而非業界術語。「你們可以把鑽地機送到我家，讓他們修理屋頂嗎？」就是查詢。「住宅區放置物流」則不是。這與撰寫搜尋者的名詞是同樣的規則。
- 在讀者所在的頁面上回答。 在問題發生的頁面上回答，而不是在沒人會去的部落格文章中。
- 回答時附上來源。 沒有來源的回答是意見；讓它值得被引用的是固定費用、已發布的規則、已測量的數字。
- 當答案不屬於你時，請說明。 如果答案屬於第三方（例如議會、保險公司、公園管理處），請說明並指出該問誰。這句話本身就是一種資產。
- 持續追蹤只有營運者知道的資訊。 每個專案都應維護一個開放問題檔案。這些答案就是沒有人能複製的內容，而該檔案就是訪談大綱。
FAQ 區塊是為讀者設計的，並附加 FAQPage 標記，因為它清楚說明了頁面回答了哪些問題。 它們並不是獲得引用的槓桿。第一手的特殊性才是。
三者如何結合
讀者從一個引用了價格範圍的 AI 答案來到網站。該頁面確認了數字、說明了影響因素，並回答了他們實際上的問題。然後他們的代理程式進行預訂，因為優惠和動作已作為資料發布。
缺少任何一環都會中斷這個鏈條。內容出色但沒有發布價格的網站不會被報價。有價格但沒有動作的網站無法被交易。兩者兼具但內容是通用內容的網站，從一開始就不值得被報價。
資料來源
- Danny Sullivan 主題演講，Google Search Central Live Toronto，2026 年 4 月，關於非大宗內容。
- AI 最佳化指南，Google Search Central，關於代理程式可讀性和查詢扇出。
- schema.org
Offer、UnitPriceSpecification、ReserveAction、EntryPoint。 - A2A（Agent2Agent）協定，Linux 基金會，關於代理程式卡和 JSON-RPC 任務介面。