食譜結構化資料產生器（Recipe schema）

食譜結構化資料怎麼產生

Recipe 的屬性之間互相牽制得特別多。產生器用同一組值寫出標記和食譜卡，並回報它看得到的每一個矛盾。

1. 寫上菜名，加一張照片。 這兩個是必要屬性。照片要是完成的那道菜，網址要能被檢索——Google 建議同一張照片給幾種不同的長寬比。
2. 時間要成對給。 要嘛給總時間，要嘛備料和烹調時間一起給。直接寫分鐘數就好，輸出一律是 ISO 8601。
3. 熱量綁定份量。 熱量是以每份計算的，只有熱量、沒有份數的數字是不完整的。Google 用一句話寫明了這個要求，所以產生器把它當成錯誤。
4. 食材和作法一行一項。 一行一個食材、一行一個步驟。每個步驟變成一個 HowToStep——Google 建議這樣寫，而不是交給它自己去切一整段文字。
5. 兩份輸出都貼上。 JSON-LD 放進食譜頁；食譜卡帶著同樣的食材、同樣的步驟——這一點在食譜上特別要緊，因為食材和步驟正是這份標記的主體。

三個時間屬性，合法的組合只有兩種

食譜結構化資料產生器會把一道食譜轉成 Recipe 的 JSON-LD——也就是 Google 用來讀取食材、作法、時間與營養的結構化資料。必要屬性只有兩個：name 和 image（完成菜餚的照片）。有意思的事都發生在建議屬性之間，因為其中好幾個只能結伴出現。

Google 繁中文件在 cookTime 寫的是「一律與 prepTime 搭配使用」，在 prepTime 寫「一律與 cookTime 搭配使用」，在 totalTime 寫「請使用 totalTime，或同時使用 cookTime 和 prepTime」。所以合法的形狀只有兩種，常見的違規有一種：

三個屬性都要 ISO 8601 時間長度——PT1H30M，不是「一個半小時」。這個表單接受你習慣的寫法——直接寫分鐘數（35）、「15 分鐘」、「1 小時 30 分」、1:30 或 ISO 字串——一律輸出 ISO 格式；讀不懂的（例如「十五分鐘」這種國字數字）會直接報錯，不會亂猜。

還有一件事不是 Google 的規則，特別說清楚：totalTime 不必等於 prepTime 加 cookTime。醃漬、冷藏、發酵、靜置，都是真實存在的時間。這個工具在總時間小於兩者相加時仍然會警告——那是算術，不是政策，而且通常是打錯字。

大匙、小匙、公克照台灣的寫法；份量只寫數字

recipeIngredient 是純文字，Google 對它的要求只有兩句：只包含製作食品所需的食材文字；不要加入非必要的資訊，例如食材的定義。單位怎麼寫，Google 沒有規定——台灣的食譜，照台灣的寫法就好。

看看台灣食譜網站自己怎麼標。愛料理的首頁寫著 30 萬道食譜；我們抽看的五頁食譜都輸出 Recipe 的 JSON-LD，食材是「醬油 1大匙」「可可粉 1茶匙」「太白粉 少許」「牛奶 640ml」「無鹽奶油 150克」這樣的寫法，有步驟的都寫成一個個 HowToStep，有標份量的都是單純的數字 3 和 8。這幾點，剛好都是 Google 要的形狀。

• 份量只寫數字。Google 的原文：指定這道食譜可製作幾人份的料理，只能使用數字；想用其他單位（例如幾「個」），可以另外加入。表單只檢查開頭是不是數字，所以「4 人份」也會過，但最乾淨的寫法就是 4。
• 熱量和份量是同一件事。Google 寫：如果已定義 nutrition.calories，recipeYield 就必須以料理的數量來定義。每份 450 大卡，卻不說一鍋是幾份，這個數字就沒有意義；所以產生器把「有熱量、沒份量」當成錯誤，不只是提醒。
• 食材只寫食材。「九層塔 1 把」是食材；「九層塔（又叫羅勒，傳統市場買比較便宜）」後半段是頁面內容，不屬於標記。

步驟不寫「步驟 1」，關鍵字不重複類別

recipeInstructions 有三種寫法，效果不一樣。一整塊文字，Google 會自己試著切成步驟，並試著找出、移除區段名稱與步驟編號——它把話說在前頭，建議你用 HowToStep 明確指定。HowToStep 清楚標出每一步從哪裡開始；HowToSection 則用在食譜真的分成幾個部分的時候，例如麵團、內餡、淋醬。

這個產生器一行寫成一個 HowToStep，也照著 Google 的另一條規則：只能加入如何製作的文字，不要加入「指示」「觀看影片」「步驟 1」這些詞組。編號屬於標記的順序，不屬於句子。有一點要說清楚：產生器會標出英文的 Step 1、Directions、Watch the video，以及中文的「步驟 1」；「步驟一」「作法：」這類變化形它不一定認得出來，貼上前自己再看一眼。

關鍵字有一條同樣精神的規則。Google 說 keywords 是額外的詞——季節（「夏天」）、節日（「萬聖節」），或「快速」「簡易」「道地」這類形容——並且「請勿使用其實是 recipeCategory 或 recipeCuisine 的標記」。類別放「晚餐」「主菜」「甜點」「零食」這種詞，料理地區放「台灣」「法國」「地中海」；同一個詞再出現在 keywords 裡，產生器會標出來。關鍵字請用半形逗號分隔，那是 Google 範例的寫法，也是產生器切字的依據。

食材和作法這兩份清單，同時變成可見的食譜卡和標記，來源是同一個陣列——讀者看到的，和 Google 解析的，是同一串字。這就是第二份輸出的用意，和 FAQ schema 產生器背後是同一條規則。

評分和食譜影片：接下來通常會加的兩樣

一個食譜頁通常還會長出兩樣東西，而兩樣的規則都住在別的地方。

評分。aggregateRating 是 Recipe 的建議屬性，完全照評論摘錄規範走：ratingCount 或 reviewCount 至少一個、不搬運其他網站的平均分數、不放未揭露獎勵關係的評論。Google 的結構化資料通用指南在這裡說得更重：使用者偏好有實際使用者評論和星級評分的食譜，但不是由實際使用者給的評論或評分，可能導致人工判決處罰。食譜只有一則評論時，評論者必須是有效的個人或機構——Google 舉的反例是「食材半價」。這些規則的完整檢查，在 評論摘錄結構化資料產生器。

影片。video 放的是一個完整的 VideoObject，必要屬性和任何影片一樣：不重複的標題、固定網址的縮圖、最好帶著時區的上傳日期。還有一條順序：Google 說，網頁的主要內容是食譜時，除了影片和評論的結構化資料，務必也加入食譜結構化資料——只有影片標記的頁面，不會被顯示成食譜複合式搜尋結果。影片標記本身，交給 影片結構化資料產生器。