122 家 Shopify：結帳能建起來，不代表代理答得出配送和取消

Bill Hunt 抽查的不是「AI 找不找得到這家店」，而是購物代理能不能把一筆購買決定做完：答得出買家的問題、完成下單，以及處理下單之後的事。樣本是 2026 年 8 月到 9 月、公開排名裡的 122 家頭部 Shopify 店。他的結論寫在標題裡：代理可以把結帳建起來，卻答不上配送和取消這類基本問題。

文章是在回應 Slobodan Manic 同年 9 月的說法。Manic 認為，現在丟給 AI 的純文字版本拿掉了不該拿的那一層：Markdown 鏡像描述了頁面，卻丟掉訪客按得下去的東西，於是網站變成一本小冊子，而且是拿給最想行動的人。他要電商團隊做三件事：露出能做的動作、讓代理呼叫得到、以及回報剛才發生了什麼。Hunt 沒有只數各店宣稱有哪些工具，而是實際去呼叫。下文先寫他認為 Manic 說對的地方，再寫 Shopify 已經做好的結帳，然後是三處結果不同，最後是商家和 Shopify 各自能改的。

目錄（11）

編譯自 Search Engine Journal · Bill Hunt · 2026-10-14 原文

完整來源聲明

來源聲明：本文根據 Bill Hunt（Search Engine Journal，2026-10-14）〈Your Store Is ‘Agent-Ready’ By Default, We Tested 122 Shopify Stores To See What That Actually Means〉編譯為繁體中文，不是逐句翻譯；結構與論點對齊原文，措辭為本站重寫。原文：https://searchenginejournal.com/your-store-is-agent-ready-by-default-we-tested-122-shopify-stores/591767。文中「編輯解讀」為本站觀點，不屬於原文。檢索日期：2026-10-16。

平台裝上的動作，不是商家自己做的

Manic 寫過，Shopify 在 8 月 5 日為每個 Liquid 店面打開 WebMCP¹ 工具，而且不是商家自己建的。Hunt 的資料在更大樣本上看到同一件事。收得到的 86 個商品頁裡，76 個載入的是同一支 Shopify WebMCP 轉接腳本。122 家裡有 89 家提供 /agents.md；這 89 份裡有 83 份幾乎是同一份 Shopify 產生的模板。整份 122 家的樣本裡，只有 5 份是商家自己寫的。

所以，把「有沒有 agents.md」當成商家已經為代理準備好，量到的其實是 Shopify 的上線進度。GEO 也不處理這個動作。多數店把代理需要的事實寫在頁面上，Shopify 的結帳也跑得起來。斷掉的是中間那一步：把已經公開的政策，變成代理做決定時取得的答案。退貨天數寫在政策頁的散文裡，被問到時代理卻取不回。被引用或排名靠前，補不上這一截。

語意這一層在商品頁同樣不完整。Manic 引用 WebAIM 2026 年的調查²：首頁上未標籤的表單控制項約 51%，空連結約 46.3%，空按鈕約 30.6%。Hunt 把同樣的檢查做到真正發生購買的商品頁，對象是取得得到的 68 家店。購買按鈕本身通常沒問題：按鈕出現時，大約 92% 是帶名稱的原生 button。問題在按鈕周圍。尺寸選擇器若沒有標籤，代理就分不清哪個下拉是尺寸、哪個是顏色。作者把這寫成這種失敗會怎麼發生，正文沒有另給「68 家裡有幾成選擇器沒標籤」的比例，不能把某一成數說成他的測量結果。

無障礙、使用體驗和代理就緒用的是同一套標記。有標籤的尺寸選擇器、有名稱的購買按鈕、以及會被朗讀出來的「已加入購物車」，同時服務螢幕閱讀器、鍵盤使用者和瀏覽器裡的代理。衝突來自只做給眼睛看的設計：色塊沒有名字、確認只出現在畫面上。標記補一次，三邊一起受益。

Shopify 已經做好的那一層

Hunt 先肯定 Shopify：這個規模上，還沒有別人鋪過代理呼叫得到的商務表面。122 家裡有 89 家回應了標準的 MCP 工具列表。商家不用自己寫程式，就拿到目錄搜尋、購物車、結帳和政策查詢。Shopify 自己說，目錄已涵蓋數百萬商家的數十億商品，而且 2026 年第一季來自 AI 搜尋的訂單年增近 13 倍³。13 倍是 Shopify 的說法，不是這 122 家審計量到的。

