The menu is a web page
Not a PDF, not a photo of a printed card. Real text with real prices, so it can be read on a phone, searched by Google, and updated without a designer.
A restaurant website has an unusually specific visitor: someone on a phone, often nearby, often right now, who wants the menu, the price range, whether you are open, and how to get there. Four things.
Almost every restaurant site in India fails on the first one, because the menu is a PDF. That single decision makes the most wanted page on the site unreadable on the device almost everyone is using, and invisible to search.
0 layouts in this category.
No layouts in this category yet
Put the image in public/assets/lander/ and add an entry to src/data/landers.ts with its real pixel width and height.
Not a PDF, not a photo of a printed card. Real text with real prices, so it can be read on a phone, searched by Google, and updated without a designer.
These are the two things being checked most often. They should be visible without scrolling and without tapping into another page.
A link that opens the native maps app with directions is what people want. An embedded iframe is heavy, often blocked, and still needs a second tap.
Stock images of generic dishes read as a template and raise suspicion. A phone photo of what you actually serve outperforms a polished picture of something you do not.
Call, order, or book — pick the one you want most and make it a button that is visible on every screen.
It pinch-zooms badly, costs data, cannot be updated quickly, and keeps your dish names out of search entirely.
It is startling on a phone in public and is the fastest way to get the tab closed.
Hiding prices does not raise perceived value, it loses the visitor who was deciding on budget — which is most of them.
If ordering goes through an aggregator, link it. Silence is read as no.
These are the requirements a layout copied from a US or European template does not have, and they decide more conversions here than any styling choice.
This is the first thing scanned on an Indian menu and it is a filter, not a detail. Use the standard green and brown marks next to each item rather than a legend at the bottom, and mark Jain availability where you offer it. A menu that forces someone to call and ask has already cost you the call.
A simple one-to-three indicator removes a real hesitation and prevents the complaint that follows. It costs one character per row.
Many outlets take direct orders on WhatsApp and it undercuts the aggregator commission entirely. Pre-fill the message with the outlet name and the menu URL so the customer is not typing their order from memory.
Pick inclusive or exclusive and say which at the top of the menu. A bill that is 5% higher than the page said is a complaint at the table.
If you are on the delivery apps, link them — that is where a hungry visitor expects to go next. Keep your own ordering option above them so the commission-free route is the first one seen.
Yes, for two reasons. The aggregator owns that customer relationship and takes a commission on every order, and a site you own is where dine-in enquiries, bookings, catering and hiring arrive. The apps are a sales channel, not a presence.
No. A PDF is the most common and most costly mistake on restaurant websites. It reads badly on phones, cannot be updated without the original file, and keeps your dishes out of Google. Put the menu in the page as text.
What kind of food, where you are, whether you are open, and the menu link. A full-screen photograph with the name over it looks good and answers none of those.
A verified Google Business Profile with correct hours and photos does most of the work, and the website supports it by carrying the same name, address and phone number as plain text, plus the menu in a form Google can read.
A layout is the easy half. The rest is the build, the hosting it runs on, and the renewal price nobody shows you at signup.