首頁 » 觀點聚焦 » HowTo Schema 教學 — AI 引擎讀懂步驟指南
SEO優化
2026.07.08　最後更新 2026.07.09 Haden

HowTo Schema 教學 — AI 引擎讀懂步驟指南

你寫了一篇「五步驟設定 Google Search Console」的教學，內容完整、排版乾淨，可是丟到 ChatGPT 或 Google AI Overview 問同一個問題，被引用的卻是別人那篇看起來更陽春的文章。差別常常不在你寫得好不好，而在機器讀不讀得懂你的步驟順序。AI 把一篇教學拆開、重新組裝成「第一步、第二步」的答案時，它需要的不是漂亮的版面，而是一份標好順序的結構說明。

這份結構說明，就是 HowTo Schema（操作指南結構化資料）——一種用 JSON-LD 寫的標記，告訴搜尋引擎與 AI「這篇是一個有先後順序的流程，總共幾步、每步在做什麼」。它不改變讀者看到的畫面，只在背後替你把步驟一條一條交代清楚。

很多人一聽到「Google 早就在 2023 年下架了 HowTo 的步驟卡片」就以為這東西沒用了。其實要看你在乎的是搜尋結果版面，還是被 AI 引擎抽出來重組的機會——這兩件事在 AI 搜尋時代已經分家。這篇會先把「為什麼還值得做」講清楚，再帶你一步步把必填欄位、JSON-LD 範本和 WordPress 設定做完。而且你會發現，這篇文章本身的每個小節，剛好就是一次 HowTo 結構的示範。

HowTo Schema 是什麼？它替機器標記了哪些資訊

簡單來說，HowTo Schema 是 schema.org 詞彙表裡專門描述「步驟型流程」的一種類型。你用它包住一段操作教學——安裝軟體、設定外掛、組裝家具都算——它會把整個流程的名稱、每一個步驟、需要的工具與材料、預估花費時間，全部轉成機器讀得懂的格式。

它跟一般文章最大的不同，在於它把「順序」這件事明說了。對人類讀者來說，看到 1、2、3 自然知道要照順序做；但機器看到的只是一堆 HTML 標籤，它無法百分之百確定哪段是第三步、哪段只是補充說明。HowTo Schema 等於替每個步驟貼上號碼牌，讓 AI 不必靠猜。

舉個生活化的比喻。沒有結構化資料的教學文，像一份沒有標頁碼、沒有目錄的食譜手稿——人看得懂，但你要機器幫你「念出第三步」就很容易出錯。加了 HowTo Schema，就像替這份手稿裝上目錄與頁碼：流程叫什麼、總共幾步、每步的標題與內文是什麼，一翻就到。

這裡要先釐清一個常見的混淆。HowTo 標記的是有先後順序、後面依賴前面的流程，例如「換輪胎」必須先鬆螺帽再頂高車身，順序顛倒會出事。如果你的內容是一組可以任意調換、彼此獨立的問答，那是 FAQPage 的工作，不是 HowTo。判斷方法只有一句話——這些項目調換順序之後，內容會不會壞掉？會壞就是 HowTo，不會壞就不是。還有一個例外要記住——如果產出物是食物，那要用 Recipe（食譜）類型，因為它有食材、份量、烹調時間這些 HowTo 沒有的專屬欄位。

為什麼步驟卡片下架了，HowTo Schema 還值得做

先把時間軸講清楚，省得你被「已淘汰」三個字嚇退。Google 在 2023 年 8 月先取消了行動裝置上的 HowTo 複合式搜尋結果（也就是那種直接顯示在搜尋頁、把步驟攤開的卡片），同年 9 月 13 日左右連桌機版也一起下架，整個複合式結果功能正式停用。Google Search Console 裡的 HowTo 報表、複合式搜尋結果測試工具裡的 HowTo 預覽，也跟著移除。

聽起來像宣判死刑，但你要分清楚它下架的是什麼。Google 拿掉的是「搜尋結果版面上的視覺呈現」，不是「這段標記本身的價值」。標記還在、schema.org 的 HowTo 類型還在，Rich Results Test 不再給你 HowTo 專屬預覽，不代表 AI 與其他機器讀不到它。

