餐飲 SEO 完整指南：Google 地圖與搜尋勝出

餐飲業 SEO 的第一個戰場，通常不是官網首頁，而是 Google 搜尋與地圖上的商家檔案。客人找「附近義式」「信義區火鍋」時，帶著地點、時間與用餐需求；店家要讓他立刻看懂位置、營業時間、菜單、評價，並完成訂位、導航或點餐。官網仍是品牌與轉換資產，只是兩者負責的工作不同。這篇把餐飲 SEO 拆成可執行的順序：Google 商家檔案、NAP 與在地引用、菜單結構化資料、多分店地點頁、外送平台、評價、內容與轉換，加上多店治理、危機應變、評分策略與平台組合。

餐飲 SEO 的第一個真相：客人先找能吃的店，不是先研究你的品牌

餐飲搜尋常帶著很明確的當下需求。一個人在午餐前搜尋「拉麵」，可能想知道附近哪家有開、要走多遠、價位如何，而不是讀拉麵的歷史。Google 官方也用手機搜尋附近義式餐廳說明在地搜尋，並指出在地結果主要由相關性、距離與知名度判斷（見 Google 的在地排名說明）。

這不代表每個餐飲查詢都一定先出現地圖，也不代表官網沒有機會。搜尋「東區早午餐」與「某品牌菜單」可能出現不同版面；「私廚是什麼」又偏向知識內容。實際做法是打開無痕視窗，切換目標地區，檢查你要爭取的查詢究竟以地圖、一般網頁、圖片還是其他版位為主，再分配資源。

商家檔案負責被找到與快速決策，官網負責完整菜單、分店資訊、訂位、線上點餐、品牌內容與可追蹤的轉換。兩邊都要做，但順序不要顛倒。還沒把商家檔案整理好，可以先照 Google 商家檔案完整設定教學 補齊基本資料，再用 在地 SEO 完整攻略 規劃網站與地圖的分工。

Google 商家檔案：餐飲業最先該整理的免費資產

商家檔案能顯示地址、營業時間、類別、評論、照片與行動連結。Google 在 官方的在地排名說明中明確表示，完整且正確的商家資訊較有機會出現在相關在地搜尋中；官方沒有公布某個欄位的固定加權，也沒有「填越多類別越好」的規則。

• 類別：主要類別選最能代表核心業務的項目，其他類別只補實際存在的業態。Google 的商家規範要求類別具體且能描述主要業務，不要把每個有沾到邊的選項都加進去。
• 營業時間：一般時段、午晚餐空檔、節日與臨時異動都要正確。顧客撲空是服務問題，也會直接破壞信任（見 Google 的在地排名說明）。
• 菜單：餐飲商家可在檔案中管理菜單區段、品項、說明、價格與菜單網址；介面與功能可能依帳號或資料來源不同（見 Google 商家檔案的菜單編輯器說明）。
• 屬性：戶外座位、Wi-Fi 等可用屬性會依商家類別與地區改變，部分由店家編輯，部分來自顧客回饋。屬性可能顯示在搜尋與地圖，也可能讓商家出現在帶有該條件的搜尋中（見 Google 的商家屬性說明）。
• 照片：用目前的門面、座位、餐點與菜單照，讓顧客能認店並確認期待。照片要清楚、真實、持續汰換，不要把圖庫照當成店內實景。

商家檔案不是填完一次就結束。每次改菜單、調價格、變更營業時間或新增分店，都要把更新列進日常流程。不要為了排名製造點擊、導航或其他假互動；Google 沒有公開可供操作的互動權重，虛假內容也可能觸犯平台政策。

連鎖品牌可以把欄位拆成「總部管理」與「分店回報」兩層。品牌名稱、主要類別、官網網域與資料格式由總部鎖定；臨時公休、供餐時段、店內設施、菜單異動與現場照片由分店回報。每次變更要留下日期、提出人、核准人與已更新管道，避免門市只改社群貼文，商家檔案與官網仍顯示舊資料。每月抽查幾家店，節日前再做一次全店營業時間檢查，會比事後處理撲空客訴省力。

商家檔案驗證、暫停與申訴流程

驗證方式會因商家類型、公開資訊、地區與營業時間而異。Google 可能提供影片錄製、電話或簡訊、電子郵件、即時視訊通話與郵寄驗證碼，實際可用選項由系統決定；店面型商家的影片錄製通常要拍到周邊位置、固定招牌與管理店面的證明（見 Google 的商家驗證說明）。符合資格、同一企業有至少 10 個商家檔案的連鎖品牌，可用 Business Profile Manager 的「商家群組」（Business groups）申請批量驗證。

Google 可能暫停或停用不符合規範的商家檔案；申訴工具會顯示處置原因與涉及的政策，修正資料後可提交申訴及營業登記、執照或帳單等證明（申訴流程見 Google 的檔案暫停處理說明）。受激勵或虛假評論則可能觸發另一類限制，例如暫時無法接收新評論、既有評論暫不公開或顯示警告，不應與整個檔案被暫停混為一談（見 Google 對違規檔案的限制說明）。Google 未公布申訴審查時間；連鎖店最好備一份每店驗證紀錄、租約與營業證明，減少暫停時的調查成本。