結帳品質比他預期好。凡是露出通用商務協議（UCP）端點的店，他都做了一次不完成的即時結帳：為一件有庫存的商品建立前往波士頓地址的結帳、讀回來、取消、再取消一次。沒有完成購買，也沒有送出付款資料。這直接對上 Manic 清單的第三項。Manic 描述過代理因為確認「只畫給眼睛看」而重複送出表單。在 Shopify 的工具層，第二次取消會被一個機器讀得懂的錯誤拒絕，而不是默默再做一次。就這一項測試而言，工具已經會向代理回報結果。

三處和 Manic 不同，但不是互相否定

Hunt 把差異寫成時間和範圍，不是誰錯了。

第一，他們走的不是同一扇門，而且 Shopify 後來補上了 Manic 測過的那扇。代理進結帳有兩條路。一條是伺服器端點，代理直接呼叫、不開瀏覽器，也就是走 MCP 的 UCP。另一條是 WebMCP：工具註冊在購物者自己的瀏覽器分頁裡。Manic 在 8 月 6 日測的是瀏覽器這條，購買路徑死在內部錯誤。當時瀏覽器工具覆蓋店面和購物車，結帳那一步多半只是把分頁帶到結帳頁。

Hunt 9 月的測試走的是伺服器這條。給的是真實、仍有庫存的商品時，每一家被測的店都成功建立結帳，回應時間中位數約 1.1 秒。僅有的失敗來自他們自己的舊資料：商品編號是幾週前收集的。到測試當天，5 件已售完，2 個編號已不存在。店家用缺貨或無效代碼拒絕，並說明該商品編號不存在。因此這次成功不能拿來證明 Manic 遇到的缺陷已修好。測的是另一條路。

這小段失敗對商家仍有用，因為代理和他們一樣會握著舊編號。助理可能從商品 feed、先前對話或共享購物車拿出一個編號，幾天後才來買。售完是正常商務，前提是代理讀得到的每個表面都及時報告有沒有貨。編號消失則多半可避免：商品被刪掉再建、或重新匯入而不是就地編輯，代理就得從頭搜。變體編號要穩定，庫存要在 feed 和目錄裡同時是新的。

接著，9 月 28 日 Shopify 宣布結帳支援 WebMCP¹。瀏覽器裡的代理可以讀取和更新 Shopify 結帳，涵蓋到結帳和訂單確認，而且商家不用另外設定。9 月 30 日他們抽樣在瀏覽器裡打開即時結帳，並讓頁面露出 WebMCP。兩家都註冊了宣布的四個工具：讀取結帳、更新結帳、完成結帳，以及回到店面。只讀的讀取結帳回傳了完整內容：明細、含稅總額、履約方式，以及哪些欄位仍缺的代碼訊息。他們沒有送出訂單。Manic 當時失敗的瀏覽器路徑，現在可以碰到並讀到結帳。工具說明也直接寫了「先讀結帳以核對結果」，並要求在狀態為完成處理中或已完成時不要重送。這就是「回報發生了什麼」，寫進工具本身。

第二，呼叫得到不等於可以獨立完成。74 筆結帳全部回來的狀態是需要升級，訊息標成需要買家輸入。這和 Shopify 預設 agents.md 的規則一致：結帳要人批准。這是合理的安全選擇，也改寫了「代理就緒」的意思。新的瀏覽器工具維持同一條：完成結帳只能在買家授權購買之後使用，像 3D Secure 這種步驟會把控制權交回買家。在今天的 Shopify 上，代理組得出標了價的購物車，付錢的是人。

第三，Manic 的清單停在「做動作」。購買決定還需要規則，以及一條退回去的路。代理要先做完決定，才執行得了。9 月 28 日那次發布沒有改變這一點。在瀏覽器結帳裡，退款條款仍只以政策頁連結的形式到達代理，不是一組數值。讀取結帳可以讀到完成後的訂單細節，但沒有工具能取消或修改訂單。有一家店的結帳裡還出現購物者沒選的明細：「Free Returns Coverage」，2.98 美元，是店家加上的。代理看得到，但結帳資料沒有標它可選，也沒說明怎麼拿掉。這是買家承諾之前需要的規則，也正是工具沒有解釋的那種東西。

「預設就就緒」量到的是宣告，不是做成

Hunt 最想電商負責人記住的是：今天看一家 Shopify 店，很容易以為它已經為代理就緒。agents.md 在、UCP 設定檔在、MCP 工具有回應，很多就緒檢查也會給高分。預設檔給不了的是：宣告過，不等於做成。

