Why AI engines don't cite most restaurant sites today
The average restaurant website in 2026 has three things ChatGPT and Perplexity can't read. The menu is a PDF or a non-indexable widget, the dietary flags live inside a dish photo, and the per-occasion pages don't exist. The atmosphere page ranks for the brand name and nothing else. When somebody asks an AI engine for a halal dinner in the Annex, a vegetarian brunch in Mount Pleasant, or an open-late spot near Yonge and Bloor, the engine has no structured data to pull from, so it cites the directory aggregators instead.
The schema layer, in order
The schema work for restaurants follows a specific order, since each layer multiplies the one underneath. The full AEO playbook from a generic frame sits in the studio's answer engine optimization guide, and the restaurant-specific stack is below.
Restaurant + Menu schema
The Restaurant schema is the parent record. It carries the name, the address, the hours, the cuisine type, the price range, the reservation URL, and the cross-link to your social profiles. The Menu schema is the child record, and it covers the structure of your menu, the sections, the time windows (brunch vs. dinner), and the seasonal flags. Most restaurant sites skip the Menu schema entirely. We ship it on day one.
MenuItem markup, per dish
MenuItem is the most under-shipped restaurant schema in 2026. Each dish becomes a structured record with a name, a description, a price, an offer (for the price), a section reference, allergen flags (gluten-free, nut-free, seed-oil-free), dietary flags (vegan, vegetarian, halal, kosher), and an optional image. Once the MenuItem is in place, an AI engine can answer "does this place have a vegan main under thirty dollars" by reading the page, instead of guessing from a photo of a printed menu.
FAQPage on every occasion page
Each per-occasion landing page (date night, business dinner, group dining, private events, anniversary, walk-in late) carries its own FAQ block with FAQPage schema. The FAQs answer the specific questions people ask AI engines about that occasion, like "how big a group can you seat without a reservation" or "is there a quiet area for a business dinner." The FAQPage schema is what makes those answers eligible for citation.
Dietary and allergen structured data
The dietary flags need to be explicit and searchable, not buried in a photo of a printed menu. Gluten-free, halal, kosher, vegan, nut-free, dairy-free, seed-oil-free, low-FODMAP, each one becomes a flag at the MenuItem level and a filterable view on the menu page. The AI engines that build dietary-restricted itineraries (ChatGPT's travel planner, Perplexity's local-search routing) pull from these flags directly, which is why most restaurants don't show up in those itineraries today.
Per-menu-variant pages
The per-menu-variant pages are where the topic depth gets built. The base menu page ranks for the brand name. The brunch page ranks for "[neighborhood] brunch." The vegetarian menu page ranks for "vegetarian dinner [city]." The prix-fixe page ranks for "prix-fixe menu [city]." The catering page ranks for catering queries. Each one carries its own FAQ block, its own MenuItem records (filtered to the variant), and its own per-occasion cross-links. Most restaurants run one menu page and lose every dish-and-occasion query underneath it. The Starlit case showed the same pattern in custom-builder land, where twelve programmatic model pages took the site from atmosphere-only to dish-level ranking. The restaurant equivalent is twelve dish-detail or menu-variant pages with the same schema discipline.
Per-occasion landing pages
Date night, business dinner, group dining, private events, anniversary, birthday party, walk-in late, post-work drinks, family dinner with kids. Each one is its own URL, its own FAQ, its own set of room photos that match the occasion, and its own reservation flow with the right party size pre-selected. The occasions are how AI engines understand intent, and the per-occasion pages are how they cite you for the right query.
llms.txt and the AI-engine handshake
The llms.txt file is the AI-engine equivalent of robots.txt, and it tells crawlers from ChatGPT, Perplexity, Claude, and Google AI Overviews how to read your site. We ship it at the Site tier and update it monthly under the Local retainer. The file lists the canonical menu URL, the per-variant pages, the FAQ pages, and the reservation flow, so the crawlers don't have to guess. Most restaurant sites don't ship llms.txt today, which is part of why they're invisible to AI search.
Cite-met monitoring
Once the schema and the topic depth are in place, the AI engines start citing the site within four to eight weeks, and Cite-met (the studio's monitoring tool, also at cite-met.com) tracks the AI-crawler traffic across six AI engines in real time, so you can see which engines are reading the site and how often. The reports run monthly under Local and weekly under Growth. The reason we built Cite-met is that most agencies report this quarterly, by which point you've already missed two reporting cycles where the data would have been useful.
Cross-industry notes
The same AEO playbook runs across the studio's other warm-register hubs. The fitness studios hub uses the same per-class-and-occasion FAQ pattern for class schedules, and the boutique retail hub uses the same per-inventory-and-occasion pattern for product collections. The schema verbs change (MenuItem becomes Product, MenuSection becomes OfferCatalog), the discipline doesn't.
The audit picks the gap
The free audit reads your current site against the schema layers above, flags where the gaps are, and quotes the build at the right tier. The deliverable is a written document, the call is twenty minutes, and there's no scope inside it. The audit is the easiest way to find out which dish-level queries you're losing today, and the document is yours either way.