問題與回答（Q&A）功能在支援的國家與地區允許使用者提問與回答，商家擁有者或管理員也可公開回覆。餐飲業可用於澄清外送範圍、包場最低人數、停車資訊與過敏原處理方式，但答案要準確並避免過度承諾。若檔案顯示 Q&A，內容會公開出現在 Google 地圖或商家檔案中，因此要與實際服務一致（功能說明見 Google 地圖的地點問答說明）。

店面型與服務範圍型商家

餐飲業主要是店面型商家（storefront），有實體地址且顧客會親自到店。Google 要求此類商家標示精準地址，並在驗證時證明實際存在（見 Google 的商家驗證說明）。外送專門、團膳承包或無店面廚房，若無顧客到店消費，可能被歸類為服務範圍型（service area business），此時應在商家檔案中設定服務區域並隱藏地址，做法可參考 Google 的商家地址管理說明。

混合經營要分清檔案。有實體店面兼做外送，而且顧客可在標示的營業時間到店，可顯示店面地址並加上服務區域，作為混合型商家管理；無顧客到店的中央廚房或外送品牌若要建立檔案，應先確認是否符合 Google 的商家資格與外送餐飲規範，並隱藏不供顧客到訪的地址，避免使用虛構或不存在的地點。

產品編輯器與餐廳菜單的差異

Google 的產品編輯器供符合資格、販售實體商品的店家管理品項；一般餐點不應把它當成餐廳菜單功能。餐廳與飲品店應使用專為 food and drink businesses 提供的 菜單編輯器，以區段分類（前菜、主餐、飲品）並管理品項、說明與價格。

功能是否出現在檔案中會依商家資格與介面而異；同一店出現多種菜單資料來源時，應在菜單編輯器選擇正確的偏好來源，並定期同步價格；品項售完或下架時則要更新或移除。第三方平台或 Google 可能提供、轉錄菜單資料，商家要定期檢查來源與是否顯示在正確分店。

NAP 一致性與在地引用：追求正確，不追求字元潔癖

NAP 是商家名稱（Name）、地址（Address）、電話（Phone）。實務上應先做一份標準資料，讓商家檔案、官網分店頁、社群與重要名錄都使用同一組真實資訊。Google 在 商家規範中要求商家名稱反映現實世界使用方式，地址精確，電話能直接聯絡該地點；連鎖店也應維持名稱與類別一致。

這裡要修正常見的過度推論。Google 的在地排名說明只要求資料完整、正確，沒有明文指出「100 號」與「100號」這種空格差異會削弱實體歸因，也沒有把跨網站 NAP 逐字一致列為獨立排名因素。真正該修的是會讓人或系統判斷成不同店家的衝突，例如舊地址仍在主要名錄、分店共用錯誤電話、品牌改名後只更新一半平台。標點、空格或電話格式不同，但內容仍清楚指向同一資訊，不必為此大規模重建連結。

在地引用（local citation）是其他網站出現商家名稱、地址、電話等資料的紀錄。優先處理顧客真的會用、與產業或地區有關、能由店家維護的來源，例如商圈名錄、訂位平台與在地組織。不要用「總筆數」當 KPI，也不要批次提交到來路不明的目錄。Search Engine Land 的實務指南同樣把主要平台的正確性、實用性與相關性放在大量鋪站之前，而 Google 並未公布引用數量門檻。

盤點時先搜品牌名、舊店名、電話與地址，列出顧客最可能遇到的頁面。每筆標記正確、過期、重複、無法修改四種狀態，先修會讓人走錯店或打錯電話的資料，再處理品牌格式。歇業或搬遷分店也要保留交接清單：舊地點的狀態、導向的新頁、訂位與外送入口、社群置頂資訊都要一起更新。這份清單的價值是降低錯誤，不是製造一張看起來很大的引用報表。

監控在地引用變化

多分店連鎖應定期掃描品牌名、電話與地址，看是否出現未授權的新名錄、地點聚合站（自動抓取商家資訊的站）或錯誤資訊。每筆記錄平台、URL、發現日期、處理負責人與結果；若無法直接修改，可聯繫平台，或在 Google 搜尋與地圖的地點資訊使用「建議修改」回報，機制說明見 Google 檢舉不正確商家資訊的文件。

主要平台變動要特別注意。UberEats、foodpanda、各類訂位平台若更新店名、地址或電話，要同步確認官網與商家檔案是否一致；平台合約若有異動（例如獨家、下架、資料使用權限），要記錄生效日與影響範圍，避免依舊導向已終止的合作頁。

菜單結構化資料：先分清 Schema.org 與 Google 顯示資格

網站可以用 Schema.org 說明餐廳與菜單。Restaurant 是 LocalBusiness 的更具體子型態，可搭配 servesCuisine、priceRange、acceptsReservations、hasMenu、地址、電話與營業時間等屬性。

Menu 可用 hasMenuSection 分成前菜、主餐與飲品，再用 hasMenuItem 連到各品項；品項可用 offers 表示售價與幣別，也能標示適用飲食型態。這些是 Schema.org 可用屬性，不是 Google 菜單豐富摘要的「必填清單」。Google 目前的 Local Business 文件要求商家名稱與地址才能取得該功能的基本資格，並建議每個實體地點使用最具體的 LocalBusiness 子型態。