凡是帶著 Shopify 政策工具的店，都被問了六個真實買家會問的問題，另外再用較像政策頁的寬問題做對照。退貨天數是唯一明顯成功的一項。其餘內容都在，工具在問題聽起來像政策頁時找得到；問題聽起來像買家時找不到。有一家的常見問題寫著美國訂單滿 75 美元免標準陸運，但問運費時這個答案不會回來。更糟的是，問取消時，有兩家回的是運費常見問題。看起來很有把握的錯答案，比沒有答案更危險，因為代理沒有可靠辦法知道它沒有回答這個問題。

到達日則是每家都缺。74 筆即時結帳裡，36 筆能給出去波士頓的運費，所以大約一半的這組樣本可以知道運費，但前提是先開始一筆購買。74 筆裡沒有一筆回傳到達估計或承運人，雖然協議裡有這兩個欄位。「什麼時候到？」在他們測過的任何一家、任何一條代理路徑上都答不出。

自取是看不見的。93 家帶有 UCP 履約宣告的店，全部只列運送，沒有一家宣告自取。其中包括明明提供自取的零售商。有一家文件寫了到店自取，代理端點卻回答沒有自取地點。另一家提供點擊後領取，宣告裡卻只有運送。代理拿到的是清楚、機器讀得懂、而且是錯的答案，於是會把客人送去配送，即使當天可以自取。

多數政策資訊不是機器可讀的。政策文字讀得到的店裡，70% 用散文寫了退貨天數。商品頁裡只有 7% 用結構化的退貨天數欄位露出它。下單之後也沒有東西能撤銷：122 家沒有一家露出取消、修改或退貨的工具。這不是商家的錯。UCP 的訂單規格⁴定義了讀取訂單和訂單事件的 webhook，沒有定義取消或修改。它甚至定義了「取消、退貨和其他修改」的權限範圍，卻沒有定義怎麼做。

他們用來判斷代理能否完成購買決定的九項檢查，122 家全都沒有全部通過。最好的三家做到九項裡的七項。這三家倒在同一兩項：沒有寫明的取消窗口，以及沒有取消的辦法。

這不是搜尋團隊單獨能修的

Hunt 按「缺的資訊歸哪個團隊」把失敗分組之後，看到一個模式：這些團隊都不擁有網站。幾乎每家都過關的檢查，是平台自動產生的：目錄、變體、價格、結帳。幾乎每家都過不了的，需要網站團隊以外的人寫下一條商業規則，並有系統去執行。這是組織問題。搜尋團隊不能一個人補上。

Shopify 可以一次改掉的缺口

因為部署已經到這個規模，Shopify 也能按這個規模修。有些缺口的資料，Shopify 已經以結構化形式握在手上。Hunt 列了七件。

把商家自己的規則放進代理看得到的表面。退貨和取消規則裡已經存著退貨窗口（14、30 或 90 天、不限或自訂）、按商品覆寫、最終銷售、退貨運費、重新上架費，以及未出貨商品的取消窗口（不可取消、直到出貨、15 分鐘、1 小時或 24 小時）。商家若已設定，這些正是預設 agents.md、政策工具和商品頁結構化資料裡缺的值。從這些設定產生那些表面，一次發布就能補上最大的缺口。正文指的是 Shopify 說明中心裡的既有設定；說明中心這次無法直接打開，數值以 Hunt 的轉述為準。

把配送日期送進協議。Shopify 已支援在結帳使用手動或自動的配送日期。UCP 的履約選項有最早和最晚履約時間，74 筆結帳全都是空的。從外面分不清是商家關掉了，還是沒有傳過去。Shopify 分得清，也可以幫已經打開的店補上。

商家有提供自取，宣告裡就要寫自取。結帳已支援零售地點自取。店若開了自取，UCP 設定檔不該預設成只有運送。

讓政策工具回答買家的問法，並且在不知道時明說。空結果和答錯主題都會誤導代理。明確說「沒有取消方面的資訊」是誠實的，代理才交得回去。

標出殘留的 robots.txt 模板。122 家裡有 51 家在 robots.txt 禁止 /policies/。這不是 Shopify 現在的預設。官方文件說，這條只留在還帶著舊 robots.txt.liquid 模板的主題上，刪掉模板就會回到預設。後台加一個警告，就能幫那些從沒注意到的大店修掉。

把「已經取消」和「從未存在」分開。重複取消目前回的是找不到這筆結帳。單獨的「已經取消」代碼，才能讓代理確定，而不是只看到一個錯誤。

把協議裡缺的那一塊補上。Shopify 把 UCP 描述成涵蓋建立購物車、結帳、付款和購買之後。規格尚未定義購買之後的操作。作為共同開發者，Shopify 最適合去定義它在顧客自己的帳戶裡已經支援的取消、修改和退貨。

商家一個下午可以核對的