真正的價值，在 AI 搜尋這一端冒出來了。當 ChatGPT、Perplexity、Gemini 或 Google 的 AI 概覽（AI Overviews）要回答「怎麼做某件事」的問題時，它們會去抓內容、再重組成步驟。這時候，一篇把步驟結構明白標出來的頁面，等於直接遞給 AI 一份「不必自己推論」的流程圖。AI 處理網頁的方式跟人不同——它把 HTML 拆解成資料點、再對應成語意關係，結構化資料就是讓這些關係變明確的那一層。沒有它，AI 得從上下文自己推斷哪段是第幾步；有了它，你是把「為什麼這段內容值得引用」直接寫給機器看。

這裡得誠實補一句，免得你抱著錯誤期待去做。坊間流傳「有 schema 的頁面被 AI 引用的機率高 2 到 4 倍」「結構化資料讓 AI 引用機率多 2.5 倍」這類數字，它們大多來自相關性觀察，不是因果驗證。Ahrefs 在 2026 年 5 月做過一份對照研究，追蹤約 1,885 個在 2025 年 8 月到 2026 年 3 月之間新加上 JSON-LD 的頁面，跟對照組比對引用率變化，結果沒有任何一個平台在加了 schema 之後出現明顯的引用提升。換句話說，那個高相關性比較可能是因為「本來就維護良好、權威度高的網站」剛好也都有用結構化資料，而不是 schema 本身把引用率拉上去。所以正確的心態是——HowTo Schema 是讓機器更準確理解你內容的基礎建設，而不是一顆按了就漲流量的按鈕。把它跟扎實的內容、清楚的順序一起做，才有意義。

除了 AI 引用，還有兩個常被忽略的長尾好處。語音助理會直接讀取 HowTo 標記，把步驟一步步念給使用者聽；如果你的教學還搭配影片，HowTo 支援把 VideoObject 嵌進來，等於告訴搜尋引擎「這段文字步驟跟這支影片講的是同一個流程」。對已經在產出教學內容的網站來說，維護這份標記的成本很低，未來 Google 若重新啟用步驟卡片，有標記的頁面也能立刻符合資格。

HowTo Schema 有哪些必填與選填欄位

要動手寫之前，先把欄位的層級搞清楚，這樣你才知道哪些非填不可、哪些是錦上添花。整個 HowTo 類型的必填欄位其實少得驚人，只有兩個；其餘十幾個都是選填，但選填的那些才是讓標記「語意完整」的關鍵。

下面這張表整理了最常用的欄位。先看必填，再看你的內容適合補哪些選填。

欄位型別是否必填作用
name文字必填這個流程的名稱（例如「如何設定 Search Console」）
stepHowToStep 陣列必填定義整個步驟序列，是 HowTo 的核心
description文字選填一句話的流程摘要
totalTimeDuration選填完成整個流程預估要花的時間
estimatedCostMonetaryAmount選填預估花費
supplyHowToSupply 陣列選填會用掉的耗材或材料
toolHowToTool 陣列選填會用到、但不會用掉的工具
imageImageObject 或 URL選填流程主圖，對 Google 圖片與 Discover 仍有用

step 這個欄位是整份標記的靈魂。它是一個 HowToStep 物件組成的陣列，每個物件代表一個步驟。最精簡的寫法只要給 text（步驟說明）就成立；如果你想讓每步同時有標題與內文，就同時給 name（步驟標題）和 text（詳細說明），AI 在抽「第三步：XXX」時會更好對應。

幾個選填欄位值得特別講。supply 標的是會被用掉的耗材，tool 標的是重複使用的工具——一個用完就沒、一個用完還在，分清楚這層差別，機器才知道做這件事到底要準備什麼。totalTime 與 estimatedCost 看似可有可無，但它們提供的是 AI 在回答「這要花多久、要花多少錢」時最想抓的中繼資料，對操作型教學特別加分。

這裡有個新手最常踩的雷，先講在前面——所有時間欄位都得用 ISO 8601 的時長格式，不能直接寫「30 分鐘」。30 分鐘要寫成 PT30M，1 小時是 PT1H，1 小時半是 PT1H30M，一天是 P1D。規則是 P 開頭代表一段期間、T 後面接時間單位。寫成人看得懂的「30 minutes」驗證工具會直接打回票。同樣地，費用也不能只寫 "$150"，要用 MonetaryAmount 物件把幣別與數值分開，機器才處理得了。

怎麼寫出一份可直接套用的 JSON-LD 範本

觀念講完，來實作。JSON-LD 的最大優點，是它是一段獨立的程式碼，包在 <script type="application/ld+json"> 標籤裡，放進頁面的 <head> 或 <body> 底部都行，完全不用動到你原本的 HTML 內容，後續維護也方便。下面從最精簡的版本，一路加到含工具材料的完整版。

