Getting your menu into search results

Why a picture of a menu is worth nothing

Most restaurant sites publish the menu as an image or a PDF. Both are opaque. A search engine looking at a photograph of a menu board sees a photograph. It cannot tell you have a carbonara, it cannot tell what it costs, and it cannot offer you to somebody asking an assistant where to eat nearby.

That is the single most valuable content on the site, thrown away.

The shape of the data

Menu markup nests in a specific order, and getting the nesting wrong is the most common failure. A Restaurant has a Menu, a Menu has MenuSection objects, and a MenuSection has MenuItem objects. Prices live on an Offer attached to the item.

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://example.com/#restaurant",
  "name": "Example Kitchen",
  "servesCuisine": "Italian",
  "hasMenu": {
    "@type": "Menu",
    "@id": "https://example.com/menu/#menu",
    "name": "All day",
    "hasMenuSection": [
      {
        "@type": "MenuSection",
        "name": "Pasta",
        "hasMenuItem": [
          {
            "@type": "MenuItem",
            "name": "Carbonara",
            "description": "Guanciale, pecorino, egg yolk, black pepper",
            "suitableForDiet": "https://schema.org/LowLactoseDiet",
            "offers": {
              "@type": "Offer",
              "price": "14.50",
              "priceCurrency": "USD"
            }
          }
        ]
      }
    ]
  }
}

Three details in there matter more than they look:

• priceCurrency is required alongside price. A price with no currency is ambiguous and gets ignored.
• price is a string without a symbol. "14.50", not "$14.50" and not 14.50.
• @id on the restaurant lets every other page reference the same entity instead of declaring a new one. A site that declares five unlinked Restaurant nodes has told search engines it is five restaurants.

Link it, do not repeat it

The menu page declares the full Menu. Every other page should reference it by @id rather than restating it:

{ "@type": "Restaurant", "@id": "https://example.com/#restaurant",
  "hasMenu": { "@id": "https://example.com/menu/#menu" } }

This is the part most implementations miss. Repeating the whole menu on every page creates competing definitions of the same thing.

The mistakes we see most

1. The menu is an image. Nothing else on this list matters until this is fixed.
2. Items with no price. A MenuItem without an Offer is a name floating in space.
3. Sections flattened away. Every item hung directly off the Menu with no MenuSection loses the structure a human reader uses.
4. Markup that disagrees with the page. If the JSON-LD says $14.50 and the page says $16, you have a problem that is worse than having no markup.
5. AggregateRating invented. Covered in the local business guide - this one can get you a manual penalty.

Check it before you ship it

Paste the rendered page into Google’s Rich Results Test and the Schema.org validator. They disagree deliberately: the Schema.org validator tells you whether the vocabulary is correct, and Google’s tells you whether you are eligible for anything it shows. You want both clean.

We audited 190 US restaurant sites and 94% carry no menu markup at all, so doing this puts you ahead of almost everyone in the sector.

Villas Cafe is a worked example - every dish on a single-page cafe site is a MenuItem inside a MenuSection carrying its own Offer and price.