Restaurant Menu Page Design: What to Keep, What to Cut

A great restaurant menu page is fast, scannable, accessible, and ready for search engines. Each dish gets a name, a five-to-fifteen-word description, a price, and item-level schema. Categories beat scrolling lists. Photos belong on hero dishes, not the full menu. Mobile is the primary canvas.

The menu is the most-visited page on most restaurant websites — and the page that should be designed with the most care. In practice, it’s usually the page that gets the least. Operators pour weeks into a homepage hero, then dump the menu into a PDF link or a single uncategorized block of text and call it done. The result is a page that bleeds orders, reservations, and trust at the exact moment a diner is leaning in.

We’ve already argued against the PDF in why your restaurant’s menu shouldn’t be a PDF. That post is the diagnosis. This one is the prescription — the practical answer to what to build instead. The framework below is what we ship every menu against, regardless of cuisine, location count, or budget tier.

What every menu page needs

The minimum bar is six things. Miss any one of them and the page is doing less work than it should.

A real URL, not a modal

The menu deserves its own indexable page at /menu/ (or /menu/dinner/, /menu/lunch/, etc.) — not a modal that pops up over the homepage, not a tab that swaps content via JavaScript, not a section anchor on a single long page. A real URL is what Google crawls, what diners share over text, and what shows up in “lobster roll nearby” searches. If a diner can’t deep-link to your menu from a thread with friends, you’ve already lost the cover.

Categorized layout (H2 per category, H3 per dish)

Diners scan menus the way they scan any other dense content — they look for the section they want, then drill in. A 40-item scrolling list defeats that pattern. Use an <h2> for each category (Starters, Mains, Desserts, Drinks) and an <h3> for each dish name. The headings give search engines a clear outline of what you serve and give screen readers a navigable structure. They also force the page into the same mental model a printed menu uses, which is what most diners are already pattern-matching against.

Price visible next to every dish

Price sits on the same line as the dish name, or directly beneath it — never buried below a paragraph of description. Hiding prices behind a “request menu” form or a phone number is a trust break. Tasting menus and omakase are exceptions because they genuinely don’t price line items; everything else gets a number. A diner with a budget in mind decides in seconds whether your menu is in range, and a missing price pushes them to the next result.

Five-to-fifteen-word descriptions

Write descriptions like a kitchen-floor note, not marketing copy. Name the technique, the key ingredient, and one differentiator. “Bone marrow, salsa verde, charred shallots, toasted sourdough” tells a diner exactly what shows up on the plate. “A rich, indulgent appetizer perfect for sharing” tells them nothing they couldn’t have guessed. Short, specific descriptions are also easier to scan on mobile and easier for Google to extract into AI Overviews and dish-level search results.

Dietary indicators (V, GF, VG, DF)

A guest with a restriction is a high-intent guest — they’re choosing where to eat partly on whether your menu has options for them. Visible labels next to the dish name (V for vegetarian, GF for gluten-free, VG for vegan, DF for dairy-free) answer the question before they have to call. Use either small icons with text alternatives or short letter labels, and put a legend at the top of the menu so first-time visitors know what the abbreviations mean. The accessibility win is real: the restaurant ADA story is also a conversion story.

Item-level Menu + MenuItem schema

Every dish gets wrapped in MenuItem schema with a name, description, price, and dietary suitability where it applies. The schema is what lets Google surface dishes in search results and rich answers — and what gives AI Overviews something structured to cite when a diner asks “what’s the best vegetarian ramen in Sawtelle.” Without it, your menu is text on a page; with it, your menu is a queryable dataset that the next wave of food search can actually use.

What to cut

Most underperforming menu pages aren’t missing anything — they’re carrying weight they don’t need. Four common bloats:

Hero-image carousel above the menu

A full-bleed carousel above the menu pushes the actual content below the fold, adds two-to-four seconds of load time, and almost never gets the second click. The menu is the page’s hero. A single still image or a tight color block sets the tone; a carousel costs you the visitor.

Photos on every dish

Photos on hero dishes (5–10 items per menu) earn their weight. Photos on every dish add page weight, force ranking decisions you don’t want to make (“why is the burger photographed and the wedge salad isn’t?”), and hide the items you actually want to push. Pick the 5–10 dishes you’re proudest of, photograph them well, and let typography carry the rest.