第一步，先把最小可用的骨架寫出來。一份能通過驗證的 HowTo，最少只需要 name 跟 step。假設你要寫一篇「重設帳號密碼」的三步驟教學，骨架長這樣：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "如何重設帳號密碼",
  "description": "忘記密碼時，重設帳號密碼的步驟說明。",
  "step": [
    {
      "@type": "HowToStep",
      "name": "進入登入頁",
      "text": "開啟登入頁面，點選密碼欄位下方的「忘記密碼」連結。"
    },
    {
      "@type": "HowToStep",
      "name": "輸入電子郵件",
      "text": "填入帳號綁定的電子郵件，按下「寄送重設連結」。"
    },
    {
      "@type": "HowToStep",
      "name": "設定新密碼",
      "text": "點開信件裡的重設連結，輸入兩次新密碼確認後送出。"
    }
  ]
}
</script>Code language: HTML, XML (xml)

第二步，替步驟加上順序需要的細節。注意 step 後面一定要用中括號 [] 包成陣列，就算只有一步也一樣——這是很多人漏掉、導致驗證失敗的地方。每個步驟除了 name 和 text，還可以加 url（連到頁面上該步驟的錨點）和 image（該步驟的示意圖），這兩個都選填，但加了能讓機器對應得更精準。

第三步，視內容補上時間、材料與工具。如果你的教學是偏實作的（例如「在本機架一個開發環境」），補上 totalTime、supply、tool 會讓標記語意更完整。一份較完整的版本會像這樣（這裡只示範新增的欄位，step 同上）：

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "如何架設本機開發環境",
  "totalTime": "PT45M",
  "estimatedCost": {
    "@type": "MonetaryAmount",
    "currency": "TWD",
    "value": "0"
  },
  "tool": [
    { "@type": "HowToTool", "name": "Node.js" },
    { "@type": "HowToTool", "name": "Git" }
  ],
  "supply": [
    { "@type": "HowToSupply", "name": "穩定的網路連線" }
  ],
  "step": [ ... ]
}Code language: JSON / JSON with Comments (json)

第四步，流程很長時用 HowToSection 分階段。有些流程天生分好幾個階段，例如「準備、部署、驗證」。這時可以用 HowToSection 把步驟分組，每個 section 底下放自己的 itemListElement，裡面才是各個 HowToStep。它的好處是讓 AI 理解「這是一個有大階段、再分小步驟」的複雜流程，而不是把十幾步攤成一長條。

最後一個觀念叫 @id。當你的頁面同時有 HowTo、文章、麵包屑等多種結構化資料時，給 HowTo 一個 @id 並用 mainEntityOfPage 連到頁面實體，能避免「孤島式標記」——也就是各塊 schema 各自為政、彼此不關聯。把它們串起來，機器才看得出這些資料描述的是同一個頁面、同一件事。

WordPress 怎麼設定 HowTo Schema 不用碰程式碼

如果你的網站是 WordPress，好消息是你多半不用手刻 JSON-LD。目前主流的 SEO 外掛內建了 schema 功能，能用點選的方式產生 HowTo 標記，省去自己寫程式的麻煩。

第一步，確認你的 SEO 外掛有沒有 HowTo 區塊。即使 Google 已經下架步驟卡片，部分外掛至今仍保留 HowTo 的 Gutenberg 區塊與 schema 產生器，讓你能把符合結構的 HowTo 內容直接寫進文章。要注意區塊與產生器的差別——區塊通常只在 Gutenberg 編輯器裡用，而 schema 產生器能搭配傳統編輯器、頁面建構器等任何環境，適用範圍更廣。

第二步，把步驟內容填進區塊或產生器。操作邏輯都一樣——選 HowTo 類型，填入流程標題、描述，再逐一新增每一個步驟的標題與內文，需要的話補上每步的圖片、整體預估時間。外掛會在後台替你把這些欄位轉成合規的 JSON-LD，輸出到頁面原始碼裡。

第三步，務必讓「標記的步驟」跟「頁面看得到的步驟」一致。這是結構化資料的鐵律，也是 Google 政策明文要求的——你的 JSON-LD 宣稱有八步，頁面上就得真的看得到那八步。標記了頁面上不存在的內容、或步數對不上，輕則被忽略，重則被視為違反垃圾內容政策。所以正確順序是先把文章正文的步驟寫好、寫完整，再用外掛去「描述」這些已經存在的步驟，而不是反過來為了標記硬湊。

