Someone looking for a restaurant on their phone wants to know three things: what there is to eat, whether it's open, and how to order or book. Over the last few days I built or reworked three restaurant demo sites, a sushi restaurant in Lisbon, a takeaway grill house in Torres Vedras and a pizzeria in the Algarve, and all three ended up revolving around those questions. None of them is a client; they are examples I made on my own initiative.
The menu is a page, not a PDF
The sushi restaurant kept its whole menu in a 25-page PDF stored on Google Drive. On a phone, that means downloading a heavy file, pinching to zoom and scrolling back and forth. And anyone who searches Google for the restaurant's name plus "menu" finds nothing, because that PDF doesn't show up in search.
In the demo, the menu became an ordinary page: 142 dishes in 24 categories, transcribed from the restaurant's own PDF, with dish photos cropped from the same document. A few decisions made the difference:
- Live search. Type "salmon" and the list filters as you type, ignoring accents and capitals.
- Each dish's reference. At that restaurant you order by writing the dish code on a pad. So every dish shows its code, and search matches on the code too.
- It works without JavaScript. Search is an extra. If it doesn't load, the whole menu is still there, readable, with its categories.
- Structured data. The page describes the menu with schema.org's
Menu,MenuSectionandMenuItemtypes, so search engines understand what each thing is.
A note on QR code menus on the tables: the QR code isn't the problem, the destination is. If it points to a PDF, the customer gets the same poor experience, just sitting down. If it points to a page like this one, it works.
Put what works first
At the grill house, the site exists for one thing: calling to order. Both numbers were on the page, but the landline came first everywhere. That landline is the one the owners themselves announced on Facebook as out of order, asking customers to call the mobile instead.
On a site like that, the first number shown has to be the one that answers. The mobile now leads in every button, in the contact list, in the footer and in the structured data. The landline is still there, labelled, because Google still lists it and it may come back.
Ordering with a pick-up time
The demo also has an order-ahead page: choose what you're taking, the day and the time, and pay at the counter. The hours are the place's real ones: closed on Tuesdays, lunch only on Sundays, and you can't book for ten minutes from now, only at least half an hour ahead. The prices and total are sample figures, and at the end the page says plainly that no order was created. On a real site, the order would reach the counter and be confirmed to the customer.
The point isn't the technology. It's that someone ordering at lunchtime doesn't have to hang on an engaged phone line, and the kitchen gets orders in sequence, with a time attached.
The category bar, and the small bugs that break it
On a long menu, a category bar that stays pinned to the top as you scroll is what makes the page usable: tap "Desserts" and you jump there. It sounds simple, and it breaks easily.
On the sushi demo, the bar disappeared under the fixed notice that all my demos carry at the top. A fixed element and a sticky element compete for the same space, and the margin that pushes the page down isn't enough to keep them apart. The fix was for the notice to publish its height as a CSS variable and for the bar to pin itself just below it, on desktop and on mobile.
On a real restaurant site, the same thing happens with a fixed header, a cookie notice or an order bar. Three things are worth checking on a phone:
- The category bar stays visible as you scroll.
- Tapping a category doesn't leave its heading hidden under the bar (fixed with
scroll-margin-top). - The bar scrolls sideways when the categories don't fit on screen.
A menu in two languages
In Lisbon, the Algarve or anywhere with tourists, an English menu isn't a luxury. The sushi demo has its menu in Portuguese and English, with a language switch at the top and the right signal to search engines that the two pages are the same menu in different languages. Two rules: dish names that don't translate stay as they are, and prices and codes are the same in both versions.
Prices: only the ones you can stand behind
At the pizzeria, the price list the restaurant itself had published contained obvious errors. Putting those prices on the site would repeat the problem. The demo kept the real dish names and a line saying prices are confirmed at the restaurant. It isn't ideal, but it beats a wrong price the customer will argue about at the counter.
What the owner must be able to change alone
A menu changes. A dish goes, another comes in, the price of chicken goes up. If every change means calling whoever built the site, the menu is out of date within months, and an out-of-date menu is worse than none.
So before handing over a restaurant site, it's settled how the owner changes at least these things on their own: dishes, prices, opening hours and the "closed for holidays" notice. There are several ways to do it, from WordPress to something simpler built to measure. What can't happen is finding this out after the site is live. The hours also need updating on the Google Business Profile, which lets the owner edit the menu and hours, so the two say the same thing.
In short
- The menu on a page you can read and search on a phone, not in a PDF.
- The phone number that answers, and a way to order, always in sight.
- A category bar that actually works on a phone.
- English, if you get tourists.
- Only prices you can confirm, and an owner who can change them.
If you run a restaurant, a grill house or a takeaway and want a menu like this, get in touch.