一份餐厅菜单同时面对三类使用者
真正好用的在线菜单，同时要服务顾客、负责更新菜单的餐厅团队，以及试图理解页面内容的搜索系统。三者的需求有交集，但并不完全相同。
顾客需要看清菜名、说明、价格、必要的饮食信息，并且能很快进入预约或点单。餐厅团队需要一种不会每次改一个菜都重新做整张图的维护方式。搜索系统则更容易理解有普通文字、稳定 URL 和明确商家信息的页面，而不是把重要内容全部封在一张照片里。
因此，菜单不应该只是一份漂亮 PDF。PDF 当然可以保留给打印或下载，但如果它是唯一版本，手机上往往需要不断缩放，页面结构难以导航，小幅更新也需要替换整个文件。
我们的 手机菜单短指南 更偏体验设计，这一篇重点解释信息结构和结构化数据。
先做好可阅读 HTML，再谈 Schema
结构化数据无法挽救一个本身就不清楚的菜单页。第一步应该是让顾客在不打开额外文件、不依赖特殊脚本的情况下直接看到：
- 菜单类型，比如午餐、晚餐、酒水或者 tasting menu；
- 菜名；
- 真正有帮助的简短说明；
- 价格，或者价格为什么需要另询；
- 只有在餐厅能够确认时才提供的饮食或过敏原信息；
- 季节性或限量供应说明；
- 与当前业务相符的预约或点单入口。
这种结构本身也更适合维护。餐厅可以只更新一个菜或者一个菜单板块，而不是每次导出一整张新图。相同的事实以后还可以支持网站展示、无障碍导航、站内搜索和其他整合。
原则很简单：先把真实信息给人看清楚，再增加机器可读的说明层。
Restaurant 结构化数据应该描述真实商家，而不是制造另一套菜单系统
Google 的 LocalBusiness 结构化数据文档 支持 Restaurant 这样的具体子类型。官方示例里包含名称、地址、电话、营业时间、菜系、价格范围和 menu URL 等字段。
这些字段可以帮助系统更明确地理解页面代表哪一家商家。但 markup 不应该和页面上可见的事实冲突。如果餐厅周一休息，结构化数据也不应该写成营业。如果现实里只有一个门店，就不应该为了 SEO 页面制造多个 LocalBusiness 实体。
Google 关于结构化数据的原则也很重要：正确的 markup 可以让页面具备某些搜索展示资格，但并不保证 rich result 一定出现。Schema 是语义层，不是排名按钮。
菜单内容经常换，菜单 URL 应该尽量稳定
不少餐厅每换一季菜单就换一个网址，比如 /spring-menu-2026，然后再换 /summer-menu-2026，或者上传一个完全不同文件名的 PDF。对于历史内容来说这未必有问题，但作为当前菜单的主要入口通常不够稳定。
更适合长期运营的结构可以是：
| URL | 作用 |
|---|---|
| /menu/ | 当前菜单总入口 |
| /menu/dinner/ | 当前晚餐菜单，确实需要独立页面时 |
| /menu/drinks/ | 当前饮品菜单 |
| /private-dining/ | 包场、活动或团体用餐 |
| 带日期的文章 | 只有历史菜单本身具有长期内容价值时 |
稳定 URL 的好处是，Google Business Profile、结构化数据、社媒资料、印刷二维码都可以长期指向同一个入口。菜品变化时更新内容，而不是让所有外部引用一起失效。
如果不同门店的价格和菜单真的不同，那么结构应该跟随真实经营差异，而不是为搜索词复制近似页面。
菜品变化时，持续维护的主网址可以保留顾客路径。
- 01批准菜品信息
确认名称、价格与必要限定。
- 02更新当前菜单页
保留合适的稳定菜单网址。
- 03同步引用入口
检查商家资料、标记与印刷链接。
- 04按顾客方式阅读
核对实际页面与对应门店。
把菜单和真实餐厅实体对应起来
网站需要让顾客清楚知道这份菜单属于哪个门店。多门店品牌尤其需要注意，因为不同门店可能有不同价格、营业时间和供应情况。
单门店餐厅可以保持关系简单：一个真实 Restaurant 实体、一个实际地址、一个主菜单 URL、一个预约入口。多门店品牌则可能需要为每个真实运营地点建立独立 location page 和对应实体，同时使用真正属于那个地点的菜单入口。
普通页面设计在这里同样重要。面包屑、门店名称和 heading 应该先让人看懂内容之间的关系，结构化数据只是强化这套可见结构。
结构化数据对 AI 搜索有什么用，又有什么用不到
Google 在 2026 年发布的 生成式 AI 搜索优化指南 明确表示，传统 SEO 基础仍然适用于 AI 功能，而且不应该把各种新“技巧”当作有用内容的替代品。
结构化数据可以帮助明确语义，但并不意味着 AI 回答必须引用或推荐一家餐厅。餐厅更扎实的基础仍然是：
- 准确的商家事实；
- 可以正常抓取的页面；
- 当前、可阅读的菜单；
- 真实本地信息；
- 稳定 URL 和一致实体信息；
- 有实际帮助的图片；
- 对顾客发现之后行为的衡量。
如果以后 AI 搜索曝光变得重要，可以把它当作新的发现渠道去观察，而不是再做一套“给 AI 看”的网站。
分开检查机器可读性和真实顾客路径
技术测试可以验证 JSON-LD 是否有效，但无法证明菜单是否容易看，也无法证明预约能完成。因此应该保留两张检查表。
机器可读检查
- Schema 可以正常解析；
- 使用最合适的商家子类型；
- URL 是真实、规范且可访问的；
- 营业时间和页面可见内容一致；
- markup 没有加入页面并不存在的营销声明。
顾客路径检查
- 320px 宽度下不需要缩放就能阅读菜单；
- 菜单分类可以用键盘和触摸正常使用；
- 价格和重要限定说明清楚；
- 饮食信息经过商家确认；
- 预约和点单操作明显；
- 离开官网进入第三方后有清楚的确认状态。
两种检查解决的不是同一个问题，任何一边 PASS 都不等于另一边自然合格。
解析通过，不能证明顾客能理解菜品或完成预约。
- JSON 可解析且对应真实门店
- 网址与时间符合可见事实
- 具备资格不等于保证展示
- 菜名、价格和限定说明可读
- 位置与下一步清楚
- 交接失败不显示成功
推荐的实施顺序
如果一家餐厅正在重做搜索基础，我建议按顺序推进：
第一，先建立稳定、可阅读的菜单页。第二，做好真实门店页面和统一商家事实。第三，再增加与可见内容一致的 Restaurant 结构化数据。第四，验证 markup。第五，用手机走完菜单到预约的完整路径。最后，再通过 Search Console、分析工具和预约平台数据观察哪些页面真的带来了发现和预约。
如果当前菜单还是一张只能缩放的图片，那么继续增加 JSON-LD 通常不是首要瓶颈。如果内容和商家事实已经稳定，结构化数据才是合理的下一层。
想进一步理解 Schema、SEO 与 AI 搜索的关系，可以继续读 GEO 深度研究 pillar；如果重点是附近顾客怎样找到餐厅，则把 Richmond Hill 与 Markham 本地 SEO 深度指南 作为更大的本地模型。
最终目标不是让菜单看起来更技术化，而是让同一份准确菜单更容易被顾客、搜索系统和餐厅团队使用。