更重要的是，不要把「語法合法」寫成「一定顯示」。Google 在 Local Business 結構化資料文件中明確表示，即使結構化資料有效，也不保證相關搜尋功能會出現；餐廳輪播目前只開放給少數供應商。Menu 沒有一份可供一般餐廳承諾菜單價格摘要的 Google 豐富搜尋結果文件。

星級也有限制。Restaurant 可作為評論對象，但商家控制的網站若在自己的 LocalBusiness 或 Organization 頁面標記自我服務評論，沒有星級評論功能資格；嵌入第三方評論工具也不會繞過這項限制（見 Google 的評論摘要結構化資料說明）；評論標記的詞彙定義可另查 schema.org 的 Review。

結構化資料的目標是準確描述頁面可見內容，不是製造搜尋版面。Google 在 AI 功能說明文件中也說明，AI Overviews 與 AI Mode 不需要特殊 Schema.org 標記；一般 SEO 基礎與可見內容仍是重點。部署方法可對照 結構化資料 SEO 完整指南。上線前可用 Schema.org Validator 檢查 Schema.org 詞彙與語法，以 Google Rich Results Test 檢查 Google 支援的豐富搜尋結果資格；上線後再用 Search Console 的網址審查確認可抓取與索引。Search Console 只為部分受支援且已偵測到的豐富搜尋結果類型提供報表，不是所有 Schema 標記的完整清單（見 官方的豐富結果報表說明）。

維護上要把菜單資料當成單一來源。官網文字、JSON-LD、商家檔案與點餐系統若由四份表格各自管理，價格與供應狀態很快就會分岔。較穩定的方式是讓品項名稱、說明、價格、幣別、供應分店與時段共用同一份資料，再輸出到各管道。測試環境可先驗證標記，上線後抽查可見內容與原始碼是否相符；下架品項要連同結構化資料移除，不要只在畫面上用 CSS 隱藏。

進階 Schema 應用：MenuModifier、營養資訊與分層菜單

Schema.org 提供更多屬性，但不等於會在搜尋結果顯示。MenuModifier 可描述加料、選配或客製化選項（例如「加起司 NT$30」）；NutritionInformation 可標示熱量與營養成分。

這些標記要配合實際頁面內容與法規要求。營養標示若涉市售有容器或包裝食品，要依《食品安全衛生管理法》規定辦理，單靠 Schema.org 不會豁免法律責任；相關規定可查 食藥署的食品標示規定。不同時段的菜單（早午餐、下午茶、宵夜）應先在頁面上清楚分類，再用各自的 Menu 實體或 hasMenuSection 對應；標記內容必須與頁面上實際可見的分類一致，否則就是與可見內容不符。

多店共用同一份菜單時，可在各店頁的 Restaurant 標記中重複使用同一 Menu ID，但要確認各店真的供應該菜單的品項。若部分分店不提供某道菜，應為各店輸出符合實際供應內容的菜單標記，不要讓該店的 Restaurant 指向不適用的共用菜單。

多分店地點頁：一店一頁一商家，但每頁要真的有用

總覽頁適合讓顧客比較全部門市；各店若有不同地址、電話、營業時間、菜單、訂位入口或設施，則應另設可由導覽與內部連結找到的分店頁。Google 的結構化資料文件也建議把每個實體地點定義為一個 LocalBusiness，並使用最具體的子型態。

每個地點頁至少要回答該店顧客會問的事：正確地址與地標、交通與停車、營業與供餐時段、訂位方式、實際菜單、座位或無障礙資訊、店內實照、限定活動。每個可接待顧客的實體分店也應有自己的商家檔案；Google 的規範要求一個實際地點不要建立重複檔案，連鎖各店名稱與類別則應反映一致的現實品牌。

內容相近不會自動觸發一個叫「重複內容處罰」的機制；Google 的標準網址說明指出，Google 可能把高度相似的網址歸成一組並選一個代表版本。風險較高的是為相似查詢大量建立幾乎相同的城市或地區頁，再把人導向同一個真正可用頁面。Google 現行垃圾內容政策仍把「針對特定地區或城市建立多頁並導向同一頁」及「大量建立高度相似、比清楚網站架構更靠近搜尋結果的頁面」列為門面頁濫用例子。

所以，模板本身不是問題，空洞模板才是。用「分店資料表＋共用版型＋必填差異欄位」管理規模，能維持一致又保留每店真實資訊。每頁的 Restaurant 地址、電話與營業時間要填該店資料；若品牌關係確實存在，可用 parentOrganization 指向上層組織，該屬性的定義就是此組織所屬的較大組織。多頁競爭同一意圖時，再用 關鍵字蠶食修正 判斷該合併、改寫或重新分工。

多分店治理、API 與稽核流程

分店數量一多，手動維護所有商家檔案與官網資料會明顯變慢；此時可用 Google Business Profile APIs 批次更新或自動化部分作業。API 可用在讀取評論、更新營業時間、上傳照片與管理回覆，但必須先申請 API 存取權，並以 OAuth 2.0 授權，不是只申請 API 金鑰；各 API 與方法另有每分鐘或每日配額，詳細限制見 官方的配額說明。

