Your menu is the most consulted content on your website: before booking, almost everyone wants to see what is on the plate and at what price. So the question is simple: should you publish your restaurant online menu in HTML or PDF?
The short answer: in HTML, meaning a real web page with text, in the vast majority of cases. The PDF can stay as a printable extra, but it should not be the only version. This guide explains why (mobile readability, indexing, updates, accessibility), how to structure the page and what schema.org and Google say about structured data for a menu. We promise no traffic gain: we describe a method.
Restaurant online menu: mobile readability first
A large share of visitors read your menu on a phone. That is where the PDF is weakest:
- it often opens in another window or app, and the visitor loses track of your site;
- its layout is that of an A4 sheet or a printed menu: you have to pinch and scroll in every direction to read;
- the file can be heavy, especially with photos, and downloads slowly on 4G;
- the text does not adapt to the screen size or to the phone's font settings.
An HTML page, by contrast, adapts to the screen width, loads fast if the images are light, and stays within your site's world with the booking button always within reach. Google also indexes the mobile version of sites (mobile-first indexing) and asks for primary content equivalent to the desktop version. A web page meets that requirement naturally.
For a menu that reads well on mobile:
- a single column, with clear sections (starters, mains, desserts, drinks);
- the dish name in bold, the description in a line or two, the price alongside, with no dot leaders or two-column layout;
- navigation anchors at the top to jump to a section;
- a fixed booking button so nobody has to scroll back up;
- comfortable text size and sufficient touch targets (web.dev recommends roughly 48 × 48 pixels for a tap target, with about 8 pixels between them).
This is one of the mistakes we detail in our article on the 10 restaurant website mistakes.
Indexing: what Google sees of your menu
Google can index PDFs: they appear in its official list of indexable file types. So a PDF is not "invisible". But it raises three concrete problems for a menu.
- A PDF that is only an image (an export of a layout or a scan of the printed menu) contains no text Google can read. Your dishes then cannot be found by name.
- An HTML page links to the rest of the site: booking, private hire, opening hours, the venue page. A PDF is a dead end.
- You control a page's title and description, its address, its subheadings. These help the visitor and the search engine understand what it is about.
Good practice:
- a dedicated page for each menu ("Menu", "Wine list", "Lunch menu"), with a clear title tag and H1;
- the real text of the dishes, not in an image;
- if you keep a PDF, link it from the HTML page ("Download the menu as PDF") rather than the other way round, and update both at once;
- in your Google Business Profile, point the menu link to the HTML page (see our guide to the Google profile);
- for a multilingual site, a menu page per language, with its own hreflang tags, as explained in our guide to the multilingual restaurant website.
Updates: the menu changes, the site must follow
A menu is alive: seasonal products, a dish sold out, a price change, the lunch menu. With a PDF, every change means reopening the source file, exporting, replacing the file and hoping nobody kept the old version in their bookmarks or emails. In practice, the PDF is often behind.
With an HTML page managed from a simple back office, the person on the floor or in the kitchen edits a line and publishes. That is the whole point of a site where the team can change menus and events on its own.
Organise the updates:
- appoint one person in charge of the online menu, with a deputy;
- set a rhythm (each service for the daily menu, each season for the main menu);
- keep a visible last-updated date if your menu changes often;
- remove old PDFs from the site and your other materials: they keep existing and being found;
- check that the displayed price is still the current tax-inclusive price, identical on the site, on the Google profile and in the dining room.
Accessibility: a menu everyone can read
An online menu must be readable by people who use a screen reader, enlarge text or have low vision. Here again, HTML has the edge:
- a PDF made from an image is not text: a screen reader has nothing to read;
- an HTML page carries structure: heading levels, lists, a logical reading order;
- text resizes and reflows with the screen, which is harder with a fixed page;
- dish images get alternative text, and the menu text is never "inside" the photo;
- contrast and font size can be tuned in your stylesheet.
If you keep a PDF, do not rely on it as the only version: a simple visual export generally does not offer this structure.
Note: allergen information and price display obligations fall under regulation. This article does not detail them: check your obligations with the competent authorities before publishing, and make sure the online version matches what is displayed in the dining room.
Restaurant menu structured data: schema.org and Google
Structured data describes your menu to a search engine, in addition to the visible text. Here is what we verified.
In schema.org:
- Restaurant is a type in the FoodEstablishment family, itself a subtype of LocalBusiness. It has, among others, the properties servesCuisine (type of cuisine), acceptsReservations, priceRange and hasMenu;
- Menu also exists as a type: "a structured representation of food or drink items available from a FoodEstablishment". Its own properties are hasMenuSection (a section: by course, by type of dish…) and hasMenuItem (a dish or drink). It inherits name, description and inLanguage;
- a Restaurant's hasMenu (or menu) property accepts a Menu object, text, or the address (URL) of the menu;
- schema.org's examples show a dish with a price (offers, with price and priceCurrency), a compatible diet (suitableForDiet) and nutrition information, and provide for separate menus by language.
At Google:
- its documentation on local businesses recommends using the most specific type (for example Restaurant), in JSON-LD, with the name and address (required), then notably the hours, phone, priceRange, servesCuisine and the menu property with the full URL of the menu;
- it asks that markup match what is visible on the page, and states that following the guidelines does not guarantee enhanced display;
- at the time of writing, we found no rich result dedicated to menu dishes in this documentation. So mark up dishes to describe your content correctly, not to obtain a particular display.
A reasonable approach:
- useful minimum: Restaurant markup with the menu property pointing to the URL of your menu page;
- fuller version, if you can maintain it: a Menu with its sections and dishes (name, description, price in euros), keeping the same texts as the page;
- one menu per language, with the language set on each Menu;
- never mark up a dish that is no longer served, nor a price different from the one displayed: outdated markup is worse than none.
Check the result with the schema.org validator.
Checklist: publishing your menu online in HTML
- a dedicated menu page per menu and per language, with a clear title;
- all text as real text (dishes, descriptions, tax-inclusive prices);
- a structure in sections, readable on mobile without zooming;
- a booking button that is always visible;
- regulatory mentions checked (allergens, prices);
- an optional printable PDF, linked from the page and updated at the same time;
- a person responsible for updates and a last-updated date;
- the menu link filled in on the Google Business Profile;
- Restaurant markup with menu (and, if you maintain it, Menu) consistent with the visible page.
Restaurant online menu: frequently asked questions
Should I delete the PDF menu?
Not necessarily. Keep it as a printable version if you have a use for it, but make the HTML page the reference version, link the PDF from that page and update both at once. A PDF alone hurts mobile reading and updates.
Does Google index a PDF menu?
Yes, Google can index PDFs; they are on its list of indexable file types. But if the PDF is just an image of the menu, there is no text to read. An HTML page with the dishes as text is more reliable and better connected to the rest of the site.
Should I add Menu structured data to my menu page?
It is not mandatory. At a minimum, mark up your venue as a Restaurant with the menu property pointing to the menu page. schema.org's Menu type lets you describe sections and dishes, but we found no dedicated rich result in Google's documentation: do not expect a guaranteed effect.
How do I handle a menu that changes every day?
Use an HTML page your team can edit from a simple back office, with a named owner. Avoid producing a new PDF for every service: show the update date and keep one single address for the menu.
Need help publishing your restaurant's online menu?
A well-made online menu reads well on mobile, updates in two minutes and stays consistent everywhere: site, Google profile, dining room. When menus, languages and venues multiply, it quickly becomes a real project.
māhie builds Webflow sites for restaurants and hotels, with more than 70 sites to our name. For your online menu, we can:
- design the menu page: structure, mobile readability and link with booking;
- set up a simple back office, so your teams edit menus and events on their own;
- handle several languages, with one menu per language and clean SEO;
- take care of SEO and performance: a fast, well-indexed, measured page;
- add Restaurant markup and tie it to your Google profile, consistent with the visible content.
Discover our websites for restaurants and hotels, then Contact māhie: we review together how to publish your menu.