Marketing copy in dish descriptions

“A symphony of flavors” is not a description. “House-pulled mozzarella, San Marzano, basil oil, 90-second oven” is. Diners skim, they don’t read essays, and they trust specificity over adjectives. Kitchen-floor voice wins every time.

Reservation widgets embedded in the menu page

A full OpenTable or Resy widget loaded into the menu page adds a heavy third-party script, blocks scroll on mobile, and competes with the menu for attention. Link to the reservation page from a sticky button or a section CTA, but don’t embed the widget itself. The menu page’s job is to make the diner want to come in; the reservation page’s job is to capture the booking.

Mobile is the primary canvas

Eighty percent or more of menu views happen on a phone. A menu designed primarily for desktop and “checked” on mobile is a menu that fails most of its visitors.

The mobile rules are simple. Thumb scroll only — no horizontal scroll, no carousels, no tap-to-zoom dish images. Categories collapse to anchor links at the top of the page so diners can jump to a section in one tap. Prices stay on the same line as the dish name, even at the narrowest viewport, so the diner never has to scroll to find out what a dish costs. The menu page is the bridge between the homepage decision and the order action — see our breakdown of online ordering vs reservations on the homepage for the upstream side of that flow. The menu is where the diner commits to coming or ordering, and on mobile, friction is the only thing standing between them and the tap.

How multi-location operators handle the menu page

For operators running more than one unit, the menu page raises one extra question: shared or per-location?

• Shared menu — one URL at /menu/, linked from every location page. Right when the menu is identical across locations (same items, same prices, same availability).
• Per-location menu — one URL per location, e.g. /locations/sawtelle/menu/ and /locations/melrose/menu/. Right when menus actually differ, even on a few items or a few dollars.

The mistake to avoid is cloning the same menu under multiple URLs to “boost SEO.” Duplicate content hurts more than it helps, and Google picks one to rank and buries the rest. If the menus are the same, link the shared one from every location. If they differ, give each its own page with its own schema. The multi-location restaurant website structure post walks through the URL patterns and schema relationships in more depth.

Schema patterns we ship every menu against

The Menu → MenuSection → MenuItem graph is the schema pattern we ship on every menu page. It gives Google a structured map of what you serve, at what price, in which category, with which dietary tags. A lean example:

{
  "@context": "https://schema.org",
  "@type": "Menu",
  "name": "Dinner Menu — Brand Name",
  "url": "https://www.brand.com/menu/",
  "hasMenuSection": [
    {
      "@type": "MenuSection",
      "name": "Starters",
      "hasMenuItem": [
        {
          "@type": "MenuItem",
          "name": "Bone Marrow",
          "description": "Bone marrow, salsa verde, charred shallots, toasted sourdough",
          "offers": { "@type": "Offer", "price": "18.00", "priceCurrency": "USD" },
          "suitableForDiet": "https://schema.org/GlutenFreeDiet"
        }
      ]
    }
  ]
}

A few notes on the pattern. name should match the visible heading on the page so search engines can tie the schema to the rendered content. description mirrors the same five-to-fifteen-word description we recommend in the visible UI — keep them in sync. offers.price is a plain decimal string with a separate priceCurrency, not “$18” baked into one field. And suitableForDiet accepts the schema.org diet URLs (GlutenFreeDiet, VegetarianDiet, VeganDiet, etc.), which is how search engines learn that your menu serves a specific dietary need.

Wrapping up

The menu page does more work than any other page on a restaurant website. It’s the page diners share, the page Google indexes for dish-level queries, and the page that decides whether a curious visitor becomes a cover. Build it as a real indexable URL, write descriptions like a line cook, categorize the layout, mark up every dish with schema, and design for the thumb before the cursor. Cut the carousel, cut the photos on every item, cut the marketing adjectives, cut the embedded widget. What’s left is a menu that loads fast, reads clearly, and earns the click.

If you’d rather hand the rebuild off, our restaurant website design engagement covers the menu architecture, schema, and ordering integration end-to-end. For a look at the menu and homepage patterns that actually convert in production, see restaurant website examples. And for the broader SEO picture this spoke fits into, the restaurant SEO checklist walks through every on-page signal that compounds with a well-built menu page.