大型連鎖需要三層治理：總部定品牌標準（名稱格式、類別清單、資料結構）、區域督導跨店一致性（資料品質抽查、品牌語氣）、分店回報現場異動（公休、維修、店內活動）。稽核頻率依分店數與異動量訂定，項目包括每店 NAP 在主要平台的一致性、菜單與商家檔案的同步、評論回覆率、照片新鮮度、結構化資料與可見內容的符合度。

權限設計要分級。可依品牌或區域建立不同「商家群組」（Business groups），把總部人員加到涵蓋全部分店的群組、區域人員只加到所屬群組，店長則只取得單一商家檔案的權限。Google 目前的檔案角色是 擁有者與管理員；管理員大多可編輯完整檔案，只是不能新增或移除使用者，也不能移除檔案，並沒有可逐欄位自訂的「店長角色」；商家群組的建立與管理可另見 Google 的商家群組說明。

加盟與直營要分開處理。Google 沒有規定加盟店的商家檔案一律歸品牌總部；只有商家擁有者或獲授權代表可驗證與管理，實際責任要依加盟合約與授權安排（見 Google 的商家資格與擁有權規範）。若同一實際地點誤建兩個檔案，才依重複檔案流程處理；加盟店資料與品牌標準不同，本身不等於應移除或合併檔案。

地點頁範本設計與差異化檢查

實用地點頁範本至少包含：可嵌入 Google 地圖的地址與街景、最近的捷運或公車站與步行時間、停車方式（自備、付費、附近的停車場）、營業時段與特殊休息規則、今日供應狀況（如有限定供應）、訂位與外送連結、實際菜單與價格、照片（門面、座位、招牌菜）、常見問題（停車、包場、兒童設施）。每店要在這些欄位填實際資料，不是直接複製鄰店內容。

定期抽取一部分分店頁，檢查是否真的有差異。若發現照片是鄰店、交通描述與實際不符、營業時間未同步最新公告，要回溯該店的資料來源與更新流程。稽核若反覆發現同一類錯誤，就要修正範本或加強分店培訓。

跨縣市或跨國展店時，地點頁要補足在地資訊：當地語言的菜單說明、通用的支付方式、在地節日的異動公告、當地交通習慣（例如香港的士站、日本門牌規則）。不要用同一套交通敘述套用全部城市。

外送平台是租來的流量：Uber Eats 與 foodpanda 不能套同一套公式

第三方平台能帶來發現、下單與配送，但店家可取得的顧客資料、費用、排序與活動工具受平台及合約控制。實際抽成與資料權限依店家合約而異，不要用單一比例概括所有餐廳，也不要把平台訂單直接當成可自由再行銷的名單。

Uber Eats 有公開部分排序資訊。官方說明列出的因素包括顧客查看店家的次數、查看後下單的比例、顧客與店家的距離，以及常客偏好；另一份官方說明提到顧客傾向較快的整體配送時間與較高評分，降低預設備餐時間可能有助排序。

這些資料支持「轉換、距離、配送時間與評分會被考量」，卻不能延伸成接單率必定是餐廳列表排序因素，也不能推算權重。foodpanda 的公開商家與整合文件可確認菜單、促銷、訂單與履約工具，但公開頁面未列出餐廳列表的完整排序因素，因此不能把轉換率、備餐時間、評分或接單率寫成已證實的 foodpanda 排名公式，公開資訊以 foodpanda 開發者文件 為準。

健康的分工很簡單：平台負責擴大發現與配送，自家網站、會員、LINE 與自家點餐承接品牌關係與第一方資料。平台內導流與優惠要先檢查合約；取得會員資料後再行銷，也要有合法的蒐集與利用依據。依《個人資料保護法》第 20 條，當事人拒絕接受行銷時，非公務機關應停止利用其個資行銷；首次行銷還要提供拒絕方式並負擔所需費用（見 全國法規資料庫：個人資料保護法第 20 條）。這個取捨也能對照 商城賣家 SEO 的租借流量與自有資產概念。

看平台績效時，不要只看訂單總數。把曝光、店家頁瀏覽、下單、取消、客訴、實收金額與備餐壓力放在同一張表，再與自家點餐、電話及現場訂單比較。平台活動帶來的訂單若同時拉高缺品、延遲與退款，就不是單純的流量成長。也不要把 Uber Eats 公開因素直接套到 foodpanda；兩邊分開記錄，改一次菜單照片、價格、促銷或備餐設定後保留觀察期，才看得出變化來自哪個動作。

平台組合策略與獨家協商

多平台上架可增加曝光，但也要考慮營運負擔。每多一個平台，菜單、照片、價格、庫存與訂單處理就要多維護一份；常見情況是大型連鎖同時上架多家平台，小型店則只挑少數主力平台經營。決策基於該平台的實際訂單、手續費、資料整合能力與競爭情況，不是越多越好。

獨家協商要算總帳。平台可能以較低手續費或資源換取獨家，但要評估放棄其他平台損失的曝光與訂單。簽約前先查該平台在你目標區域的市場佔有率、實際單量與顧客重疊度；若已上架多家，可比較各平台表現後再決定是否轉單一平台。