Hunt 寫明，不需要一輪完整審計。大部分一個下午就夠。先用自己的政策工具，問買家會問的話，看代理實際拿回什麼。再分別問退貨天數、運費、一個真實地址的到達時間、今天能否自取，以及使用過或開封退貨。若回來的是空清單、一個連結，或錯的主題，那就是代理拿到的東西。

然後做這些事：在 Shopify 後台設定退貨和取消規則，並把同一組數字寫進退款頁、運送政策頁和常見問題，不要只寫散文。做得到到達承諾再打開配送日期。檢查 /.well-known/ucp.json；若你有自取，檔案裡卻只有運送，就向 Shopify 提出。檢查 robots.txt 有沒有禁止 /policies/，有的話拿掉舊的 robots.txt.liquid。用你真實的退貨天數、取消規則、免運門檻和自取方式，替換或擴充預設的 agents.md。頭部 122 家裡只有 5 家這樣做了。商品結構化資料加上退貨政策和運送細節；若賣二手或整新，加上商品狀態。按 Manic 的建議用 WAVE 掃商品頁，給每個尺寸和選項選擇器加上標籤。

小冊子、結帳，以及這次沒測的選擇

Manic 的收尾是：網站的純文字版是一本小冊子。Hunt 的資料補了下半句。Shopify 已經給商家一個代理操作得了的結帳。它還沒給、而且多數商家也還沒自己提供的，是代理要負責任地使用結帳所需的規則：多少錢、多久到、能不能自取、能不能改變主意。

資訊在，還不夠。代理要解決顧客的決定，需要資訊、情境、規則和操作能力。目前多數看起來預設就就緒的店，只就緒到買家問出一個真問題為止。

測試沒有量、而他事後覺得最意外的一點是：他們告訴每家店要買哪一件。真實買家很少帶著變體編號來。他們需要幫忙在尺寸、型和相關商品之間選擇，這套決定邏輯是商家的知識，沒有平台能預設裝上。Shopify 可以承載它，只有商家寫得了。他說這是下一次要測的，也是之後專欄的題目。

方法寫在文末，分母不能混。122 家頭部 Shopify，選自公開的頭部商家排名，探測在 2026 年 8 月到 9 月。測過的層包括 agents.md、llms.txt、UCP 設定檔和 MCP 工具列表、商品頁結構化資料、政策頁可見文字、向各店政策工具提出的買家問題與對照問題、不完成的結帳生命週期（從不呼叫完成結帳、不送付款）、商品頁的靜態 HTML 無障礙檢查，以及 9 月 30 日在兩家店用瀏覽器檢查新的 WebMCP 結帳工具、只讀不送出。請求有限速；被限流或擋住的記成未知，不記成沒有。覆蓋因測試而異：政策文字 56 家，政策工具 88 家，即時結帳 74 家，商品頁無障礙 68 家。運費只測了一個波士頓地址。無障礙檢查只讀伺服器送出的 HTML，因此會低估 JavaScript 後來補上的標記。

常見問題

有 agents.md 是不是代表商家已經為購物代理準備好了？不是。122 家裡 89 家有這個檔案，其中 83 份幾乎是同一份 Shopify 模板，整份樣本只有 5 份是商家自己寫的。用它來量就緒，量到的是平台上線進度。
結帳測試成功，是不是表示 Manic 8 月看到的錯誤已經修好？不能這樣說。9 月那次成功走的是伺服器端的 UCP，Manic 8 月 6 日測的是瀏覽器裡的 WebMCP。9 月 30 日的抽樣才看到瀏覽器路徑可以讀到結帳，而且只測了兩家、沒有送出訂單。
74 筆結帳都建立成功，代理能不能自己付完款？不能。74 筆全部是需要升級、需要買家輸入。代理組的是標了價的購物車，付錢仍要人批准，包含 3D Secure 這類步驟。
為什麼問「什麼時候到」和「能不能自取」會失敗？74 筆裡沒有一筆回傳到達估計或承運人；36 筆要先開始購買才給得出去波士頓的運費。93 家有履約宣告的店全部只宣告運送。有的店文件寫了自取，端點仍回答沒有自取地點。
九項檢查有沒有店全部通過？沒有。122 家都沒有全過。最好的三家做到七項，而且都倒在同一兩項：沒有寫明的取消窗口，以及沒有取消訂單的工具。

編輯解讀

一句話重點：Shopify 的預設工具能把結帳建起來，不能當成商家已經回答了配送、自取和取消；就緒檢查的高分量的是檔案在不在。

這對你的網站意味著什麼：

