Answer in brief
A restaurant does not need a large site — it needs five screens that open on a weak signal and do not lie about opening hours. Here is what belongs on the first screen, why the menu is never a file, and how to accept the work in fifteen minutes.
Why a restaurant needs a site when maps and social exist
The objection sounds reasonable: a map listing brings people in, a social account shows the dishes, an aggregator takes orders. Why maintain another page on top of that.
The answer is practical. The listing and the account belong to platforms: rules change, reach gets cut, an account can be lost over a violation you learn about afterwards.
A site is the only place where you decide what a person sees first, and the only source maps, aggregators and search engines draw your hours, address and menu from when they reconcile data.
And it is cheaper than it sounds, because the job is narrow. A restaurant does not need a large site; it needs five screens that load fast and do not lie about opening hours.
What people are actually looking for
A visitor arrives at a restaurant site with one of four questions: where you are, when you are open, what you serve and how to book. Everything else is secondary.
That means address, hours, menu and a way to make contact have to be visible without scrolling and without navigating. Not in the footer, not on a separate contacts page, not in a caption under a photograph.
The most common mistake is a large beautiful full-screen splash with all the useful information hidden behind it. Somebody standing on the street with a phone will not scroll that far.
It is easy to check: open the site on a phone and time how long it takes to find the phone number. More than five seconds means the design is solving the wrong problem.
The menu: why a PDF is the worst option
A menu published as an image or a file feels convenient: the printer supplies it and nobody has to lay it out. On a phone it becomes an unreadable sheet that has to be pinched and dragged.
Besides the inconvenience there is a technical one: a file is a separate document, not a page of your site. Even where a search engine reads the text inside it, the visitor lands on a download rather than on your page, and structured data, internal links and a booking button have nowhere to sit. If the menu is published as an image, there is no text in it at all.
The menu has to be text on a page: sections, names, short descriptions, prices. Then it reads on any screen, it can be updated in a minute, and it gets indexed.
A separate question is accuracy. A menu that disagrees with what is served is worse than no menu: a person arrives for a specific dish and leaves disappointed.
Booking: one button instead of a form
An eight-field booking form is the most reliable way to lose a guest. They want a table for two at eight tonight, not to fill in a questionnaire.
The minimum that works is date, time, number of guests and one way to reach them. Everything else gets settled by phone or message, and that is faster than a field in a form.
On a phone a call button often beats any form, because tapping it dials immediately. It is worth keeping visible all the time rather than only on the first screen.
If booking runs through an external service, check how it looks on a phone and which language it speaks. A guest does not distinguish your site from somebody else's widget and will complain to you.
Photographs: what almost everyone is missing
Everyone has shots of the food, and they are almost always taken from above on a white plate. They are not enough to decide on, because a person is not only choosing a dish.
The room is missing. A guest wants to understand where they are going: loud or quiet, bright or dim, whether jeans are fine, whether a party of six will fit.
The entrance is missing. A photograph of the door and the sign from the street saves a guest five minutes of wandering, especially if the entrance is off the main street or in a courtyard.
And scale is missing. A portion shot close up looks identical at any size, while a person wants to know whether one dish is a meal or whether they should order two.
The first screen
Four things belong on the first screen: what you are, where you are, when you are open and what to tap. All of it fits without scrolling even on a small phone.
"What you are" is one line, not a slogan. "Neapolitan pizzeria in the old town" works; "Where flavour is born" does not, because it answers none of the questions.
An "open now" status is worth more than a list of hours. People rarely work out in their head whether they fall inside a window, and the mistake costs them a journey.
And one action, not five. The booking or call button has to be visibly primary; menu, delivery and social come after it and smaller.
The mobile version is the main one
A restaurant site is viewed on a phone, on the street, one-handed and often on a weak signal. That is not "the mobile version", it is the main scenario, and desktop is the exception.
Hence the requirements: large buttons a thumb actually hits, text that reads without zooming, and a page weight that opens on a slow connection.
A heavy video on the first screen is the most common source of trouble. It looks beautiful in the supplier's presentation and is painful on mobile data near a station.
Testing has to happen on a real phone on a poor connection, not in a browser window shrunk with a mouse. The difference between those two tests is roughly the whole difference between a working and a broken site.
Several locations and one listing
As soon as there are two locations the mistakes start: one address in the footer, one menu, one set of hours. A guest turns up at the wrong place or at a closed room.
The right structure is a page per location with its own address, hours, phone and photographs of the room. Even when the menu is shared, the pages have to differ.
The same applies to maps: each location has its own listing, and it links to its own page rather than the home page. Otherwise the data about the locations gets mixed.
What stays on the home page is choosing a location — a plain list with the district and the nearest station, not a map that loads slowly and fails without a connection.
Delivery and pickup: where the site ends
Building a delivery system on the site is usually not worth it for a small venue. Aggregators have already solved logistics, payment and refunds, and competing with them through an order page is hard.
The sensible role for a site is being a fork in the road. Clear buttons to the aggregators you are on, and a separate button for pickup, which you handle yourself and which costs you less.
If pickup really is better for you, say so in words: how long the wait is, where to collect, whether there is a discount. A guest chooses on clarity, not on your margin.
And keep the aggregator list current. A button to a platform you have already left is the same mistake as stale opening hours, only more visible.
The text people actually read
Almost nobody reads a long history of the venue, and that is fine. What gets read are captions: under a photograph, next to a price, beside a button.
So specifics in the right places are more useful than a paragraph of philosophy: "sourdough, 48 hours", "high chairs available", "parking in the courtyard", "dogs welcome".
Each of those facts removes an objection that would have kept somebody away. A dozen of them add up, and they are worth more than any text about passion for the product.
The philosophy can stay too, only lower down and shorter. It works on people who have already decided to come and want confirmation they chose well.
What makes a restaurant visible in search
Map listings bring a restaurant people who never reach the site at all, and they deserve the same seriousness: hours, photographs, category, phone, a link to the right page.
From the site's side, structured data helps — a machine-readable statement that you are a restaurant, where you are and when you open. That is what search engines display directly in results.
The second is agreement between sources. Address, phone and hours have to be identical everywhere: on the site, in maps, in aggregators. A discrepancy lowers the systems' confidence in your data.
And the third is pages for the way people search. "Terrace", "breakfast", "private dining for twenty" are separate questions, and a separate page answers them better than a paragraph on the home page.
How to accept the work: A restaurant does not need a large site — it needs five…
Start the check on a phone on a poor connection. It opened in a reasonable time, the number was found immediately, the menu reads without zooming — the three main points are passed.
Then reconcile the data: the hours on the site, the hours in map listings and the hours on the door have to match. That is the most common and most expensive error.
Test booking all the way through, not as far as the button. Send a real request and see whether it arrived and how quickly it was answered.
And ask for the credentials and sources: the domain, the site's admin, the photographs at full resolution. Without them the next menu change turns into a new project.
Practical checklist
- Put address, hours, menu and contact on the first screen without scrolling.
- Move the menu out of a file into text on a page, with sections and prices.
- Cut the booking form to date, time, number of guests and one contact.
- Shoot the room, the entrance from the street, and a portion beside a familiar object.
- Give every location its own page and its own map listing.
- Reconcile the hours on the site, in maps and on the door on the same day.
Questions and answers
Does a restaurant need a site if it has a map listing?
Yes, because the listing belongs to the platform and the site belongs to you. The site decides what a person sees first, and it is the source maps, aggregators and search engines draw your hours, address and menu from when they reconcile data.
Can the menu be published as a PDF?
Technically yes, practically no. On a phone such a menu has to be pinched and dragged, and a file is a separate document rather than a page of your site: the visitor lands on a download, with nowhere for structured data or a booking button. Published as an image it carries no text at all. The menu has to be text on a page.
How many fields should a booking form have?
Four: date, time, number of guests and one way to reach them. The rest is faster to settle by call or message. On a phone a call button often works better than a form, because tapping it dials immediately.
What does a site like this cost at VITON13 for “Website Design for a Restaurant: Five Screens That Decide Everything Else”?
Design runs as packages: Brand Sprint at $120 over 1–2 working days with two revision rounds on the chosen direction; Launch Landing at $290 over 3–5 working days with two rounds after the first full layout; Product Identity System at $540 over 5–8 working days with three rounds across the system. The exclusions differ by package: Brand Sprint leaves out copywriting and photography, Launch Landing leaves out development, and Product Identity System leaves out printed production and its artwork. For this case, the decision criterion is specific: A menu as a file is unreadable on a phone and invisible to search — it has to be text on a page.
What should we do with several locations?
A page per location with its own address, hours, phone and photographs of the room, even when the menu is shared. Each location gets its own map listing pointing at its own page rather than the home page, or the data about the locations gets mixed.