Menu Structured Data Audit: Schema.org Restaurant Properties and Rich Result Eligibility

What Menu Markup Completeness Actually Controls

Schema.org publishes a vocabulary — not a mandatory schema in the enforcement sense. The Restaurant type and its related types (Menu, MenuSection, MenuItem, Offer, RestrictedDiet) let you describe your menu in a way machines can parse consistently. Completeness and accuracy affect one thing directly: whether your data is machine-readable enough for a search product to consider using it. They do not by themselves cause a booking link, price, or dietary badge to appear in any specific search product. That decision sits entirely with the platform consuming the data.

This distinction matters for an audit. The goal of checking your markup is not to "unlock" a feature but to remove structural defects — missing types, malformed prices, orphaned references — that make your data unusable regardless of what any platform decides to do with it.

The SIPA Audit Framework

Use a four-layer framework — Structure, Items, Price, Attributes (SIPA) — to move through your markup in a fixed order rather than checking properties at random. Each layer depends on the one before it, so an error in Structure will cascade into false negatives in every layer above it.

1. Structure: Confirm the Restaurant entity correctly references a Menu (or an array of Menu objects) through the menu property, and that the Menu uses hasMenuItem to reference MenuSection or MenuItem entities.
2. Items: Confirm each MenuItem has a name and, where useful, a description, and that it is nested under the correct section rather than duplicated or orphaned.
3. Price: Confirm each MenuItem's offers property contains a valid Offer with price and priceCurrency, formatted consistently across the whole menu.
4. Attributes: Confirm optional properties such as suitableForDiet use recognized RestrictedDiet values and are applied only where the underlying claim is accurate.

Property-by-Property Checklist

Audit Workflow Before Requesting Reindexing

Run the layers in order rather than jumping to whichever property seems most visible. This keeps the audit reproducible across locations if you operate more than one restaurant.

1. Export the current live markup from the page (not from a template or CMS draft).
2. Walk through the SIPA layers in sequence, recording every deviation from the checklist table above.
3. Fix Structure-layer errors first, since Item, Price, and Attribute checks are meaningless if the menu reference itself is broken.
4. Re-run the full walkthrough after each fix rather than assuming a single correction resolved the entire chain.
5. Only after all four layers pass cleanly, request reindexing through your search engine's own submission tools.
6. Log the audit date and findings so future edits to the menu can be checked against a known-good baseline.

Explicit Limitations

This checklist addresses markup validity and completeness only. It does not, and cannot, address several things operators sometimes expect from structured data work:

• Passing this audit does not guarantee a rich result, a booking link, or any visual treatment will appear in any search product.
• Search engines change eligibility rules independently of Schema.org's vocabulary, and those rules are not published in a way this checklist can anticipate.
• There is no single "most common" failure across restaurants in general; the errors your markup contains depend on your specific CMS, template, and editing history, and should be identified through your own audit rather than assumed from outside claims.
• suitableForDiet and similar attribute claims carry accuracy and, in some jurisdictions, liability implications that go beyond whether the markup validates. Legal questions about dietary claims should be directed to qualified counsel, not resolved through structured data alone.
• This article does not address AI-answer readability or LocalBusiness field compliance, which involve different properties and different consuming systems.

Measurement: What You Can Actually Verify

Because this checklist governs eligibility conditions rather than outcomes, measurement should focus on markup state, not on downstream results like traffic, rankings, or AI citations — none of which this process can promise or reliably attribute to a markup change.

• Validity check: Use a general-purpose structured data testing tool to confirm the markup parses without errors after each SIPA layer is corrected.
• Consistency check: Compare markup values against the live, human-readable menu on the same page to confirm no drift between the two.
• Change log: Record each audit date, the layer(s) corrected, and the reindexing request date, so you can trace whether a later display change coincides with a markup fix or with an unrelated platform update.
• Recurrence check: Re-audit after any menu redesign, CMS migration, or price update, since these are the events most likely to reintroduce Structure-layer errors.

Treat these as process metrics — they tell you whether your data is in good shape, not whether any particular search feature will appear.

Where ChefNet Fits

ChefNet is developing restaurant discovery and operations products, and menu data structure is one area within that broader scope. Because platform capabilities change and rollouts vary, operators should verify directly with ChefNet which menu-related features, if any, are currently live for their account before assuming a specific capability — such as automated markup validation or reindexing support — is available. This audit checklist is a general Schema.org-based practice independent of any single vendor's roadmap, and it remains useful regardless of which tools you ultimately use to implement or check your markup.

Edge Cases That Break Otherwise Valid Markup

Several situations pass a basic validity check yet still create eligibility problems downstream. Auditors should treat these as a supplementary pass after the SIPA layers, not a replacement for them.

Seasonal and rotating menus

When a Menu entity is swapped seasonally, operators sometimes leave the prior season's MenuItem entities in the markup alongside new ones, or update the visible page copy without updating the underlying hasMenuItem references. The result is markup that validates but no longer matches what a customer sees. Treat any seasonal changeover as a trigger for a full re-audit, not a partial one.

Multi-location and shared templates

Restaurants using one CMS template across several locations can end up with identical price or suitableForDiet values across sites where the underlying menus actually differ. Structural validity at the template level does not guarantee per-location accuracy. Each location's live markup should be exported and checked independently rather than assumed correct because the template passed once.

Nested or shared MenuItems

Some CMS platforms reference a single MenuItem entity from multiple MenuSections (for example, a side dish appearing under both "Lunch" and "Dinner"). This is not automatically an error, but it can mask duplication problems if the item's price or diet attributes differ between contexts and only one instance was updated. Confirm that shared items carry identical Offer and suitableForDiet values everywhere they are referenced, or split them into distinct entities if the values genuinely differ.

Handling Partial or In-Progress Markup

Operators mid-migration — adding structured data to some menu sections but not others — should avoid submitting the page for reindexing until the Structure layer covers the entire live menu. Partial coverage can produce inconsistent results across sections of the same page, which is harder to diagnose later than simply waiting until the full menu is marked up.

1. Mark the incomplete sections clearly in your internal audit log so they are not mistaken for finished work.
2. Prioritize completing the Structure layer across the whole menu before refining Price or Attribute detail on any single section.
3. Defer reindexing requests until the log shows zero open Structure-layer items.

Version Control for Markup Changes

Because menu markup is edited alongside routine price and item changes, treat it with the same discipline as any other production content:

• Keep a dated export of the markup before and after each audit, not just a note that an audit occurred.
• Record which staff member or system made the correction, particularly when a CMS auto-generates parts of the markup.
• When a discrepancy is found months later, use the version history to determine whether it originated at the last audit or was introduced afterward by an unrelated content edit.

This history is useful for internal accountability only; it does not substitute for re-running the SIPA layers, since a clean prior audit does not guarantee current validity.

Distinguishing This Audit From Adjacent Work

Teams sometimes fold this checklist into broader structured data cleanups covering LocalBusiness fields (hours, address, contact) or general content readability for AI answer systems. Keep the scope separate in your documentation: this checklist verifies menu-specific properties under the Restaurant, Menu, MenuSection, MenuItem, and Offer types only. Findings here should not be cited as evidence about the state of unrelated markup, and unrelated audits should not be assumed to have already covered menu properties.

Primary sources

• Schema.org Restaurant

FAQ

Editorial disclosure: ChefNet publishes this guide and develops products for restaurant discovery and operations. General operating guidance is separated from product claims. Capabilities can change as pilots progress. Published 2026-08-02.