平台活動與折扣要看淨收入。滿額折抵、免運、平台優惠券可能帶來訂單，但扣除折扣與手續費後的實收金額是否划算，要依品項毛利與客單價計算。高毛利品項適合配合平台活動；低毛利品大量參加可能導致賺量不賺利。

平台資料整合與 POS 對接

部分外送平台提供 API、Webhook 或合作整合工具，讓符合資格的店家與整合商管理菜單、門市、訂單或狀態；支援範圍與存取資格依平台而異，不能從 Uber Eats 的 Marketplace API 文件推論所有主要平台都用同一種 REST 推送機制。整合可減少手動錯誤與漏接，但需技術資源與維護成本。

實作前確認 API 功能範圍：是否支援庫存同步（售完自動下架）、價格更新、訂單修改、列印選項與時段設定。若平台 API 不支援庫存同步，就需手動或定期監控，避免客人在平台下單但現場已售完。

POS 對接後要持續監控錯單與漏單。常見問題包括平台與 POS 品項編碼不一致、修改菜單後未同步平台、網路斷線導致訂單未推送、第三方整合服務停機。設定異常警訊（超過一定時間未收到訂單確認、庫存數量異常、平台與 POS 金額不符），可即時發現並處理。

評價累積與回覆：排名、信任與政策要分開看

Google 在改善在地排名的說明文件中公開說明在地知名度會參考網路資訊，更多評論與正面評分可能有助於在地排名；官方沒有公布近期評論、回覆速度或回覆數量的固定權重。因此可以穩定邀請真實顧客評論，但不要承諾「每月新增幾則就會上三包」。

底線是評論必須來自真實、無偏見的體驗。付費、折扣、免費品項或其他利益交換的評論，會被 Google 視為受激勵評論；違反假互動政策時，評論可能被移除，商家檔案也可能依違規處理的官方說明暫停接收新評論、隱藏既有評論或顯示警告。

把邀評做進結帳動線即可：桌牌或發票夾放 QR code，結帳後提供官方評論連結，邀請所有顧客留下真實意見，不篩選滿意顧客。回覆則以服務為主，保持簡短、專業，不公開個資；負評先核對紀錄，再說明可處理的方式。Google 在顧客評論管理說明中也提醒商家回覆會公開顯示，並建議不要攻擊評論者或透露私人資訊。更多流程可看 顧客評論收集與經營。

評分策略與多平台評價管理

評分明顯低於同區同類店家或品牌其他分店時，先看服務問題根源：是出餐慢、口味不符期待、環境問題或溝通落差。沒有適用所有餐廳、可判定消費者點擊意願驟降的固定星等門檻。每則負評應標記類型（服務、餐點、環境、價格、其他），定期統計主要抱怨類型，再對應改善。若忽略服務問題只追求邀評數量，評分仍會持續低迷。

不同平台的評分要分開管理。Google 商家檔案、Tripadvisor、Facebook、OpenRice、Uber Eats、foodpanda 各有不同評分機制與顧客群；不要把 Google 評論直接複製到其他平台。各平台評分低於該平台常態或競爭者時，要依該平台特性回覆，不要複製貼上同一回應。

連鎖店可比較各店評分與類型。若某店連續低於品牌平均且負評集中某主題，要派督導了解現場狀況；若某店持續高於平均，可分析其服務流程、管理方式與團隊，整理成可複製的案例。

負評回覆範本與危機處理

負評回覆要具體，不要空泛回應「感謝反饋」。可用的結構：確認細節（若資訊不足，可請顧客提供日期或菜名）、承擔責任（若有明確失誤）、說明改善行動、提供聯絡方式。回覆長度適度簡短即可，太長可能顯得防衛性過強，也會讓其他讀者失去耐心。

危機評論（食安、爭議事件、惡意攻擊）要先確認事實。若有法律或食安風險，不要在評論區爭辯，應由公司發布正式說明；Google 商家檔案回覆可簡短表示「已接獲反映，正在處理，請致電專線討論」。惡意評論（明顯造謠、人身攻擊、競爭者攻擊）可依Google 的檢舉評論政策舉報，但審議需要時間，期間不要互相指謫。

評論炸彈（短期大量一星評論）要先判斷來源。若是社會事件或爭議，先由官方渠道說明，再回覆代表性評論；若疑似系統性攻擊，可依Google 的檢舉不當評論流程逐則舉報違反政策的評論，並在 Reviews Management Tool 查看狀態或提出一次申訴。商家沒有自行暫停或重新開啟評論的設定；特定情況下暫停使用者內容是由 Google 決定。期間先處理建設性評論，不要試圖回覆每一則攻擊。

在地關鍵字：用料理、地點與情境整理需求

餐飲長尾常由三種資訊組合：料理類型、地點、用餐情境，例如「信義區義式餐廳」「桃園素食宵夜」「台中可包場合菜」。這些詞不保證低競爭或高轉換，仍要用 Search Console、網站分析、商家檔案查詢字詞、訂位與訂單資料判斷價值。

頁面要回答情境，不是堆詞。「親子餐廳」頁面應清楚交代兒童餐、推車空間、兒童椅、洗手間與座位限制；「可包場」要寫人數、時段、低消、設備與聯絡方式。沒有提供的服務不要為了關鍵字硬寫，否則流量進來也只會變成落差與負評。完整方法可參考 長尾關鍵字佈局策略。