用買家的問法去打自己的政策工具：運費、到達時間、今天能否自取、取消、開封能否退。回來的是空的、只有連結，或答成另一個主題，就不要對外說代理就緒。
退貨天數和取消窗口在後台設成數字之後，同一組數字要寫進政策頁和常見問題。散文裡的 70% 有寫退貨天數，商品頁結構化欄位只有 7%。
有自取就檢查 UCP 設定檔是不是仍只有運送。機器讀得懂的「只有運送」會讓代理把客人送去配送。
不要刪了商品再重建來改資料。變體編號一變，握著舊編號的代理就會被拒絕，或得從頭搜。
九項都過之前，不要用「有 agents.md、工具有回應」當代理就緒的結論。最好的店也還沒有取消窗口和取消工具。

適用與不適用的情境：適用於已經在 Shopify 上、而且要判斷購物代理能不能完成購買的店，尤其是 Liquid 店面。不適用於非 Shopify 的結帳、也不適用於「代理幫人選尺寸和型號」——這次測試事先指定了商品，作者把選擇邏輯留到下一篇。運費和到達只測了一個波士頓地址。

需要注意的限制：這是 Bill Hunt 的審計，不是 Shopify 的官方測試，也不是隨機樣本，而是公開排名裡的頭部店。各項分母不同：122、93、88、86、74、68、56 不能混成同一個比例。13 倍訂單是 Shopify 自己的說法。無障礙只讀伺服器 HTML。被限流或擋住的記成未知。說明中心頁面這次打不開，退貨窗口和 robots.txt 的官方細節以他的轉述為準。

延伸閱讀：

可沉澱規則 · 供站點自檢4 條

從本文提煉，可供人工對照或 AI 分析站點時作為依據。全部規則

122 家頭部 Shopify 裡，89 家有 /agents.md，其中 83 份幾乎是同一份平台模板，整份樣本只有 5 份是商家自己寫的。有這個檔案，不能當成商家已經為購物代理準備好了。
適用用 agents.md 或就緒檢查的高分對外說「代理就緒」之前
排除不要把平台預設模板的採用率寫成商家準備度
- 已打開檔案看是不是模板
- 是否寫了自己的退貨天數、取消規則、免運門檻和自取
代理能建立結帳，不等於答得出配送、到達、自取和取消。政策要用買家的問法打一遍；回來的是空清單、只有連結或錯主題，就是代理拿到的答案。
適用結帳或 MCP 工具已經有回應、準備對外說購買代理可用時
排除不要用「被引用」或政策頁有散文，代替代理取得到的答案
- 已用買家問法測運費、到達、自取、取消
- 74 這類分母沒有和 122 混用
UCP 只宣告運送時，可能把明明有自取的店說成不能自取。有自取就要核對設定檔；到達估計要另測，不能從運費推斷。
適用店有到店自取或點擊後領取，卻要讓代理回答履約方式時
排除不要把機器可讀的「只有運送」當成自取不存在
- /.well-known/ucp.json 是否仍只有運送
- 是否有一筆結帳回了到達估計或承運人
這次九項購買決定檢查，122 家沒有一家全過。最好的三家做到七項，仍沒有寫明的取消窗口，也沒有取消訂單的工具。
適用用單項通過（例如結帳建立成功）總結整店代理就緒時
排除不要把需要人批准的結帳說成代理可以獨立付完款
- 狀態是否為需要買家輸入
- 取消窗口和取消工具是否都有

名詞與資料來源

WebMCP — 註冊在瀏覽器頁面裡、讓代理呼叫網站動作的工具。Shopify 2026-09-28 的結帳支援說明：https://shopify.dev/changelog/posts/webmcp-support-for-checkout（檢索日期：2026-10-16）
WebAIM Million — WebAIM 對首頁無障礙的年度偵測。2026 年結果頁含未標籤表單、空連結與空按鈕的比例：https://webaim.org/projects/million/（檢索日期：2026-10-16）
Shopify 對代理商務與 AI 搜尋訂單的說明：https://www.shopify.com/blog/how-agentic-commerce-works（檢索日期：2026-10-16）。13 倍是這篇裡 Shopify 的說法。
UCP 訂單規格 — 通用商務協議裡關於訂單的部分。此版定義讀取與事件，未定義取消或修改操作：https://ucp.dev/2026-08-25/specification/order（檢索日期：2026-10-16）
Bill Hunt／Search Engine Journal：〈Your Store Is ‘Agent-Ready’ By Default, We Tested 122 Shopify Stores To See What That Actually Means〉 https://searchenginejournal.com/your-store-is-agent-ready-by-default-we-tested-122-shopify-stores/591767（刊登：2026-10-14；檢索：2026-10-16）