多數人以為 Google 在 2023 年拿掉 HowTo 步驟卡片之後，這段標記就沒必要做了。事實是，2026 年 5 月，Google 又用幾乎一樣的手法，把 FAQ 的複合式搜尋結果也收掉了。這兩件事說明的不是「結構化資料沒用」，而是它的舞台換了。你可能也遇過這種情況，同一篇教學文，步驟寫得清清楚楚，丟去問 ChatGPT 或 Google 的 AI 摘要，被引用的卻是別人那篇看起來更陽春的文章，差別常常不在內容好不好，而在機器讀不讀得懂你的步驟順序。
這份結構說明，就是 HowTo Schema（操作指南結構化資料），一段用 JSON-LD 寫的標記，告訴搜尋引擎與 AI「這是一個有先後順序的流程，總共幾步、每步在做什麼」。它不改變讀者看到的畫面，只在背後把步驟一條一條交代清楚。當 AI 引擎要回答「怎麼做某件事」的問題時，一篇把步驟結構標明白的頁面，等於直接遞給它一份不必自己推論的流程圖，這正是它現在真正值錢的地方。
這篇會把 HowTo Schema 該懂的欄位、能直接套用的完整 JSON-LD、WordPress 上不用寫程式的設定方式，一路做到驗證避雷全部講完。先從它跟一般教學文的差異講起，再一步步把骨架寫成完整的標記。
HowTo Schema 是什麼？跟一般教學文有什麼差異？
HowTo 是 schema.org 詞彙表裡，專門描述「一步步達成結果的流程」的一種類型。安裝軟體、設定外掛、組裝家具都算，只要用它包住一段操作教學，就能把整個流程的名稱、每一個步驟、需要的工具與材料、預估花費時間，全部轉成機器讀得懂的格式。
它跟一般文章最大的不同，在於把「順序」這件事明說了。想像工廠生產線牆上貼的作業指導書，每一步都編了號，新人一看就知道現在該做第幾件事，不用自己回頭猜前一步做完了沒。一篇沒有結構化資料的教學文，對人類讀者來說一樣看得懂 1、2、3，但機器看到的只是一堆 HTML 標籤，它沒辦法百分之百確定哪段是第三步、哪段只是補充說明。HowTo Schema 等於替每個步驟貼上號碼牌，讓 AI 不必靠猜。
HowTo 跟 FAQPage、Recipe 常被搞混，一句話分辨
判斷該不該用 HowTo 很簡單，自問一句「把這些項目的順序打亂，內容會不會壞掉」就好。拿網站搬遷來說，先備份、再匯入新主機、最後才改 DNS，這個順序一旦反了，網站就會出問題，這就是 HowTo 的工作，步驟彼此依賴，後面靠前面。但如果你要標的是一組各自獨立的問答，比如「搬遷會不會影響 SEO 排名」「搬完多久網站才會恢復正常」，誰先誰後都不影響讀者理解，這時候該用的是 FAQPage，不是 HowTo。
還有一個例外要記住，如果流程的產出物是食物，一律改用 Recipe。「如何做巧克力蛋糕」聽起來像 HowTo，但 Recipe 有專屬的食材、份量、烹調時間欄位，把食譜硬標成 HowTo，等於放棄了這些更貼切的欄位。
步驟卡片被拿掉，不代表 HowTo Schema 沒用了
先把時間軸講清楚，省得被「已淘汰」三個字嚇退。2023 年 8 月，Google 先把 HowTo 複合式搜尋結果限縮到只剩桌機版顯示，等於先拿掉了行動裝置那一半；到了 9 月，Google 乾脆連桌機版也一起下架，HowTo 複合式結果全面停用，Rich Results Test 不再產生 HowTo 預覽，Search Console 裡的 HowTo 報表也跟著移除。
這個模式後來又重演一次，而且時間點更近。2026 年 5 月，Google 用幾乎一樣的手法對待 FAQ，先在結構化資料文件加上棄用聲明，FAQ 複合式結果從 5 月 7 日起不再顯示於搜尋結果，6 月接著把相關文件、報表跟 Rich Results Test 裡的支援一併拿掉。把這兩件事放在一起看就會發現，Google 在做的是持續簡化搜尋結果版面，跟某段標記本身有沒有價值，是兩回事。
真正的價值，在 AI 搜尋這端冒出來了。當 ChatGPT、Perplexity 或 Google 的 AI 摘要要回答「怎麼做某件事」的問題時，它們得先把內容拆解、重組成步驟。一篇把步驟結構明白標出來的頁面，等於直接遞給 AI 一份不必自己推論的流程圖；沒有它，AI 得從上下文自己猜哪段是第幾步。
不過這裡得誠實補一句，免得抱著錯誤期待去做。Ahrefs 在 2026 年 5 月的一份研究，追蹤了 1,885 個在 2025 年 8 月到 2026 年 3 月之間新加上 JSON-LD 的頁面，拿去跟 4,000 個沒加的對照頁面比較，結果 Google AI Mode 只多了 2.4%、ChatGPT 只多了 2.2%，兩個數字在統計上都跟零沒有明顯差異，Google AI Overviews 甚至還掉了 4.6%。
而且這份研究本身有個但書值得注意。研究對象本來就是已經被 AI 大量引用的頁面，對於完全沒被 AI 看見的新頁面，加了標記會不會有幫助，這份研究沒測到。換句話說，HowTo Schema 是讓機器更準確理解你內容的基礎建設，不是一顆按了就漲引用率的按鈕。
最後更正一個常見的誤解，語音助理會不會照著念步驟，靠的其實是 Speakable 這個獨立的結構化資料類型，它專門標記「這段適合被朗讀」的內容，HowTo 本身沒有自動具備朗讀能力。兩者可以搭配著用，但別以為裝了 HowTo，語音助理就自動會念你的步驟。
動手寫之前，先弄懂必填和選填欄位
要動手寫之前，先把欄位的層級搞清楚，這樣才知道哪些非填不可、哪些是錦上添花。整個 HowTo 類型的必填欄位其實只有兩個，其餘十幾個都是選填，但選填的那些才是讓標記語意完整的關鍵。
下面這張表整理了最常用的欄位，先看必填，再看你的內容適合補哪些選填。
| 欄位 | 型別 | 是否必填 | 作用 |
|---|---|---|---|
| name | 文字 | 必填 | 這個流程的名稱 |
| step | HowToStep 陣列 | 必填 | 定義整個步驟序列，是 HowTo 的核心 |
| description | 文字 | 選填 | 一句話的流程摘要 |
| totalTime | Duration | 選填 | 完成整個流程預估要花的時間 |
| estimatedCost | MonetaryAmount | 選填 | 預估花費 |
| supply | HowToSupply 陣列 | 選填 | 會用掉的耗材或材料 |
| tool | HowToTool 陣列 | 選填 | 會用到、但不會用掉的工具 |
| image | ImageObject 或 URL | 選填 | 流程主圖 |
step 是整份標記的靈魂，它是一個 HowToStep 物件組成的陣列，而且一定要用中括號包起來，就算只有一步也一樣，這是很多人漏掉、導致驗證失敗的地方。
這裡有個新手最常踩的地雷，先講在前面。所有時間欄位都得用 ISO 8601 的時長格式，不能直接寫「30 分鐘」。30 分鐘要寫成 PT30M，1 小時是 PT1H，1 小時半是 PT1H30M，一天是 P1D。規則是 P 開頭代表一段期間、T 後面接時間單位，寫成人看得懂的「30 minutes」，驗證工具會直接打回票。
同樣地，費用也不能只寫 “$150″，要用 MonetaryAmount 物件把幣別與數值分開，機器才處理得了，寫法像這樣。
"estimatedCost": {
"@type": "MonetaryAmount",
"currency": "TWD",
"value": "500"
}Code language: JSON / JSON with Comments (json)從最小骨架開始，一步步寫出完整 JSON-LD
觀念講完，來實作。JSON-LD 的最大優點，是它是一段獨立的程式碼，包在 <script type="application/ld+json"> 標籤裡，放進頁面的 <head> 或 <body> 底部都行，完全不用動到原本的 HTML 內容，後續維護也方便。下面從最精簡的版本，一路加到含分階段、時間材料工具的完整版，示範主題統一用「把 WordPress 網站搬到新主機」這件事。
第一步：只用 name 和 step 建立最小可行版本
一份能通過驗證的 HowTo，最少只需要 name 跟 step。假設要寫一篇「把網站搬到新主機」的三步驟教學，骨架長這樣。
{
"@context": "https://schema.org",
"@type": "HowTo",
"name": "如何把 WordPress 網站搬到新主機",
"description": "備份、匯入、更新網域指向，三個步驟把網站搬到新主機。",
"step": [
{
"@type": "HowToStep",
"text": "備份現有網站的所有檔案與資料庫，下載保存，避免搬遷過程中資料遺失。"
},
{
"@type": "HowToStep",
"text": "把備份檔案上傳到新主機，建立新的資料庫並匯入資料，更新網站設定檔裡的資料庫連線資訊。"
},
{
"@type": "HowToStep",
"text": "把網域的 DNS 記錄改指向新主機，等待全球 DNS 更新完成後確認網站顯示正常。"
}
]
}Code language: JSON / JSON with Comments (json)這份骨架已經能通過驗證，先有一個能動的版本，再往下一步一步加細節。
第二步：替每個步驟補上 name、text，讓 AI 對答案更精準
HowToStep 裡的 name 和 text 各司其職，name 是短標籤，AI 在抽「第三步是什麼」的答案時會直接對應到它；text 才是完整的操作說明。只給 text 也能成立，但兩個都給，AI 會對應得更精準。比如剛剛的第一步，補上 name 之後會變成這樣。
{
"@type": "HowToStep",
"name": "備份現有網站",
"text": "備份現有網站的所有檔案與資料庫，下載保存，避免搬遷過程中資料遺失。"
}Code language: JSON / JSON with Comments (json)其餘兩步照同樣邏輯補上 name（「匯入新主機」「更新網域 DNS」）。除了 name 跟 text，每個步驟還能加 url（連到頁面上該步驟的錨點）和 image（該步驟的示意圖），這兩個都選填，但加了能讓機器對應得更精準。
第三步：流程分階段就用 HowToSection
有些流程天生分好幾個大階段，像網站搬遷就至少分「動手前的準備」跟「正式搬遷」兩段，這種情況可以用 HowToSection 把步驟分組，每個 section 底下放自己的 name 跟 itemListElement，裡面才是各個 HowToStep。
{
"@context": "https://schema.org",
"@type": "HowTo",
"name": "如何把 WordPress 網站搬到新主機",
"step": [
{
"@type": "HowToSection",
"name": "搬遷前準備",
"itemListElement": [
{
"@type": "HowToStep",
"name": "備份現有網站",
"text": "備份所有檔案與資料庫，確認備份檔案完整可還原。"
},
{
"@type": "HowToStep",
"name": "記錄現有外掛與設定",
"text": "列出目前啟用的外掛版本與佈景主題設定，方便搬遷後逐一核對。"
}
]
},
{
"@type": "HowToSection",
"name": "正式搬遷",
"itemListElement": [
{
"@type": "HowToStep",
"name": "匯入新主機",
"text": "把備份檔案上傳到新主機，建立資料庫並匯入，更新資料庫連線設定。"
},
{
"@type": "HowToStep",
"name": "更新網域 DNS",
"text": "把網域的 DNS 記錄改指向新主機，等待全球 DNS 更新完成後確認網站正常。"
}
]
}
]
}Code language: JSON / JSON with Comments (json)用 HowToSection 的前提是流程真的有天然的階段感，不要為了用這個欄位硬把步驟拆成好幾組，那樣機器讀到的階段跟頁面實際的結構對不上，反而失去語意上的意義。
第四步：時間、材料、工具怎麼標最完整
如果流程偏實作，補上 totalTime、supply、tool 會讓標記語意更完整。totalTime 與 estimatedCost 看似可有可無，但它們是 AI 在回答「這要花多久、要花多少錢」時最想抓的中繼資料，對操作型教學特別加分。
幾個選填欄位值得特別講。supply 標的是會被用掉的耗材，tool 標的是重複使用的工具，一個用完就沒、一個用完還在，分清楚這層差別，機器才知道做這件事到底要準備什麼。用搬遷網站舉例，寫法像這樣。
"totalTime": "PT2H",
"tool": [
{ "@type": "HowToTool", "name": "FTP 用戶端" },
{ "@type": "HowToTool", "name": "資料庫管理工具" }
],
"supply": [
{ "@type": "HowToSupply", "name": "新主機的暫存空間" }
]Code language: JSON / JSON with Comments (json)supply 還能再加 requiredQuantity 標出數量，讓語意更完整，但沒有真的需要標數量的情境，就別為了填滿欄位硬湊。
用 HowToDirection 和 HowToTip，分清楚「一定要做」跟「建議做」
HowToDirection 標的是使用者一定要做的必要動作，HowToTip 標的是可做可不做的建議，兩者都放在某個 HowToStep 底下的 itemListElement 陣列裡，用 position 排序先後。判斷法很簡單，跳過它會不會讓這一步失敗，會就是 Direction，不會就是 Tip。
拿「更新網域 DNS」這步驟來說，寫法像這樣。
{
"@type": "HowToStep",
"name": "更新網域 DNS",
"itemListElement": [
{
"@type": "HowToDirection",
"position": 1,
"text": "DNS 生效前先別關閉舊主機，兩邊同時保留運作，直到確認新主機上的網站顯示正常再停用舊主機。"
},
{
"@type": "HowToTip",
"position": 2,
"text": "可以提前把網域的 DNS TTL（存活時間）調低，縮短轉換期間的等待時間。"
}
]
}Code language: JSON / JSON with Comments (json)同時保留兩邊運作是必要動作，跳過它，DNS 還沒完全生效前網站就可能中斷，這是 Direction；調低 TTL 只是讓轉換更順一點，不做也不會出事，這是 Tip。
有個容易漏掉的細節。一旦某個 HowToStep 用 itemListElement 放了 Direction 或 Tip，父層的 HowToStep 就不要同時再放 text。兩邊都寫，等於同一個步驟有兩份互相獨立的說明，機器不知道該讀哪一份，反而製造混淆。
WordPress 不用手刻 JSON-LD，外掛怎麼設定？
如果網站是 WordPress，多半不用自己寫程式。主流的國際 SEO 外掛，像 Yoast SEO、Rank Math 這類，內建了 Schema 產生器，能用填欄位的方式產生合規的 HowTo 標記，省去自己寫程式的麻煩。
操作邏輯都差不多，選 HowTo 類型，填入流程標題與描述，再逐一新增每個步驟的標題與內文，需要的話補上每步的圖片、整體預估時間。外掛會在後台替你把這些欄位轉成合規的 JSON-LD，輸出到頁面原始碼裡。
務必先把文章正文的步驟寫好、寫完整，再用外掛去描述這些已經存在的步驟，不是反過來為了標記硬湊步驟，這個順序不能顛倒。這不只是最佳實務，是 Google 結構化資料規範明文要求的。標記的內容必須對應頁面上讀者真的看得到的內容，標了頁面不存在的東西屬於隱藏式標記，會被視為違反內容政策，輕則被忽略，重則觸發人工判定。你的 JSON-LD 宣稱有三個步驟，頁面上就得真的看得到那三步。
不想用外掛，或想完全掌控輸出，手動把上面那些 JSON-LD 貼進頁面的 <head> 也完全可行。兩種做法產出的標記沒有高下之分，差別只在維護方式：外掛適合不想碰程式碼、希望內容與標記綁在一起更新的人；手動則適合需要客製、或要串接多種結構化資料做複雜關聯的情況。
寫完先驗證，這幾個地雷最容易讓標記白做
寫完別急著上線，先驗證。雖然 Google 不再提供 HowTo 專屬的複合式結果預覽，但「機器能不能正確解析你的標記」這件事還是要確認。用 schema.org 官方的 Schema Markup Validator 貼上程式碼或網址，它會檢查整份標記符不符合 schema.org 詞彙，抓出拼錯的欄位名、型別放錯（該放物件卻放了字串）、缺漏必填欄位、時長格式寫錯、巢狀結構錯誤這些問題。
上線後，可以到 Search Console 的無法剖析的結構化資料報表，看 Google 有沒有在解析你的 JSON-LD 時遇到錯誤，每次改完模板都值得回去看一眼。
接著是幾個出現頻率最高、卻最容易自己看不出來的錯誤，逐一避開：
- 時間格式寫成人看的字串。把「30 分鐘」直接填進 totalTime 一定被退，要寫 PT30M，這是新手第一名的錯。
- step 漏了中括號。就算只有一個步驟，也得用
"step": [ { ... } ]的陣列語法，少了中括號驗證直接不過。 - 標記步驟與頁面內容對不上。JSON-LD 寫三步、文章只看得到兩步，違反 Google 政策，可能招來人工判定。
- HowToStep 同時放 text 又放 itemListElement。兩份說明互相打架，機器不知道該讀哪一份，這點前面已經提醒過，很容易被忽略。
- 把 supply 跟 tool 搞混。耗材跟工具分不清楚，機器就沒辦法正確判斷這件事到底要消耗什麼、又要準備什麼。
- 費用寫成純字串。”$150″ 雖然能過驗證，卻丟失了幣別與數值的結構，要用 MonetaryAmount 物件分開寫。
- 拿 HowTo 去標食譜。「如何做巧克力蛋糕」聽起來像 HowTo，其實該用 Recipe，否則就放棄了食材、份量、烹調時間這些專屬欄位。
避開這七個，標記在語意上就乾淨了。剩下的，是回到內容本身。驗證只能抓語法有沒有寫對，抓不出步驟本身寫得夠不夠扎實，標記從來不是內容品質的替代品。
步驟卡片會被拿掉，FAQ 的複合式結果也會被拿掉，Google 還會繼續拿掉哪些視覺呈現，沒有人說得準。但可以確定的是，AI 讀懂步驟順序的需求只會愈來愈重——這代表 HowTo Schema 的價值判準，已經從「會不會跳出漂亮版位」換成「機器讀不讀得懂你的流程」。
下一次你動筆寫一篇步驟教學，不妨先問自己一句，這個流程調換順序會不會壞？如果不會，它根本不該是 HowTo；如果會，那就把每一步的標題與內文寫扎實，標記只是把已經想清楚的流程，用機器聽得懂的格式再講一次，不是內容不夠時的補救措施。