如果你不是用 WordPress，或想要完全掌控輸出，手動把上一節那段 JSON-LD 貼進頁面的 <head> 也完全可行。兩種做法產出的標記沒有高下之分，差別只在維護方式——外掛適合不想碰程式碼、希望內容與標記綁在一起更新的人；手動則適合需要客製、或要串接 @id 做複雜實體關聯的情況。

設定完怎麼驗證？又有哪些常見錯誤要避開

寫完別急著上線，先驗證。雖然 Google 不再提供 HowTo 專屬的複合式結果預覽，但「機器能不能正確解析你的標記」這件事還是要確認。用 schema.org 官方的 Schema Markup Validator（結構化資料驗證工具）貼上你的程式碼或網址，它會檢查整份標記符不符合 schema.org 詞彙——抓出拼錯的欄位名、型別放錯（該放物件卻放了字串）、缺漏必填欄位、時長格式寫錯、巢狀結構錯誤這些問題。

要提醒的是，Google 的 Rich Results Test 自從下架 HowTo 之後，就不再針對 HowTo 給專屬回饋了，它頂多把你的標記當成一般結構化資料解析，不會生成 HowTo 預覽，所以驗證請以 schema.org 的驗證工具為準。上線後，可以到 Search Console 的「無法剖析的結構化資料」報表，看 Google 有沒有在解析你的 JSON-LD 時遇到錯誤，每次改完模板都值得回去看一眼。

接著是幾個出現頻率最高、卻最容易自己看不出來的錯誤，逐一避開：

  1. 時間格式寫成人看的字串。把「30 分鐘」直接填進 totalTime 一定被退，要寫 PT30M。這是新手第一名的錯。
  2. step 漏了中括號。就算只有一個步驟，也得用 "step": [ { ... } ] 的陣列語法，少了中括號驗證直接不過。
  3. 標記步驟與頁面內容對不上。JSON-LD 寫八步、文章只看得到六步，違反 Google 政策，可能招來人工處罰。
  4. 把必要指示跟選填提醒搞混。HowToDirection 標的是「使用者一定要做」的必要動作，HowToTip 標的是「可做可不做」的建議。判斷法很簡單——跳過它會不會讓流程失敗？會就是 Direction，不會就是 Tip。
  5. 費用寫成純字串。"$150" 雖然能過驗證，卻丟失了幣別與數值的結構，要用 MonetaryAmount 物件分開寫。
  6. 拿 HowTo 去標食譜。「如何做巧克力蛋糕」聽起來像 HowTo，其實該用 Recipe，否則就放棄了食材、營養、烹調時間這些專屬欄位與對應的複合式結果資格。
  7. 期待它變出步驟卡片。HowTo 複合式結果在 2023 年 9 月已全面下架，現在它服務的是 AI 抽取、語音助理與機器理解，不是搜尋頁上的視覺版位。帶著「設了就會跳卡片」的期待去做，只會失望。

避開這七個，你的標記在語意上就乾淨了。剩下的，就是回到內容本身——標記只是把好內容講給機器聽，它沒辦法替平庸的步驟教學加分。

把這篇文章倒過來看，你已經讀完一次 HowTo 示範

回頭看你剛剛讀過的這幾節——「是什麼」「為什麼做」「有哪些欄位」「怎麼寫範本」「WordPress 怎麼設」「怎麼驗證」——它們之間有明確的先後依賴，你得先懂欄位，才寫得出範本；先有範本，才談得上 WordPress 化與驗證。這種「後面靠前面、順序不能亂」的結構，正是 HowTo Schema 存在的理由，也是 AI 在回答「HowTo Schema 怎麼做」時，最希望從一篇文章裡抽出來的東西。

所以與其把結構化資料當成一個要額外應付的技術項目，不如換個角度——它其實是逼你把教學的骨架想清楚的工具。當你能用 HowTo 把每一步乾淨地標出來，通常意味著你的內容本身就已經夠有條理、夠值得被引用了。下一篇你寫的步驟教學，不妨在動筆時就先問自己一句，這個流程調換順序會不會壞？如果不會，它根本不該是 HowTo；如果會，那就把每一步的標題與內文都寫扎實，讓機器和人，都能一步不漏地照著走。

延伸閱讀