頁型也要分工。分店頁回答「去哪一家、怎麼去、何時開」；菜單頁回答「吃什麼、多少錢、何時供應」；訂位頁回答「還有沒有位、規則是什麼」；文章才處理聚餐情境、食材與料理知識。若同一段文案同時塞進全部頁面，搜尋者很難快速找到答案，站內也會出現多頁搶同一意圖。先為每組需求指定一個主要頁，再用清楚內部連結串到下一步。

在地頁與情境頁的實作與評估

建立「地區＋料理」頁（如「台中義式餐廳推薦」）前，先確認是否已有相關搜尋需求與轉換意圖。可用 Search Console 查看網站實際獲得曝光的查詢，或用 Google Trends 比較不同地區組合經標準化後的相對搜尋熱度；Google Trends 官方 FAQ也說明不提供絕對搜尋量，低量詞也可能顯示為 0。若現有資料顯示需求有限，投入內容的優先序可放低。

情境頁要服務真實需求，不是猜測。可從店內常被問到的問題、客服紀錄、訂位留言挖掘題材：平日晚餐聚餐選擇、商務午餐要求、生日包場流程、素食替代方案、外送時段與範圍。每個情境頁說明該情境的實際安排（限制、費用、預約方式），而非僅列出品牌與菜名。

評估在地頁成效，要追蹤曝光、點擊、轉換（訂位、點餐、電話）與跳出率。若「XX區早午餐」頁曝光高但點擊低，可能是標題或描述未傳達差異化；若點擊高但轉換低，可能是頁面未解答顧客疑問或缺乏明確行動呼籲。

照片與菜單頁：先讓人看懂，再談機器理解

餐飲頁面最常見的摩擦，是菜單只有一張難以縮放的圖片，價格看不清，手機點進去還要下載 PDF。依 Google 官方文件，Google 可以索引未加密 PDF 中可擷取的文字，但能被索引不代表它比 HTML 更好用。

官網菜單最好同時提供可讀文字與必要圖片，列出品項、價格、供應時段、加價條件與售完規則；更新價格時，頁面文字、結構化資料、商家檔案與點餐系統要一起改。Menu 標記只能描述真實可見內容，不會替錯誤或過期菜單補救。技術檢查可搭配 技術 SEO 完整指南。

菜單工程與轉換優化

菜單設計影響轉換，不只是內容問題。品項排序可依暢銷度或毛利分組，高毛利且受歡迎的品項放在顯眼位置；招牌菜可標示店長推薦或人氣標章，但不要標示「第一名」「No.1」等無法證實的稱號。品項圖片要節制使用：PC 版可配合較大的圖片與說明，手機版則要避免過多圖片讓頁面過長、滑動太久影響點餐。圖片大小也要壓縮，避免拖慢載入。

價格呈現要清晰。隱藏價格直到點擊或詢問，會提高跳出率；飲品或配菜加價若未明示，結帳時容易引發負評。若有服務費或低消，要在菜單頁顯眼處說明，不要只在結帳時才告知。

售完狀態要即時。若店內已售完但網站仍顯示可選，會直接造成客訴與退單。可用 CSS 視覺處理（變灰、標示售完）但結構化資料要同步移除或更新 availability 屬性；若用機器人抓取菜單到平台，售完狀態也要同步推送（見 schema.org 的 ItemAvailability）。

餐飲廣告紅線：食品宣傳與過敏原不要憑印象寫

依《食品安全衛生管理法》第 28 條，食品標示、宣傳或廣告不得不實、誇張或易生誤解，也不得宣稱醫療效能。食藥署的認定準則還把「與事實不符」「無證據或證據不足」列入判斷，因此「手工」「現做」「無添加」等字眼都要能對應實際製程與證據，判斷基準見食藥署 2024 年 10 月的 標示規定說明與 認定準則。

過敏原要分清適用對象。食藥署問答指出，現行強制規定以市售有容器或包裝食品為對象；餐廳菜單與散裝食品不在該項規範對象內，業者仍可自主揭露（見 食藥署 2018 年的過敏原標示問答集）。這不等於餐廳可以忽略食安風險；若涉及包裝販售、特殊商品、平台欄位或地方要求，要再確認適用規則。對外宣稱健康或療效前，應交由熟悉食品法規的人員審查。

個資與隱私：餐飲業的特別注意事項

餐飲業常蒐集的個資包括：會員姓名、電話、生日、飲食偏好、訂位紀錄、消費金額。直接向當事人蒐集個資時，原則上應依個資法第 8 條告知蒐集目的、資料類別、利用期間、地區、對象、方式及當事人權利等事項；以個資行銷時，當事人拒絕接受行銷就應停止利用，首次行銷並應提供拒絕方式且負擔所需費用（見 個人資料保護法第 8 條、第 20 條）。

訂位系統與點餐平台若委外，要確認第三方資料處理合約是否合規。外送平台提供的顧客資料，使用限制要依平台合約，不要直接匯入自家 CRM 再行銷，除非合約明文允許且個資告知已到位。

