餐飲業者必讀！揭秘 GPO/GEO 搜尋核心機制。為何美味照片救不了你？掌握營業時間與菜單結構化 (Schema.
當客人在 AI 視窗輸入「附近好吃的日式拉麵」，你的店家好不容易出現在搜尋結果中，旁邊還配著精緻的高畫質照片，卻被系統標記為「不確定選項」。這不是因為照片拍得不夠誘人，而是對搜尋引擎來說，那張照片只是一堆無法解讀的像素。AI 不像人類，看一眼色香味俱全的菜單就會流口水；它需要的是能驗證的事實、可結構化的實體關係，以及能回答「現在有開嗎？」、「有推薦什麼？」這類具體問題的信任訊號。
這也是餐飲業在做 GEO（生成式引擎優化）時最常遇到的盲點：直接把舊的 SEO 套路硬塞給 AI。以前大家習慣花大錢請攝影師拍精美菜單、拍宣傳影片，一心想讓 Google 覺得「這家店看起來很好吃」。但在 ChatGPT、Perplexity 或 Gemini 的運作邏輯裡，一張 JPEG 圖檔對它們理解「這家店到底在賣什麼」幾乎毫無幫助，除非你主動把這些視覺畫面，轉譯成機器看得懂的結構化語言。
TrueLink 在協助眾多餐飲品牌規劃 GEO 的過程中，發現一個很有意思的現象：那些經常被 AI 引用、甚至直接推薦給使用者的店家，往往不是照片拍得最漂亮的那間，而是把「營業時間」、「菜單品項」與「地理位置」這三項基礎資料，結構化做得最乾淨、最完整的店。當客人問「現在附近還有開門、好吃的拉麵嗎？」，AI 優先抓取的是能立刻對應時間、地點與具體品項（例如「豚骨拉麵」、「辣味雞白湯」）的資料，而不是一張精美的靜態照片。
現在餐飲品牌的數位信任基礎，不再只是看你砸了多少預算做視覺包裝，而是看你願不願意把那些「看似瑣碎卻非常關鍵」的營運細節——像是營業時間、菜單結構化、作者與店家實體連結——老老實實地轉譯成 AI 讀得懂的語言。這代表網路行銷的重點，已經從過去的「讓人看見」，轉變為現在的「讓機器看懂」。
為什麼高畫質照片在 AI 搜尋中只是裝飾？
很多餐廳老闆覺得，只要把高質感的食物照放上官網，AI 就會自動判定這家店很厲害、值得推薦。但實際上，目前的生成式引擎（Generative Engines）本質上是「資訊整合與重組系統」，而不是靠看圖說故事的瀏覽器。它們讀取網頁時，會先去解析背後的結構化資料（Schema.org），理清各個實體之間的關係，最後才會把圖片當作輔助佐證。
當 AI 收到使用者的詢問，它會先去翻找資料庫裡的「知識圖譜」。如果你的網站上只有一堆散落的圖片標籤，像是 <img alt="美味拉麵">，卻沒有對應的 MenuItem、Restaurant 或 OpeningHoursSpecification 等結構化標記，AI 就沒辦法把這張照片，跟你的營業時間、地址，甚至是「辣度」或「素食」等標籤綁在一起。對 AI 來說，這只是一張沒有身分證的孤立圖片，它根本不知道這是哪家店的菜，更不知道客人現在點不點得到。
我們在實務上碰過很多這種例子：有一家裝潢極有質感的日式燒肉店，官網上的食物攝影水準極高，但當客人在附近問 AI「有沒有推薦聚餐的燒肉店」時，AI 卻推薦了另一家照片普通、但菜單結構完整且營業時間標示極為清晰的競爭對手。這不是因為照片輸了，而是因為 AI 根本無法從前者的網站裡，抓到「現在有營業」、「有提供雙人套餐」等可以立即驗證的關鍵資訊。在我們協助該燒肉店補齊結構化資料並完成實體綁定後，根據去識別化的追蹤觀測，該店在主要 AI 搜尋引擎（如 Perplexity、ChatGPT Search）的相關情境推薦頻次，在優化後的三個月內預估提升了約 40%（此數據為特定案例之觀測結果，實際成效可能因個別店家權重與在地競爭度而異）。
兩者的核心差異在於：
- 傳統搜尋（SEO）的邏輯： 圖片是吸引眼球、爭取點擊的關鍵，搭配 alt 屬性與周邊文字來累積搜尋權重。
- 生成式搜尋（GEO）的邏輯： 圖片只是用來佐證體驗的「配角」；結構化資料才是決定你的店能不能被 AI 推薦的「主角」。
如果網站只有漂亮的視覺包裝，卻少了結構化資料的支撐，在 AI 眼中，你的店就像一個穿著華麗禮服卻沒有身分證的人——看起來很體面，但系統根本無法確認你的身分。這也解釋了為什麼許多餐廳砸了大筆預算拍美照，卻在 AI 搜尋結果中直接「隱形」。
營業時間與菜單：AI 決策的「剛性結構化」基礎
在生成式搜尋的時代，消費者最常問的往往不是空泛的「這家店好不好吃」，而是非常實際的具體問題，像是：「現在有開嗎？」、「有沒有素食？」、「大概要花多少錢？」。要回答這些問題，AI 必須依賴嚴謹的結構化資料（Structured Data），而不是網頁上那些感性的描述文字或圖片。
Google 和各大 AI 引擎在處理餐飲相關的搜尋時，最優先抓取的就是 OpeningHoursSpecification 與 Menu（包含 MenuItem）這兩組 Schema。對機器來說，這些數據是不能妥協的「硬規則」。要是這些欄位漏掉、格式寫錯，或者你的單頁式網頁（SPA）沒有做好 SSR（伺服端渲染）把資料吐出來，AI 就會直接把你的店貼上「資訊不完整」或「無法驗證」的標籤，轉而推薦其他資料更齊全的競爭對手。
營業時間：即時性的生死線
當客人問 AI「附近好吃的拉麵店現在還有開嗎？」，系統會立刻去比對資料庫裡的 OpeningHours。如果你的營業時間是做在一張精美的海報圖片裡，或者只是寫在網頁角落的純文字、沒有任何 Schema 標記，AI 就無法判定「當下」到底有沒有開門。
- 別再這樣做： 在首頁放一張寫著營業時間的 Banner 大圖，或只在頁尾用純文字打上一週營業時間。
- 建議這樣做： 採用 JSON-LD 的
OpeningHoursSpecification格式，清清楚楚標示每週每一天的營業時段、特殊節日調整（例如除夕公休），並確保這些資料能透過 SSR 直接呈現在原始 HTML 原始碼中。
菜單結構化：從「視覺清單」到「實體屬性」
AI 必須先搞懂你的菜單上到底賣的是「什麼東西」。當客人問「有沒有辣的豬排飯？」或「哪些餐點不含過敏原？」，系統需要將 MenuItem 與它的屬性（例如 spicyLevel、allergenInfo、priceRange）進行精準比對。
- 別再這樣做： 直接放一張菜單長圖，讓所有文字都被鎖在圖片裡；或者只在網頁上用一般段落寫著「本店提供多種拉麵」。
- 建議這樣做： 把每一道料理都拆解成結構化的資料物件：
name: 豚骨拉麵description: 慢火熬製 12 小時的濃郁湯頭，搭配厚切叉燒。hasMap(或屬性):spicyLevel: "low",priceRange: "$$", dietaryRestriction: ["containsPork"]。
以下是標準的 MenuItem JSON-LD 程式碼範例，您可以直接提供給工程團隊嵌入網頁中：
``json { "@context": "https://schema.org", "@type": "MenuItem", "name": "豚骨拉麵", "description": "慢火熬製 12 小時的濃郁湯頭，搭配厚切叉燒。", "offers": { "@type": "Offer", "price": "280", "priceCurrency": "TWD" }, "suitableForDiet": "https://schema.org/PorkDiet" } ``
只有當你的菜單被拆解成機器讀得懂的「實體」時，AI 才能在面對複雜的複合式提問（例如「幫我找一間不辣、預算不高，而且現在有開的拉麵店」）時，精準地把你的店推薦出去。這也是為什麼我們一直強調：在 GEO 時代，做好菜單的結構化，價值遠遠超過一張拍得很漂亮的菜單照片。
E-E-A-T 與實體錨點：讓 AI 知道你是誰、可信度在哪？
Google 的搜尋品質評分指南早就把 E-E-A-T（經驗、專業、權威、信任）當作核心標準。到了生成式搜尋時代，這個概念的影響力更被無限放大：AI 到底是怎麼判斷一家餐廳值不值得信任的？
AI 不會去管你的 Logo 設計得大不大氣，它看重的是你跟那些「可驗證實體」之間的連結有多深。這主要取決於兩個關鍵維度： 1. 作者與內容的真實性（Authorship）： 你的菜單介紹、品牌故事是不是由真人撰寫的？有沒有使用 Person Schema 標記，並連結到能證明專業背景的主廚或創辦人個人檔案？ 2. 實體錨點（Entity Resolution）： 你的官網有沒有透過 sameAs 屬性（例如連結到 Google 商家檔案、Facebook 粉絲專頁、OpenTable 等），跟外部的權威平台建立起「我們是同一個實體」的強烈證明？
為什麼需要 C2PA 與 sameAs？
在假資訊與 AI 生成內容氾濫的今天，AI 引擎對於「來路不明」的網路內容戒心越來越重。C2PA（內容憑證）標準提供了一套跨產業的可信來源驗證機制，雖然目前餐飲業還沒全面普及這種數位簽章，但現階段透過 sameAs 將官網與 Google 商家檔案（Google Business Profile）、TripAdvisor 等指標性平台串聯，就是最基本的數位信任建設。
如果你的網站只有店名 and 簡單的介紹，卻沒有透過 Schema.org 明確告訴機器「這段內容是誰寫的」，或者「這家店對應到現實世界中哪一個具體地址與官方地標」，AI 就會把你的網站歸類在「通用型資訊」（Generic Content）。在 AI 生成推薦答案時，這類缺乏身分證明的內容通常會被排在最後順位。
從我們輔導的案例來看，那些經常被 AI 點名推薦的餐飲品牌，幾乎都有一個共同特徵——他們的網站不只把菜單做好了結構化，還特別標示了「主廚/創辦人」的個人檔案（Person Schema），並將這個檔案與 Google 商家檔案或其他官方社群連結綁定。這等於是直接向 AI 證明：「我們提供的資訊都是真實、且有真人出面背書的。」
相反地，許多連鎖餐飲或加盟店的網站，因為沒有針對個別分店做好實體身分的錨定，很容易被 AI 誤判為「某個同業」或是當成 generic placeholder（通用佔位符）。這也解釋了為什麼當客人在附近問 AI「有什麼好吃的拉麵」時，AI 報出來的卻是別家知名拉麵店的名字，而不是你。
建立數位信任的具體步驟：
- Person Schema： 在「關於我們」或品牌故事頁面加入
Author標記，並連結到真實人物的專業社群（例如 LinkedIn 或官方主理人介紹頁）。 - Organization + sameAs： 確保網站上的
OrganizationSchema 裡，包含了指向 Google 商家檔案（Google Business Profile）的sameAs網址。這等於是在對 AI 宣告：「這就是我們，我們在網路上有真實且可查證的足跡。」
Geo-Contextual & Actionable: GEO 的可執行結構化清單
GEO 的核心邏輯與傳統 SEO 完全不同。它不玩堆疊關鍵字那一套，而是看重可驗證的實體關係與即時的情境回應。對餐飲業來說，這意味著你的網站必須同時具備「機器看得懂、人類信得過」的雙重實力。
為什麼以前那套優化方法不管用了？
很多店家現在還在試著用一堆關鍵字（像是「最好吃的拉麵」、「台北必吃美食」）來塞滿網頁。但在 GEO 的時代，AI 篩選資料時更看重情境化與可執行性。當客人問「現在附近有什麼好吃的？」，AI 必須在幾秒內確認： 1. 即時狀態： 現在到底有沒有開？(Open Now? Closed?) 2. 具體選項： 有哪些菜色符合客人的需求？(What dishes fit my criteria?) 3. 可信來源： 這些資訊是經過驗證的嗎？(Is this verified?)
如果你的網站只有一堆靜態的「推薦文字」，背後卻沒有結構化資料支持，AI 就沒辦法把這些資訊跟客人當下的情境（時間、地點）進行即時配對。這就是為什麼許多看起來精美無比的官網，在 AI 搜尋時代卻完全派不上用場——因為它們缺乏了讓 AI「理解並引用」的骨架。
TrueLink 實戰建議：三步驟建立餐飲 GEO 信任
想讓你的餐廳在 AI 搜尋結果中脫穎而出，建議立即著手進行以下三項結構化優化：
- 第一步：全面導入 Schema.org 標記
確保 Restaurant、Menu（包含 MenuItem）、OpeningHoursSpecification 這三組核心標記完整無誤。同時，檢查 JSON-LD 是否有透過 SSR（伺服端渲染）直接寫入 HTML，而不是依賴 JavaScript 在瀏覽器端動態載入。如果 AI 爬蟲在讀取「原始 HTML」時找不到這些資料，就會當作完全不存在。
- 第二步：串接實體錨點
利用 sameAs 屬性，將你的官網與 Google 商家檔案（Google Business Profile）、OpenTable、TripAdvisor 等權威平台綁定，織出一張信任網。確認主廚或主理人頁面有完整的 Person Schema，並指向可驗證的社群媒體或專業個人檔案。
- 第三步：內容情境化與具體化
寫菜單介紹時，多寫一些具體屬性（如價格區間、辣度、過敏原標示），少用「美味」、「新鮮」這類主觀且空泛的形容詞。另外，導入 FAQPage Schema，把顧客常問的高頻問題（例如：有沒有提供外帶？好不好停車？怎麼預約？）做成結構化問答。
你可以立即採取的行動： 你可以從今天開始採取行動：首先，使用 Google 複合搜尋結果測試（Rich Results Test）工具盤點現有網站，檢查餐廳網頁是否已經正確識別 Menu 與 OpeningHours。如果發現錯誤或遺失，請馬上修正。接著，重構結構化菜單，把目前純圖片或純文字的菜單，轉換為 JSON-LD 格式的結構化資料，並補上具體的餐點屬性。最後，綁定實體連結，檢查網站上的 Organization Schema，確認已經放入指向 Google 商家檔案（Google Business Profile）的 sameAs 網址。
這三個步驟是餐飲業在 GEO 時代的基本功，就像開店一定要拿到的「營業登記」與「實體菜單」一樣。少了這些，店面裝潢得再漂亮，AI 也無法辨識你的存在。如果你在執行上遇到瓶頸，歡迎參考我們的 [GEO Strategy](/blog) 系列文章，或直接透過 [顧問服務](/consulting) 進行網站的深度診斷。