餐廳基於業務在店內拍攝可識別顧客的監視影像，應依《個人資料保護法》處理；《警察職權行使法》規範警察職權，並不是私人餐廳架設監視器的一般依據（見 個人資料保護委員會籌備處的函釋）。將可識別顧客的影像公開上網屬於另一項利用行為，不能只因店內已錄影就任意公開；應確認合法依據、符合原蒐集目的與必要範圍，或先取得同意、去識別化，並避免侵害人格權。

貼文、訂位與點餐：曝光後要有下一步

Google 商家檔案貼文可發布近況、優惠與活動，內容可出現在搜尋與地圖的商家檔案中；顯示位置會依裝置與介面而異（見 Google 商家檔案貼文說明）。適合發布新菜、節慶套餐、臨時異動與活動提醒，但 Google 沒有說固定發文頻率會直接提高在地排名。資訊有變再更新，比為了湊篇數更實際。

商家檔案可依資格加入菜單、訂位與點餐連結，部分第三方供應商也可能自動提供連結；店家應定期檢查網址、首選連結與供應商是否正確，對照 Google 的在地商家連結管理說明。官網首屏則要讓手機使用者立刻找到主要動作，不要把訂位藏在多層選單。檢查三件事：訂位能否完成、點餐是否直接到正確分店、電話或 LINE 是否容易點擊。更完整的轉換設計可看 餐廳訂位與線上點餐 SEO。

內容行銷與手機體驗：只做能幫客人決定的內容

菜色故事、食材來源、主廚理念、用餐指南與活動頁，可以承接品牌或知識型搜尋，也能讓顧客理解差異。內容發布不等於必然得到連結、AI 引用或排名；應追蹤品牌查詢、菜單瀏覽、訂位輔助轉換與實際詢問，再決定要不要持續。經營框架可對照 內容行銷策略完整框架。

手機版必須放進完整內容與功能。Google 使用手機版內容進行索引與排名，這叫 Mobile-first indexing；它不是「做一個手機版就自動加分」，而是提醒你不要讓手機版少掉菜單、內部連結、結構化資料或重要文字（見 Google 的 mobile-first indexing 最佳實務）。

實測菜單字級、價格可讀性、按鈕點擊範圍、圖片大小、載入與互動穩定性。Core Web Vitals 會被排名系統使用，但拿到好分數不保證排到前面，Google 也不建議只為 SEO 追求滿分（見 Google 對頁面體驗的說明）。技術處理可參考 網站速度優化指南 與 站內 SEO 指南。

語音查詢與行動助理的「附近」需求

行動助理或語音介面處理「附近餐廳」查詢時，可能使用搜尋、地圖或其他商家資料，但沒有一份官方文件證明所有語音結果都採用固定的「完整度、評分、距離、營業狀態」公式。Google 也已把多數行動裝置上的傳統 Google Assistant 體驗逐步升級為 Gemini，因此不應把 Google Assistant 當成規則固定、獨立於搜尋與地圖的 SEO 管道（見 Google 的升級公告）。

「現在附近的火鍋店」這類查詢明確包含當下時間與位置條件。商家檔案的地址與營業時間要正確，臨時公休或特殊營業時間也要更新，避免任何搜尋或助理介面向顧客顯示過期資訊。

不同裝置與助理採用的資料來源、可讀欄位與呈現方式不一，不能保證它會讀取某個特定商家檔案欄位。名稱、地址、營業時間、菜單與餐廳類型仍應用清楚文字維護，並避免在描述中堆疊關鍵字。

展店與跨區擴張：開店前就把數位門牌準備好

新店的 SEO 不該等開幕後才補。地址、電話、營業時間與訂位尚未確定時，可以先準備分店頁模板與資料欄位；資訊正式公開後，再上線地點頁、商家檔案、菜單與點餐入口。不要提前發布未確認資訊，也不要為尚未實際營業的地點製造評論。

跨縣市時保留品牌骨幹，再補該店的真實差異。總部可集中管理名稱、類別、結構化資料規格與更新流程；分店負責回報營業異動、照片、交通、設施、限定菜與在地活動。這樣能避免各店自行改寫後資料漂移，也不會把每頁做成只換地址的空殼。

跨國餐飲與多語言菜單

跨國展店時，菜單與資訊要支援當地語言。依 Google 的多地區與多語言網站文件，hreflang 標籤可幫助搜尋引擎理解不同語言版本的對應關係。各語言頁面的 Menu 品項應以該頁可見語言提供 name 與 description，不要在 Schema 標一個語言、頁面卻顯示另一個語言。

要注意當地食安與營業法規。某些國家對酒精飲料宣傳、營業時間、外送規範有特殊規定；標示健康聲明要符合當地主管機關定義，不要直接翻譯母國的宣稱。

支付方式也要在地化。某些市場以現金為主，某些偏好信用卡、行動支付或特定電子錢包。菜單頁應列出該店可接受的支付方式，避免顧客用餐後才發現無法使用習慣的付款方式。

餐飲 SEO 投資優先序：依規模安排，不照表保證成效

下面是資源配置建議，不是 Google 的排名公式。實際優先序仍要看品牌需求、分店數、技術負債與轉換資料。

規模	建議第一優先	建議第二優先	可視需求延後
單店、剛起步	商家檔案的類別、營業時間、菜單、照片與連結	真實評論邀請、回覆與轉換入口	大規模內容產線
單店、穩定經營	菜單頁、訂位與點餐轉換	在地情境內容、結構化資料	多分店系統
小型連鎖（少數分店）	一店一頁一商家、分店資訊差異化	NAP 維護、菜單與資料同步	全國型內容佈局
區域連鎖	地點頁模板、資料庫與商家檔案治理	品牌搜尋、會員與點餐整合	無法量測的零碎微調
全國連鎖	技術健檢、資料品質、權限與更新流程	自有會員、分店分析與平台分工	各店無標準的手動操作

單店可以自己維護商家檔案、菜單、照片與評論回覆，因為店內團隊最清楚實際異動。多分店跨縣市後，難點會轉向權限、資料同步、模板、監控與技術驗證；這時可把可標準化的工作交給專責人員或顧問，分店仍保留真實素材與服務處理。判斷內容可信度與責任分工時，可延伸閱讀 E-E-A-T 經驗權威建立。

競品分析與餐飲業專屬指標

觀察競爭者時，重點不在模仿他們的關鍵字堆疊，而是看他們的商家檔案運用、菜單呈現方式、評論回覆策略、平台組合與內容主題。可比較同城同類型店家的評分與評論數，但不要因為競品有較多評論就決定購入評論或激勵評論；違反 Google 政策的行為長期風險高於短期排名。

餐飲業特有的 SEO 指標包括：訂位完成率（點擊訂位按鈕後實際完成的比例）、訂單取消率、平均訂單金額、熱門時段的轉換落差、不同管道的客單價（平台 vs 自有）、菜單品項的點擊與轉換。這些資料能幫助判斷 SEO 流量的品質，而非只看曝光量。

季節性與事件驅動的查詢要提前準備。母親節餐廳、尾牙、跨年、情人節、畢業季等，搜尋量會在特定時間上升；可在活動前數週準備活動頁、菜單與商家檔案貼文，讓搜尋引擎有時間索引，但避免在全年都掛上節日促銷，否則活動標籤失公信力。

AI Overviews 與 AI 搜尋的準備

Google 在AI 功能官方文件中明確表示，AI Overviews 與 AI 搜尋不需要特殊 Schema.org 標記；搜尋引擎依現有排名系統判斷內容引用與顯示。因此餐飲業的 AI 準備不是標記某種特殊 Schema，而是強化基礎 SEO：讓菜單可讀、資訊正確、權威可信。

若要讓搜尋系統更容易理解內容，應明確回答具體問題，並在有可靠依據時提供數據、流程、原理或差異。餐飲業可發展的內容型態包括：食材來源與處理方式說明、不同菜系的風味差異、特殊飲食（素食、無麩質）的定義與安排、外送與內用的價格差異原因、包場流程與費用結構。這些內容也可能被 AI 搜尋功能引用，但 Google 不保證任何特定寫法會獲得引用。

品牌在官網、商家檔案與可信的產業或媒體來源中，應維持名稱、地點與背景資訊正確一致；不要為了所謂實體建構而製造 Wiki 條目或不實紀錄。Google 沒有保證外部資料庫紀錄會帶來 AI 引用或排名，被 AI 引用也不能直接等同於 SEO 成功。

把餐飲 SEO 串成一條執行順序

1. 整理商家檔案。選對主要類別，補齊正確營業時間、菜單、屬性、照片與行動連結。
2. 建立標準店家資料。修正真正衝突的名稱、地址與電話，優先維護重要且相關的在地引用。
3. 做好可讀菜單頁。讓人看得到品項、價格與供應條件，再用 Restaurant、Menu 描述同一份可見內容。
4. 多分店採一店一頁一商家。保留品牌一致性，也補足每店才有的交通、設施、照片、活動與菜單。
5. 拆開平台與自有管道。依各平台已公開規則優化營運，不把未公開因素說成排名公式；同步經營官網、會員與自家點餐。
6. 持續量測。把搜尋曝光、商家檔案互動、訂位、點餐、電話與到店資料串起來，按實際阻力調整。

餐飲 SEO 不是靠一個 Schema、幾篇地區頁或固定發文頻率取勝。真正有用的工作，是讓每家店的資訊正確、頁面可讀、平台承諾與現場一致，並縮短客人從搜尋到訂位、下單或走進店裡的距離。地圖是入口，網站是資產，菜單與服務才是顧客做決定的理由。

每月檢查可以固定看四層數據：搜尋曝光是否出現在對的地區與需求、商家檔案是否帶來網站點擊或導航、網站是否完成訂位與點餐、訂單最終是否成功履約。曝光增加但訂位不動，就檢查菜單、價格與入口；訂位很多但取消也高，就檢查規則與現場承接；只有品牌詞成長，則不應直接宣稱在地非品牌 SEO 已成功。量測的目的不是做漂亮報表，而是找出下一個最該消除的摩擦點。

本文談的是餐飲業的搜尋曝光與內容經營方法，不構成食品安全或法律建議；食品廣告標示、過敏原、個資與平台規範以主管機關及各平台現行規定為準，有疑義請洽合格專業人士。